Are you a forensic programmer

Which, again, is not exactly correct, as there are no real requirements imposed by digital forensic science that a computer programmer with knowledge of software engineering principles would not have already accounted for in his/her design and code.

I stand corrected 😉

So, how do you know what they really do/are doing, under the hood? And to those who go "Why should we care?", my reply is, as DF people, why should you _not_ care?

DarkSYN you're actually addressing a very significant point. I've seen e-discovery and some forensic software using code libraries that alter the input data; mainly in regard to undisclosed file formats like PST, NSF. Which is not mentioned by these product at all. This is bad-practice in my opinion, because as an investigator you need to know if software has to potential to alter our data.

For the sake of this thread the question could have been are you a forensic-aware programmer 😉

Personally I have been writing code to access disk/tape images and reverse engineering file systems and file formats in a full time forensics role for over 17 years now - despite what you may think, I think that makes me a forensic programmer, i.e. a programmer with a very good knowledge of file/filesystem and hardware/image access techniques and whos programming time is spent almost exclusively in this field.

If that makes you feel better about yourself and your place in the universe, far be it from me to argue.

As opposed to someone who can code a web page, query a database or write a word processor - the skill set is different, not everyone can look at a hex dump and work out what it means.

No its really not, actually. They are programmers too. They're just in a different field to you. And most programmers can look at a hex dump and work out what it means, because most programmers are at least familiar with the hexadecimal system. -)

I would argue that in general the person best equipped to do this is someone who has some experience of doing an investigation. This doesn't mean that someone with no forensics experience couldnt write good forensics software.

In programming terms, a person with such knowledge is considered to be a computer programmer who is a "domain expert" in said field.

There are plenty of people I know who havent coded for a long time, or maybe never programmed outside of academia, but can read a bit of asp or java script and work out what it is doing - I have had some extremely well respected forensics bods working for me who fall into this camp.

Undoubtedly. But while they can read the code and understand a bit of what it does, they don't understand it as well as a pro coder, and definitely not as well as someone who codes ASP for a living, for example. And sometimes its such differences in understanding that matter the most.

And, kindly, don't regret asking the question. It has lead to a rather interesting debate.

OO and programing are not the same thing - I can program, reasonably proficently, but only in non-OO languages ( or only using the non-OO features of languages ) and, in the main, I find this all that is required. I've tried to learn OO, but I always get bored, find that I actually need to _do_ something in a language and take the path of least resistance !

LOL!! I share your feelings and your pain, I really do, lol!! But, its still programming, I'm afraid… Its just that the OOP languages are a bit more high-level than structured ones.

DarkSYN you're actually addressing a very significant point. I've seen e-discovery and some forensic software using code libraries that alter the input data; mainly in regard to undisclosed file formats like PST, NSF. Which is not mentioned by these product at all. This is bad-practice in my opinion, because as an investigator you need to know if software has to potential to alter our data.

Thank you. -)

Now, let me take this argument a step further and ask the following If we don't know what the code in those libraries is really doing, how do we know its not been subverted/subvertable? Or exploitable?

Now, let me take this argument a step further and ask the following If we don't know what the code in those libraries is really doing, how do we know its not been subverted/subvertable? Or exploitable?

Basically we don't. E.g. because I did some work on EWF I actually know how to make an EWF file that takes down EnCase (at-least older versions), in this case in a crash. And that is just a crash. in theory this could be made into an exploit.

However you can take this argument very far. Actually you still not have a guarantee if an independent party reviewed the code and gave of a certificate (or similar).
You wouldn't be even sure when you use Open Source software.

Let me elaborate, Open Source can be validated; but how often does this happen?
I've several OS projects but I can't remember anyone doing a full security review on them.

Then there are the tools building the OS; are they open ? Sometimes
Can they contain or generate exploitable or subvertable code ? Yes they can.

However you can take this argument very far. Actually you still not have a guarantee if an independent party reviewed the code and gave of a certificate (or similar).
You wouldn't be even sure when you use Open Source software.

Let me elaborate, Open Source can be validated; but how often does this happen?
I've several OS projects but I can't remember anyone doing a full security review on them.

Then there are the tools building the OS; are they open ? Sometimes
Can they contain or generate exploitable or subvertable code ? Yes they can.

Yes, you're absolutely right in pretty much everything you say. Mind you, I don't want to start an Open vs Closed Source software debate as that's outside the scope of the topic.

My whole point is that programmers are much more likely to spot problems of that sort and, to some extent, correct or ameliorate them, or even take them into account when looking at their results / writing their reports. And their "hacks" (by which I mean quick spur-of-the-moment code to solve a problem) are much more likely to be of better quality & more secure by default.

You should, by now, know that absolutely everything is exploitable.

For the sake of this thread the question could have been are you a forensic-aware programmer

My initial issue with the topic still stands. What makes someone "forensically aware"?

For the sake of this thread the question could have been are you a forensic-aware programmer

My initial issue with the topic still stands. What makes someone "forensically aware"?

You see to me, that question, phrased like that is actually quite simple to answer.

Somebody who is "forensically aware" is somebody who understands the principals required to be able to present evidence infront of a court - taking the fundamental purpose of the profession at its word. (http//en.wikipedia.org/wiki/Forensic_science)

Thus someone who understands the requirements of preserving evidence where possible, recording throughout, and justifying where you can't preserve evidence for whatever reason irregardless of their other skills, be they programmer, analyst or SoC Officer can be considered "forensically aware".

Yes, you're absolutely right in pretty much everything you say. Mind you, I don't want to start an Open vs Closed Source software debate as that's outside the scope of the topic.

You're right that is not the topic discussion here and also definitely not my interest.

My initial issue with the topic still stands. What makes someone "forensically aware"?

Good question, to reflect upon. At the moment, I do not have a conclusive answer for it.

azrael interesting answer, but what is your perspective on the following comment in that regard understanding principles is one thing, applying them another.

Let me elaborate on that even though you are aware of the means and importance of evidence preservation. How would you make sure that you are covering all bases ?

You see to me, that question, phrased like that is actually quite simple to answer.

And that, to some extent, is what Functional Decomposition is. -)

Somebody who is "forensically aware" is somebody who understands the principals required to be able to present evidence infront of a court - taking the fundamental purpose of the profession at its word. (http//en.wikipedia.org/wiki/Forensic_science)

Thus someone who understands the requirements of preserving evidence where possible, recording throughout, and justifying where you can't preserve evidence for whatever reason irregardless of their other skills, be they programmer, analyst or SoC Officer can be considered "forensically aware".

Very good! Progress!! We now have an initial set of requirements. How would you go about refining them and making them slightly more clear?

We now have an initial set of requirements. How would you go about refining them and making them slightly more clear?

First let's rephrase what azrael is saying

high-level requirements forensic-awareness
1. ability to present evidence in-front of a court according to principles
2. preserving evidence where possible
3. recording throughout
4. justifying preservation of evidence

Some more input
NIST Computer Forensic Tool Testing (CFTT) project
http//www.cftt.nist.gov/

OK, a rough first outline

point 1 entails
* the interpretation of evidence, eg. relevance, reasoning/logic, presentation, visualisation
* what the court in question accepts as evidence /
or more general what is accepted as evidence

* understanding of the law, dependent on the type of court (and to what extent?)
* understanding of presenting a case (and to what extent?)

I'm considering to what extent last two relate to forensic software ?
* dealing with LPP
* workflow

points 2, 3, 4
* AKA the (digital) forensic process
acquisition, analysis and reporting

point 2 and/or 4 entails
* recovery of evidence
* identification of evidence
* validation of evidence

point 3 entails
* transparency in both process and findings

azrael interesting answer, but what is your perspective on the following comment in that regard understanding principles is one thing, applying them another.

I think that the thing is, the principles are actually quite easy to understand, the success of application is directly proportional to the knowledge of the actor in whichever field - now that knowledge might be through the application of learnt routines in the case of first responders, or might be through in-depth understanding and previous study/experience in the case of analysts. My application of the principals in a computer scenario would be considerably better than my application in a meatspace scenario for example, although my understanding of the principals doesn't differ.

Let me elaborate on that even though you are aware of the means and importance of evidence preservation. How would you make sure that you are covering all bases ?

My personal opinion is that you can never be sure that you are covering all bases in the real world - there are so many variables that assurance is pretty much out of the question - even for the most experienced analyst. We are left with a "best efforts" ( and for that matter "best practice" )scenario, which in general is fine, it is when things become complex and unusual, like all fringe cases, where things start to become more of an issue, and it is at this point where expereince, academic research, and scientific method are more important and simply following process won't do ( often because there _is_ no process ).

My definition of a forensic progrmmer is

Do you think in HEX?

A lot of forensic programming (as Paul says) is reverse engineering formats and understanding data structures. This can involve hours looking at Hex dumps and understanding pointers, lengths, bits within bytes etc. I am always upset when dumps are described (on this forum and elsewhere) and nice simple hex numbers are converted to (meaningless) decimal numbers. When in France, where possible speak fench, when in computer data, think hex.