nikolatesla20
January 17th, 2003, 11:10
Hello all,
Target: Original CD emulator 2.05
This program is a classic display of a chain only being as strong as its weakest link. Please , if I blabber on, skip to the end, I found an easy way to defeat this target *without unpacking*.
First of all, I believe this target is protected by the latest version of *SProtect. I'm just guessing of course, it could be telock. PEScan says teLock .98. I've never unpacked a teLock app before, this is my first..Anyway, it has an IAT with re-redirected imports. What a mess! BUT it's easy anyway, because if you look in memory at where one of the imports gets redirected you will see crap like this:
JMP 00C300A2
then after the JMP:
JMP 00C30163
Then you go there, and it's
SUB EAX,0000045
MOV EAX, 00BE0453
INC EAX
PUSH [EAX]
RET
Yep, the SUB is at completely useless instruction. Notice the MOV, and then the INC. If add one to EAX and then "DD eax" you will see the real import address that gets pushed. Big deal you say? Well, it's a big deal , because you will see there is an entire table in memory of these import addresses. In fact, it's the same format as the original IAT table would have had. Scroll to the top and bottom of the table you see in memory and write down the addresses. Now get out of SoftICE and "dump partial" these memory ranges with LordPE. Open them up in a HexEditor and now you have all the right addresses (you could probably even plug them into Revirgin). All you have to do if figure out the names. Why is this a big deal? because the beauty of Windows linkers, functions are always in alphabetical order. You can just go down the line and plug them into ImpREC. In other words, the order of the functions in this table is the same as the order they should appear in ImpREC when you are fixing the bad addresses.
With ImpREC, I was able to cut out a lot of bad thunks, which exist in the IAT. It's easy to find these because they will have addresses which don't make sense at all. After you cut out all the bad thunks, you can repair the IAT with the tables that you dumped from above. In this program I found 4 tables. Just look up the function names the correspond to the addresses in the table. (You can use S.I. and do a "U <address>" to get the name - I'm sure there is a faster way of course, but this is how I did it) There will actually be around 188 functions that exist in memory tables, from Kernel32, gdi32, user32, and shell32. I am pretty sure this is *SProtect.
Anyway, I did all of this, and then dumped the process at what I thought was the OEP, and it still wouldn't work, so I tried a different approach. I noticed that the program would just exit, so I put a bpx on ExitProcess. This led me to a DLL called “ECCverify.dll”. I dissassembled my dumped OCDE.exe file (after I pasted on my fixed IAT), and looked for references to ECCverify.dll , and here is one:
notice the test at 0040376B. Also, notice that if we don’t jump, we are considered registered. Notice “Registered” is spelled wrong? Nice
So all we need to do is make sure ECCverify returns a 1 here. So make your own ECCVerify.dll to try it ! Fire up VC++ and write a vanilla dll with one exported function “ECCverify” and have it just return a 1, and replace the original ECCVerify.dll, and run the orginal program. Lo! It works! No more nag screen, and it thinks I’m registered. You can click on "register" and enter your name and just a couple of letters for the code, and click ok - restart the program, and it says its registered to you.
Holy crap that was too simple. After all the “protection” on the program and it’s DLL, all you needed to do was make a fake DLL. Just goes to show you that a good RCE man will think “out of the box” (and dll protections are stupid).
‘til next time
-nt20
Target: Original CD emulator 2.05
This program is a classic display of a chain only being as strong as its weakest link. Please , if I blabber on, skip to the end, I found an easy way to defeat this target *without unpacking*.
First of all, I believe this target is protected by the latest version of *SProtect. I'm just guessing of course, it could be telock. PEScan says teLock .98. I've never unpacked a teLock app before, this is my first..Anyway, it has an IAT with re-redirected imports. What a mess! BUT it's easy anyway, because if you look in memory at where one of the imports gets redirected you will see crap like this:
JMP 00C300A2
then after the JMP:
JMP 00C30163
Then you go there, and it's
SUB EAX,0000045
MOV EAX, 00BE0453
INC EAX
PUSH [EAX]
RET
Yep, the SUB is at completely useless instruction. Notice the MOV, and then the INC. If add one to EAX and then "DD eax" you will see the real import address that gets pushed. Big deal you say? Well, it's a big deal , because you will see there is an entire table in memory of these import addresses. In fact, it's the same format as the original IAT table would have had. Scroll to the top and bottom of the table you see in memory and write down the addresses. Now get out of SoftICE and "dump partial" these memory ranges with LordPE. Open them up in a HexEditor and now you have all the right addresses (you could probably even plug them into Revirgin). All you have to do if figure out the names. Why is this a big deal? because the beauty of Windows linkers, functions are always in alphabetical order. You can just go down the line and plug them into ImpREC. In other words, the order of the functions in this table is the same as the order they should appear in ImpREC when you are fixing the bad addresses.
With ImpREC, I was able to cut out a lot of bad thunks, which exist in the IAT. It's easy to find these because they will have addresses which don't make sense at all. After you cut out all the bad thunks, you can repair the IAT with the tables that you dumped from above. In this program I found 4 tables. Just look up the function names the correspond to the addresses in the table. (You can use S.I. and do a "U <address>" to get the name - I'm sure there is a faster way of course, but this is how I did it) There will actually be around 188 functions that exist in memory tables, from Kernel32, gdi32, user32, and shell32. I am pretty sure this is *SProtect.
Anyway, I did all of this, and then dumped the process at what I thought was the OEP, and it still wouldn't work, so I tried a different approach. I noticed that the program would just exit, so I put a bpx on ExitProcess. This led me to a DLL called “ECCverify.dll”. I dissassembled my dumped OCDE.exe file (after I pasted on my fixed IAT), and looked for references to ECCverify.dll , and here is one:
Code:
:0040375B EB05 jmp 00403762
* Referenced by a (U)nconditional or (C)onditional Jump at Address:
|:00403756(C)
|
:0040375D B8D3074B00 mov eax, 004B07D3
* Referenced by a (U)nconditional or (C)onditional Jump at Address:
|:0040375B(U)
|
:00403762 50 push eax
* Reference To: eccverify.ECCVerify, Ord:0001h
|
:00403763 E850AE0A00 Call 004AE5B8
:00403768 83C408 add esp, 00000008
:0040376B 84C0 test al, al
:0040376D 0F8481000000 je 004037F4
:00403773 66C743106803 mov [ebx+10], 0368
:00403779 33D2 xor edx, edx
* Possible Reference to String Resource ID=40002: "Registed to: "
|
:0040377B B8429C0000 mov eax, 00009C42
:00403780 899544FEFFFF mov dword ptr [ebp+FFFFFE44], edx
:00403786 8D9544FEFFFF lea edx, dword ptr [ebp+FFFFFE44]
notice the test at 0040376B. Also, notice that if we don’t jump, we are considered registered. Notice “Registered” is spelled wrong? Nice
So all we need to do is make sure ECCverify returns a 1 here. So make your own ECCVerify.dll to try it ! Fire up VC++ and write a vanilla dll with one exported function “ECCverify” and have it just return a 1, and replace the original ECCVerify.dll, and run the orginal program. Lo! It works! No more nag screen, and it thinks I’m registered. You can click on "register" and enter your name and just a couple of letters for the code, and click ok - restart the program, and it says its registered to you.Holy crap that was too simple. After all the “protection” on the program and it’s DLL, all you needed to do was make a fake DLL. Just goes to show you that a good RCE man will think “out of the box” (and dll protections are stupid).
‘til next time
-nt20
Reminds me of the old salesagent protections that dumped themselves when you flipped a bit