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.
Perhaps in my naivety, I would assume that if you are writing a program you will already have a full comprehension of the data structures you are dealing with and are able to manually demonstrate the process.
If you are then verifying your output is that not enough ?
Perhaps in my naivety, I would assume that if you are writing a program you will already have a full comprehension of the data structures you are dealing with and are able to manually demonstrate the process.
If you are then verifying your output is that not enough ?
Learning a programming language will not teach you that.
Exposure to and experience with programming will … but it will take time. If you are pogramming within a poorly created framework, you'll learn it sooner, but it will still take time.
As for assuming full comprehension … it can always be assumed, but how do you propose to test the assumption? Basic programming skills may be enough to give the impression that 'I know how to do that', yet inadequate to do anything but 'programming-in-the-small'. Input documentation may be incorrect, incomplete, outdated, or irrelevant.
To write a program to interpret, say, data structures on a CD, a copy of ISO 9600 seems to be all that is needed. In practice, only a handfull of CD-writing software follows that standard well, and so you are forced to deal with non-standard data, incorrectly created data structures, and generally bad data. That is not exceptional in any way.
That's why programming language learning only goes part of the way. Learning programming is the next third. Learning about factors affcting correctness of computation is probably the final part.
This is particularly important for programming for computer forensics an arithmetic overflow was the reason the Ariane 5 rocket crashed – and similar errors have probably caused lot less obvious indications that something has gone wrong. You don't want anything to go ignominiously wrong in a forensic case.
Take Windows event log parsing … should be a piece of cake, as Microsoft has documented the format quite well. Some of my preliminary tests of ceatively malformed event log test files suggest that there are very little code that really does the right thing. Some even believes what the file says, even if it says that 'this next event log record has a size that exceeeds the log file size'.
And that's with full documentation. With a 'reverse-engineered' file format, it's far more unclear does a particular field contain a timestamp, or does it do so only if some other field has a bit appropriately set, or perhaps if two other fields have contents of a particular kind? Knowing a programming language or how to program does not help much here.
Nor do I really think it's something that can be learned, except the hard way.
Learning a programming language, fine.
Learning how to use that programming language, fine.
But then follows two to three years of making all those mistakes and being exposed to all the bad data that is the real world.
Yes, you have to start somewhere. But I rather think the risk for making those errors is so much larger in the computer forensic field, and carries such a large damage cost, that it would perhaps be less expensive to recruit programmers with the necessary experience rather than train forensic analysts.
But that cost equation is obviously up to each separate business to solve.
Personally I think every lab should invest in dedicated R&D staff, who are already experienced programmers. The last lab I worked in employed two full time programmers and the ROI from them far outweighed the productivity that would have been gained from a couple of extra analysts. A decent programmer should be able to pickup enscript (or any other scripting language) pretty quickly. In our case we had heaps of customised scripts and more complex complied apps.
I also think that having a solid understanding of a low level language provides an analyst with a really solid understanding of how data is stored by applications and how and why programs behave the way they do. (I agree with Michael regarding C/C++ giving you an excellent understanding of data structures)
Hi, although I am not in the digital forensics field myself, but planning to go back to school to get into the field, I would like to say that I think learning to write and read code could really benefit oneself when examining data. Not only will the person be able to write programs to help with more coverage, but also, he/she will be able to understand how to read and analyze malicious codes found on a computer. I'm not sure how often this is the case, but it's an advantage to have. Yes, these programs will have to go through extensive testing prior to using it in the field.
By profession, I'm a Sr. Software Quality Assurance Analyst. Any advice for me to break into the field would be greatly appreciated! I am planning to apply for the masters in high tech crime investigation at GWU in VA - hopefully by fall 2011.
Great post Chris. I was a developer before I started doing digital forensics. I was never a great developer, but I could write working software. Being able to script things together has been a huge help in my career as a forensic analyst. There are so many tasks that lend themselves to automation and many of these tasks are repeated from one investigation to the next. Sometimes it may take more time up front to write a script to accomplish a given task than it would to do it manually, but for tasks that are repeated across multiple investigations, the return on time invested is fairly quick.
I'm grateful for the efforts of folks like Brian Carrier, Harlan Carvey, Kristinn Guðjónsson, Mike Murr, David Kovar and the dozens of other people who have released their custom tools for the community at large, all of those folks have saved me countless hours.
I DO think it's import to grasp some programing languages,especailly for people who want to Get More Information from Disks .
TO me, 10 years's programming…Now ,Forensic Work
I think there is also one important issue here, maybe overlooked a bit,
it is question if there can be a specific programmic language capable of describing
digital forensic tasks even on lovest level or up to testing relatively abstract scenarios on evidence
.. like
open investigation test1
include evidence from disk1
include evidence from disk2
carve for jpg and piture generally
report in pdf
alert on problem
end investigation test1
or
test if images in listOne exists in casedata from investigation test1
I know it sounds a bit strange, recently I was having a lot of crosstools expericence and lack of common interface, commands formats are really bad, expecially if we come to mobile forensic and network forensic
We have some standards available for evidence data format, but it stays there …
when we come to processing there is no real standard,
ok, we have phyton, perl, shell very promising ruby in open source and combination like EnCase / Enscript
more or less uniq combination each time
If we have something like sql in database area this can simplfy things a lot …
better automatisation, maybe standard high level scripting in each forensic tool
a lot of goodies ..
What do you think ?
Damir Delija
My view as a programmer who went into forensics.
The ability to write code has helped me lots. There is plenty of situations where coding skills helped me out, from writing simple log parsers that can do things that MS Log parser cannot, programs that auto generate scripts that extract data and creating replacement software for old code that didn't make it into Windows 7. And sometimes just writing things that we simply cannot afford to buy.
Obviously, not everyone can put in hundreds of hours trying to get a usable understanding of how to write a simple script (let alone learn .NET or Java). And as mentioned before in this thread, there is no need to be a full software developer - as long as you can get the job done you will do fine.
There is plenty of simple scripting languages that you can use, like python. It is close to simple English, it runs on both Windows and Linux and is very close to the Basic-language. With it you can do simple file processing and data extraction, and with just a few hours of trying to figure out how to open a file and do some string matching, you could make yourself more effective and "throw away the chains" of the software vendors - at least that is how i view it.
Summing up Simple scripting is useful and it isn't brainsurgery.
I see programming added to most forensics and even security degrees.
I see programming added to most forensics and even security degrees.
Yes, but - being an old dinosaur - I suspect that what would be offered unless some common sense (a rare IMHO quality) is used, will be
java VM based
MS .NET based *whatever*
as opposed to "plainer" scripting languages like (examples)
batch/bash scripts (I know, I know)
powershell
Python
Ruby
Possiby because wriiting half-@§§ed scripts is my only capability in the programming field, I often find it the "simpler" solution for "simple" problems whilst (real) "programmers" tend to make it more complex than needed.
Of course this is only a generic note, there are of course many very good C, C#, Java and possibly also .NET supported languages/whatever programmers that also know how the KISS prrinciple is one of the fundamental rules to apply whenever possible.
I find that a short Philosophy course 😯 , centered on Occam's Razor
http//
would also be very useful wink .
jaclaz