A Crypto Trick That Makes Software Harder to Reverse-Engineer

Re:A Crypto Trick That Makes Software Harder to Reverse-Engi... by ars on Thursday February 12, 2015 @01:43AM (#9037747)

Isn't this trivially (for some definitions of trivially) defeated by running it inside a virtual machine?

You don't need an expensive JTAG device when the virtual machine gives you that ability for free.

[ Parent | on HN ]

Re:A Crypto Trick That Makes Software Harder to Reverse-Engi... by AlyssaRowan on Thursday February 12, 2015 @02:00AM (#9037785)

We have a winner! Yes.

People have been hiding crypter variables in debug registers since… the early 90s was the first I saw it? Sure it might have tripped up those who thought SoftICE was the bee's knees, but those of us who had access to (or wrote) emulating debuggers - which had "debug registers" and a functioning "MMU" just fine - sailed right through this sort of thing and could just read the obfuscation code and adapt it to dump the unencrypted code right out.

Hell, with this, we wouldn't even have to translate/recompile bytecode, the MMU did all the work.

[ Parent | on HN ]

Re:A Crypto Trick That Makes Software Harder to Reverse-Engi... by Ded7xSEoPKYNsDd on Thursday February 12, 2015 @04:39AM (#9038108)

Yes, however I'm not aware of any virtual machine (including emulators) for x86 that isn't trivially detected.

[ Parent | on HN ]

Re:A Crypto Trick That Makes Software Harder to Reverse-Engi... by Tegran on Thursday February 12, 2015 @05:09AM (#9038181)

But the VM detection has to occur BEFORE you setup the clever encrypted CPU stuff so that code is then vulnerable to the usual debugger cracking techniques (without worrying about the encryption stuff).

[ Parent | on HN ]

Re:A Crypto Trick That Makes Software Harder to Reverse-Engi... by AlyssaRowan on Thursday February 12, 2015 @08:00AM (#9038569)

Deadlisting. :)

Competitive advantage from tool exclusivity.

[ Parent | on HN ]