Hello Reader,
Have I mentioned how good Civ 5 brave new world is? It's really good, and the reason I'm writing this blog post this morning instead of last night again. Tip, playing Venice is hard on king. I realized I missed a couple scenarios we should go over so I'm continuing the go bag series a little longer before we begin our discussion on 'Web 2.0' forensics. We focused on the NAS's in the last post and now we are going to talk about how to deal with embedded devices and a quick look a memory storage devices.
The system is an embedded storage device - You won't see this very often, but every so often you'll be told that there is an embedded device that contains logs you need.
When dealing with embedded devices you have a couple types you'll come across
1. SoC (System on a chip) with sdcard storage
If you have this you are lucky, power down the embedded device and remove the sdcard for standard imaging. When you image it you have two options, you can actually get a memory card write blocker or you can use software write blocking. In Windows you can use the registry write block hack and then attach a memory card reader via USB or you can boot off a forensically sound Linux distribution and image the device. In either case this is the best possible scenario.
2. SoC (System on a chip) with a maintenance port
You may come across an embedded device where the memory is soldered to the board and no removable storage options exist, but they may have a maintenance port. Either through ethernet, usb or com port getting access to the underlying maintenance port can also lead to shell access as many of these devices are running embedded unix variants and others are running DOS. Once in this shell, and getting there will very by device, the nice part about embedded systems it that they are rarely multi user systems, meaning every process runs as root or administrator. Once you have the console you can then capture raw logs back to your system through it, sometimes if your lucky there may be older kermit/zmodem transmission programs left on the image or tftp for network connected systems (originally intended for network booting).
You can in embedded unix systems get full disk images this way by dumping the contents of the physical memory devices, just remember that you need to use a protocol capable to transmit the data without treating it as ascii strings or pipe it through a function to encode it first (base64 works here well).
3. SoC (System on a chip) with no access
This happens, and it sucks. At this point you can hope that there is some kind of Jtag access or firmware flashing access. If there is no firmware flashing access (which you can use to download the current memory image) then you are stuck with Jtag. Jtag means you are going to have to find the Jtag pads (documented if your lucky) solder a Jtag connection to the board and find a compatible app for the processor to dump the nvram to your system.
This isn't fun and if you are not experienced with Jtag easy to mess up. At this point you should probably let your client know that you need to send this system off to a specialist shop for extraction.
4. SoC (System on a chip) locked down for security
This typically is only found in high security embedded devices (ATMs, Lottery terminals, etc...) where they have attempted to remove all internal access to the system and its underlying data. You have one option here and you can't really go back from it. You have to de-solder the memory chips from the board and plug them into a raw reader. From that point its up to you to reconstruct the file system and access the underlying files. If you are on this step you are likely dealing with a pretty serious case and if you are not comfortable with what mobile forensic experts have termed 'Chip Off' forensics I would send this to a lab that is. Once you remove the chip its not likely you'll get it on the board and get the device functioning again so remember this is on way street, no going back.
That was longer than I thought it would be, as you can see I've dealt with a lot of weird systems over the last 14 years. We should talk about memory cards tomorrow and then on to 'Web 2.0' forensics. Don't forget this sunday you can win tickets to PFIC!
Have I mentioned how good Civ 5 brave new world is? It's really good, and the reason I'm writing this blog post this morning instead of last night again. Tip, playing Venice is hard on king. I realized I missed a couple scenarios we should go over so I'm continuing the go bag series a little longer before we begin our discussion on 'Web 2.0' forensics. We focused on the NAS's in the last post and now we are going to talk about how to deal with embedded devices and a quick look a memory storage devices.
The system is an embedded storage device - You won't see this very often, but every so often you'll be told that there is an embedded device that contains logs you need.
When dealing with embedded devices you have a couple types you'll come across
1. SoC (System on a chip) with sdcard storage
If you have this you are lucky, power down the embedded device and remove the sdcard for standard imaging. When you image it you have two options, you can actually get a memory card write blocker or you can use software write blocking. In Windows you can use the registry write block hack and then attach a memory card reader via USB or you can boot off a forensically sound Linux distribution and image the device. In either case this is the best possible scenario.
2. SoC (System on a chip) with a maintenance port
You may come across an embedded device where the memory is soldered to the board and no removable storage options exist, but they may have a maintenance port. Either through ethernet, usb or com port getting access to the underlying maintenance port can also lead to shell access as many of these devices are running embedded unix variants and others are running DOS. Once in this shell, and getting there will very by device, the nice part about embedded systems it that they are rarely multi user systems, meaning every process runs as root or administrator. Once you have the console you can then capture raw logs back to your system through it, sometimes if your lucky there may be older kermit/zmodem transmission programs left on the image or tftp for network connected systems (originally intended for network booting).
You can in embedded unix systems get full disk images this way by dumping the contents of the physical memory devices, just remember that you need to use a protocol capable to transmit the data without treating it as ascii strings or pipe it through a function to encode it first (base64 works here well).
3. SoC (System on a chip) with no access
This happens, and it sucks. At this point you can hope that there is some kind of Jtag access or firmware flashing access. If there is no firmware flashing access (which you can use to download the current memory image) then you are stuck with Jtag. Jtag means you are going to have to find the Jtag pads (documented if your lucky) solder a Jtag connection to the board and find a compatible app for the processor to dump the nvram to your system.
This isn't fun and if you are not experienced with Jtag easy to mess up. At this point you should probably let your client know that you need to send this system off to a specialist shop for extraction.
4. SoC (System on a chip) locked down for security
This typically is only found in high security embedded devices (ATMs, Lottery terminals, etc...) where they have attempted to remove all internal access to the system and its underlying data. You have one option here and you can't really go back from it. You have to de-solder the memory chips from the board and plug them into a raw reader. From that point its up to you to reconstruct the file system and access the underlying files. If you are on this step you are likely dealing with a pretty serious case and if you are not comfortable with what mobile forensic experts have termed 'Chip Off' forensics I would send this to a lab that is. Once you remove the chip its not likely you'll get it on the board and get the device functioning again so remember this is on way street, no going back.
That was longer than I thought it would be, as you can see I've dealt with a lot of weird systems over the last 14 years. We should talk about memory cards tomorrow and then on to 'Web 2.0' forensics. Don't forget this sunday you can win tickets to PFIC!
