A New Live Triage Tool Taking Shape, Part 2
I last left off describing what led to my ideas regarding a comprehensive digital forensic platform named Carnivore and the live triage tool CarnivoreLE (Live Edition). The first two incarnations of Carnivore were what is now termed Carnivore Portable. That's an external drive partitioned and loaded with tools useful to both livebox and deadbox triage and forensic preview. It tends to follow in Dell's footsteps regarding processing and evidence capture at the scene in a manner easily brought back to the lab for further processing using an integrated systems approach. These first two iterations were miles from the ideal, but were a positive and critical step in the right direction. Both Version 1 and Version 2 have seen extensive use in the field and the feedback has been overwhelmingly favorable.
Carnivore Portable now still benefits from the ability to make use of other third party tools loaded onto it before deployment, but the two main tools are CarnivoreLE and CarnivorePM. CarnivorePM (Postmortem) is exactly what it sounds like - a deadbox tool consisting of a GNU/Linux-based live operating system, allowing controlled booting into a forensically sound environment for interactive processing at the scene. CarnivoreLE is the tool of choice when a live running suspect system (livebox) is encountered. Essentially, it's a series of automated modules that process the running machine and capture evidential material/artifacts to be examined or analyzed later. Once the tool completes, the idea is to reboot into CarnivorePM to address whatever CarnivoreLE captured, as well as perform other examinations of interest in a triage/preview situation. CarnivorePM will be discussed in further detail in future posts.
One other goal seemed to creep in and take a prominent position: to serve as a learning platform. It’s been my experience that most digital evidence examiners are not also programmers. They don’t typically know how to write computer code in any language and have never learned to think in terms of code logic and troubleshooting. This becomes evident based on usage habits of some on the major forensic platforms I've witnessed, such as FTK, EnCase, Autopsy, Nuix, etc. These and many others have some sort of facility to extend functionality, most often through use of interpreted languages such as Python or Ruby. These facilities provide an examiner with a way to add features to the platform that weren’t there out of the box. Most providers also conduct or host training courses that teach how to use these facilities, but none I’ve ever attended teach programming generally. If you already code in a given language and understand basic programming concepts such as primitives, methods, classes, functions, variables, keywords, etc., then these classes are all you need to start writing modules or extensible scripts for that platform. If you don’t understand these basic concepts, the class doesn’t help much and may only firmly cement in your mind the idea that “this stuff is too hard for me.” It's not too hard for you. Don't listen to that nonsense.
The Carnivore System starting with CarnivoreLE may find good use here. One of the long term goals of the LE project is to refactor (meaning, rewrite the code without changing what it does) from the C language to the Go language (sometimes called Golang). There are several reasons I think this would be a good move. The fact that Go is statically compiled by default is one of the more compelling reasons. Regardless, this would also be a great time to develop curriculum for a new training course for examiners who recognize their need to learn coding skills. Go’s specification has been designed to be small enough to fit in a person’s head. Try that with C++ or, worse yet, try it with the monstrosity that is Java, and you’ll come away so disillusioned that you may never consider learning to program ever again. C is itself pretty simple, but neither I nor anyone I’ve never met would say that the C11 specification is easy for most people to carry around in their heads. Golang, on the other hand… yeah, I’d say that about it.
An examiner’s course on programming using the CarnivoreLE model could teach the most important coding fundamentals that would then easily translate to any other Turing complete language. It could make learning those languages easier which should lead to easier module building for other platforms. The rest of the Carnivore pantheon uses other languages besides Go and they, just like LE, could also serve a primarily educational purpose. Only time will tell.
In any case, you can find CarnivoreLE on GitHub starting here. That link takes you to the GitHub home page for Positronikal. Clicking on the CarnivoreLE link there will take you to the repo. Word to the wise: read all the documentation before attempting to work with anything and especially before sending a pull request.
Carnivore Portable now still benefits from the ability to make use of other third party tools loaded onto it before deployment, but the two main tools are CarnivoreLE and CarnivorePM. CarnivorePM (Postmortem) is exactly what it sounds like - a deadbox tool consisting of a GNU/Linux-based live operating system, allowing controlled booting into a forensically sound environment for interactive processing at the scene. CarnivoreLE is the tool of choice when a live running suspect system (livebox) is encountered. Essentially, it's a series of automated modules that process the running machine and capture evidential material/artifacts to be examined or analyzed later. Once the tool completes, the idea is to reboot into CarnivorePM to address whatever CarnivoreLE captured, as well as perform other examinations of interest in a triage/preview situation. CarnivorePM will be discussed in further detail in future posts.
 |
| CLI - not something to be afraid of here. |
CarnivoreLE was designed from the beginning with the following goals in mind:
- Run as identically and seamlessly as possible on Windows, Macintosh, and GNU/Linux systems.
- Maximize automation without dispensing with interactivity.
- Reduce the RAM footprint as much as possible.
- Provide a means to capture a compressed RAM image.
- Be expedient.
- Provide an open and universal method of compressed logical imaging.
- Run as close to the hardware as practical.
- Use plain text output in general so results can be accessible to a wide range of tools.
- Provide only necessary functionality while operating on the live suspect system, leaving the rest for follow up deadbox examinations.
One other goal seemed to creep in and take a prominent position: to serve as a learning platform. It’s been my experience that most digital evidence examiners are not also programmers. They don’t typically know how to write computer code in any language and have never learned to think in terms of code logic and troubleshooting. This becomes evident based on usage habits of some on the major forensic platforms I've witnessed, such as FTK, EnCase, Autopsy, Nuix, etc. These and many others have some sort of facility to extend functionality, most often through use of interpreted languages such as Python or Ruby. These facilities provide an examiner with a way to add features to the platform that weren’t there out of the box. Most providers also conduct or host training courses that teach how to use these facilities, but none I’ve ever attended teach programming generally. If you already code in a given language and understand basic programming concepts such as primitives, methods, classes, functions, variables, keywords, etc., then these classes are all you need to start writing modules or extensible scripts for that platform. If you don’t understand these basic concepts, the class doesn’t help much and may only firmly cement in your mind the idea that “this stuff is too hard for me.” It's not too hard for you. Don't listen to that nonsense.
The Carnivore System starting with CarnivoreLE may find good use here. One of the long term goals of the LE project is to refactor (meaning, rewrite the code without changing what it does) from the C language to the Go language (sometimes called Golang). There are several reasons I think this would be a good move. The fact that Go is statically compiled by default is one of the more compelling reasons. Regardless, this would also be a great time to develop curriculum for a new training course for examiners who recognize their need to learn coding skills. Go’s specification has been designed to be small enough to fit in a person’s head. Try that with C++ or, worse yet, try it with the monstrosity that is Java, and you’ll come away so disillusioned that you may never consider learning to program ever again. C is itself pretty simple, but neither I nor anyone I’ve never met would say that the C11 specification is easy for most people to carry around in their heads. Golang, on the other hand… yeah, I’d say that about it.
An examiner’s course on programming using the CarnivoreLE model could teach the most important coding fundamentals that would then easily translate to any other Turing complete language. It could make learning those languages easier which should lead to easier module building for other platforms. The rest of the Carnivore pantheon uses other languages besides Go and they, just like LE, could also serve a primarily educational purpose. Only time will tell.
In any case, you can find CarnivoreLE on GitHub starting here. That link takes you to the GitHub home page for Positronikal. Clicking on the CarnivoreLE link there will take you to the repo. Word to the wise: read all the documentation before attempting to work with anything and especially before sending a pull request.
Comments
Post a Comment