Reversing
IDA 4.01
Watermarked protection scheme
by tsehp+
|
Reversing
IDA 4.01 | ||
|
by tsehp+ | |
First I have to tell you : Don't ever mistake on my purposes.
The main goal of this essay is to study the
protection if this great tool and not to give ready made tricks for someone to
spread it on the web.
Discovered by Nolan blender : Ida 4.01 include your license info inside idb
databases in the same way it
does on asm and lst files, if you apply the changes in ida.key and ida.wll this
will be finished.
I was able able to remove all the watermarks of IDA 4.01 and did a serious byte
compare of idb
databases created with ida almost completly unwatermarked on this essay and my
version that is
completly unwatermarked. There's absolutly NO DIFFERENCES with the idb files
resulting, so your
privacy is respected if you apply this essay.
You need a regular copy of ida 4.01 to make this work, this program contains
your name watermarked everywhere
and I don't tell you everything on this essay.
So some watermarks will be left if you just apply what I will tell you.
This tool is a must, for every serious Fravia and have to be improved by its
authors, they really deserves the money it costs.
What are we dealing with ? Your registered name resides encrypted in your
ida.key, ida uses this all the time to validate a lot of functions.
All its modules *.w32 are encrypted in part of data section with a unique key
generated for your copy, its the same for the main dll ida.wll and
all the different loaders *.ldw. The rest is left intact.
I made this essay on win2k final.
But they can also crypt some parts of several dlls and
modules working in your app. Whats new about that ?
Well datarescue doesn't sell a mass of copies, so they have the time to
customise their prog for everyone of their customer. If you manage only to crack
the ida.key and spread the rest, they can track you back.
The watermarks consist of two parts, first a signed
encryption of the executables, modules and loaders. All those decrypts at load
time and
are different for the encrypted part on every copy. At last, the ida.key is used
to generate your license info, clearly inserted at the top of
the listings produced by IDA and embedded inside your packed idb files. Pierre
Vandevenne said it was for multi-users to be able to
identify authors but we don't know this when we buy this prog and can't avoid
this to occur.
*1 The ida.key protection.
If you search on the web, you could find some older copies of ida with ida.key
generators. Don't waste your time with encryption or decryption routines, you
will play their game. Its more easy just to let your pc decrypt this and check
what's after. Load softice and do a bpx createfileA do "d esp->4",
wait for ida.key to be sent to this api. Look for the handle returned in eax, do
a bpx readfile, check for the handle pushed in esp->4 inside the api and do a
d esp->8 and F12, the data is filled with the content of the key that is
used. Very careful here, do a bpr on a byte inside this block, you will land in
a movsd instr, remove your bpr and do a bpr on the new mem loc where this
content is copied. You will land again on a second movsd, do the same. You
finally land at $10078231,inside ida.wll keep in the data view with the crypted
info. Do several f12 (p ret) until you land at $10077aa6. You must see in the
data section of softice your personal info on reverse order. So we went thru
several routines that reads the ida.key, apply the decryption and build your
info on reverse order. Apply p ret until you land here :
001B:10077848 E83B020000 CALL 10077A88 001B:1007784D 85C0 TEST EAX,EAX <-- 001B:1007784F 7C09 JL 1007785A <-- patch this to nop 001B:10077851 0FBE4610 MOVSX EAX,BYTE PTR [ESI+10] 001B:10077855 83F83D CMP EAX,3D 001B:10077858 7404 JZ 1007785E <-- patch this to jmp 1007785e 001B:1007785A 33C0 XOR EAX,EAX 001B:1007785C EB1F JMP 1007787D 001B:1007785E 6A7F PUSH 7F 001B:10077860 56 PUSH ESI 001B:10077861 53 PUSH EBX 001B:10077862 E84556FBFF CALL 1002CEAC 001B:10077867 83C40C ADD ESP,0C 001B:1007786A C605B4EE091007 MOV BYTE PTR [1009EEB4],07 001B:10077871 C7054488081001000000 MOV DWORD PTR [10088844],00000001 001B:1007787B 8BC3 MOV EAX,EBX
If you do a "d esi" you will see your registration info. The first part is to put some ff inside ida.key, just to remove your info inside this file, you will find the corresponding bytes that you saw before after the readfile api, all the other bytes are unused. This place is called about five times until ida decompiles your target, you can apply 3 patches to force ida to work without a good key. The patches are showed on the listing. first patch on ida.wll .text:1006A34E jz short loc_0_1006A36B .text:1006A350 mov eax, [eax+8] .text:1006A353 mov edx, dword_0_1009AA62 .text:1006A359 cmp edx, 20h .text:1006A35C jge short loc_0_1006A376 <- patch this to jmp .text:1006A35E mov ecx, edx .text:1006A360 mov edx, 1 .text:1006A365 shl edx, cl .text:1006A367 test edx, eax .text:1006A369 jnz short loc_0_1006A376 .text:1006A36B
The last patch is here :
001B:1006A340 0000
ADD [EAX],AL
001B:1006A342 BA01000000 MOV EDX,00000001
001B:1006A347 E800D40000 CALL 1007774C <-- this call leads to the above
listing
001B:1006A34C 85C0
TEST EAX,EAX
001B:1006A34E 741B
JZ 1006A36B
001B:1006A350 8B4008
MOV EAX,[EAX+08]
001B:1006A353 8B1562AA0910 MOV EDX,[1009AA62]
001B:1006A359 83FA20
CMP EDX,20
001B:1006A35C 7D18
JGE 1006A376 <--force this to jump
001B:1006A35E 8BCA
MOV ECX,EDX
001B:1006A360 BA01000000 MOV EDX,00000001
001B:1006A365 D3E2
SHL EDX,CL
001B:1006A367 85C2
TEST EDX,EAX
001B:1006A369 750B
JNZ 1006A376
001B:1006A36B 6812770810 PUSH 10087712
001B:1006A370 E8F7CEFEFF CALL 1005726C
This place occurs when the loaders are called by ida, like pe.ldw for
example. Those modules are used for ida to interpret typical file formats like pe, ne, dos etc...
But you have a big problem, you can't find those places inside idag.exe, its
normal, this prog is encrypted. We will face this again later on this essay, so I will use two different
approaches to allow those patches.
The first technique is used here for teaching purposes, if you want to remove
the watermarks it will not succeed. Why ? Because idag.exe is encrypted with your license info, so the
better way would be to reconstruct a virgin dumped app.
*2 Reconstructing ida.wll
To allow the patches inside ida.wll, you have to dump it decrypted. You will
use icedump, procdump and
your hex editor. This technique will be further explained in the last part of
this essay.
First load ida until the nag screen. Do addr idag to switch to its address
context.
Do bpmb 8:10001000 x , the ida.wll will be stopped at its *decrypted* entry
point.
Look at the pe structure in procdump : base address 1000000 length ac000
Exit ida and start it again, first break at 10001000 with a ret, let run until
the second break.
At the second break, all is decrypted so you can
dump it.
Do a pagein d 10000000 ac000 c:\temp\ida.dmp , so all the mem is dumped.
We have to fix the pe header with procdump with those options enabled :
* recompute object size
* optimize pe structure
* check header sections
* rebuild header
* use actual import infos
We have to manually rebuild the import table, I did a fast rebuild by copying
and pasting with my hex editor, a fast way but we could have manually fixed the
api's addresses using the pe import table structure.
You can locate the import table with procdump by the directories function and
calculate the raw offset, read
the pe docs.
Heres a snip of the original values in ida.wll not dumped :
0004A6A2 0090 C1A8 0A00 D2A8 0A00 E5A8 0A00 0000 0000 6B65 726E 656C 3332 2E64 ..................kernel32.d
0004A6BE 6C6C 0000 0047 6574 5072 6F63 4164 6472 6573 7300 0000 4765 744D 6F64 ll...GetProcAddress...GetMod
0004A6DA 756C 6548 616E 646C 6541 0000 004C 6F61 644C 6962 7261 7279 4100 0000 uleHandleA...LoadLibraryA...
0004A6F6 0000 0000 0000 0000 0000 B4A8 0A00 A4A8 0A00 0000 0000 0000 0000 0000 ............................
0004A712 0000 30A9 0A00 3BA9 0A00 0000 0000 0000 0000 0000 0000 0000 0000 0000 ..0...;.....................
0004A72E 0000 7573 6572 3332 2E64 6C6C 0043 A90A 0000 0000 0000 0045 6E75 6D54 ..user32.dll.C.........EnumT
0004A74A 6872 6561 6457 696E 646F 7773 hreadWindows
You must paste that inside your dumped ida.wll (ida.dmp) at this location :
0008B2A2 0090 5401 0080 3B01 0080 E001 0080 0000 0000 4B45 524E 454C 3332 2E44 ..T...;...........KERNEL32.D
0008B2BE 4C4C 0000 0047 6574 5072 6F63 4164 6472 6573 7300 0000 4765 744D 6F64 LL...GetProcAddress...GetMod
0008B2DA 756C 6548 616E 646C 6541 0000 004C 6F61 644C 6962 7261 7279 4100 0000 uleHandleA...LoadLibraryA...
0008B2F6 0000 0000 0000 0000 0000 B4A8 0A00 A4A8 0A00 0000 0000 0000 0000 0000 ............................
0008B312 0000 30A9 0A00 3BA9 0A00 0000 0000 0000 0000 0000 0000 0000 0000 0000 ..0...;.....................
0008B32E 0000 5553 4552 3332 2E44 4C4C 0043 A90A 0000 0000 0000 0045 6E75 6D54 ..USER32.DLL.C.........EnumT
0008B34A 6872 6561 6457 696E 646F 7773 hreadWindows
00000054 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ............................
00000070 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ............................
0000008C FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ............................
000000A8 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ............................
000000C4 FFFF FFFF FFFF FFFF FFFF ..........
This section is inserted into your idb files, and no use for integrity checks. Better void it.
000000F0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ............................
0000010C FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ............................
00000128 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ............................
00000144 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ............................
You can remove other bytes, try it as an exercise.
All the encrypted info is removed on the second snip. After that, ida 4.01 still works and doesn't show you anymore your license info, even on *.asm or other files it can generate. And the embedded license info inside the idb files is not generated anymore. BUT there's is still a small problem, you can try to decompile big progs, it works ok at the beginning and finally crashed at the end with messages like execution flows beyond limits etc... And if you put back your right key, the decompiling is working fine. Whats happening ? Put back your normal key in the ida directory. A very devious final check of your key at the end of the decompiling procedure, the one that's hard to find. How did I found that ? I went to the patched routine at this location :
001B:10077848
E83B020000
CALL 10077A88
001B:1007784D
85C0
TEST EAX,EAX <--stop here
001B:1007784F
7C09
JL 1007785A <-- patch this to nop
001B:10077851
0FBE4610
MOVSX EAX,BYTE PTR [ESI+10]
If you do a bpmb 1b:10077848 x at this place, and load idag.exe you will hit
5 times before your target is decompiled.
When you stop, just do a d esi, you will see in the data section your decompiled
license info :
= name , date , blah blah.
If you change the egal sign to something else in mem at the second hit the
errors will happen again at the end of the decompiling.
The check resides here, on your decrypted key. Yes we patched ida but this info is kept in mem and
used again. If you want to trace that by yourself, take some time and be patient, this info is copied in mem to several locations (about 300
times) before the check. You have to do a bpmb on the egal sign and release your bpmb when this value is copied to another location and do a bpmb at
the new place. I used also other tricks not said here, but if you're patient, this method works fine.
We finally land at this place inside ida.wll, when your license info is finally
checked and not copied to another mem location.
0008:10013318 53
PUSH EBX
0008:10013319 56
PUSH ESI
0008:1001331A 57
PUSH EDI
0008:1001331B 55
PUSH EBP
0008:1001331C 51
PUSH ECX
0008:1001331D E876FFFFFF CALL 10013298
0008:10013322 84C0
TEST AL,AL
<-You land here
0008:10013324 0F858E000000 JNZ 100133B8
0008:1001332A A1CF930910 MOV EAX,[100993CF]
0008:1001332F E8AC080000 CALL 10013BE0
0008:10013334 33D2
XOR EDX,EDX
0008:10013336 8AD0
MOV DL,AL
0008:10013338 B888AA0810 MOV EAX,1008AA88
0008:1001333D 891424
MOV [ESP],EDX
0008:10013340 E857E1FFFF CALL 1001149C
0008:10013345 50
PUSH EAX
Guess what ? if al contains 0 the errors occurs, and that whats happens when
your voided ida.key is used.
The call 10013298 is used later at run time, so we need to patch this call so it
nevers put a 0 on AL.
Very important : the same technique will be used on encrypted modules of ida
(find them). We have to do this on all those places because the encryption is watermarked, I mean that they used
your personal info to crypt everything, I have to thank Nolan Blender who helped me a lot by providing me a sfv file (files crc) on all the files of
his copy of ida 4.01. I needed this info to locate the different files, heres a summary of the differences :
Idag.exe
Ida.wll
ida.key 4 sure ;-)
all the *.ldw and *.w32
On previous versions, only the ida.key was different and you can now see where are the watermarks. I recommend reading the stenography section of this mirror to learn more about this.
On every file I treated, I saw very small differences between nolan's version and mine, that means that some watermarks remains (small encrypted parts) and are decrypted by idag.exe at run time, when the modules are loaded and initialized.
*3 Restoring ida.wll and modules to their *almost* original state.
First you need to understand about pe structure before reading the rest. Check here if you don't and come back.
Ida.wll and all the modules have a normal entry point. Use procdump's pe editor on ida.wll you will find : $100AA000.
Do a bpmb on it and load ida.
001B:100AA000 60 PUSHAD <-- You land here
001B:100AA001 E841060000 CALL 100AA647
001B:100AA006 EB41 JMP 100AA049
001B:100AA008 0000 ADD [EAX],AL
001B:100AA00A E177 LOOPZ 100AA083
001B:100AA00C 0C00 OR AL,00
001B:100AA00E 0000 ADD [EAX],AL
001B:100AA010 0000 ADD [EAX],AL
Typical decryption or unpacking routine, pushad saves all the registers and
the next instructions does the dll decryption and finally jumps to the
real entry point. To find this place you must know something, all the dlls have
a common init section, the real entry point. This init functions maps
the memory, initializes the vars etc... But this functions unloads the dll too.
So exit idag.exe just after the nag and the bpmb triggers again, do
a p ret (f12) and :
001B:10001000 A1E0A10710
MOV EAX,[1007A1E0] <--- you land
here
001B:10001005 C1E002
SHL EAX,02
001B:10001008 A3E4A10710 MOV [1007A1E4],EAX
001B:1000100D 8B442408
MOV EAX,[ESP+08]
001B:10001011 A356A20710 MOV [1007A256],EAX
001B:10001016 FF148546A20710 CALL [EAX*4+1007A246]
001B:1000101D 833D56A2071001 CMP DWORD PTR [1007A256],01
001B:10001024 0F8580000000 JNZ 100010AA
001B:1000102A 803DECA1071000 CMP BYTE PTR [1007A1EC],00
001B:10001031 7424
JZ 10001057
001B:10001033 E88A850700 CALL KERNEL32!GetVersion
001B:10001038 BAEDA10710 MOV EDX,1007A1ED
001B:1000103D 2500000080 AND EAX,80000000
001B:10001042 7405
JZ 10001049
001B:10001044 BA0DA20710 MOV EDX,1007A20D
001B:10001049 52
PUSH EDX
That's just the real entry of the ida.wll, it's the same with all the modules, always at base address + 1000 to find the virtual address.
We need to dump entirely this dll from mem to hd , I first used procdump to do that but it fails when ida loads again the dumped dll. Why ?
Very simple, procdumps uses loadlibrarya to load ida.wll in its address
context (a big mistake to dump protected dll's), so the init section at
10001000 is called, the memory mapped and the dll is dumped. But when the mem is
mapped, the init section puts some flags on and those
flags are dumped too. If ida loads then the dumped dll, the mem flags will
already be set and the protection will detect this and some errors occurs. The
main flags are located in data section, and tested at the dll's init procedure.
We just need to dump the dll just at the beginning of the init section. You will use icedump to do that.
Put a bmpb at 1b:10001000 x , load ida, wait for the second trigger (you have
a ret at 10001000 when it first triggers at decrypt time)
then you land again at the same address, but this time, the dll is loaded, the
mem is paged in its data section and the flags are not set.
Procdump told you about ida.wll
image base 10000000
lenght ac000
Just use icedump and do : pagein d 10000000 ac000 "your path, like \??\temp\ida.dmp"
You will get an ida.dmp file, containing a header to rebuild, with all the decrypted sections.
You must rebuild the header with procdump's automated feature. You change the entry point to 10001000 with proc dump too and it's working.
Dont forget to patch ida.wll so the CALL 10013298 will never put eax at 0. Find the raw offset by yourself !
Here's what I done inside ida.wll
0008:10013298 83C4E8
ADD ESP,-18
0008:1001329B 33C9
XOR ECX,ECX
0008:1001329D 8BC4
MOV EAX,ESP
0008:1001329F C644240424 MOV BYTE PTR [ESP+04],24
0008:100132A4 C644240520 MOV BYTE PTR [ESP+05],20
0008:100132A9 C644240675 MOV BYTE PTR [ESP+06],75
0008:100132AE C644240773 MOV BYTE PTR [ESP+07],73
0008:100132B3 C644240865 MOV BYTE PTR [ESP+08],65
0008:100132B8 C644240972 MOV BYTE PTR [ESP+09],72
0008:100132BD C644240A31 MOV BYTE PTR [ESP+0A],31
0008:100132C2 C644240B00 MOV BYTE PTR [ESP+0B],00
0008:100132C7 8D542404
LEA EDX,[ESP+04]
0008:100132CB E878410100 CALL 10027448
0008:100132D0 8BC4
MOV EAX,ESP
0008:100132D2 B153
MOV CL,53
0008:100132D4 33D2
XOR EDX,EDX
0008:100132D6 E825480100 CALL 10027B00
0008:100132DB 85C0
TEST EAX,EAX
0008:100132DD 7504
JNZ 100132E3
0008:100132DF B001
MOV AL,01 *patched part, it was XOR
eax,eax
0008:100132E1 EB31
JMP 10013314
0008:100132E3 8B5004
MOV EDX,[EAX+04]
0008:100132E6 81FAC030D737 CMP EDX,37D730C0
0008:100132EC 7D04
JGE 100132F2
0008:100132EE B001
MOV AL,01 *same
0008:100132F0 EB22
JMP 10013314
0008:100132F2 8B5010
MOV EDX,[EAX+10]
0008:100132F5 81C2C9FDFFFF ADD EDX,FFFFFDC9
0008:100132FB 81FA0605FFA5 CMP EDX,A5FF0506
0008:10013301 7404
JZ 10013307
0008:10013303 B001
MOV AL,01 *same
0008:10013305 EB0D
JMP 10013314
0008:10013307 8B500C
MOV EDX,[EAX+0C]
0008:1001330A 85D2
TEST EDX,EDX
0008:1001330C 7404
JZ 10013312
0008:1001330E B001
MOV AL,01 *same
0008:10013310 EB02
JMP 10013314
0008:10013312 B001
MOV AL,01
0008:10013314 83C418
ADD ESP,18
0008:10013317 C3
RET
So we managed to dump ida.wll and replace the crypted one with a almost virgin one.
Your ida is now working well, decompiling everything without errors, and not signing the files, as an exercise we can bring back the *.w32 and *.ldw to their *almost* original state. We will use the same technique to dump, rebuild the header and change the entry point to base address +1000.
But this time you have errors when the loadlibraryA function called from ida
tries to load the module, we take pe.ldw as a target practice.
You can use a great tool called Pebrowse to compare pe.ldw original to the
dumped one, it will show you that the import section is not
the same on your dumped module, why ? Because when you dumped it, your windows
changed the api addresses inside this section and those addresses are not working on your dumped module.
The import section is damaged. Where is it located, look in procdumps directory structure: import table = 178f4 (virtual address)
What is the corresponding file offset ? Look at the sections : .adata Virtual offset 17000 and Raw Offset f200.
The raw offset is (178f4-17000) = 8f4 + f200 = faf4
You see here the imported functions on ascii style with you hex editor. You
can do two things :
the most interesting is to learn, check in pe.txt the
import table structure and rebuild it yourself, I did that, it takes times but
you will get great rewards
in you future cracks.
The easy method, get the import section from your original pe.ldw :
0000889C 6172 7920 2573 0090 C178 0100 D278 0100 E578 0100 0000 0000 6B65 726E ary %s...x...x...x......kern
000088B8 656C 3332 2E64 6C6C 0000 0047 6574 5072 6F63 4164 6472 6573 7300 0000 el32.dll...GetProcAddress...
000088D4 4765 744D 6F64 756C 6548 616E 646C 6541 0000 004C 6F61 644C 6962 7261 GetModuleHandleA...LoadLibra
000088F0 7279 4100 0000 0000 0000 0000 0000 0000 B478 0100 A478 0100 0000 0000 ryA..............x...x......
0000890C 0000 0000 0000 0000 4479 0100 5779 0100 0000 0000 0000 0000 0000 0000 ........Dy..Wy..............
00008928 4C79 0100 5F79 0100 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 Ly.._y......................
00008944 6964 612E 776C 6C00 7573 6572 3332 2E64 6C6C 0001 0000 8000 0000 0067 ida.wll.user32.dll.........g
00008960 7901 0000 0000 0000 0045 6E75 6D54 6872 6561 6457 696E 646F 7773 0000 y........EnumThreadWindows..
compare this place to your dumped pe.ldw and copy all the bytes from 889c to 8962 from original to your dumped ldw.
The import section is now restored and points to the good api's addresses.
Don't forget to : rebuild the pe header, change the entry point and rebuild the import sections on all the modules ldw or w32 that you want
and they will be all decrypted, you can now decompile them with ida if you want to look further.
As an example I did that on my pe.ldw and nolan's pe.ldw, three places in the
dumped files still differs (first your license info in plain ascii text
in the header, easy to remove, and two other places in the files. So my essay
stops here and I still will not explain you how to remove the last
watermarks, search for yourself, it's an easy thing for you if you understood
all the essay.
If you manage to remove the last watermarks, don't spread this cracked tool. Software protections are getting more and more hard to defeat. You could compromise further updates of ida if you do that, so you will work against you reversing potential.
Here's a snippet of a word from Pierre Vandevenne, the product administrator :
**/**Re: Re: IDA 4.01 changing thoughts...
**/**
At this day 14/2/2000 the ida 4.02 version still injects your ida.key into idb database...
If something is wrong, or updates are needed to allow this on win98 or nt4, send me a word.
Greetings,
+Tsehp
homepage
links
search_forms
+ORC
how to protect
academy database
reality cracking
how to search
javascript wars
tools
anonymity academy
cocktails
antismut CGI-scripts
mail_Fravia
Is reverse engineering legal?