System Forensics - Part 2

(Ref Id: 1433085324)

Before going much further let's think about why you would be reviewing a system in the first place. The most obvious reason is the one that will serve you best -- curiosity. This is a bit like the motivation to learn a different language or to discover the flavors of beer in Europe. You are driven by a desire to 'know.' In the purest sense, that is the best desire to have.

Next, below this pure desire to know, is the desire to take a system that is Open Source or freely available and make money off of it. It is a weaker desire because it is less patient than the first. When one is on a quest for learning and knowledge lots of sharing and new ideas ensue. The quest for money on the other hand is somewhat binary -- it is bit like taking a look under the hood of a '78 Chevy. The value you are looking for is there or it is not. No further discussion is warranted.

There is indeed a third motivation but it is hardly worth discussing. It is the desire to trounce someone else's solution and claim that your own is so much better. This is the sport of the bored and unimaginative. It is not unlike studying aboriginal peoples to highlight their shortcomings when, in fact, viewed from a larger perspective they mimic our own. It is best to get out of the habit of looking at technology through this lens if you find yourself infected by it.

First Stop: Documentation

Before doing too much make an effort to identify and actually read any documentation that accompanies the project/tool. It is true that sometimes developers are leery about keeping this stuff up to date. That should not matter early on because you want to get some idea about the motivation for building the solution and some architectural clues that will help you navigate the source tree. You will be looking for:

A five minute read through available documentation can literally save you hours later on. Nevermind that it is probably ugly and messy. Just read it.

Next Stop: Code Analysis

Computing solutions are often written predominantly in a particular language so the source code files are probably inside of physical files with a particular file extension. This means the entire source code tree will often reside inside of a series of folders that you can scan through.

In the LIMSExpert.com Documents section you'll find a series of documents created via scripts for the Open-LIMS system. This was done to foster communication between remote analysts, but a similar method can be used to learn a system. The scripts number the lines of each file and move them into documents with the entire file name included before each entry. This is very useful in source code analysis because associations can be produced simply by searching through the document.

Let's take an example. Let's say (continuing to use Open-LIMS) we are in location.class.php and we open the file to find the following include statement:

require_once("interfaces/location.interface.php");

Interfaces? Where is that? The code uses relative paths, so this particular interfaces folder is underneath the current file location. The actual location of this file is openlims/www/core/include/location/interfaces. This means that the structure of this solution does not aggregate similar types of files in certain folders -- instead things are relatively stored. That would mean that one should expect to see an interfaces folder underneath other parts of the tree -- like under equipment (in fact, the interfaces for equipment are stored in /var/www/openlims/www/core/include/equipment/interfaces).

The goal at this point is to reduce what you have to read. Quick perusal of several interface files reveals that they are not too interesting early on. They can be skipped and referenced for later reading. Next up for Open-LIMS are the access classes. These abstract the persistent storage interactivity so you can expect to find mappings between properties and tables/fields/sequences/etc. in there. These too can be skipped early on so long as the authors were disciplined and kept actual business logic out of them (which appears to be the case). Once again, you can skip and reference these. The same can be done with the exceptions classes as well. They are useful to know but take up space in an analysis.

That leaves you with a set of files that are not inside of /interfaces, /exceptions, or /access folders. Very likely this is where the bulk of the business logic for the system resides for the Open-LIMS.

Summary and What's Next

Checking your motivations at the door is necessary before undertaking a task of this size. If you just want to poke at something and tell the world how much better your solution is then your time/effort is better spent proving that your solution has made clients actual money or saved them real time -- both on implementation and during subsequent rounds of upgrade. The analysis itself could start in various ways, but a good idea is to study what not to look at -- that is, to identify early on which classes are performing rudimentary and predictable activities. Then you can get to the heart of the system -- the architecture and business logic.

Next we will start to run simple tests against a system to see how it reacts to input.

Go Back

Citation: System Forensics - Part 2. (2015). Retrieved Sat Jul 22 04:45:29 2017, from http://www.limsexpert.com/cgi-bin/bixchange/bixchange.cgi?pom=limsexpert3;iid=readMore;go=1433085324