Dozens of umbrella approaches are used to create computer programs. Despite all the different concepts, writing styles, languages, and tools for making source code, the result is a computer program file (or what would be in a file is in memory). Each operating system spells out what these files should look be organized. This way, the operating system can qualify and run computer programs according to the rules it has defined. Regardless of how the code is written, when it gets transformed into an actual computer program, the parts that hold information goes in one of a few areas and the parts that do things go into a few others. Programs that have flaws can be cracked partly because the finished computer program file can be inspected in a straightforward way.
Cracks Start with Research
People who crack programs may study a program to see how it works in detail. Source code is not required to do this. In fact, source code is fully irrelevant because is not about what the code says, but how the code actually is when it is in the form of actual computer code. Just the finished program is enough along with automated tools, skills, and time. The goal is to learn how the program goes in actual practice in order to learn how to go into the program when it is operating. You study the hand offs between different parts in the program and whatever flaw exists is your door into the program. Once you are in, you can sabotage the program to present false information or siphon off actual information.
Robert Seacord mentions some tools in chapter 3 of his book, Secure Coding in C and C++, that are provided by Microsoft to encrypt some aspects of a computer program. This is actually a great idea, but I do not think it works. The quintessential problem with most encryption is that the information has to be decrypted at some point. At the point of decryption, the game is over. If you narrow well the gap in time between decryption and erasure of the decrypted data, you have a higher chance of sustained security, but the nature of automation can limit this greatly. Also, forget about encrypting the program itself. In principle, encrypting a program generally means running code on the fly and that is so error prone as to be itself a source of security vulnerability. Still, program encryption may be a direction worth pursuing. It could one day be a viable solution as it could more greatly limit productive efforts to crack programs.
So far, I am partway into chapter 4 of Robert Seacord’s book, Secure Coding in C and C++. A common theme that is developing is that the first, best way to diminish program and data compromise is to write the code very well. I would expound on that to say avoid trendy code practices and, instead, focus on solid, clear-cut and prudently written code structure. Much of what I have just said may be less relevant to newer programming languages and tools, but since they all translate down to the same form, a measure of prudence may yet prove beneficial.
Operating systems and programming platforms could do well to have strict modes that better isolate program code. One program, or the code therein, should not be able to talk to another program, or it’s code unless highly defined mechanisms exist to allow this. Any action that occurs not in observation of this principle, from top to bottom, would be disallowed. In reality, there are things in operating systems and computer processors that add some element of what I have mentioned but the continued cadence of patches for identified data breachable flaws shows us that a broader level of improvements are possible.
In a networked world in which the stakes are pretty high, certainly operating systems on servers, desktops, laptops, mobile, and embedded devices like routers and smart appliances could improve as stated. A huge challenge concerns tools for inspecting, diagnosing, and managing programs that are a legitimate part of the creation and software administration process. Hard challenges are opportunities and one I am sure the market, commercial or gratis, would recognize.
The Part of the Software Writer
The migration of these ideas into the broader consciousness is gradual. A reason for that is some tools and technologies are advertised or implied as having no association with the program flaws of the past. I bought into that once upon a time, but I had used some of these technologies long enough to see that many of the claims were unrealized in practice. You can overcome deficits in execution by applying measures of your own to the extent latitude exist in the tools, operating environment, available knowledge sources and process allows. That is the real benefit of Robert Seacord’s book. He communicates the ideas of his field of research in a way that greatly improves the understanding of his audience.
As I am going through his work I am reminded of things like code injection. Code injection, by several names, is when you have a main program and you can add in new code so you don’t have to push out the entire program. Seems like a good idea and it could allow you to speed up the maintenance and revision of programs, but in light of the potential for abuse by third-parties, is this really a good idea? Code injection may be an unwise means to achieve flexibility.
Whatever tool you are using, being better informed of the ground level issues can be useful. A tool may have certain aspects to it that reduce the chance of the kinds of issues spoken about here. I am reminded of advice given in Microsoft ASP.NET web application programming. The advice is to write and configure ASP.NET web applications in such a way that if the web page crashes, make sure there is no unintended disclosure of information. It was part of Microsoft’s Patterns & Practices for ASP.NET. During the time these suggestions began to circulate, mitigation was not automatic. What caused the crash? Often, it might be an item you programmed the web page to access but when it went to access it, it was not actually there. In technical language, you had a null reference or you exceeded the bounds of an index. The scenario applies to some forms of Java programming as well. It is the same things Robert Seacord is discussing in the book.
Even the Trivial May be Important
Some insight may be found in the beginning of chapter 4 of the Robert Seacord’s book. He alludes to the precaution taken in most safety critical software. I would assert that all of our data, potential privacy and the accurate portrayal of data and proper functioning of systems under normal conditions is a safety critical matter if not for our financial disposition, the social ones that follow.