Reverse Engineering a Hex File

Hi Guys, I have recently completed the design for my first product based on the Fez Cerberus board, the product is powered by a detachable Mini USB cable which connects to 3-Pin UK style plug, this Mini USB can also be connected to a PC to program the Products PCB as well as using Fez Config to read its Hex file. Is it possible for someone to reverse engineer this Hex file to see all Class/Methods etc that would have been in the original VS Solution?

@ andre.m - Hi I downloaded this program “Eazfuscator.NET” which claims to obfuscate everything in the release folder, I tried it out and used .Net Reflector and all my Classes/Methods did indeed appear obfuscated. So I decided to deploy the release folder assemblies and everything worked as expected but when pulling this new Hex file using Fez Config, it’s exactly the same size as the Hex File for when I deployed Unobfuscated assemblies

@ andre.m - Okay perhaps not, how would I go about Reverse Engineering the Hex File?, I’m curious to see what it exposes.

I have not personally tried this, but this might be useful : Peering Inside the PE: A Tour of the Win32 Portable Executable File Format | Microsoft Learn
It is the PE file format. Presuming that the HEX file retains PE structure, that might work on it.

If not, then you are certainly going to find IL code in there somewhere, and any good ID disassembler will work.

Is your concern that people will reuse your hex bytes, or modify them? If your concern is reuse, then maybe some kind of hardware interlock would be better than obfuscation. For instance, a computed hash based on some Mac address and config value.

If your concern is revealing some intellectual property in the code, then that’s a way harder problem and you can spend a lot of resources and never get full protection. Short of a TPM chip and runtime decryption of the binary, the most you can hope for is to make it just hard enough to be not worthwhile for someone to pursue.

@ mcalsyn - Thanks, I just want to protect the code, looks like I’ll have to use Refactor to rename Methods/Properties with random strings and minify, there’s only about 10 classes in entire solution so shouldn’t be too much work

Obfuscation only changes names of variables and functions and inserts dummy code.
It makes it a little bit more difficult to reverse engineer but it is still possible.
The only way to make reverse engineering really hard for a cracker is to write code in C or C++.
But everything you write in .NET will always be and stay reverse engineerable no matter how you try to protect it.
It lies in the nature of .NET.

1 Like

Yes - you just move up and down the scale of difficulty. If code reverse engineering was impossible in any given language, then all the virus researchers would be out of business. That said, IL code can be particularly easy to map back to the original source structure.

If you have some magic algorithm in there, you’re don’t have much protection - the best you can do is to build in some node locking, but of course, even that is no real obstacle to a determined hacker.

I’m curious about this. You do realize that the Cerberus is not licensed for commercial use w/o special arrangements from GHI, correct? I’d hate to see you get into any problems post-release.

As Dr. Evil has often said cracking a program is like standing on the train tracks and wondering where the train goes, just follow the tracks. Any program is a set of instructions and no matter the language is crackable as at some point in time has to be instructions that the CPU understands. Interpreted languages are often easier to crack as at some point they end up as something the interpreter has to understand and that is at least on level up from the metal. At best you can make it a bit of an effort to crack but you can’t make it impossible.

Understand the asymmetry of hacking, the hacker always has the advantage so don’t let fear of hacker stop you.

1 Like