Jacques
August 9th, 2004, 20:53
The target I am working on is protected by a Sentinel SuperPro dongle.
I have successfully done another SuperPro app before, but that one was pretty easy (and it's the limit of my Sentinel experience). I am now stuck on a couple of points...
Here's what I've done:
1) I've re-read the Sentinel API.
2) I've read most of the Sentinel related posts on the board.
3) I've applied the Sentinel signatures in IDA, but no luck.
I applied the following sigs:
sentpro -- Sentinel SuperPro static link library
sspro ---- Sentinel SuperPro Lib - Killer_3K
sspro62 -- Sentinel Super Pro 6.2 lib (sope)
sspro_v6 - Sentinel SuperPro (v6.0 lib) by CyberHeg
I didn't expect the last two sigs to work because the target comes with version 5.41.1 of the Sentinel drivers. I was hoping that Killer_3K sig would work as it had on the first app (which used version 5.39.2), but no luck.
Side Question:
IDA was not able to recognize the compiler that created the target. Does this by any chance hamper it's ability to apply other signatures?
Looking at the code in IDA, there are a couple of fishy things.
First, there are numerous cmp's to the infamous 7242h Sentinel packet ID. These cmp's are near the beginning of the functions (just past an initial NULL check), and the functions are all nestled in close proximity. Sure looks like a statically linked Sentinel library to me.
Second, the multi-color code map that is part of one of the toolbars shows the first 90% or so as dull green (data), and only the last 10% as code (blue).
I thought that this might mean they used the SuperPro shell feature to hide the code. I downloaded SPUICA v1.05.1 and SSunshl 1.0 by ExeLord, but both tools reported that the exe is NOT shelled. (Note: I do not have a dongle (required by these tools for unshelling) but they still seemed to analyze the file ok.)
BUT, doing some more digging, I found CyberHeg's tutorial on Sentinel Shells: http://www.woodmann.com/crackz/Tutorials/Cyberheg4.htm
The first block of code given in the tutorial describes the main switch in that app... it's quite similar to the area of code near "start" in my target. Both contain a lot to sequential cmp's and jmp's with similar compare constants (704h, 611h, 0e4h, etc.). Way too similar for it to be a coincidence. Here is the block from my target:
cmp ecx, 5910h
mov ds:dword_508D48, edx
mov ds:dword_4FE77C, ebp
jg loc_50BAE9
jz loc_50BD1F
cmp ecx, 1992h
jg loc_50BA1C
jz loc_50B9FD
cmp ecx, 704h
jg loc_50B9A5
jz loc_50B981
cmp ecx, 0E4h
jz short loc_50B94D
cmp ecx, 342h
jz short loc_50B940
cmp ecx, 611h
jnz loc_50B866
...
jmp short loc_50B916
Near the bottom of the tutorial CyberHeg also shows a block of "decoy" code (with calls to GetTickCount & GetCurrentProcessId) which is meant to mislead the reverser. This block is nearly identical to the first chunck of code in my target.
Questions:
-- Are the similarities noted above enough proof that the exe is indeed shelled?
-- Do the unshellers need the dongle to figure out if it's shelled? (Or is version 5.41.1 of the shell just not covered by the tools?)
-- Any ideas as to why none of the IDA sigs worked?
Back-tracking a bit, one of the first things I attempted was to try the emulator I had successfully used in my first project. This emulator was written by some guy named Steven. I found version 0.24 very useful, because it identified each SuperPro function it responded to by doing a DebugPring (making it very easy to follow the sequence of calls by watching the debugger's output window).
When I try to use the emulator, to at least see what is begin called, it responds with the following DebugPrints:
---- RNBO: fn is ABE - yet unknown
---- RNBO: fn is 5076 - yet unknown
---- RNBO: fn is 453E - yet unknown
These bogus (?) function numbers aren't constant either. Subsequent invocations of the app produce new numbers:
2nd invocation:
---- RNBO: fn is B3D4 - yet unknown
---- RNBO: fn is F6B0 - yet unknown
---- RNBO: fn is 80AD - yet unknown
3rd invocation:
---- RNBO: fn is 2847 - yet unknown
---- RNBO: fn is 85AD - yet unknown
---- RNBO: fn is AC64 - yet unknown
I did verify that the emulator obtains the function numbers from:
base of packet (location of 7242h id) + 30h
These calls most likely equate to:
RNBOsproInitialize
RNBOsproFindFirstUnit
RNBOsproQuery
but it would be nice to confirm this and actually see what's happening.
Last question:
-- Why is the emulator not able to recognize the functions with this target? (Are the packets being encrypted?)
Any pointers would be appreciated, and thanks for reading my long-winded post...
Jacques
I have successfully done another SuperPro app before, but that one was pretty easy (and it's the limit of my Sentinel experience). I am now stuck on a couple of points...
Here's what I've done:
1) I've re-read the Sentinel API.
2) I've read most of the Sentinel related posts on the board.
3) I've applied the Sentinel signatures in IDA, but no luck.
I applied the following sigs:
sentpro -- Sentinel SuperPro static link library
sspro ---- Sentinel SuperPro Lib - Killer_3K
sspro62 -- Sentinel Super Pro 6.2 lib (sope)
sspro_v6 - Sentinel SuperPro (v6.0 lib) by CyberHeg
I didn't expect the last two sigs to work because the target comes with version 5.41.1 of the Sentinel drivers. I was hoping that Killer_3K sig would work as it had on the first app (which used version 5.39.2), but no luck.
Side Question:
IDA was not able to recognize the compiler that created the target. Does this by any chance hamper it's ability to apply other signatures?
Looking at the code in IDA, there are a couple of fishy things.
First, there are numerous cmp's to the infamous 7242h Sentinel packet ID. These cmp's are near the beginning of the functions (just past an initial NULL check), and the functions are all nestled in close proximity. Sure looks like a statically linked Sentinel library to me.
Second, the multi-color code map that is part of one of the toolbars shows the first 90% or so as dull green (data), and only the last 10% as code (blue).
I thought that this might mean they used the SuperPro shell feature to hide the code. I downloaded SPUICA v1.05.1 and SSunshl 1.0 by ExeLord, but both tools reported that the exe is NOT shelled. (Note: I do not have a dongle (required by these tools for unshelling) but they still seemed to analyze the file ok.)
BUT, doing some more digging, I found CyberHeg's tutorial on Sentinel Shells: http://www.woodmann.com/crackz/Tutorials/Cyberheg4.htm
The first block of code given in the tutorial describes the main switch in that app... it's quite similar to the area of code near "start" in my target. Both contain a lot to sequential cmp's and jmp's with similar compare constants (704h, 611h, 0e4h, etc.). Way too similar for it to be a coincidence. Here is the block from my target:
cmp ecx, 5910h
mov ds:dword_508D48, edx
mov ds:dword_4FE77C, ebp
jg loc_50BAE9
jz loc_50BD1F
cmp ecx, 1992h
jg loc_50BA1C
jz loc_50B9FD
cmp ecx, 704h
jg loc_50B9A5
jz loc_50B981
cmp ecx, 0E4h
jz short loc_50B94D
cmp ecx, 342h
jz short loc_50B940
cmp ecx, 611h
jnz loc_50B866
...
jmp short loc_50B916
Near the bottom of the tutorial CyberHeg also shows a block of "decoy" code (with calls to GetTickCount & GetCurrentProcessId) which is meant to mislead the reverser. This block is nearly identical to the first chunck of code in my target.
Questions:
-- Are the similarities noted above enough proof that the exe is indeed shelled?
-- Do the unshellers need the dongle to figure out if it's shelled? (Or is version 5.41.1 of the shell just not covered by the tools?)
-- Any ideas as to why none of the IDA sigs worked?
Back-tracking a bit, one of the first things I attempted was to try the emulator I had successfully used in my first project. This emulator was written by some guy named Steven. I found version 0.24 very useful, because it identified each SuperPro function it responded to by doing a DebugPring (making it very easy to follow the sequence of calls by watching the debugger's output window).
When I try to use the emulator, to at least see what is begin called, it responds with the following DebugPrints:
---- RNBO: fn is ABE - yet unknown
---- RNBO: fn is 5076 - yet unknown
---- RNBO: fn is 453E - yet unknown
These bogus (?) function numbers aren't constant either. Subsequent invocations of the app produce new numbers:
2nd invocation:
---- RNBO: fn is B3D4 - yet unknown
---- RNBO: fn is F6B0 - yet unknown
---- RNBO: fn is 80AD - yet unknown
3rd invocation:
---- RNBO: fn is 2847 - yet unknown
---- RNBO: fn is 85AD - yet unknown
---- RNBO: fn is AC64 - yet unknown
I did verify that the emulator obtains the function numbers from:
base of packet (location of 7242h id) + 30h
These calls most likely equate to:
RNBOsproInitialize
RNBOsproFindFirstUnit
RNBOsproQuery
but it would be nice to confirm this and actually see what's happening.
Last question:
-- Why is the emulator not able to recognize the functions with this target? (Are the packets being encrypted?)
Any pointers would be appreciated, and thanks for reading my long-winded post...
Jacques