Programming for Digital Forensics

After meeting Chris, I inevitably believe it is important. Previous to that though, I would of said only a basic understanding is needed.

What changed your mind? I mean, was it his eyes, or something he said…and if so, what?

After discussing research.

It's a good article, but to put my (worthless) two cents in here, there is another "time" constraint to consider. Not the time it takes to learn a programming language, but the time it takes to write a bespoke script for a specific purpose compared to the time restraints on your examination.

This is only an issue, in my opinion, when you are attempting to write something to parse a "new digital object". If I have a relatively new and unknown binary file, it could take considerable time to even analyse, and then verify, the file structure. I would say that it's not inconceivable that this could take a week's solid work, maybe longer. After this you need to factor in time to write the script itself, which may take a day or so. That means you have six days where you're investigating a very specific area of potential evidence. Is this a good use of your time?

But that is really only a specific example for a specific area. As with the writer, I personally find programming skills to be hugely useful to Digital Forensics - even indirectly.

To use a real life example, I recently had a series of recorded webcam sessions and associated WLM logs. The officer in the case was wondering how to present this material in a straightforward way - so I wrote a short python script which re-parsed the chat logs (which are, if you are unaware, handily stored as XML) into SRT-format subtitle files. This then allowed her to just show the recorded movies with the chat history displayed in "real time" as a subtitle - pretty handy. And it wouldn't have been possible if I hadn't known how easy it was to manipulate XML using Python.

A great article Chris.

There is a great sense of achievement to be gained from reverse engineering someone else's bespoke data. As Chris_Ed has said - time can be an obvious limiting factor.

With so many good pieces of bespoke code from the likes of Keydet & others, it never hurts to verify their work. It may even be possible to find something "extra".

Not sure if it is – learning a programming language, that is. Learning how to program (and not just how to code), is probably more important, as it would help focussing on errors and misassumptions and all kinds of problems.

It often is necessary to create special code for a case … but, unless the code is tested thoroughly, it's no good. (There was an article many years ago about bugs in formulas in Excel sheets … very useful to raise the awareness of what a very small error could lead to.)

So, learning a programming language for the purpose of writing programs is not enough. Equally useful would be to learn how to test a program thoroughly.

There is real promise for 'hand crafted' code and systems,
however I feel the issue in no so much 'programming' or learning to program, but audit-ability.

All the opposition need do is introduce a reasonable doubt about your custom code, bugs, audit-ability, number of users, testing, software quality assurance systems, your competence/training as a computer programmer Etc.

potentially the whole case could fall apart, because you have given them 'reasonable doubt' to question the integrity of the systems you employ.

A bit like a medical forensic examiner, who does not follow established systems but does his/her own thing.

The good thing about established tools is that they have a track record that can be fallen back on, when you go custom you go it alone.

The good thing about established tools is that they have a track record that can be fallen back on

This is no guarantee whatsoever. I have posted bug reports in relation to most of the major 'established' tools where I have demonstrated incorrectly interpreted data. IMHO none of them get it perfectly right and any results that are relied upon need to be double checked at the very least.
In one case the failing was of epic proportions. The company never even acknowledged formally that the problem even existed - not surprising really as it was their reputation at stake. The bug was quietly 'fixed' however.

Paul

Having spent over 25 years examining media (floppy disks, tapes and hard drives) at byte level and then writing handlers to read the data logically, I feel programming is an extremely important tool. It is also just as important to understand hex dumps, and beable to decode data structures, complex fields, pointers etc. The joy of putting both together is that one can test out one's theories, and verify that pointers, or bits within a structure do do what you first thought.

The next stage is being able to correct corrupted, or misisng data.

Not everyone needs to be a programmer, but as often mentioned, being able to manipulate data is a very useful skill. The best ability though is understanding data at the raw level. I always get very upset when I see so many postings mentioning data as decimal numbers, whereas a simple hex number 99% of the time makes far more sense. My simplest example is 0x60003f is much easier to understand and remember rather than 6,291,519 (a typical location for $MFT start sector).

As for language, I have always used C / C++ which I feel has does not isolate one too much from the data, and I love pointers!