Всем кто делал загрузчики для программ защищённых аспротектом не вдаваясь в вопросы распаковки и восстановления импорта наверняка приходилось видеть сообщение Protection Error: 15. Решения были в виде патча с небольшой задержкой, что бы аспр успел проверить память. На практике это работало через раз, что совершенно не допустимо в серьёзных проектах. Я задался целью отключить проверку целостности кода, но столкнулся с проблемой. В моём случае нужные места в распакованной программе располагаются в адресах 401000 - 550000, а тело аспра, проверка кода и некоторые места например NAG окна в адресах > B42000. Всё отлично работает и патчится, но только на моём компе. Проблема возникает именно со вторым диапазоном адресов. Посоветуйте как можно вычислять адрес тела аспра или как его заставить всегда оказываться в нужном месте. Или дайте ссылки на описание его работы. В статьях о нём обычно только распаковка - а меня как видите интересует немного другое. tobadko@mail.ru

| Сообщение посчитали полезным:

ToBad
Ну в большинстве случев мне помогал PELG, генератор лоадеров, довольно неполохой, каким-то боком обходил аспр. Про особо новые версии не знаю, но с 2.0. работал ОК.

| Сообщение посчитали полезным:

ToBad пишет:
На практике это работало через раз, что совершенно не допустимо в серьёзных проектах
имхо лоадер и серьёзный проект это вещи несовместимые =) хочешь серьёзности/надёжности - распаковывай, либо инлайн.

| Сообщение посчитали полезным:

чтобы тупо не ждать нужно в лоадере хукать какую-нибудь API используемую ASPr'ом

| Сообщение посчитали полезным:

Mario555 пишет:
имхо лоадер и серьёзный проект это вещи несовместимые =)
Да не всегда...Серьезные кодеры мыслят свои защиты, которые лодятся еще быстрее,чем собственно защита аспра. Скорее другое - аспр и серьезная защита - вещи несовместимые.

| Сообщение посчитали полезным:

В версиях 2.0 aspr.crc.locator убирает проверку! В следущих версиях эту дырку похоже прикрыли !
Но для серьезных проектов это не выход! Проблемы совместимости лоадера с разными осями!

| Сообщение посчитали полезным:

ToBad пишет:
Посоветуйте как можно вычислять адрес тела аспра

Лоадер юзающий debug api. Железный бряк на VirtualAlloc, и ты узнал адрес.

| Сообщение посчитали полезным:

в диапазоне 401000-.. я искал переход типа jmp abcd то есть код E9 x1 x2 x3 x4
ведущий в аспровую память
так вот x1 - не зависит от машины а x2..x4 зависят

| Сообщение посчитали полезным:

r99 пишет:
так вот x1 - не зависит от машины а x2..x4 зависят
Наверно проверял на двух/трёх машинах с одинаковой операционкой из одного дистрибутива ? Теоретически, x1,x2,x3,x4 могут быть любыми.

| Сообщение посчитали полезным:

r99 пишет:
теоретически - ты можешь и неправду сказать
теоретически - да, но фактически твой ответ скорее флуд. Конструктивные замечания с док-вами есть?

| Сообщение посчитали полезным:

Aspr.crc.locator делает тоже самое, к чему стремлюсь я. Просто я это делал руками. Прога интересная, но моя задача упростить этот процесс и делать это на лету во время работы собственного загрузчика.
Вот результат работы aspr.crc.locator на одной и той же программе на 2-х компах:
1) XP Sp0 - 00B426A0
Win98 - 00D126A0
2) XP Sp2 - 00A826A0
Win98 - 012226A0
Вопрос в том, как и по какой причине аспр использует одну и ту же область памяти на конкретном компьютере с конкретной виндой. От чего это зависит ? Почему не разную область во время каждого запуска ? Почему у себя я всегда вижу B426A0 ??? Может кто то знает ответ на этот вопрос ? Помогите понять ! Не от железа же это зависит ?
Сейчас планирую капать дальше испытав варианты предложенные r99 и TOG. Pavka - спасибо за интересную прогу. Очень оказалась кстати.
Вообще всем огромное спасибо за помощь, советы и комментарии ! Ничего не оставлю без внимания !

| Сообщение посчитали полезным:

Можно вычислить смещение относительно вызова из реального адреса...
Типа например:
C твоей машины идет 401000: call B42000
На другой 401000: call B82000
Значить адреса патчей тебе надо править на B82000-B42000=40000h

Если нужно будет могу выслать пример)
А про ожидание: можно например ждать первую форму приложения, если это дельфи то это наверняка TApplication

-----
StarForce и Themida ацтой!

| Сообщение посчитали полезным:

Maximus пишет:
А про ожидание: можно например ждать первую форму приложения

ИМХО это полный отстой. У тебя приложение будет загружаться в 10 раз дольше, а если низкий
приоритет поставишь - будешь пролетать мимо кассы . Лучше отладочные события ловить.

| Сообщение посчитали полезным:

Хто сказал что в 10 раз дольше?

procedure ProcessMessages;
begin
While PeekMessage(Msg, 0, 0, 0, 1) do begin
TranslateMessage(Msg);
DispatchMessage(Msg);
end;
end;
...
Repeat
ProcessMessages;
StartForm:=FindWindow(PAnsiChar(wStart), nil);
Until (StartForm<>0);


-----
StarForce и Themida ацтой!

| Сообщение посчитали полезным:

Maximus пишет:
StartForm:=FindWindow(PAnsiChar(wStart), nil);

Ну вот и посчитай сколько раз будет вызвана эта ф-я . (если вызывать ее часто, те высокий приоритет
у твоего лоадера, то это сильно загрузит процессор и загружаемая прога будет грузиться долго.
А если низкий приоритет лоадеру поставить - редко вызывать ф-ю FindWindow, то она сработает
не в момент создания окна а намного позже и будет уже позняк.)
Я делал через FindWindow, это кранты .

| Сообщение посчитали полезным:

TOG
Сколько же занимает твоя прога то...

Я так подгружал 8 метровую прогу, окошко перехватывалось ВСЕГДА, а за счет того что патчем отключались ненужные проверки, прога грузилась БЫСТРЕЙ с лоадером чем без него...

Короче в любом случае дело твое, я просто попытался помочь...)

P.S: Процессор грузить не будет, думаешь это тут зря?
While PeekMessage(Msg, 0, 0, 0, 1) do begin
TranslateMessage(Msg);
DispatchMessage(Msg);
end;

-----
StarForce и Themida ацтой!

| Сообщение посчитали полезным:

Maximus пишет:
Сколько же занимает твоя прога то...

Дык, проги с протекторами всегда долго грузятся.
А что про загрузку проца...... ты попробуй сделать CreateProcess(lpPhotoshop......), ну или еще
какого нибудь монстра, который и так-то секунд 20 грузится и поставь этот свой цикл с FindWindow -
минут 5 грузиться будет или сработает намного позже.

| Сообщение посчитали полезным: