Tuesday, November 19, 2013

Start of a New Day

Sure, take on something new. Why not? This seems like a good outlet for stuff that doesn’t fall into the categories of other things I’m doing between teaching, writing and recording video training titles. I expect there will be a smattering of different concepts that show up here, including forensics, networking, security and so forth. Maybe more generically, technology discussions.
This first item arrived as a result of a homework assignment I was doing for a graduate Operating Systems Forensics course. We were supposed to take a look at a number of ways to gather artifacts under Windows and then translate the same sort of things to Linux, Mac OS or another operating system. I decided to take a look at the Volatility Framework and the things it could do under Windows and provide the same sort of guidance under Linux without using the framework. One of the issues was taking a look at raw system memory. Fortunately, there are ways to do that in Linux.
Linux makes use of pseudo filesystems to present information that is stored inside the kernel space. One of those filesystems is /proc, which provides a way of accessing information about the current processes. Even though it’s accessed from the filesystem, you aren’t accessing files in the sense of bits that are stored on a disk in your system. Instead, you are accessing an interface into kernel space. You can see a list of all of the files in the directory of the init process, which will always be the first process on a Linux system.

attr cpuset limits net sched syscall
autogroup cwd loginuid ns schedstat task
auxv environ map_files oom_adj sessionid timers
cgroup exe maps oom_score smaps wchan
clear_refs fd mem oom_score_adj stack
cmdline fdinfo mountinfo pagemap stat
comm io mounts personality statm
coredump_filter latency mountstats root status

All of those files and directories are statistics and other pieces of data belonging to the init process. You can see the stack and pagemap, for example. While this can give you a lot of data about individual processes, at some point you may simply need to just get a dump of all of the memory on a system. This is especially true when it comes to a forensic investigation and you need to grab all of the information in memory for later analysis. We can do this pretty easily using another pseudo filesystem, /dev. In this case, we are going to use the memory device from the /dev filesystem in order to grab memory. If I just dump the /dev/mem device, though, it’s not going to look like anything I can use since there will be a lot of values that don’t have ASCII representations that can be printed. As a result, we need to dump the output into a utility that can convert the input into a hex dump output. Since I probably have a lot of memory and I want to look at it visually, I want to make use of a pager that can display a portion of memory at a time. Below, you can see the command string I used and a portion of the memory from my Linux system.

$ dd if=/dev/mem | xxd | less
0000000: a072 00f0 a072 00f0 a172 00f0 a072 00f0 .r...r...r...r..
0000010: a072 00f0 dc72 00f0 a072 00f0 a072 00f0 .r...r...r...r..
0000020: 91ad 00f0 c5a3 00f0 cc72 00f0 cc72 00f0 .........r...r..
0000030: cc72 00f0 cc72 00f0 1785 00f0 cc72 00f0 .r...r.......r..
0000040: 1001 00c0 ea72 00f0 f472 00f0 9788 00f0 .....r...r......
0000050: 62a0 00f0 fe72 00f0 24a5 00f0 59ab 00f0 b....r..$...Y...
0000060: 1779 00f0 ff7d 00f0 05ac 00f0 a072 00f0 .y...}.......r..
0000070: a072 00f0 3370 00f0 7283 00f0 3313 00c0 .r..3p..r...3...
0000080: a072 00f0 a072 00f0 a072 00f0 a072 00f0 .r...r...r...r..
0000090: a072 00f0 a072 00f0 a072 00f0 a072 00f0 .r...r...r...r..
00000a0: a072 00f0 a072 00f0 a072 00f0 a072 00f0 .r...r...r...r..

It’s important here to recognize that the addresses shown are physical addresses, which have no resemblance to the addresses that would be in use by an application since Linux, like all other modern operating systems, uses virtual memory in order to support more allocated memory than is physically in the system. However, having a full dump of memory can be critical in some cases. Having access to a character-based device that is an interface to raw system memory is powerful so it’s helpful to remember that with the /dev/mem device, you can not only read, but you can write as well so it’s best to be careful as as to avoid forking up your system.