Software Diagnostics Institute

By software internals, we mean how software actually works instead of how it was intended to work. Intention and actuality may also coincide, but, sometimes, they don’t, especially in the cases of victimware and malware, and their discrepancy, therefore, cause various problems. Learning software internals, especially operating system internals, is a necessary step towards better software construction, effective and efficient troubleshooting and debugging, successful forensics, malware and vulnerability research.

There are different approaches to teaching software internals of operating systems and products. Some authors prefer computer science approach from general software design and architecture principles; some prefer software hands-on troubleshooting approach such as troubleshooting and debugging; some prefer reversing and deconstructive approach. Learners of different backgrounds may find particular approaches difficult to internalize. Here we refer to our own experience learning operating system internals when our main background was in software design, programming, and debugging (before we moved to software support to study software diagnostics).

We think that the ideal way would be to cover all aspects of software construction and post-construction using patterns. However, different phases of software evolution use different pattern paradigms. Software construction phase mainly uses software construction pattern stack of requirements analysis, architecture, design, and implementation patterns which are patterns of software construction problem solving. Software construction pattern paradigm considers patterns as solutions to recurrent problems of building software. Software post-construction phase mainly uses diagnostic patterns and debugging pattern stack [Analysis, Architectural, Design, Implementation and Usage Debugging Patterns, Memory Dump Analysis Anthology, Volumes 6 - 7]. Diagnostic pattern paradigm considers patterns as indicators of software behavior such as signals, symptoms, and signs describing software execution problems. Debugging patterns are similar to software construction patterns in documenting common recurrent problems of fixing software defects. They provide solutions to recurrent debugging problems. Similar can be said about problem workaround patterns and patterns of building software troubleshooting and debugging tools (Debugware patterns [Memory Dump Analysis Anthology, Volumes 2, 4, 6]). There is also a third pattern paradigm: software deconstruction patterns including reversing (ADDR patterns) and structural memory patterns [Memory Dump Analysis Anthology, Volume 5]. This paradigm just shows how things are really are organized before and during software execution including software / hardware interface.

In summary, we have three pattern paradigms corresponding to the domain of construction, post-construction, and deconstruction.

All three pattern paradigms are needed to describe software internals, its architecture, implementation, inner workings, and problem-solving. Instead of devising a new set of patterns to describe software internals we propose a pattern stack of existent patterns. In its rough and simple form it consists of 3 stack slots corresponding to 3 pattern paradigms:

Each pattern paradigm can be expanded into its own substack or a collection (when order is not important) of pattern categories:

Individual software internal features can be described by a concrete pattern stack of patterns from pattern category subcatalogs, for example, software fault processing pattern stack (only a few important conceptual patterns and pattern subcatalogs are listed):

We believe that teaching software internals, for example, operating system internals, using a pattern stack approach would appeal to all types of learners: software architects, software developers, software support engineers, and software security researchers.