CRCs r.i.p.?

[Extremist]

http://www.scs.carleton.ca/~paulv/papers/tamper.25feb05.pdf

Comments?

[Shub-nigurrath]

mumble really interesting..will read soon!

[Extremist]

A new 'n improved version:

http://www.scs.carleton.ca/~paulv/papers/tamper.TDSC.18apr05.pdf

[omega_red]

Very interesting reading indeed. Good to see such a creative ideas around

[Shub-nigurrath]

well, not coming from the scenes indeed..anyway that practical on windows systems, because there's the assumption of being able to modify the kernel. While on linux systems is easy, isn't so on windows' machines..despite some "holes"..

Is interesting on the other hand to modify the virtual machines to accomplish such attack, it's an opportunity the authors don't explore

[JohnWho]

This sounds like the old method used on ASProtects CRC check. Patching aspr to make it's CRC check on a backup of the original .exe! This of course still works, tho patching the mapped .exe is a much better solution.

[Shub-nigurrath]

no no, the thing is completely different..the only analogy is that you divert the executed code and the code used to calc the crc, so breaking the assumption I(x)=D(x), where I are instructions and D are the same instructions accessed as data to cal the crc value.

[JohnWho]

Quote:

[Originally Posted by Shub-nigurrath]no no, the thing is completely different..the only analogy is that you divert the executed code and the code used to calc the crc, so breaking the assumption I(x)=D(x), where I are instructions and D are the same instructions accessed as data to cal the crc value.

Hehe well i didn't actually read much of that doc more looked at the illustrations and highlights Maybe i should read properly


*EDIT*

Okay i read a bit more:

Quote:

1. The attacker makes a copy of the original program code. 2. The attacker modifies the original program code as desired. 3. The attacker modifies the kernel on the machine, installing a kernel module or patch designed to implement our attack. 4. The attacker runs the modified code under the modified kernel. During the attack, the attack code in the kernel will redirect data reads(including those by the checksumming code) to the corresponding information in the un-modified application.

well this sounds just like the old aspr method except that step 3/4 is kept in the target instead of modifying kernel.

I still haven't read it all so i might have missed something. I'm too tired to go through so intense material, will get there eventually