I do agree and that is taught in two other classes in the degree. I would have to make those two classes the pre-requisites to get into the reverse engineering class so that by the time that they get into there, they would know which files they were looking for, where they were at, and now be learning how the information is stored within the file.
For what it's worth, whilst I use Perl daily for a huge range of tasks, I think that I learnt more about the fundamentals of programming from learning C.
It is an excellent foundation language, introduces the concepts of parsing, compilation and linking (which, lets face it, is more commonly used than interpreted languages). It is (like Perl) relatively platform independent (ANSI C anyway …) and compilers are easy to come by (GCC) - it also allows the student to progress to other languages more easily (C++, Objective-C, C# and Java all being C derivatives) - there are countless books on C and, certainly when looking at File Systems, much of the available source code is in C - so the structures are easy to demonstrate. It has been taught as a foundation language in Universities the world over for many years - not only in Computer Science, but also many Maths, Physics and Electrical Engineering courses.
Significant parts of all the current major operating systems have been written in C (Unix/Linux most clearly, but also MacOS and Windows - although each of these have significant amounts in derivative languages now [ Objective-C for MacOS and C++ for Windows ]), as have some significant open source forensic tools. I've also found, over time, that a founding in C has at least allowed me to be able to read other languages and to learn new ones better than I think Perl would have …
Again, I'm not bashing Perl, it is a brilliant language, that can do pretty much anything - and I use it to, however as a foundation, I think that C is better.
I agree. Perl is great for scripting but if you are talking about a real forensic programming class you would need C and probably some Assembly. You will need to get at the device on a Ring level 0. Adding something about DDK and such would probably be helpful.
After rereading this it looks like it would really take a couple of courses.
Take a look at the Sleuth Kit and Autopsy. They are open source and Brian Carrier is very good at this low level programming and ATA commands.
PERL is a good choice because there already exist a number of modules to manipulate the Windows registry, file systems, etc.
Perl is a good choice for a different reason as well it illustrates and may even reinforce the need for testing and validation of tools used for forensic purposes.
Write blockers are tested and validated – acquiry products and process are tested and validated – but I have yet to se Perl module that has been tested and validated to forensic standards. They may have been, but the results from such testing have not been published – to my knowledge.
It is, of course, up to each practitioner to do this … but that doesn't in any way absolve the programmer/coder from doing his part. A 'forensic programmer' who creates modules or plugins or other software products should, I think, include a test designs and a test suites with those. Source code for independent review is clearly a sine-qua-non here.
There's some activity to do testing and to create test data, but it really need to be addressed from the beginning, rather than tacked on at the end.
This is probably an area where sound software engineering practices can be illustrated through forensic requirements. It's also an area where legal requirements such as the Daubert criteria (in an area where those apply, of course) can be demonstrated to influence not only how forensic software is used, but even how it is designed and produced.
Obviously, I'm seeing this mainly as an exercise in software engineering in the computer forensic area
Ok, I do see the point. One of the main purposes that I wanted to develop the class was to teach people the structure behind the files that they were looking at. For me, it was much easier to learn by programming a way of reverse engineering them. Would it be a better idea to have a class on reverse engineering common Windows artifacts?
Well, in a prior life I was a programmer and used a number of languages so I'm not knocking programming. But you did say, I think, that your class was mainly for non-programmers and I think that you might unnecessarily complicate things by trying to teach architecture using programming.
One of the best examples of what I think that you want to do is the EnCase Advanced Forensics class which starts each exercise with a brute force deconstruction of some structure, like the MBR or the MFT, and then follows that up with an example of how that same task is done using a script.
As someone else noted, you could likely do much of the same thing by taking The Sleuthkit and combining a source code analysis with Brian Carrier's book on File System Forensics. The source code documentation for NTFS-NG is also a good place to look because the authors discuss what they know (and don't know), about NTFS. C is a fairly straightforward language to learn, especially if you only have to read the code, not write it.
This wouldn't help with such things as the registry, but there is only so much that you can do in a semester and by the time you finish file systems, I think that your students might appreciate a break from looking at code.