diff --git a/INSTALL b/INSTALL new file mode 100644 index 0000000..b4d6a78 --- /dev/null +++ b/INSTALL @@ -0,0 +1,189 @@ +Installing lmg On A Thumb Drive +Hal Pomeranz (hal@deer-run.com), 2014-03-29 + +Step 1 - Thumb Drive Setup: +=========================== + +BE VERY CAREFUL HERE. There is a large potential for data loss! + +This example assumes you're using a 64G thumb drive, and you're following +these instructions on a Linux system with a single hard disk. + +Plug the thumb drive into a spare USB port. If you run "fdisk -l" +as root, you should see output like: + + Disk /dev/sda: 160.0 GB, 160041885696 bytes + 255 heads, 63 sectors/track, 19457 cylinders, total 312581808 sectors + Units = sectors of 1 * 512 = 512 bytes + Sector size (logical/physical): 512 bytes / 512 bytes + I/O size (minimum/optimal): 512 bytes / 512 bytes + Disk identifier: 0x0002a430 + + Device Boot Start End Blocks Id System + /dev/sda1 * 2048 499711 248832 83 Linux + /dev/sda2 501758 312580095 156039169 5 Extended + /dev/sda5 501760 312580095 156039168 83 Linux + + Disk /dev/sdb: 61.8 GB, 61847109632 bytes + 72 heads, 8 sectors/track, 209713 cylinders, total 120795136 sectors + Units = sectors of 1 * 512 = 512 bytes + Sector size (logical/physical): 512 bytes / 512 bytes + I/O size (minimum/optimal): 512 bytes / 512 bytes + Disk identifier: 0x396a32a9 + + Device Boot Start End Blocks Id System + /dev/sdb1 8064 120795135 60393536 c W95 FAT32 (LBA) + +/dev/sda is your primary hard drive, and /dev/sdb is the thumb drive +we're going to use. If you are not able to identify your thumb drive, +DO NOT PROCEED. You will invariably end up destroying important data +and we will both be sad. I am going to use /dev/sdb as the thumb drive +in the examples below. BE CAREFUL AS YOU CUT AND PASTE. + +Normally, I format my thumb drives as EXT4 file systems-- they're fast, +but can only be read on Linux systems. If you want to be able to see +the captured memory images on other platforms, then format your thumb +drive as NTFS. But the Linux NTFS-3g drivers have much slower performance +than EXT4. Your call. + +For EXT4 format: + + parted /dev/sdb mklabel msdos + parted /dev/sdb mkpart primary ext4 1 62G + mkfs -t ext4 /dev/sdb1 + +For NTFS: + + parted /dev/sdb mklabel msdos + parted /dev/sdb mkpart primary ntfs 1 62G + mkntfs -Q /dev/sdb1 + +Finally, mount the thumb drive so that we can install files on it. +I'm going to use /mnt/usb in all of the examples below, so I recommend +following these steps exactly. + + mkdir -p /mnt/usb + mount /dev/sdb1 /mnt/usb + + +Step 2 - Copy lmg Script +======================== + +Copy the lmg script to the top-level directory of your thumb drive. +lmg uses the directory that it's run from as the starting point to +find all of the other files it needs to operate, so the location of +the script is important. + + cp /some/path/to/lmg /mnt/usb + chmod +x /mnt/usb/lmg + + +Step 3 - Install LiME Source Code +================================= + +LiME is the kernel module lmg uses to dump memory from target Linux systems. +Download the souce code from http://code.google.com/p/lime-forensics/ + +The lmg script will be compiling the LiME kernel module on the thumb drive +as part of the acquisition process. So we need to get the LiME source onto +our thumb drive: + + mkdir /mnt/usb/lime + cd /mnt/usb/lime + tar zxf ~/Downloads/lime-forensics-*.tar.gz + +I've included a file called lime-Makefile.patch with the lmg distribution +that makes a minor tweak to the way LiME is built. With my patch applied, +the resulting kernel module will include the CPU architecture ("i686" or +"x86_64") as part of the module name. This makes life better when you're +dealing with both 32-bit and 64-bit systems. YOU MUST APPLY MY PATCH or +lmg will be unable to find the appropriate kernel module for your system. + +To apply the patch: + + cd /mnt/usb/lime/src + patch < /some/path/to/lime-Makefile.patch + + +Step 3 - Install (Statically-Linked) dwarfdump +============================================== + +NOTE: If you do not want lmg to automatically build Volatility(TM) +profiles for you, then you can stop right here. lmg + LiME is enough +to capture RAM dumps from Linux systems. + +But assuming you want to build Volatility(TM) profiles on the fly, +you're going to need the dwarfdump program. And if you don't want +to be dependent on shared libraries, you're going to want to build +it statically-linked. To save everybody some hassle, I'm including +statically-linked 32-bit and 64-bit versions of dwarfdump with lmg. +To install them onto your thumb drive: + + cd /mnt/usb + tar zxf /some/path/to/static-dwarfdump.tgz + +If you want to try to build these yourself, read on... + +There's an issue around of which version of dwarfdump you want to use. +Various users have reported problems using newer versions of dwarfdump +to create Volatility(TM) profiles. For further details see: +http://code.google.com/p/volatility/issues/detail?id=260 +Per Andrew Case's comment in the thread, it appears that the v20120410 +has been tested, so I recommend going with that. The code can be found at +http://www.prevanders.net/libdwarf-20120410.tar.gz + +To build dwarfdump statically linked, you'll need static versions of +the elfutils libraries for your architecture. This worked for me on +my CentOS (Red Hat) system: + + yum install elfutils-devel-static elfutils-libelf-devel-static + +Now download libdwarf, unpack the tar archive, and cd into the resulting +directory. To build statically-linked executables: + + export LDFLAGS='-static' + ./BLDLIBDWARF + +Once you've built dwarfdump, copy it to the thumb drive along with the +dwarfdump.conf file. Note that the binary must be installed using the +program name "dwarfdump-$(uname -m)" (e.g., "dwarfdump-i686") or lmg +won't find it. The commands below will do the right thing: + + mkdir /mnt/usb/dwarfdump + cp dwarfdump2/dwarfdump /mnt/usb/dwarfdump/dwarfdump-$(uname -m) + cp dwarfdump2/dwarfdump.conf /mnt/usb/dwarfdump + +You'll need to repeat the above steps on both a 32-bit and a 64-bit +system if you want to support both architectures. + + +Step 4 - Install Volatility(TM) +=============================== + +Technically, building a Volatility(TM) profile for Linux only requires +the files under .../volatility-*/tools/linux. But I prefer to install +the entire Volatility(TM) distro on my thumb drive. That way I know +I'll always have a copy of Volatility(TM) handy when I want to do my +analysis. + +You can grab a copy of the latest Volatility(TM) release from + + http://code.google.com/p/volatility/downloads/list + +After you've downloaded the source code, install it on the thumb drive: + + cd /mnt/usb + tar zxf ~/Downloads/volatility-*.tar.gz + +ALTERNATIVELY, grab the current source code tree using the instructions +found at: + + http://code.google.com/p/volatility/source/checkout + +Installing on the thumb drive might look like: + + cd /mnt/usb + svn checkout http://volatility.googlecode.com/svn/trunk/ volatility-read-only + +lmg doesn't really care about the exact name of the directory Volatility(TM) +gets installed in. It will find the appropriate files automatically. diff --git a/README b/README new file mode 100644 index 0000000..9442c13 --- /dev/null +++ b/README @@ -0,0 +1,264 @@ +Linux Memory Grabber +A script for dumping Linux memory and creating Volatility(TM) profiles. +Hal Pomeranz (hal@deer-run.com), 2014-03-29 + +THANKS! +======= + +"If I have seen further it is by standing on the shoulders of giants." + ~ Issac Newton + +There are a lot of people who deserve thanks for making this simple +little tool possible: + +-- Joe Sylve for his work on LiME + +-- The entire Volatility(TM) development team for their ongoing work. + I'd like to particularly recognize Andrew Case who answered a number + of pesky questions from me during development of my tool. + +-- David Anderson for his ongoing support of libdwarf and dwarfdump + +-- Matt Suiche from MoonSols. When I was putting my tool together, + my design goal was "make it as easy to use as DumpIt" (if you need + to capture Windows memory, I know of no easier to use tool). + So thanks for the inspiration, Matt! + +The community is better for all of these efforts. I have chosen to make +my tool available under the Creative Commons "Attribution" License (CC BY), +in order to make it as widely available as possible. + +ABOUT THE TOOL +============== + +To analyze Linux memory, you first need to be able to capture Linux +memory. Joe Sylve's Linux Memory Extractor (LiME) is excellent for +this, but you need to have a LiME module compiled for the kernel of +the system where you want to grab RAM. + +Volatility(TM) is great at analyzing Linux memory images. But it needs +a profile that matches the system where the memory was captured. +Building a profile means compiling a C program on the appropriate system +and using dwarfdump to get the addresses of important kernel data structures. +You also need a copy of the System.map file from the /boot directory. + +Now if you happen to have a duplicate of your target system, you can +build LiME and compile the Volatility(TM) profile on the clone and +use them to capture and analyze memory from your target. But there are +many situations where a duplicate of your target system is not available. +So you may have to compile LiME and build your Volatility(TM) profile +on your target machine. + +And this is not for the faint of heart. There are a number of steps, +and some fairly low-level Linux commands involved. My goal was to +create a package that could be installed (by an expert) on a thumb drive +and distributed to agents in the field. The user of the thumb drive +should be able to plug the thumb drive in, run a single command, +and successfully acquire a memory image of the target machine and +a working Volatility(TM) profile. The result is my lmg (Linux Memory +Grabber) script. + +ON FORENSIC PURITY +================== + +If you're a stickler for forensic purity, this is probably not the +tool for you. Let's discuss some of the ways in which my tool interacts +with the target system: + +Removable Media -- The tool is designed to be run from a portable USB + device such as a thumb drive. You are going to be plugging a writable + device into your target system, where it could potentially be targeted + by malicious users or malware on the system. The act of plugging the + device into the system is going to change the state of the machine + (e.g., create log entries, mtab entries, etc). If the device is not + auto-mounted by the operating system, the user must manually mount the + device via a root shell. + +Compilation -- lmg builds a LiME kernel module for the system. + Creating a Volatility(TM) profile also involves compiling code on + the target machine. So gcc will be executed, header files read, + libraries linked, etc. lmg tries to minimize impact on the file + system of the target machine by setting TMPDIR to a directory on + the USB device lmg runs from. This means that intermediate files + created by the compiler will be written to the thumb drive rather + than the local file system of the target machine. + +Dependencies -- In order to compile kernel code on Linux, the target + machine needs a working development environment with gcc, make, etc + and all of the appropriate include files and shared libraries. + And in particular, the kernel header files need to be present on + the local machine. These dependencies may not exist on the target + system. In this case, the user is faced with the choice of installing + the appropriate dependencies (if possible) or being unable to + acquire memory from the target. + +Malware -- lmg uses /bin/bash, gcc, and a host of other programs from + the target machine. If the system has been compromised, the applications + lmg uses may not be trustworthy. A more complete solution would be + to create a secure execution environment for lmg on the portable USB + device, but was beyond the scope of this initial proof of concept. + +Memory -- All of the commands being run will cause the memory of the + target system to change. The act of capturing RAM will always create + artifacts, but in this case there is extensive compilation, file system + access, etc in addition to running a RAM dumper. + +All of that being said, lmg is a very convenient tool for allowing +less-skilled agents to capture useful memory analysis data from +target systems. + +Note that lmg will look for an already existing LiME module on the +USB device that matches the kernel version and processor architecture +of the target machine. If found, lmg will not bother to recompile. +Similarly, you may choose to not have lmg create the Volatility(TM) +profile for the target in order to minimize the impact on the target system. + +USING LMG +========= + +First, prepare a thumb drive according to the instructions in the +INSTALL document provided with lmg. + +When you wish to acquire RAM, plug the thumb drive into your target +system. On most Linux systems, new USB devices will get automatically +mounted under /media. Let's assume yours ends up under /media/LMG. + +Now, as root, run "/media/LMG/lmg". This is interactive mode and +the user will be prompted for confirmation before lmg builds a LiME +module for the system and/or creates a Volatility(TM) profile. +If you don't want to be prompted, use "/media/LMG/lmg -y". + +Everything else is automated. After the script runs, you will have +a new directory on the thumb drive named + + ".../capture/-YYYY-MM-DD_hh.mm.ss" + +In this directory you will find: + + -YYYY-MM-DD_hh.mm.ss-memory.lime -- the RAM capture + -YYYY-MM-DD_hh.mm.ss-profile.zip -- Volatility(TM) profile + -YYYY-MM-DD_hh.mm.ss-bash -- copy of target's /bin/bash + +The copy of /bin/bash is helpful for determining the address of the shell +history data structure in the memory of bash processes in the memory capture. +See http://code.google.com/p/volatility/wiki/LinuxCommandReference23#linux_bash +for further details on how to use this executable. + + +USAGE EXAMPLE +============= + +Here is an example of using the lmg tool, which includes using Volatility(TM) +directly off the thumb drive to analyze the captured image. On my test +machine, the thumb drive was at /dev/sdb and it was not auto-mounted by +my operating system. So I did everything manually. + +1) Getting root and mounting the thumb drive +-------------------------------------------- + +caribou$ sudo -s +[sudo] password for hal: +caribou# mkdir -p /mnt/usb +caribou# mount /dev/sdb1 /mnt/usb + + +2) Running lmg +-------------- + +caribou# /mnt/usb/lmg -y +make -C /lib/modules/3.2.0-41-generic/build M=/mnt/usb/lime/src modules +make[1]: Entering directory `/usr/src/linux-headers-3.2.0-41-generic' + CC [M] /mnt/usb/lime/src/tcp.o + CC [M] /mnt/usb/lime/src/disk.o + CC [M] /mnt/usb/lime/src/main.o + LD [M] /mnt/usb/lime/src/lime.o + Building modules, stage 2. + MODPOST 1 modules + CC /mnt/usb/lime/src/lime.mod.o + LD [M] /mnt/usb/lime/src/lime.ko +make[1]: Leaving directory `/usr/src/linux-headers-3.2.0-41-generic' +strip --strip-unneeded lime.ko +mv lime.ko lime-3.2.0-41-generic-x86_64.ko +make tidy +make[1]: Entering directory `/mnt/usb/lime/src' +rm -f *.o *.mod.c Module.symvers Module.markers modules.order \.*.o.cmd \.*.ko.cmd \.*.o.d +rm -rf \.tmp_versions +make[1]: Leaving directory `/mnt/usb/lime/src' +Dumping memory in "lime" format to /mnt/usb/capture/caribou-2014-03-29_12.06.01 +This could take a while...Done! Cleaning up...Done! +Grabbing a copy of /bin/bash...Done! +make -C //lib/modules/3.2.0-41-generic/build CONFIG_DEBUG_INFO=y M=/mnt/usb/volatility-2.3.1/tools/linux modules +make[1]: Entering directory `/usr/src/linux-headers-3.2.0-41-generic' + CC [M] /mnt/usb/volatility-2.3.1/tools/linux/module.o + Building modules, stage 2. + MODPOST 1 modules + CC /mnt/usb/volatility-2.3.1/tools/linux/module.mod.o + LD [M] /mnt/usb/volatility-2.3.1/tools/linux/module.ko +make[1]: Leaving directory `/usr/src/linux-headers-3.2.0-41-generic' +dwarfdump -di module.ko > module.dwarf +make -C //lib/modules/3.2.0-41-generic/build M=/mnt/usb/volatility-2.3.1/tools/linux clean +make[1]: Entering directory `/usr/src/linux-headers-3.2.0-41-generic' + CLEAN /mnt/usb/volatility-2.3.1/tools/linux/.tmp_versions + CLEAN /mnt/usb/volatility-2.3.1/tools/linux/Module.symvers +make[1]: Leaving directory `/usr/src/linux-headers-3.2.0-41-generic' + adding: module.dwarf (deflated 90%) + adding: boot/System.map-3.2.0-41-generic (deflated 79%) +caribou# ls /mnt/usb/capture/caribou-2014-03-29_12.06.01/ +caribou-2014-03-29_12.06.01-bash +caribou-2014-03-29_12.06.01-memory.lime +caribou-2014-03-29_12.06.01-profile.zip + + +3) Check for the new profile +---------------------------- + +caribou# export VOLATILITY_PLUGINS=/mnt/usb/capture/caribou-2014-03-29_12.06.01 +caribou# /mnt/usb/volatility-2.3.1/vol.py --info | grep Linux +Volatility Foundation Volatility Framework 2.3.1 +linux_banner - Prints the Linux banner information +linux_yarascan - A shell in the Linux memory image +Linuxcaribou-2014-03-29_12_06_01-profilex64 - A Profile for Linux caribou-2014-03-29_12.06.01-profile x64 + + +4) Choose the new profile and memory capture, run linux_pslist to test +---------------------------------------------------------------------- + +caribou# export VOLATILITY_PROFILE=Linuxcaribou-2014-03-29_12_06_01-profilex64 +caribou# export VOLATILITY_LOCATION=file:///mnt/usb/capture/caribou-2014-03-29_12.06.01/caribou-2014-03-29_12.06.01-memory.lime +caribou# /mnt/usb/volatility-2.3.1/vol.py linux_pslist +Volatility Foundation Volatility Framework 2.3.1 +Offset Name Pid Uid Gid DTB Start Time +------------------ -------------------- --------------- --------------- ------ ------------------ ---------- +0xffff88022e0e8000 init 1 0 0 0x0000000228f73000 2014-03-29 14:10:23 UTC+0000 +0xffff88022e0e9700 kthreadd 2 0 0 ------------------ 2014-03-29 14:10:23 UTC+0000 +0xffff88022e0eae00 ksoftirqd/0 3 0 0 ------------------ 2014-03-29 14:10:23 UTC+0000 +[... more output not shown ...] + + +5) Use the captured copy of /bin/bash to dump shell history with linux_bash +--------------------------------------------------------------------------- + +caribou# gdb /mnt/usb/capture/caribou-2014-03-29_12.06.01/caribou-2014-03-29_12.06.01-bash +GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04 +Copyright (C) 2012 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. Type "show copying" +and "show warranty" for details. +This GDB was configured as "x86_64-linux-gnu". +For bug reporting instructions, please see: +... +Reading symbols from /mnt/usb/capture/caribou-2014-03-29_12.06.01/caribou-2014-03-29_12.06.01-bash...(no debugging symbols found)...done. +(gdb) disass history_list +Dump of assembler code for function history_list: + 0x00000000004a53f0 <+0>: mov 0x2490c9(%rip),%rax # 0x6ee4c0 + 0x00000000004a53f7 <+7>: retq +End of assembler dump. +(gdb) quit +caribou# vol.py linux_bash -H 0x6ee4c0 -P +Volatility Foundation Volatility Framework 2.3.1 +Pid Name Command Time Command +-------- -------------------- ------------------------------ ------- + 2604 bash 2014-03-29 14:11:17 UTC+0000 cat workshop-outline + 2604 bash 2014-03-29 14:11:17 UTC+0000 sigfind -b 4096 006D6C6F6361 /dev/mapper/RD-var +[... more output not shown ...] diff --git a/lime-Makefile.patch b/lime-Makefile.patch new file mode 100644 index 0000000..45d09bd --- /dev/null +++ b/lime-Makefile.patch @@ -0,0 +1,32 @@ +*** Makefile.orig 2013-03-19 09:55:54.000000000 -0500 +--- Makefile 2014-03-29 11:25:06.367909918 -0500 +*************** +*** 24,36 **** + lime-objs := tcp.o disk.o main.o + + KVER := $(shell uname -r) + + PWD := $(shell pwd) + + default: + $(MAKE) -C /lib/modules/$(KVER)/build M=$(PWD) modules + strip --strip-unneeded lime.ko +! mv lime.ko lime-$(KVER).ko + + $(MAKE) tidy + +--- 24,37 ---- + lime-objs := tcp.o disk.o main.o + + KVER := $(shell uname -r) ++ CPU := $(shell uname -m) + + PWD := $(shell pwd) + + default: + $(MAKE) -C /lib/modules/$(KVER)/build M=$(PWD) modules + strip --strip-unneeded lime.ko +! mv lime.ko lime-$(KVER)-$(CPU).ko + + $(MAKE) tidy + diff --git a/lmg b/lmg new file mode 100755 index 0000000..98a132f --- /dev/null +++ b/lmg @@ -0,0 +1,145 @@ +#!/bin/bash +# +# lmg -- Linux Memory Grabber +# +# Automation script for dumping Linux memory via LiME and building +# a Volatility(TM) profile. "lmg -y" will take care of the entire +# process without prompting and save everything to the "capture" +# sub-directory wherever the lmg program is installed (e.g. a thumb drive). +# If you prefer raw dumps add "-F raw" (the default is "lime" format). +# +# See INSTALL doc for instructions for how to configure a thumb drive +# for use with this tool. +# +# Hal Pomeranz (hal@deer-run.com), 2014-03-29 +# +# No warranty expressed or implied. +# Distributed under the Creative Commons "Attribution" (CC BY) License +# See https://creativecommons.org/licenses/ + +export PATH=/sbin:/bin:/usr/bin + +FORMAT=lime +YESTOALL=n +while getopts ":F:y" opt; do + case $opt in + F) + FORMAT=$OPTARG + ;; + y) + YESTOALL=y + ;; + \?) + echo "Usage: $0 [-y] [-F lime|raw]" + exit 255 + ;; + esac +done + +# Linux USB 2.0 speedup -- see http://marc-abramowitz.com/archives/2007/02/17/ +for f in $(find /sys -name max_sectors); do + echo 1024 >>$f +done + +# Figure out where the tool is being run from and create an absolute pathname. +# All other paths are expected to be relative to here. +# +TOPDIR=$(dirname $0) +[[ $(echo $TOPDIR | cut -c1) != "/" ]] && TOPDIR=$(pwd)/$TOPDIR +TOPDIR=$(echo $TOPDIR | sed 's/\/\.*$//') + +KVER=$(uname -r) # e.g., "3.2.0-41-generic" +CPU=$(uname -m) # typically "x86_64" or "i686" +HOST=$(hostname) +TIMESTAMP=$(date '+%F_%H.%M.%S') # YYYY-MM-DD_hh.mm.ss + +# Try to keep temp files under install directory-- avoid impact to +# system where tool is running... +# +mkdir -p $TOPDIR/tmp +export TMPDIR=$TOPDIR/tmp + +# Go find the LiME installation and build a new kernel module if necessary. +# Abort if no module found/created. +# +LIMEDIR=$(dirname $(find $TOPDIR -name lime.h)) +cd $LIMEDIR +if [[ ! (-f lime-$KVER-$CPU.ko) ]]; then + if [[ $YESTOALL == 'n' ]]; then + echo -n 'Try to build LiME kernel module? [N|y] ' + read mod + fi + if [[ $YESTOALL == 'y' || $mod == 'y' || $mod = 'Y' ]]; then + make + if [[ ! (-f lime-$KVER-$CPU.ko) ]]; then + echo Still no matching kernel module found... exiting! + exit 255 + fi + else + exit + fi +fi + +# Use the LiME module to capture memory to $TOPDIR/capture/$HOST-$TIMESTAMP +# +mkdir -p $TOPDIR/capture/$HOST-$TIMESTAMP +echo Dumping memory in \"$FORMAT\" format to $TOPDIR/capture/$HOST-$TIMESTAMP +echo -n This could take a while... +insmod lime-$KVER-$CPU.ko "format=$FORMAT path=$TOPDIR/capture/$HOST-$TIMESTAMP/$HOST-$TIMESTAMP-memory.$FORMAT" +echo -n Done! Cleaning up... +rmmod lime +echo Done! + +# We want a copy of the local bash executable so we can find the offset +# of the history data structure. +# +echo -n Grabbing a copy of /bin/bash... +cp /bin/bash $TOPDIR/capture/$HOST-$TIMESTAMP/$HOST-$TIMESTAMP-bash +echo Done! + +# Last step is to build a profile for the system. If you don't want +# this, then you don't have to install dwarfdump or volatility on your +# thumb drive. lmg will give up if these directories aren't found. +# +if [[ $YESTOALL == 'n' ]]; then + echo -n 'Compile profile for this system? [N|y] ' + read prof +fi +if [[ $YESTOALL == 'y' || $prof == 'y' || $prof = 'Y' ]]; then + VOLDIR=$(dirname $(find $TOPDIR -name module.c)) + if [[ ! (-d $VOLDIR) ]]; then + echo Can\'t find volatility directory. Giving up! + exit 255 + fi + + DWARFPROG=$(find $TOPDIR -name dwarfdump-$CPU) + if [[ ! ( -x $DWARFPROG ) ]]; then + echo Failed to find program dwarfdump-$CPU. Giving up! + exit 255 + fi + DWARFDIR=$(dirname $DWARFPROG) + + # Put the right dwarfdump for this CPU architecture into the PATH + export HOME=$DWARFDIR + cd $DWARFDIR + rm -f dwarfdump + ln -s dwarfdump-$CPU dwarfdump + export PATH=$DWARFDIR:$PATH + + # Build module.c against kernel headers found on local system and + # with System.map from local /boot directory. + cd $VOLDIR + make dwarf + if [[ ! (-f module.dwarf) ]]; then + echo Failed to make module.dwarf. Giving up! + exit 255 + fi + if [[ ! (-f /boot/System.map-$KVER) ]]; then + echo /boot/System.map-$KVER not found. Giving up! + exit 255 + fi + + # Profile ends up in $TOPDIR/capture/$HOST-$TIMESTAMP with memory image + zip $TOPDIR/capture/$HOST-$TIMESTAMP/$HOST-$TIMESTAMP-profile.zip \ + module.dwarf /boot/System.map-$KVER +fi diff --git a/static-dwarfdump.tgz b/static-dwarfdump.tgz new file mode 100644 index 0000000..fab5ca7 Binary files /dev/null and b/static-dwarfdump.tgz differ