Core Dump

I sometimes lament the fact that most software people do not have the necessary hardware knowledge to understand how computers actually work. A software person may think that the algorithm is secure simply because he/she had obfuscated and encrypted both the library and the application software using the library. A software person may think that it would take years to break the encryption and obfuscation.

Unfortunately, I have a very bad news for these software people. The hardware guys totally agree that encryption standards today are so strong that there is no point attacking your algorithm at the software level, which is why hardware people always attack these problems at the hardware level. The primary problem, you see, is that there is no microprocessor that executes encrypted code. All code will need to be decrypted at some point, and stored in-memory for the processor to execute. That is where the hardware person will attack the problem. The typical hardware person would just dump the memory and then read and interpret its contents, which is much easier than it actually sounds. It is fairly easy to differentiate random data and proper sequence of instructions in-memory. There are tell-tale signs that any embedded programmer would be able to read.

In fact, even if you do not store your encryption algorithms nor encryption keys in external memory but choose to store it in the on-chip cache, it is still possible to force the processor to evict that cache content into external memory and then steal the code from the memory. All these are fairly standard hardware debugging techniques that need to often be used to verify that hardware works. For example, if a processor isn’t doing what it is supposed to be doing, one of the first things that a hardware person needs to check is that the programme in memory is actually being executed by the processor (and it is not just sitting there in memory).

And with today’s virtualisation technology, it makes the job much easier to do. It is possible to run the secure application in a virtual machine and to dump and inspect the virtual machine’s memory while the application is actually running inside the virtual machine. That is one of the cool advantages for using virtual machines that every software developer needs to learn. The hardware person does not need to actually crack the encryption protecting the software nor does the hardware guy need to debug the code inside the operating system. It only needs to be intercepted at the virtual machine level.

It is something that people should just be aware of, especially people peddling security applications.

PS: In case anyone was wondering why there are no processors that run encrypted software, the reason is again due to software. It would be a nightmare to debug the software written for an encrypted processor.

Published by

Shawn Tan

Chip Doctor, Chartered Engineer, Entrepreneur, Law Graduate.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s