buntus
April 9th, 2003, 06:29
Hi folks,
Some big fan of pacman asked me to have a look at this :
hxxp://fe.trymedia.com/d/alawar/2u10p_d/trygames/PacmaniaII.exe
1. Facts :
It appears to be protected by ActiveMark from TryMedia. I had a look at it, dumped it,
fixed import table, fixed relevant api calls. They actually emulate a few API for which
u can find a translation table in memory (ie APINAME, Offset of garbaged emulation),
hence u can easily fix those :
call dword ptr is replaced by nop call emulatedAPI (90 E8 XX XX XX XX).
jmp dword ptr is replaced by nop jmp emulatedtAPI (90 E9 XX XX XX XX).
mov dword ptr is replaced by nop mov reg32, Offset emulatedAPI (90 BX XX XX XX XX).
The following detection strings are used, it is easily bypassed :
FilemonClass
RegmonClass
File Monitor - Sysinternals: www.sysinternals.com
Registry Monitor - Sysinternals: www.sysinternals.com
\\.\NTICE
\\.\SICE
\\.\SIWVID
\\.\FROGSICE
\\.\SUPERBPM
INT3 backdoor is used too.
Loader APIs are checked for softBP (1st and 2nd byte... sounds dangerous to me, ah well).
Some API code is replicated in a buffer too (CreateThread for instance and Sleep).
Entrypoint is easy to find as well (0x2958D), the image is using thread for doing some
tasks, and you will find the UPX loader code to decompress, resolve API of some code
inside (Sigh !!!) which is garbaged.
2. Problem :
For some reason, it does an infinite loop after being fixed while accessing the file
MAIN.ARF (Seek Offsets are different from trial and dumped version). I Looked at it for
2 days and I can't figure out what is the thing I missed. I'd be very glad to get any
input from you guyz from this target. It must be a very stupid thing, coz the whole scheme
looks plain dodgy (we are very far from a ProtectCD, ASPR, VBOX, or SafeDisc wrapping scheme).
Thanx in advance.
Some big fan of pacman asked me to have a look at this :
hxxp://fe.trymedia.com/d/alawar/2u10p_d/trygames/PacmaniaII.exe
1. Facts :
It appears to be protected by ActiveMark from TryMedia. I had a look at it, dumped it,
fixed import table, fixed relevant api calls. They actually emulate a few API for which
u can find a translation table in memory (ie APINAME, Offset of garbaged emulation),
hence u can easily fix those :
call dword ptr is replaced by nop call emulatedAPI (90 E8 XX XX XX XX).
jmp dword ptr is replaced by nop jmp emulatedtAPI (90 E9 XX XX XX XX).
mov dword ptr is replaced by nop mov reg32, Offset emulatedAPI (90 BX XX XX XX XX).
The following detection strings are used, it is easily bypassed :
FilemonClass
RegmonClass
File Monitor - Sysinternals: www.sysinternals.com
Registry Monitor - Sysinternals: www.sysinternals.com
\\.\NTICE
\\.\SICE
\\.\SIWVID
\\.\FROGSICE
\\.\SUPERBPM
INT3 backdoor is used too.
Loader APIs are checked for softBP (1st and 2nd byte... sounds dangerous to me, ah well).
Some API code is replicated in a buffer too (CreateThread for instance and Sleep).
Entrypoint is easy to find as well (0x2958D), the image is using thread for doing some
tasks, and you will find the UPX loader code to decompress, resolve API of some code
inside (Sigh !!!) which is garbaged.
2. Problem :
For some reason, it does an infinite loop after being fixed while accessing the file
MAIN.ARF (Seek Offsets are different from trial and dumped version). I Looked at it for
2 days and I can't figure out what is the thing I missed. I'd be very glad to get any
input from you guyz from this target. It must be a very stupid thing, coz the whole scheme
looks plain dodgy (we are very far from a ProtectCD, ASPR, VBOX, or SafeDisc wrapping scheme).
Thanx in advance.