Well, never found a paper about real IDA watermark, kind of impressive for a some people who consider themselves elite.

(that's the troll part of this post)

Now to serious things.

As you know datarescue implemented a watermark in each executable of IDA. This is something that strikes you when you manage to get two same versions of two different users.

Basically each exe is packed with Aspack, you'll notice the difference in size. Once expanded (Caspr works well), you will see that the files are very different, yet they do not have different features (obviously).

The catch is that the addresses of the sections are different, starting with the second. This implies that the whole code is different each times it makes a reference to data/code located in another section.

The size is different too... This might be caused by the linker, maybe I should worry about it though...

Obviously, IDA links a version at each requests from the users (anyone who upgraded their versions know this is possible) and this is how they can track leaks, even with a forged/hacked key...

So the solution would be to do some kind of plugin for IDA that would parse the executable and fix the addresses to another, a blank, neutral one, resulting in a completly unwatermarked version of IDA, if no other watermark is applied, of course.

You could code your own disasm engine too, and do something about it.

Their shit reminds me the metamorphic virusii in a much lamer way. I'm pretty sure their shit is only based on stuff they supply to the bcc linker.

Any remarks about it welcomed (plz don't post blah you're ghay to hack IDA, coz you're the only ghay here ).

Quine wrote some interesting stuff about reversing the watermarks in IDA a while back. You should check the Tsehp mirror. I am not so sure that it is linked for each user. I think they may have an obfuscation tool. IDA.KEY is also of interest. I think this topic is underdone because not enough people own a legitimate copy of IDA Pro. And even if they do they dont have 2 copies at their disposal. I am interested in the protection though and would be willing to colaberate. I assume you are talking about 4.30.

Snatch

No, I only managed to get two copies of 4.21. I can assure you the linking is different, it cannot be done by some obfuscation tool. I really know my way around compilers, and I can recognize the modifications were done at compilation (well linking to be more precise).

I read all the "essays" (as you guys like to call that) about that, but the key is no problem, it's mundane to remove it. The problem is to alterate the linking to remove the watermark. It's non-trivial, writing plugins for IDA is a pain in the ass, so I guess I'll quickly have to write a little ia32 disasm... :/

Yet there may be additional watermarks...

Datarescue greatest fear is to have an "unmarked" IDA hitting the black market, which is understandable. I'm a bit disapointed now though, coz I was expecting to find some kind of poly/metamorphic engine and found nothing...

Well once again I am going to disagree with you. They have several distributors. You are going to convince me now that they have given source code to all of them and tell them to do a different compilation process for each one. Sorry but I seriously doubt that. And I know that a new copy can be made in less than 10 minutes. I cannot tell you any more than that however. Remember. An advanced enough tool can do anything and even make it appear to be different linking. What your goal should be is to make the two copies you have identical somehow. Thus you elminate all watermarks. If addresses can identify the copy at that point then just change them all. Course we still have to worry about all the w32 files and IDA.KEY.

Snatch

thx for the info...

Can you tell me anything about the stuff you have noticed with respect to differences. I think if we make our own PE-Aligner we could somehow do this. Yes it would involve rewriting the entire file and almost all directories but it would probably kill the protection. And how would linking something again produce different results. Thats something strange to me because the linker usually just combines the object modules and builds the PE. But unless size or other things are changing durastically doesnt sound like it wouldnt reproduce the same thing twice. I would be interested in working with you on this.

Snatch

Basically I've noticed the addresses of the sections are different, after the first one. You can decide this at linking, amonst other things (like base address, etc.).

Since the .data sections have different addresses, the code is different (offset differs).

Why couldnt this be obfuscated after the fact. If the addresses are different that is a matter of simplicity. The relocation table has all of them. You could make your watermarker just load the whole relocation table and if the relocation in question is between the start and end address then add a certain ammount to it. You dont need a disassembler. You need a PE viewer that can actualy read not only what addresses are relocated but what is at each of those addresses. Now you have sparked my interest in this big time. It sounds that dewatermarking may be easier than we thought.

Snatch

if and only if this is the only watermark... Then you are right, parsing the relocations (if still present) would solve the problem...

The problem is that the size also differ... The following files appear to be different :

ida*.exe
*.ldw

*.ldo seem to be identical.
Most of dll I have tested seem identical.

The best way would be for you to get two copies of IDA...
CASPR will unpack without a problem your executables.

once i tried to compile the loder example from idasdk.
I got an error saying ident.obj could not be found.
searching the sdk for ident.cpp or ident.obj failed so i greped for 'ident' and found this line in loader.mak:
OBJS=$(F)$(PROC)$(O) $(OBJ1) $(OBJ2) $(OBJ3) $(OBJ4) $(OBJ5) $(OBJ6) $(L)ident$(O)
so for every loader you build it tries to link with ident.obj.
because of the fact that the sdk is just some headers and a library used to build ida itself and the fact that the file is called ident i jumped into the conclusion that ident.cpp must be the watermark!!

this can explain why the first section is diffrent from one user to another: because the watermark is in the first section (code i think).
and can explain how distributors watermarks ida: distributors gets from datarescue a distribution kit: all the *.ldo and other files that are not watermaked, all other files comes as a .obj file plus a utility (watermark generator) that produces ident.cpp, compiles it and links all the .ldw and ida itself aginst it.

If that is true, obfuscation could involve just nopping that area.
since this is the only static link of external code (all other functions are exported by ida.wll), my idea how to find the watermark without another copy of ida is to search all the .ldw files for similar blocks.

hope i helped.
Cheers.

Clearly file size normalization and segment and address realignment must be done as well though. Otherwise they could probably tell whose copy it was. If I had 2 copies I might experiment. But with 1 copy you can never be sure. The goal would be to take 2 copies. Deobfuscate and have them be exactly identical at the end.

Snatch

Hello Guys

I have found a solution to use Ida 4.30 Pro. Somebody had send it to me without the Ida.key and i had copied the Ida.key from my ida 4.15 Pro into this version and the version of 4.30 works without any problem.

Regards Taz

Hi,

I have my own IDA Pro ver 4.17

and bring a key from a friend and as Taz says it works without any problem. Is't possible to have the IDA Pro 4.30 FULL without the key and test it

KSA

That is far from a solution the watermark is not the key file. The key file is blatently obvious. The water mark is latent and in the w32 and exe files. It has to do with the alignment and filesize. If you release that IDA 4.30 you will screw over that person. They might as well have sent you their IDA.KEY it is just another lace in the protection the obvious one. So keep that copy private and dont screw over another user.

Snatch

One question about sparc disassembly .
I did the Sun Sparc disassembly sucessfully in the past .
Recently i try it in the 64bits (Solaris >2.7 ) . The IDA return the unknow format in elf . Does someone have the soultion for disassemble the 64bits Sparc elf file ?

Check out /usr/ccs/bin/dis (man dis). It comes with Solaris.

I've used it for several projects and it seems to do a reasonable job. Now if I can just get a handle on RE Windows stuff.

Ish