5 ms·
>This repository contains RCEd code extracted from Stuxnet binaries via disassembler and decompilers. Is there a way to write code (make binaries) such that it
by max_ 3y ago
>This repository contains RCEd code extracted from Stuxnet binaries via disassembler and decompilers.
Is there a way to write code (make binaries) such that it would be extremely difficult to recover the source code via decompilers or a disassembler?
- karatinversion 3y agoThere’s always movfuscator [1] [1] https://github.com/Battelle/movfuscator https://github.com/Battelle/movfuscator
- misja111 3y agoYes, there are many ways to do that. When writing in a higher language such as e.g. C, you can use code obfuscators to make your C code extremely hard to read. If you want to make decompiling even impossible, you could modify the machine code generated by the C compiler. Even slight moderations are already enough. If you want to make it (virtually) impossible to even disassemble the machine code, you could encrypt your binary itself except for a small bootstrap that will unencrypt the remainder of the binary when it runs.
- lozenge 3y agoAnd the countermeasures for that: DEP or pause the program after decryption and inspect its memory.
- misja111 3y agoYeah true. But at least the virus binary might be able to get passed the heuristic checks of a virus scanner.
- inetknght 3y ago> When writing in a higher language such as e.g. C, you can use code obfuscators to make your C code extremely hard to read. Obfuscating C code shouldn't have any bearing on the decompilability of the output. > If you want to make it (virtually) impossible to even disassemble the machine code, you could encrypt your binary itself except for a small bootstrap that will unencrypt the remainder of the binary when it runs. Unencrypting the binary at startup is somewhat easy to hook into. It's harder to decrypt each individual function when that function is called and then re-encrypt it after the function ends. Bonus points if you re-encrypt after each `CALL`. This is stuff which was available back in 2003 -- that's when I first used techniques.
- tlb 3y agoThere are obfuscators that also make decompilation difficult. See the "two approaches" section at https://www.star-force.com/products/starforce-obfuscator/ https://www.star-force.com/products/starforce-obfuscator/
- jonpalmisc 3y ago> Obfuscating C code shouldn't have any bearing on the decompilability of the output. This is the entire point of obfuscation and it absolutely does affect how easy the code is to reverse engineer. If it didn’t, there wouldn’t be a market for obfuscators.
- misja111 3y ago> This is stuff which was available back in 2003 -- that's when I first used techniques. It was available already in the 1980's, so I learned at the time when I was manually disassembling computer games hoping to be able to crack them.
- arsome 3y agoIt already is quite difficult to recover to this level, even for a relatively small malware codebase this probably took hundreds of man-hours to decompile into a meaningful state. To protect it beyond a basic level - You can try but it's a cat-and-mouse game. A sufficiently skilled reverser will drop a debugger on your program, execute the code until it's past any decryption and then dump it from memory. So better schemes to obfuscate applications have been developed, like VMProtect, which makes a simple virtual machine with a custom instruction set and uses it to obfuscate your application. It's of course possible to break that as well, but it takes more time and requires more skill.