The point came up that, "What if a program checksums code segment?" One solution I thought of was, what if, instead of hooking the code, you hooked, say, winsock.dll (or ws2_32.dll or whatever) instead, so the checksum of the code wouldn't change? Since there are many versions of winsock, it's doubtful they could have a valid checksum for that.

Then we talked about, what if somebody wrote a program that could analyze a .dll, pull out the symbols and ords, as well as the code for them, and prepare a .c file that, if compiled, will produce a near-identical .dll file. That way, you can easily write your own hooks in c without having to worry about modifying the program while running.

Just wondering how feasible this is/if it's been done before/if it could be useful. :)

[quote author=iago link=board=23;threadid=3406;start=0#msg27356 date=1067976216]
we[/quote]
Who?

[quote author=iago link=board=23;threadid=3406;start=0#msg27356 date=1067976216]
a program that could analyze a .dll, pull out the symbols and ords, as well as the code for them, and prepare a .c file that, if compiled, will produce a near-identical .dll file[/quote]

IDA: File -> Produce -> ASM File
Your idea, but ASM instead of C. This makes a .asm source file that can be assembled with (I think) MASM.

[quote author=Yoni link=board=23;threadid=3406;start=0#msg27363 date=1067978528]
[quote author=iago link=board=23;threadid=3406;start=0#msg27356 date=1067976216]
we[/quote]
Who?[/quote]
us!

[quote]
[quote author=iago link=board=23;threadid=3406;start=0#msg27356 date=1067976216]
a program that could analyze a .dll, pull out the symbols and ords, as well as the code for them, and prepare a .c file that, if compiled, will produce a near-identical .dll file[/quote]

IDA: File -> Produce -> ASM File
Your idea, but ASM instead of C. This makes a .asm source file that can be assembled with (I think) MASM.
[/quote]

hmm, that could work too, I guess :)

It's much easier to hook the function pointers used to pass control from application to dll - i.e. patch the import table.

But the idea is not to modify the actual program, which, I would think, includes the import table.

It can't checksum the import table because the import addresses depend on the system. You could also modify the export tables of the dlls.

Note that it would be trivial to locate the code doing the checksum with a break-on-access breakpoint set via the debug registers.

Yes, but editing the checksum algorithm may be tricky, and you may only have one chance to do it.

And Adron's right, I hadn't really thought about that :)

Mind you, this is purely theoretical. I can't think of any program that's actually done it, but some speculate that Diablo 2 1.1 might have implemented protection that works like that, which is what brought up the discussion. But there is no confirmed case of that that I have heard of.

AIM OSCAR protocol used to (- not sure about if it does now or not -) send a request for a hash of a certain amount of data randomly from the AIM files on a periodical basis. This sound similar to the thoery you outline about diablo 2 -- not having diablo2 (yet alone the amazing, mystical 1.10 patch that took so long) installed I wouldn't want to speculate on that theory.