Re-release "Item Validator"

[Vormav]

Originally Posted by SheenBR
would be nice if you could translate all the function to C.. after all you did, I guess it wouldnt be that hard lol

Not at all sure about that, but I guess you could write a DLL / LIB to compile in C which incorporates this routine as in-line assembler:-

It also have some values that are "generated" by server.
I disassembled it to TASM syntax and I saw more calls that than. I think current method is "preferable". Clean and easy

Btw. if I may ask, how long ago did you got this stuff? Do you have more hidden goodies?
I simply would like to know history of this tool, was it invented for some server? Why some "random hack maker" would make tool that is server sided.

 

[bobsobol]

I disassembled it to TASM syntax and I saw more calls that than.

Nope. I "broke out" the calls in that translation.

If a "call" is only made once, and not part of a loop which would otherwise become a "long" jump, there is no point in representing it as a function / subroutine in it's own right. Especially if it's parameters are "void".

The thing which worries me most is the Unk1-3 values which are 0 when the image is loaded. In particular, Unk3 is loaded into a register only once, and never written to. If that is how it is designed to work then the register should simply be XORed with it's self. I'm sure some other routine must affect that memory location without being called from, or calling to that routine.

However, if the value is not constant, I can't see how the hash would produce a consistent value either.

 

[mixteczinho]

Don't know if I did it by the harder way, but I tried to "brute force" the checksum algorithm by getting some sections of .ITM file, XORing with bytes from 0x00 to 0xFF, and generating a crc32 checksum, but got no success on validating a modified item.
Maybe checksums are generated with some formulas like login packet encryption, that doesn't uses a single byte to XOR the whole packet of bytes?

 

[bobsobol]

The disassembly looks like a simpler algorithm along similar lines to MD5 to me. The long list of calls to Hash1 or Hash2 are usually written as a Macro when you actually assemble / compile them from source.

As for "better way to do it", if you rebase a PE of your own which calls LoadLibrary to load "4096.exe" at it's normal virtual address, you can make those calls in the server executable without having it running in the background.

The concern about Unk3 still stands in that case though.