Reversing IDA 4.01
Watermarked protection scheme

8 Feb 2000
by Tsehp
Courtesy of Reverser's page of reverse engineering
slightly edited
by tsehp+
There is a crack, a crack in everything That's how the light gets in
Rating
( )Beginner ( )Intermediate (x)Advanced ( )Expert

A great tools deserves a great protection, and I was not disappointed by this jewel. You will deal here with RSA encryption of the main app and its modules, a license key checked everytime, reconstructing dumped dll's, and finally looking for false errors generated by the authors.
 

Reversing IDA 4.01 
Watermarked protection scheme

Written by Tsehp


Introduction

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 reverser 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.

Tools required

Softice 4.01
Nt_Icedump 1.6
Procdump 1.6.2
An hexeditor with binary file compare (hex workshop)
One Legal copy of IDA 4.01 (to apply this essay) Or two legal copies to check the watermarks.

Target's URL/FTP
www.datarescue.com

Program History

On this site, quine did some great work on previous versions. He managed to enable some crippled functions in trial versions and finally extended ida by adding new functions. You *must* read his previous essays about this.
Essay
The purpose is to make IDA work without watermarks. What are they ? They can take your name, strong encrypt it and put it inside a license file (ida.key) like a lot of downloaded trials. 

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 :

 

ida.wll (original)



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 :
 

ida.dmp



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

Not at the same raw offset, because this file expanded in mem when you dumped it and the size grew up.
You can rename your ida.dmp to ida.wll and find the 3 places to apply the patches I described above.
 
After you did that, you can void your ida.key at the same places I did :

ida.key



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.
 

ida.key



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 :

 

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.

Final Notes

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...
Wednesday, 09-Feb-2000 16:18:29
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  



Ob Duh
I wont even bother explaining you that you should BUY this target program if you intend to use it for a longer period than the allowed one. Should you want to STEAL this software instead, you don't need to crack its protection scheme at all: you'll find it on most Warez sites, complete and already regged, farewell, don't come back.

You are deep inside reverser's page of reverse engineering, choose your way out:


redhomepage redlinks redsearch_forms red+ORC redhow to protect redacademy database
redreality cracking redhow to search redjavascript wars
redtools redanonymity academy redcocktails redantismut CGI-scripts redmail_reverser
redIs reverse engineering legal?