Log in

View Full Version : Article: Software Security Through Targetted Diversification


Kayaker
September 6th, 2006, 00:33
Hi all,

This link was posted over on ARTeam by Shub-nigurrath, I'm just stealing it..

Software Security Through Targetted Diversification
http://www.cosic.esat.kuleuven.be/publications/thesis-122.pdf

The paper is a thesis which discusses the idea of creating software which is distributed as polymorphised versions, in an effort to discourage automated or generic cracking of it. Specifically it suggests the use of Genetic Algorithm (GA) programming to create a diverse population of software for distribution to the masses.

Being a thesis, it does have its dry and theoretical moments and parts of it are introductory and aimed at the uninitiated, but the section on implementing the genetic programming polymorphism might be of more general interest here.

The paper also discusses a way of attacking such a scheme through automated pattern search analysis but suggests that the addition of the polymorphic security layer makes this relatively unfeasible.

For those who like the challenge, this last assertion might be an interesting point of discussion..

Cheers,
Kayaker

LLXX
September 6th, 2006, 23:41
Many packers/protectors already have polymorphic code in them - two examples, TheMida and EXEcryptor come to mind. ...and yet both have been successfully cracked.

Polymorphic virii are not new, yet virus scanning software still detects them properly. The code analysis does not focus on which registers/memory locations/etc. are specifically used, but rather the overall functioning of the code.

Shub-nigurrath
September 7th, 2006, 02:00
well, the concept is a little different than polimorphic. It is of releasing the same program in different versions, different binary images so as an universal crack has less opportunities to apply on it: image the last step on an industrial chain, where the program is written on the distribution cd or the web site backend that handles the button "Download". There the program is assembled dynamically using different protection options taking them from a basket. The result is each time different and crackers have less opportunities to write a generic patch, given that there are not two binary equal versions of the same program.

The polimorphic code is just the same program distributed with an even complex protection, but just a single distribution.

Silver
September 7th, 2006, 08:05
It's a good idea but has practical difficulties in operation. If you're trying to create a truly "dynamic" protection then the changes must be made on the fly, at download or distribution time. In other words you can't build 10 versions of the code then release those 10 versions, because all the crack.exe will need to do is to hash the exe and apply the correct patch. But if you're making dynamic changes to every package you release, you're effectively also releasing untested code. That's risky.

Increased protection diversity makes it difficult to crack but with a higher risk of instability. Conversely a smaller subset of protection (Shub-nigurrath's "basket" makes it easier to crack but with a lower instability risk.

The closest thing to this is the embedded signatures in IDA.

naides
September 7th, 2006, 09:14
Just my thoughts here:
First of all we need to cut Gert (The author ) some slack. . . This is a thesis: He is supposed to find, research and expose an interesting problem, then come up with an ingenious and innovative solution that is workable, at least in theory. I would not expect a Engineering school thesis to solve, once and for ever, the problem of software protection.
He chose to attack the problem of automatic patchers, and suggested an interesting solution to deal with this issue.
I think his polymorphic code approach does have gaps: It defeats a dumb, hard coded patch program, pattern search patchers and some more sophisticated automatons. But if instead there is a human cracker at the other end, it actually HELPS the cracker. His obfuscated, polymorphic code, which necessarily has to be located to a limited area around the critical protection, will act as a Waving Flag, pointing to the Hot areas of the code, saving the cracker quite a bit of searching.
In one approach, a cracker may collect a small set of polymorphic versions of the software, do a group compare, then accurately locate the polymorphic segments of the code.
All that is left is to write a smarter patch program , which uses one working, cracked version of teh file as a template to repair every possible variant, by simply inserting the template code at the right places in the target file. All this done at the disk level, without sophisticated debugging.

Another possible problem with this polymorphic gneration scheme, is that patching is not only done for the purpose of cracking. It is also customary to distribute small size updates and bug/security hole repairs for programs. Gert’s approach may prevent or complicated such patching.

deroko
September 7th, 2006, 13:17
Quote:
[Originally Posted by naides]
Another possible problem with this polymorphic gneration scheme, is that patching is not only done for the purpose of cracking. It is also customary to distribute small size updates and bug/security hole repairs for programs. Gert’s approach may prevent or complicated such patching.



The Mental Driller has researched this updated problem with plugins here : http://vx.netlux.org/29a/29a-6/29a-6.205 , very interesting concept.

Also I remember someone writing, I think it was IBM, about undetectable virus and very soon we got zd10 viri by z0mbie so maybe someone will implement this thesis too

SiGiNT
September 7th, 2006, 22:43
Definitely not a trend setter, but, I ran into a small prog out of which I made a self keygen, subsequently a friend of mine tried the patch and it wouldn't work! so I went back and re-downloaded the prog and bingo the patcher won't work - turns out every other time it's downloaded you get 1 of 2 versions, both with the same ver. # and build # - interesting part is in one version the serial is twice as long as the the other, but the first half matches, presumably when you purchase this you get the long serial - BTW another interesting thing - the prog was a no installation, single executable, with no accompanying EULA - so it was "fair game", an unusual find, but I have run into one other when disassembled contains encouragement to try and crack it!

SiGiNT