Столкнулся с тем, что по уроку «Распаковка конверта HASP/HASP_HL/HARDLOCK» от s0cpy не получается снять конверт на проге защищённой HASP HL. Перечитал тему «И снова HASP Envelope». Импорт подгаженный частично. Видимо многие встречались с подобным, но как я понял из темы, вариант восстановления импорта только ручной предлагается. Вопрос в том, есть ли на паблике скрипты облегчающие восстановления импорта после конверта или автоматизирующие всё что делалось ранее в уроке s0cpy ?

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

На паблике скриптов не встречал. В приватах есть.
Вообще конверты HASP HL можно разделить на 2 группы: старые (которые были сделаны инструментами из HASP_HL_CD_1.00 и HASP_HL_CD_1.10) и новые (HASP_HL_CD_1.20 и HASP_HL_CD_1.30).
В "старых" конвертах импорт в определенном месте(сразу после декриптовки секций) чистенький и никаких телодвижений не требуется (все по статье). В "новых" импорт изначально идет загаженным (переходники). Кроме того в импорте новых конвертов есть еще и эмулируемые функции (мне известно как минимум 6 функций, которые эмулируются)

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

ToBad
Восстанови импорт руками. Там не так сложно. Можно полуавтоматизировать

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

AlexVel у меня видимо новый конверт.

Rustem пишет:
Восстанови импорт руками. Там не так сложно. Можно полуавтоматизировать

Как полуавтоматизировать ? Функций которые нужно восстановить около 98. Пытался оттрейсить несколько, получилось на одной... Долго по коду прыгал... На второй не вышло. Основная проблема в том, что в момент вызова второй функции программа переходит в DX режим. Экран 640х480, переключится в отладчик нельзя. Когда уже всё полностью загружено, переключится и восстановить режим можно, но тогда уже не вызываются некоторые функции... Я уже думал как нибудь применить керберос. Например мониторить kernel32, а в Ольге вести лог в файл при обращении к переходникам. Потом смотреть по времени вызова после какого переходника какая была вызвана функция... Хотя гиморно я придумал, жаль что скрипты не пишу и плохо Ольгой владею, всё наверняка проще...

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

У меня есть флешка-видяшка и тутор по снятию НАSP_HL envelоpe.Оба на английском. Могу поделиться.

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

Iron пишет:
У меня есть флешка-видяшка и тутор по снятию НАSP_HL envelоpe.Оба на английском. Могу поделиться.

Давай конечно !

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

Лучше все таки изучить и написать скриптик под Olly. Там ничего сложного нет.
И в дальнейшем пригодится (как скриптик, так и знания).
А вообще скрипт получается очень простой (с объвлением переменных и прочей лабудой всего строк на 50).
Но скрипт не решает проблемы с эмулируемыми функциями.

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

Флешка весит 8 метров,в аттач не влезла.Она на рапиде имеется:

rapidshare.de/files/38454954/HASPHL_ENVELOPE_SCORM.rar.html <--

Если не покатит могу почтой отправить

3ae0_14.03.2008_CRACKLAB.rU.tgz - HASP-HL_CRACK.rar

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

Iron
все это годиться к старые (которые были сделаны инструментами из HASP_HL_CD_1.00 и HASP_HL_CD_1.10) и для конвертов HASP_4...
AlexVel
А вообще скрипт получается очень простой (с объвлением переменных и прочей лабудой всего строк на 50).
ну 50 это че та много... ;)
а с эмулируемыми функами не так все сложно...
в принципе как вариант, ставим бряк на GetCommandLineA (одна из эмулируемых), упали и смотрим, куда будет "записан" результат выполнения функи. Если в тело секции .protect, то это оно... Трассируем дальше - будут выполняться остальные эмулируемые функи, и их результаты будут писаться в область рядом с результатами GetCommandLineA... Ну а потом собственно практически все прозрачно становиться, за исключением GetTickCount кажется (щас на вскидку не помню тонкостей)...

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

Делал так:
Все нераспознанные места в импорте ведут на одну функцию которая большая, сложная и очень замученная. По её ходу если трейсить выполняется много левых функций в нескольких потоках и в итоге пробегает одна искомая. Иногда трейслог проходит за пару секунд и весит несколько десяток килобайт, иногда на 10-15 минут и весит 20-30 мб. Всё одна и таже процедурка. Делал всё очень гиморным способом. На входе в эту процедуру делал переназначение на вызов функции _msg из собственной длл, в параметрах вычислял и передавал адрес ячейки импорта откуда пошол вызов. К процессу цеплял kerberos и мониторил kernel32, user32 и свою dll. По логу смотрел что идёт после вызова моей функции. Таким образом восстановил 35 функций, ещё с 3-4 есть вопросы. Написал скриптик который прописывает в нужное место импорта адреса на найденные функи. Скрипт примерно такой:

gpa "CreateFileA","kernel32.dll"
mov [006840B0],$RESULT
gpa "TlsSetValue","kernel32.dll"
mov [00684130],$RESULT
gpa "LoadIconA","user32.dll"
mov [0068421C],$RESULT


Теперь собственно вопрос. Осталось много не распознанных функций, но они при запуске и моих действиях не выполняются. Если я сделаю дамп и оставлю всё так как есть, то это будет запуск до поры до времени и очень скоро всё сбойнёт. Не знаю как быть. Вот что получилось в итоге, ещё масса функций...
Может можно как то интуитивно где и что идёт в импорте ? Или я не правильным путём пошол ?

00684000 7373FC55 DDRAW.DirectDrawCreate
00684004 7373DBCC DDRAW.DirectDrawEnumerateExA
00684008 00000000
0068400C 73ED4C43 DSOUND.DirectSoundCreate
00684010 00000000
00684014 003B00A0
00684018 77F16000 GDI32.CreateCompatibleDC
0068401C 003B00B0
00684020 77F16E98 GDI32.DeleteDC
00684024 003B00C0
00684028 003B00C8
0068402C 003B00D0
00684030 003B00D8
00684034 003B00E0
00684038 77F161E1 GDI32.GetStockObject
0068403C 003B00F0
00684040 003B00F8
00684044 00000000
00684048 003B0148
0068404C 7C809BF8 kernel32.MultiByteToWideChar
00684050 7C81AB58 kernel32.GetConsoleMode
00684054 003B0160
00684058 003B0168
0068405C 003B0170
00684060 7C80CCA8 kernel32.LCMapStringW
00684064 003B0180
00684068 7C80A490 kernel32.GetStringTypeW
0068406C 7C81CB65 kernel32.WriteConsoleA
00684070 003B0198
00684074 7C83538C kernel32.WriteConsoleW
00684078 7C873FF3 kernel32.GetConsoleCP
0068407C 7C80A427 kernel32.QueryPerformanceCounter
00684080 7C812ED0 kernel32.GetEnvironmentStringsW
00684084 7C814AA7 kernel32.FreeEnvironmentStringsW
00684088 003B01C8
0068408C 7C81D5F7 kernel32.FreeEnvironmentStringsA
00684090 7C834FC7 kernel32.GetTimeZoneInformation
00684094 7C80A0D4 kernel32.WideCharToMultiByte
00684098 7C81109B kernel32.IsValidCodePage
0068409C 003B01F0
006840A0 003B01F8
006840A4 003B0200
006840A8 003B0208
006840AC 003B0210
006840B0 7C801A24 kernel32.CreateFileA
006840B4 003B0220
006840B8 003B0228
006840BC 003B0230
006840C0 003B0238
006840C4 003B0240
006840C8 7C80180E kernel32.ReadFile
006840CC 7C80180E kernel32.ReadFile
006840D0 7C809B47 kernel32.CloseHandle
006840D4 7C80A017 kernel32.SetEvent
006840D8 7C802520 kernel32.WaitForSingleObject
006840DC 003B0270
006840E0 003B0278
006840E4 7C802442 kernel32.Sleep
006840E8 7C809EF1 kernel32.InitializeCriticalSection
006840EC 7C91188A ntdll.RtlDeleteCriticalSection
006840F0 7C9010ED ntdll.RtlLeaveCriticalSection
006840F4 7C901005 ntdll.RtlEnterCriticalSection
006840F8 7C859DCC kernel32.OutputDebugStringA
006840FC 003B02B0
00684100 003B02B8
00684104 7C80B4CF kernel32.GetModuleFileNameA
00684108 003B02C8
0068410C 7C910331 ntdll.RtlGetLastWin32Error
00684110 7C910340 ntdll.RtlSetLastWin32Error
00684114 003B02E0
00684118 003B02E8
0068411C 7C835FE5 kernel32.SetCurrentDirectoryA
00684120 003B02F8
00684124 7C801625 kernel32.DeviceIoControl
00684128 003B0308
0068412C 003B0310
00684130 7C809BC5 kernel32.TlsSetValue
00684134 7C809740 kernel32.TlsGetValue
00684138 7C812D67 kernel32.TlsAlloc
0068413C 003B0330
00684140 003B0338
00684144 7C809915 kernel32.GetACP
00684148 003B0348
0068414C 003B0350
00684150 7C80ADA0 kernel32.GetProcAddress
00684154 003B0360
00684158 7C80B6A1 kernel32.GetModuleHandleA
0068415C 003B0370
00684160 003B0378
00684164 7C80ABDE kernel32.FreeLibrary
00684168 003B0388
0068416C 003B0390
00684170 7C9105D4 ntdll.RtlAllocateHeap
00684174 7C80ABC1 kernel32.GetProcessHeap
00684178 7C91043D ntdll.RtlFreeHeap
0068417C 7C9179FD ntdll.RtlReAllocateHeap
00684180 003B03B8
00684184 003B03C0
00684188 7C80BFAD kernel32.ReleaseSemaphore
0068418C 003B03D0
00684190 7C937A40 ntdll.RtlUnwind
00684194 003B03E0
00684198 7C80929C kernel32.GetTickCount
0068419C 003B03F0
006841A0 003B03F8
006841A4 003B0400
006841A8 7C81015E kernel32.SetUnhandledExceptionFilter
006841AC 003B0410
006841B0 003B0418
006841B4 003B0420
006841B8 003B0428
006841BC 7C812AA6 kernel32.GetVersionExA
006841C0 7C910331 ntdll.RtlGetLastWin32Error
006841C4 003B0440
006841C8 7C809766 kernel32.InterlockedIncrement
006841CC 7C809728 kernel32.GetCurrentThreadId
006841D0 7C80977A kernel32.InterlockedDecrement
006841D4 7C9109ED ntdll.RtlSizeHeap
006841D8 003B0468
006841DC 7C812B7E kernel32.HeapCreate
006841E0 003B0478
006841E4 003B0480
006841E8 7C812F01 kernel32.GetStdHandle
006841EC 7C80CC97 kernel32.SetHandleCount
006841F0 7C810E21 kernel32.GetFileType
006841F4 7C812E3E kernel32.GetCPInfo
006841F8 7C809915 kernel32.GetACP
006841FC 7C81276F kernel32.GetOEMCP
00684200 00000000
00684204 77D3C97C USER32.PeekMessageA
00684208 77D3A8BD USER32.wsprintfA
0068420C 77D3D4FE USER32.DefWindowProcA
00684210 77D44C51 USER32.PostQuitMessage
00684214 003B0020
00684218 77D3EF79 USER32.LoadCursorA
0068421C 77D40946 USER32.LoadIconA
00684220 77D3C02B USER32.SetWindowPos
00684224 77D3B6BE USER32.GetClientRect
00684228 77D38FAD USER32.GetSystemMetrics
0068422C 77D4179F USER32.EnumDisplayDevicesA
00684230 77D4A62B USER32.ChangeDisplaySettingsExA
00684234 003B0060
00684238 003B0068
0068423C 77D3F3C3 USER32.GetAsyncKeyState
00684240 77D38C06 USER32.TranslateMessage
00684244 77D396C8 USER32.DispatchMessageA
00684248 77D3D668 USER32.GetActiveWindow
0068424C 77D3FFA8 USER32.CreateWindowExA
00684250 77D3D8B4 USER32.ShowWindow
00684254 00000000
00684258 76B3BA77 WINMM.waveOutSetVolume
0068425C 00000000
00684260 774EEE46 ole32.CoUninitialize
00684264 774F2A44 ole32.CoInitialize
00684268 00000000
0068426C 10006D80 zlib1.inflateEnd
00684270 100057A0 zlib1.inflate
00684274 10005640 zlib1.inflateInit_


Лог примерно такой получается после обработки:

00684144-VirtualAlloc-GetACP-InterlockedIncrement-GetTickCount-CreateF ileA-LocalAlloc-DeviceIoControl-LocalFree-CloseHandle-CreateFileA
00684108-VirtualAlloc-GetTickCount-InterlockedIncrement-GetTickCount-I nterlockedDecrement-GetTickCount-VirtualFree-QueryPerformanceCounter
006841C0-VirtualAlloc-GetLastError-InterlockedIncrement-GetTickCount-I nterlockedDecrement-VirtualFree-GetProcessHeap-HeapAlloc
006841DC-VirtualAlloc-GetTickCount-InterlockedIncrement-GetTickCount-I nterlockedDecrement-HeapCreate-VirtualFree-GetModuleHandleA
00684138-VirtualAlloc-GetTickCount-InterlockedIncrement-GetTickCount-I nterlockedDecrement-TlsAlloc-VirtualFree
00684138-VirtualAlloc-GetTickCount-InterlockedIncrement-GetTickCount-I nterlockedDecrement-TlsAlloc-VirtualFree-HeapAlloc-TlsGetValue
006841C0-VirtualAlloc-GetLastError-InterlockedIncrement-GetTickCount-I nterlockedDecrement-VirtualFree-HeapAlloc-GetStdHandle
006841B8-VirtualAlloc-InterlockedIncrement-GetTickCount-InterlockedDec rement-VirtualFree
006840D0-VirtualAlloc-GetTickCount-InterlockedIncrement-GetTickCount-I nterlockedDecrement-CloseHandle-VirtualFree-HeapAlloc-HeapFree
0068421C-VirtualAlloc-GetTickCount-InterlockedIncrement-GetTickCount-I nterlockedDecrement-LoadIconA-VirtualFree-LoadCursorA
00684214-VirtualAlloc-GetTickCount-InterlockedIncrement-GetTickCount-I nterlockedDecrement-RegisterClassA-VirtualFree-CreateWindowExA
00684250-VirtualAlloc-GetTickCount-InterlockedIncrement-GetTickCount-I nterlockedDecrement-ShowWindow-VirtualFree-GetLastError


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

Нда. Мы не ищем легких путей, а делаем все через ж..у
Если вызывается АПИ функция, то в некотором месте должен проскакивать ее адрес? Логично ?
Твоя задача просто найти такое место. И автоматом прогнать ВСЕ функции из импорта (всю табличку переходников)
через одну функцию которая большая, сложная и очень замученная (или через другую функцию - которая поменьше и вызывается из этой большой).
Подправляешь, натравливаешь imprec - и у тебя нормальный импорт.
Таким образом восстановишь почти все функции (кроме эмулируемых -коих всего то MAX=6 шт).
А эмулируемые функции уже ручками в imprec назначишь.

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

Посмотри сюда:
00684170 7C9105D4 ntdll.RtlAllocateHeap
00684174 7C80ABC1 kernel32.GetProcessHeap
00684178 7C91043D ntdll.RtlFreeHeap
0068417C 7C9179FD ntdll.RtlReAllocateHeap
00684180 003B03B8
00684184 003B03C0
00684188 7C80BFAD kernel32.ReleaseSemaphore
0068418C 003B03D0
00684190 7C937A40 ntdll.RtlUnwind
видно, что ты криво распознал импорт. функции из ntdll перемешаны с kernel32
Согласись, что это подозрительно. Т.е. наверняка не правильно.
Вообще редкие Ring3 приложения имеют в импорте ntdll
Да и разделения (00000000) между библами не наблюдается, в отличие от
...
00684250 77D3D8B4 USER32.ShowWindow
00684254 00000000
00684258 76B3BA77 WINMM.waveOutSetVolume
0068425C 00000000

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

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


7197_24.03.2008_CRACKLAB.rU.tgz - hhl_env_1.2x_1.3x_iatresolver.rar

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

AlexVel
А вообще скрипт получается очень простой (с объявлением переменных и прочей лабудой всего строк на 50).
s0cpy
ну 50 это че та много... ;)
А у самого-то около 80 строк
Да и у пользователя достаточно спросить только start address of IAT
А то сейчас тебе вопросы посыплются - а что вводить на запросы скрипта

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

AlexVel
А у самого-то около 80 строк - ну поспешил с выводом...
сорри...

Да и у пользователя достаточно спросить только start address of IAT
А то сейчас тебе вопросы посыплются - а что вводить на запросы скрипта
у тех кто с пониманием все делает, я думаю вопросов не должно возникнуть...

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

AlexVel пишет:
Посмотри сюда:
00684170 7C9105D4 ntdll.RtlAllocateHeap
00684174 7C80ABC1 kernel32.GetProcessHeap
00684178 7C91043D ntdll.RtlFreeHeap
0068417C 7C9179FD ntdll.RtlReAllocateHeap
00684180 003B03B8
00684184 003B03C0
00684188 7C80BFAD kernel32.ReleaseSemaphore
0068418C 003B03D0
00684190 7C937A40 ntdll.RtlUnwind
видно, что ты криво распознал импорт. функции из ntdll перемешаны с kernel32
Согласись, что это подозрительно. Т.е. наверняка не правильно.

Я распознавал пока только с kernel32 и user32. В том то и дело, что импорт это оригинальный. Вот он без распознанных функций:

00684000 7373FC55 DDRAW.DirectDrawCreate
00684004 7373DBCC DDRAW.DirectDrawEnumerateExA
00684008 00000000
0068400C 73ED4C43 DSOUND.DirectSoundCreate
00684010 00000000
00684014 003B00A0
00684018 77F16000 GDI32.CreateCompatibleDC
0068401C 003B00B0
00684020 77F16E98 GDI32.DeleteDC
00684024 003B00C0
00684028 003B00C8
0068402C 003B00D0
00684030 003B00D8
00684034 003B00E0
00684038 77F161E1 GDI32.GetStockObject
0068403C 003B00F0
00684040 003B00F8
00684044 00000000
00684048 003B0148
0068404C 003B0150
00684050 7C81AB58 kernel32.GetConsoleMode
00684054 003B0160
00684058 003B0168
0068405C 003B0170
00684060 003B0178
00684064 003B0180
00684068 7C80A490 kernel32.GetStringTypeW
0068406C 7C81CB65 kernel32.WriteConsoleA
00684070 003B0198
00684074 7C83538C kernel32.WriteConsoleW
00684078 7C873FF3 kernel32.GetConsoleCP
0068407C 003B01B0
00684080 003B01B8
00684084 7C814AA7 kernel32.FreeEnvironmentStringsW
00684088 003B01C8
0068408C 7C81D5F7 kernel32.FreeEnvironmentStringsA
00684090 7C834FC7 kernel32.GetTimeZoneInformation
00684094 003B01E0
00684098 7C81109B kernel32.IsValidCodePage
0068409C 003B01F0
006840A0 003B01F8
006840A4 003B0200
006840A8 003B0208
006840AC 003B0210
006840B0 003B0218
006840B4 003B0220
006840B8 003B0228
006840BC 003B0230
006840C0 003B0238
006840C4 003B0240
006840C8 003B0248
006840CC 003B0250
006840D0 003B0258
006840D4 7C80A017 kernel32.SetEvent
006840D8 7C802520 kernel32.WaitForSingleObject
006840DC 003B0270
006840E0 003B0278
006840E4 003B0280
006840E8 7C809EF1 kernel32.InitializeCriticalSection
006840EC 7C91188A ntdll.RtlDeleteCriticalSection
006840F0 7C9010ED ntdll.RtlLeaveCriticalSection
006840F4 7C901005 ntdll.RtlEnterCriticalSection
006840F8 7C859DCC kernel32.OutputDebugStringA
006840FC 003B02B0
00684100 003B02B8
00684104 003B02C0
00684108 003B02C8
0068410C 7C910331 ntdll.RtlGetLastWin32Error
00684110 7C910340 ntdll.RtlSetLastWin32Error
00684114 003B02E0
00684118 003B02E8
0068411C 7C835FE5 kernel32.SetCurrentDirectoryA
00684120 003B02F8
00684124 7C801625 kernel32.DeviceIoControl
00684128 003B0308
0068412C 003B0310
00684130 003B0318
00684134 003B0320
00684138 003B0328
0068413C 003B0330
00684140 003B0338
00684144 003B0340
00684148 003B0348
0068414C 003B0350
00684150 003B0358
00684154 003B0360
00684158 003B0368
0068415C 003B0370
00684160 003B0378
00684164 7C80ABDE kernel32.FreeLibrary
00684168 003B0388
0068416C 003B0390
00684170 7C9105D4 ntdll.RtlAllocateHeap
00684174 7C80ABC1 kernel32.GetProcessHeap
00684178 7C91043D ntdll.RtlFreeHeap
0068417C 7C9179FD ntdll.RtlReAllocateHeap
00684180 003B03B8
00684184 003B03C0
00684188 7C80BFAD kernel32.ReleaseSemaphore
0068418C 003B03D0
00684190 7C937A40 ntdll.RtlUnwind
00684194 003B03E0
00684198 003B03E8
0068419C 003B03F0
006841A0 003B03F8
006841A4 003B0400
006841A8 003B0408
006841AC 003B0410
006841B0 003B0418
006841B4 003B0420
006841B8 003B0428
006841BC 003B0430
006841C0 003B0438
006841C4 003B0440
006841C8 7C809766 kernel32.InterlockedIncrement
006841CC 003B0450
006841D0 7C80977A kernel32.InterlockedDecrement
006841D4 7C9109ED ntdll.RtlSizeHeap
006841D8 003B0468
006841DC 003B0470
006841E0 003B0478
006841E4 003B0480
006841E8 003B0488
006841EC 7C80CC97 kernel32.SetHandleCount
006841F0 003B0498
006841F4 003B04A0
006841F8 003B04A8
006841FC 7C81276F kernel32.GetOEMCP
00684200 00000000
00684204 003B0000
00684208 77D3A8BD USER32.wsprintfA
0068420C 77D3D4FE USER32.DefWindowProcA
00684210 77D44C51 USER32.PostQuitMessage
00684214 003B0020
00684218 003B0028
0068421C 003B0030
00684220 77D3C02B USER32.SetWindowPos
00684224 77D3B6BE USER32.GetClientRect
00684228 003B0048
0068422C 003B0050
00684230 003B0058
00684234 003B0060
00684238 003B0068
0068423C 77D3F3C3 USER32.GetAsyncKeyState
00684240 77D38C06 USER32.TranslateMessage
00684244 77D396C8 USER32.DispatchMessageA
00684248 77D3D668 USER32.GetActiveWindow
0068424C 003B0090
00684250 003B0098
00684254 00000000
00684258 76B3BA77 WINMM.waveOutSetVolume
0068425C 00000000
00684260 774EEE46 ole32.CoUninitialize
00684264 774F2A44 ole32.CoInitialize
00684268 00000000
0068426C 10006D80 zlib1.inflateEnd
00684270 100057A0 zlib1.inflate
00684274 10005640 zlib1.inflateInit_


s0cpy пишет:
скрипт для восстановления импорта (кроме эмулируемых ф-ций) в аттаче...
сначало откройте в каком-нть вьювере и ознакомьтесь. скрипт требует для своей работы некоторую инфу...
возникнут вопросы - пишите...

Большое спасибо !!! Буду изучать и прибывать. О результате отпишу обязательно.

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

Еще раз говорю. В импорте не должно быть ntdll
Например:
006840EC 7C91188A ntdll.RtlDeleteCriticalSection
006840F0 7C9010ED ntdll.RtlLeaveCriticalSection
006840F4 7C901005 ntdll.RtlEnterCriticalSection
На самом деле это (и в таблице импорта они должны выглядеть так):
kernel32.DeleteCriticalSection
kernel32.LeaveCriticalSection
kernel32.EnterCriticalSection
которые просто являются переходниками к ntdll
Я думаю что Imprec тебе их покажет именно в таком виде.

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

AlexVel пишет:
В импорте не должно быть ntdll
Я думаю что Imprec тебе их покажет именно в таком виде.

Да, ты совершенно прав, теперь после импрека импорт без ntdll.

s0cpy - Большое спасибо за скрипт ! Он очень помог. Всё что нужно было скрипту для работы - понял без проблем. Написано доходчиво.

Я хочу поблагодарить всех кто помогал мне советами, туторами, информацией и разумеется скриптом. Очень помогло то, что почти каждый ваш комментарий вселял надежду на то, что задача эта не из ряда сложных и что всё просто. Это помогло не бросить тогда, когда было сложно...
На данный момент дамп снят, импорт восстановлен, лишние секции удалены и жертва работает. Как и сказано было ранее, оставалось 6 эмулируемых функций. Где то по передаваемым параметрам, где то по функциям до и после эмулируемой, я вычислил 5: GetTickCount, GetProcAddress, ExitProcess, GetCommandLineA, GetModuleHandleA. Шестая не вызывается пока, работает всё и без неё. Думаю её будет легко узнать по примерам вызова (если кто знает - намекните):

CALL DWORD PTR DS:[68416C]
TEST EAX,80000000
JB 0061782D

и

PUSH ESI
CALL DWORD PTR DS:[68416C]
MOV ESI,EAX
MOV EAX,DWORD PTR DS:[6B6B68]
TEST EAX,EAX
JE 00617034

00617034 MOV DWORD PTR DS:[6B6B68],1
CALL 006328E6

006328E6 PUSH EBX
PUSH ESI
PUSH 006B7727 ; ASCII "kernel32.dll"
XOR EBX,EBX
JB 00605D89
CALL DWORD PTR DS:[684160] ; kernel32.LoadLibraryA


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

ToBad
CALL DWORD PTR DS:[68416C]
TEST EAX,80000000
JB 0061782D - похоже на GetVersion...

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

s0cpy пишет:
похоже на GetVersion

Да, точно, гугл показал по поиску "GetVersion TEST EAX, 80000000" что это проверка на Win98.

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

Сегодня детально разобрался в работе скрипта и потренировался поделать это вручную. Действительно всё очень просто ! Так же посмотрел свои старые трейслоги... Блин всё перед носом было, а я выбрал самый гиморный и бесперспективный способ... Сейчас оглядываюсь назад на проделанную работу и думаю сколько времени убито зря и как я только такой бред выдумал... Стыдно мне...

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

оставалось 6 эмулируемых функций. Где то по передаваемым параметрам, где то по функциям до и после эмулируемой, я вычислил 5: GetTickCount, GetProcAddress, ExitProcess, GetCommandLineA, GetModuleHandleA.
Уверен, что правильно вычислил ?
Насчет GetProcAddress, GetVersion, GetCommandLineA - согласен.
А вот насчет GetTickCount, ExitProcess, GetModuleHandleA - не уверен, что эти функции эмулируются

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

AlexVel пишет:
А вот насчет GetTickCount, ExitProcess, GetModuleHandleA - не уверен, что эти функции эмулируются

ExitProcess думаю точно, вот место:

0041826A 68 090400C0 PUSH C0000409
0041826F FF15 8C845300 CALL DWORD PTR DS:[53848C] ; kernel32.ExitProcess
00418275 50 PUSH EAX
00418276 FF15 88845300 CALL DWORD PTR DS:[538488] ; kernel32.TerminateProcess
0041827C C9 LEAVE
0041827D C3 RETN


GetTickCount определил тут (конечно есть сомнения, но уже в двух снятых конвертах работает, да и это место недалеко от OEP):

004185EE 50 PUSH EAX
004185EF FF15 A8845300 CALL DWORD PTR DS:[5384A8] ; kernel32.GetSystemTimeAsFileTime
004185F5 8B75 FC MOV ESI,DWORD PTR SS:[EBP-4]
004185F8 3375 F8 XOR ESI,DWORD PTR SS:[EBP-8]
004185FB FF15 50845300 CALL DWORD PTR DS:[538450] ; kernel32.GetTickCount
00418601 33F0 XOR ESI,EAX
00418603 FF15 A4845300 CALL DWORD PTR DS:[5384A4] ; kernel32.GetCurrentThreadId
00418609 33F0 XOR ESI,EAX
0041860B FF15 A0845300 CALL DWORD PTR DS:[5384A0] ; kernel32.GetTickCount
00418611 33F0 XOR ESI,EAX
00418613 8D45 F0 LEA EAX,DWORD PTR SS:[EBP-10]
00418616 50 PUSH EAX
00418617 FF15 9C845300 CALL DWORD PTR DS:[53849C] ; kernel32.QueryPerformanceCounter
0041861D 8B45 F4 MOV EAX,DWORD PTR SS:[EBP-C]
00418620 3345 F0 XOR EAX,DWORD PTR SS:[EBP-10]
00418623 33F0 XOR ESI,EAX
00418625 3BF7 CMP ESI,EDI
00418627 75 07 JNZ SHORT test1.00418630


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

---

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

ГетТикКаунт гораздо больше похож на снятии большой энтропии для чего-нить типа сида для псевдорандома, ну да ладно.

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

---

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

Kiev78 пишет:
Ты точно ничего не путаешь?

Конечно могу путать, но думаю конкретно в этом месте это не критично.
Насчёт двух записей одной функции мне тоже интересно узнать...

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

Kiev78 пишет:
реальность наличия 2 записей в ИАТ (по адресам 538450 и 5384A0) для одной АПИ! Мне кажется, автор скорее всего ошибся, или может ошибаюсь я?
Вполне реально. Delphi например может одну и туже апи и 10 и 20 раз в иат записать. Это всё из за модульности при проектировании и изъяны ООП.

-----
Yann Tiersen best and do not fuck

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

---

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

Delphi например может одну и туже апи и 10 и 20 раз в иат записать. Это всё из за модульности при проектировании и изъяны ООП.
В данном случае не то что модуль один, так еще и функция одна:
004185EE 50 PUSH EAX
004185EF FF15 A8845300 CALL DWORD PTR DS:[5384A8] ; kernel32.GetSystemTimeAsFileTime
004185F5 8B75 FC MOV ESI,DWORD PTR SS:[EBP-4]
004185F8 3375 F8 XOR ESI,DWORD PTR SS:[EBP-8]
004185FB FF15 50845300 CALL DWORD PTR DS:[538450] ; kernel32.GetTickCount
00418601 33F0 XOR ESI,EAX
00418603 FF15 A4845300 CALL DWORD PTR DS:[5384A4] ; kernel32.GetCurrentThreadId
00418609 33F0 XOR ESI,EAX
0041860B FF15 A0845300 CALL DWORD PTR DS:[5384A0] ; kernel32.GetTickCount
00418611 33F0 XOR ESI,EAX
00418613 8D45 F0 LEA EAX,DWORD PTR SS:[EBP-10]
00418616 50 PUSH EAX
00418617 FF15 9C845300 CALL DWORD PTR DS:[53849C] ; kernel32.QueryPerformanceCounter
Вывод: эмулируемая функция идентифицирована НЕ ПРАВИЛЬНО.
Вообще-то в данном случае это без сомнения фунция GetCurrentProcessId
Ну и ExitProcess соответственно тоже НЕ ПРАВИЛЬНО :
0041826A 68 090400C0 PUSH C0000409
0041826F FF15 8C845300 CALL DWORD PTR DS:[53848C] ; kernel32.ExitProcess
00418275 50 PUSH EAX
00418276 FF15 88845300 CALL DWORD PTR DS:[538488] ; kernel32.TerminateProcess
0041827C C9 LEAVE
0041827D C3 RETN
Вместо ExitProcess д.б. некоторая функция, которая вернула -бы в EAX (т.к. видим последующий вызов TerminateProcess)
HANDLE процесса. Думаю, что догадаться не просто, а очень просто

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