4 ms·
I quite like this - nothing is going to stop companies wanting to secure their code on customers' machines, and this is at least an elegant way to do it. I do
by tehwalrus 13y ago
I quite like this - nothing is going to stop companies wanting to secure their code on customers' machines, and this is at least an elegant way to do it.
I do see problems though, e.g. people trying to make malware could use this very effectively: make a small pointless change, reencrypt, repeat, you then have a pseudo-unique malware signature across as many PCs as you can reach, so antivirus is useless.
- VMG 13y agoYou don't even need to change the source, you just use a different key.
- tehwalrus 13y agoI was imagining a random unused string somewhere in the code / random uncalled function. If you use an encryption key to actually generate the obfuscated program (I wasn't sure the article was saying you did,) this is clearly not required.
- VLM 13y agoA different salt might be another way to phrase it.
- rainforest 13y agoWouldn't this be easily solved by behavioural analysis? I'm not even sure what AVs do these days but I'm sure at least one sandboxes all executables for a while to see if they do anything suspicious before letting them run normally. The re-encrypted malware would presumably make the same system and library calls in the same order - you don't need to know what the code looks like, just how it behaves. As far as I can tell this method presents the same problem to signature detection as randomly inserting noise into code caves in the binary. The real target of this obfuscation is making reverse engineers lives difficult.