FD folks - I'd like to thank those who replied to my suggestion. I wanted to reply to a few points. The suggestion was to use code polymorphism and metamorphism on applications where it is desired to keep the innards of the application relatively safe. My thought was that this process would be done to pieces of code in an operation separate from development of the programs, using some sort of "code transmogrifier" to cause variations in the instructions used, the layout of the program, and the layout of its data, and to do so such that potentially every copy of a program would be different. This could make it fairly uneconomical to attack such code since, while reverse engineering of a copy would be possible, it would give little help in finding where to attack another copy. (I will use the term "transmogrification" to mean the modifying of code instructions and layout in a way that nevertheless preserves function.)
It is important that data layouts as well as code layouts get varied, as I think about this. For this to work, the transmogrifier must not alter the function of the code at all. This might seem a pipe dream, but the fact is there is malware doing this now. That existence proof is convincing, and might indicate that somewhere there may be code transmogrifiers already available. Otherwise one or more would need to be written. Think of this perhaps as ASLR on steroids. (Perhaps other drugs also <grin>). Anyhow, on to some points made. 1. This has nothing to do with writing code correctly or not, won't make good code bad or bad code good if the transmogrifier is implemented right. Nor is the intent to PREVENT reverse engineering. It is to make reverse engineering economically unrewarding. The intent is also not to hide bad code as such; function would get left alone. (Besides, how many of the Great Unwashed decide a piece of code is bad because they disassembled it and found it to be so?) 2. In writing and debugging a piece of code my notion is that you do so, and THEN apply the transmogrification process. Transmogrified code would still work and still be debuggable, but getting symbol tables and the like would be hard to do. Some of us have had to debug in octal or hex in our youths and I for one don't much want to go there again (and published a symbolic debugger that would work remotely so neither I nor others would need to, way back when too.) Thus the criticism that code debug becomes hard is partly erroneous, though reports of problems from the field will be harder to reproduce or check. I would imagine that as a transmogrification process got more mature, such might become easier. 3. A transmogrified program can still be handled as a black box. Its inputs and outputs, whether direct or via internal system calls, will remain visible. (This scheme would of course be harder to access if the operating system transmogrified everything on the way in, but even so system calls would have to remain workable.). At any rate, it is clearly a good idea for anything so handled to have as few system calls as possible - build it statically linked, built portable, so that libraries and so on are all in there already (and all get transmogrified with the rest). Then try and make sure inputs and outputs are well guarded, disguised, encrypted...so that there is not much for outside code to see or alter. This won't help with everything, but it will make it harder. The system is not 100% protection, and really cannot be. It can nevertheless hide some things. The thought was that a somewhat obscurely stored key in such a program might for example be tough to find if it were stored right, in layouts that were scrambled (and preferably stored in multiple places, or better, partly constituted programmatically. Therefore the fact someone can intercept some system calls the program makes has to be understood as a vulnerability, and programs trying to avoid this happening need to be designed to have as few such points as possible. Any external calls get outside the transmogrification boundary. (This was a good point to make though. A program can be attacked that way regardless, and to some degree if my program calls system call "fubar", every copy will call that system call and whatever can be gleaned from that call will work on any copy. If I analyze one transmogrified program, I can get an idea what that call might do. Of course, being aware of this I can also design my program so that this doesn't threaten much... 4. The point here is to raise the cost of attack, and yes, this is security by obscurity. It gives no complete protection. Where the code's input and output can be encrypted in some way (or encoded so that it is hard for malware to observe it and understand its i/o [though a human might be able to]), the code can have some secrets internally which might be used to perform some functions and yet make it hard for someone to steal the secrets of most of the copies of the code. The stuff malware does is not all just to avoid detection, but to make it hard to find where to hook in or to find data structures. If offsets vary and data layout varies and instruction sequences vary, the only places that will be easy to find will be some global entry points or possibly syscall sites and immediate arguments thereof. Tracking much else automatically will get to be hard. (Yes, humans can disassemble code and understand it, but it is a skilled activity and has been tough to teach programs to do it for years. Rearrangement will be most possible where the code isn't all the way to binary; you will want to get it before any address relocation is done. I expect something like a special link editor might be needed. Imagine an OS that did this kind of thing to its code as it loaded everything just for (far fetched) laughs. You could of course find main entry points, but finding internal places to patch would become a monumental pain. I've built such to search for some instructions to be somewhat sub-version-insensitive. This kind of thing blows that strategy out of the water. (It'd also make writing third party systems code a whole lot harder, whatever your motives. That's not something I am happy with, but I won't worry just yet ;-) ... Thanks for all the thoughtful responses though. Glenn Everhart Anyhow that is what has occurred to me about this. _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
