I read up on some basic tips for decompiling an executable. That is, I learned how you can take an executable, and reconstruct the source code used to build the software. There were a number of things listed that made it hard to understand how to decompile an executable. I thought I would use these difficulties to make my most secretive applications hard to reverse engineer.
One thing that slipped up the hacker is compiler optimizations. Yes this will slow down your application build. But you can turn it on at the end when you are doing the final release of your software. The compiler will work harder to make your code fast and/or small. The result is that it is more difficult for somebody looking at the binary to figure out what is going on.
Another thing that trips up decompilation is the use of user defined types. In the C programming language, that means use structures. Somehow the access to memory of such constructs makes it hard to reverse engineer. This is good news. Using structure is good programming practice anyway. We use that for our production code at work. I might a well use it on home programming projects where I want to keep the source code secret.
To truly combat the decompilation process, you probably need to spend some time trying to crack binary executables. Then you will have first hand knowledge on how to make it harder. However I figure I could take one expert’s advice and use it to my advantage. That is a way to work smarter and not harder.
LeetCode Getting Downright Ugly - I continue doing LeetCode exercises. Worked on another "Medium" difficulty problem today. Seemed straightforward enough. Find the longest length of any su...