 |
eXeL@B —› Вопросы новичков —› Распаковка длл |
| Посл.ответ | Сообщение |
|
|
Создано: 20 мая 2009 11:30 · Личное сообщение · #1 Что лучше восстанавливать сначала релоки или импорт?  |
|
|
Создано: 20 мая 2009 16:54 · Личное сообщение · #2 Релоки можно делать только на готовой дллке если нет таблички релоков |
|
|
Создано: 20 мая 2009 17:49 · Личное сообщение · #3 Вообще говоря, разницы нет, что тыкать в первую очередь. Лично я предпочитаю импорт, потом релоки. Полагаю, топик можно закрыть. |
|
|
Создано: 20 мая 2009 19:56 · Личное сообщение · #4 Archer пишет: Полагаю, топик можно закрыть Подожди, не торопись. Спрошу тоже, под руку  Распаковывал я DIVX после аспра 1.23 (проосто доставала своими исключениями при запуске нужной мне программы, переключаться в Оле тоже надоело).
Так вот, релоки я никак не восстанавливал, просто поправил у них RVA и размер в Directories. Распакованная DLL нормально работает, вопрос в том, будет ли она работать на других компах и в других ОС. Что-то я запутался в этом. |
|
|
Создано: 20 мая 2009 21:15 · Личное сообщение · #5 Возьми да попробуй на другой ОС, на варе поставь. Вообще надо бы иметь пару разных ОС под рукой. Или как минимум подгрузи по другой базе и проверь, будет ли работать. Аспр не трогает релоки, насколько я помню, стало быть, есть надежда, что ты попал, и работать будет нормально. Если бы уничтожал релоки-пришлось бы восстанавливать тулзами, а не просто вбивать адрес уже существующих. |
|
|
Создано: 21 мая 2009 03:15 · Личное сообщение · #6 Archer пишет: Вообще говоря, разницы нет Разница есть |
|
|
Создано: 21 мая 2009 18:16 · Личное сообщение · #7 Нууу... эээ... как бы пояснить неплохо на примере, в каких случаях есть разница, может, я что-то упустил. |
|
|
Создано: 21 мая 2009 21:18 · Личное сообщение · #8 Я правильно понял, что если остались старые релоки - новые создавать не нужно? |
|
|
Создано: 21 мая 2009 21:23 · Личное сообщение · #9 Смотря какие старые, старые могут быть от самого пакера, а могут быть и от проги, которые лежат в памяти, а пакер просто не затёр. Короче, с умом тоже надо. |
|
|
Создано: 21 мая 2009 22:41 · Поправил: Nightshade · Личное сообщение · #10 pavka пишет: Archer пишет: Вообще говоря, разницы нет Разница есть Как делаешь ты? И такая мысль Допустим импрек перестроил таблицу импорта на новые адреса импорт например выглядит как call dword ptr [const] Импрек перебьет константы, но при загрузке длл адреса изменятся и тут должны сработать релоки. получается что если сначала забить релоки, а импорт восстановить в новую секцию, то после загрузки длл все вызовы импорта будут идти лесом, т.к. релоки были настроены на другие константы. Я правильно думаю? Или релокам все равно на эти константы и они просто добавят (вычтут) разницу image base от константы? |
|
|
Создано: 22 мая 2009 00:14 · Поправил: Konstantin · Личное сообщение · #11 Допустим импрек перестроил таблицу импорта на новые адреса импорт например выглядит как call dword ptr [const] Импрек перебьет константы, но при загрузке длл адреса изменятся и тут должны сработать релоки. получается что если сначала забить релоки, а импорт восстановить в новую секцию, то после загрузки длл все вызовы импорта будут идти лесом, т.к. релоки были настроены на другие константы. Нет, все будет нормально. Релоки - это всего лиш "списoк адресов", в которых надо сделать изменения. Т. е. при загрузки проги в память считается смещение типа Image base(по которому прога загружена в память) минус Original Image base (из pe - заголовка). Это смещение прибавляется к const-е лежащей по адресу взятому из "списка адресов". Поэтому как не меняй const-у импреком смещение к ней добавиться одно и тоже. |
|
|
Создано: 22 мая 2009 03:19 · Личное сообщение · #12 О чем идеть речь ? Что значит востановить релоки? Найти оригинальную табличку если она есть и прописать в хидере соответствющие значения? Если есть табличка и ты востанавливаешь код до исходного то этого достачно Делать релоки если нет таблички возможно только на готовой к употреблению длл т.е с импортом экспортом и т.д |
|
|
Создано: 22 мая 2009 14:00 · Личное сообщение · #13 pavka В файле нет релоков. Допустим у меня есть дамп распакованной длл. И есть дамп второй распакованной длл по другому image base. Импорт и релоки еще не прикручены и их нет в файле. Почему нельзя к дампу сначала прикрутить релоки, а потом импорт? Я так понял что разницы нет. Но ты говоришь обратное... |
|
|
Создано: 22 мая 2009 16:45 · Поправил: pavka · Личное сообщение · #14 Nightshade пишет: В файле нет релоков. Допустим у меня есть дамп распакованной длл. И есть дамп второй распакованной длл по другому image base. Потому что я не знаю какой ты протектор распаковываешь и какой у тебя импорт Nightshade пишет: Что лучше восстанавливать сначала релоки или импорт? При востановлении импорта во многих протах, не хило меняется секция кода по этому делание релоков сизифов труд ..Сответственно делать релоки тогда, когда уверен что ни чего менять в коде не будешь
Все это относится не только к импорту но спласингу, реплейсу и прочей лабуде |
|
|
Создано: 24 мая 2009 22:08 · Личное сообщение · #15 Похоже, Nightshade разобрался со своим вопросом, поэтому я снова влезу со своей DIVX. Вобщем, как и сказал Archer, оригинальные релоки аспр1.23 не трогает, т.к. сам правит ими распакованный код. Для того чтобы заставить DIVX грузиться не по своей базе (1000 0000), мне пришлось переделать базу на это значение у другой dll. Есть ли простой способ загрузить dll не по своей базе, если ее адрес в памяти всегда свободен (под Олей, например)? |
|
|
Создано: 24 мая 2009 23:15 · Личное сообщение · #16 SVLab пишет: Есть ли простой способ загрузить dll не по своей базе, если ее адрес в памяти всегда свободен VirtualAlloc с первым параметром - адресом, который нужно зарезервировать (естесственно до загрузки длл) ----- EnJoy! |
|
|
Создано: 24 мая 2009 23:31 · Личное сообщение · #17 SVLabЕсть утиль от DrGolova называется DLL Rebaser перестраивает dll под другую базу может стоит её попробывать? ----- Чтобы правильно задать вопрос, нужно знать большую часть ответа. Р.Шекли. |
|
|
Создано: 25 мая 2009 01:17 · Личное сообщение · #18 Jupiter Будем знать, спасибо. MEM_RESERVE? ClockMan Да, я ею и пользовался. Имелось ввиду не меняя саму dll. Например, проверить, нормально ли работают релоки. |
|
|
Создано: 25 мая 2009 08:51 · Личное сообщение · #19 можешь после получения памяти чо-нить записать в первую страницу - и убедиться, что данные записаны тогда ты можешь быть уверен, что адрес тобой занят ----- EnJoy! |
|
|
Создано: 25 мая 2009 10:41 · Личное сообщение · #20 Лучше MEM_COMMIT, но можно и MEM_RESERVE-разницы нет, память занята в любом случае, лоадер виндовый не станет туда мапить длл. Твоя задача-занять дефолтный адрес, а как занять-пофигу, можешь выделить память, можешь замапить туда свою длл, вариантов много. |
|
|
Создано: 25 мая 2009 14:22 · Личное сообщение · #21 Jupiter пишет: можешь после получения памяти чо-нить записать в первую страницу - и убедиться, что данные записаны Не будет ли это лишним? в EAX видно ведь, что возвращается. Archer MEM_COMMIT не работает без предварительного резервирования. Или я ошибаюсь? Возник еще вопрос. Такой способ можно использовать, если dll подгружается после запуска программы или по мере надобности. Т.е., загружается в Олю программа, резервируется нужная память, программа отпускается и грузит dll в новый адрес. А как быть, если библиотека импортируется? Ведь она будет уже в памяти еще до того, как Оля встанет на EP программы. |
|
|
Создано: 25 мая 2009 14:47 · Личное сообщение · #22 Если нулевой адрес, можно сразу MEM_COMMIT, почитай мсдн, короче, там написано. Ну возьми запихай в импорт сперва свою либу по тому же адресу или убери из импорта и подгрузи её руками, тебе же не вечно так делать надо, а поиграться разок и всё. Если грузишь сторонней софтиной, при запуске спящего процесса либа ещё не замаплена. |
|
|
Создано: 26 мая 2009 19:57 · Личное сообщение · #23 Archer Ну, MEM_COMMIT с нулем не подходит для моей задачи, нужен ведь конкретный адрес. Ладно, с этим все понятно, нашелся даже плагин для Оли, выделяющий указанный участок памяти. А дальше твои мысли от меня ускользают. Archer пишет: Ну возьми запихай в импорт сперва свою либу по тому же адресу Имеется ввиду библиотека, которая должна сбивать со своей базы ту, которую нужно проверить? Если так, встает вопрос о порядке загрузки в память импортируемых dll. Грузятся ли они так, как прописаны в импорте? Добавить легко можно только в конец, в середину или в начало сложнее, но, в принципе, наверное, осуществимо. Archer пишет: убери из импорта и подгрузи её руками Сэмулировать импорт вручную - еще более нетривиальная задача. Загрузить библиотеку, найти все адреса ее функций, где-то прописать их и перенаправить туда все вызовы. Я ничего не упустил? Даже если ничего, слишком много кода. Archer пишет: Если грузишь сторонней софтиной, при запуске спящего процесса либа ещё не замаплена Совсем не понял. Имеется ввиду какой-то загрузчик для проги или что-то еще? |
|
|
Создано: 26 мая 2009 21:19 · Личное сообщение · #24 Про порядок загрузки длл, думаю, что в порядке следования в импорте (с учётом зависимостей), но не уверен, настаивать не буду. Подгрузка либы руками и заполнение её импорта не так уж и тяжко, парсинг таблички в цикле и вызов GetProcAddress. Я говорю, смотря откуда вызываешь. Если через лоадер грузишь, можно процесс запустить suspended. В этом случае грузи длл-заглушку пустую руками на нужную базу или память аллокай, а потом ResumeThread делай. В любом случае это делать тебе не каждый раз, а просто 1 раз проверить работоспособность, а для этого и не очень красивое решение сгодится. |
|
|
Создано: 26 мая 2009 21:29 · Личное сообщение · #25 Все ясно, спасибо. |
|
|
Создано: 02 июня 2009 11:57 · Личное сообщение · #26 Проще всего изменять порядок загрузки длл и первой ставить свою библу которая займет нужный адрес. CFF Explorer в помощь (в нем так же есть dll rebaser) |
|
|
Создано: 02 июня 2009 13:36 · Личное сообщение · #27 Nightshade Да, это как раз то, что было нужно, спасибо. |
|
eXeL@B —› Вопросы новичков —› Распаковка длл |
Для печати