Commit 7c3869d6 authored by Tails developers's avatar Tails developers
Browse files

Document 2 more ways to analyze RAM.

parent 3f80e7a4
**FIXME** this process is quite complicated and should be automated using VMs
# 0. prepare the systems
[[!toc levels=2]]
## prepare a Tails USB stick
# 0. Prepare the needed tools
Install the Tails version to test on a 1st USB stick.
Pick one of those:
## prepare a minimal lenny live system
* [[erase_memory_on_shutdown/live_USB]]
* [[erase_memory_on_shutdown/qemu_pmemsave]]
* [[erase_memory_on_shutdown/pxedump]]
We will use this system to do a coldboot attack. It is useful that it is a
minimal system so that it doesn't fill the RAM to boot.
# 1. Fill the RAM with a known pattern
To be able to grep /dev/mem, it must have a kernel with CONFIG_STRICT_DEVMEM
disabled. It is enabled in debian since 2.6.28-1, so we use lenny:
lb config --architecture i386 --linux-flavours 686 --apt-recommends false --distribution lenny --binary-images usb-hdd --binary-indices false --memtest none --packages-lists="minimal" --syslinux-menu vesamenu --initramfs=live-initramfs --bootappend-live "init=/bin/bash"
Then install this image on a 2nd USB stick
# 1. fill the RAM with a known pattern
* boot on Tails
* launch fillram a few times in parallel (on a 32-bit architecture the
* Boot Tails.
* Run `fillram` a few times in parallel (on a 32-bit architecture the
address space of a given process is usually limited at 3 GiB - or
less, depends on the kernel configuration); as root:
for i in $(seq 0 31) ; do fillram & done ; watch free -m
# 2. test that you can get the pattern
# 2. Test that you can get the pattern after rebooting, if no memory wiping takes place
* plug the USB stick containing the minimal Lenny Live system
* reboot from Tails using `SysRq + b`; if testing in a VM, you'd
* Make sure your preferred memory scrapper toolkit is ready.
* Reboot from Tails using `SysRq + b`; if testing in a VM, you'd
better be careful not rebooting your host system and proceed like
this:
echo 1 > /proc/sys/kernel/sysrq ; echo b > /proc/sysrq-trigger
* Dump memory and try to find the known pattern in it, e.g.:
echo 1 > /proc/sys/kernel/sysrq ; echo b > /proc/sysrq-trigger
* boot on the minimal Lenny Live system
* actually run the test:
grep -c wipe_didnt_work /dev/mem
grep -c wipe_didnt_work tails.dump
- you should get some integer larger than zero if the pattern was found in
RAM, which is the expected result ;
RAM, which is the expected result;
- you should get `grep: /dev/mem: Cannot allocate memory` otherwise. In that
case, it is **not** useful to process to the next step, there is something
wrong in the way you tested.
# 3. test that sdmem really hides the pattern
# 3. Test that you can*not* get the pattern after rebooting Tails normally
* redo step 1
* reboot from Tails by running `reboot` as root
* plug the USB stick containing the minimal Lenny Live system
* when Tails displays that you can remove the USB stick, unplug the
Tails stick and plug the USB stick containing the minimal Lenny Live
system in
* boot on the minimal Lenny Live system
* actually run the test:
* Redo step 1.
* Reboot Tails by running `reboot` as root.
* Make sure your preferred memory scrapper toolkit is ready (e.g.
plug your USB scrapper stick).
* When Tails tells you you can unplug the USB stick, unplug the
Tails stick.
* Dump memory and try to find the known pattern in it, e.g.:
grep -c wipe_didnt_work /dev/mem
grep -c wipe_didnt_work tails.dump
- you should get zero if the pattern was not found in RAM, which is the
optimal (and expected) result;
......
[[!toc levels=2]]
# Prepare the needed tools
We will use a minimal Debian Lenny Live system to setup a coldboot
attack.
Why minimal? So that it doesn't overwrite too much of the RAM we want
to analyze.
Why Lenny? To be able to grep `/dev/mem`, one must run a kernel that
has `CONFIG_STRICT_DEVMEM` disabled. This setting has been enabled in
Debian kernels since 2.6.28-1, so we use lenny:
lb config --architecture i386 --linux-flavours 686 --apt-recommends false --distribution lenny --binary-images usb-hdd --binary-indices false --memtest none --packages-lists="minimal" --syslinux-menu vesamenu --initramfs=live-initramfs --bootappend-live "init=/bin/bash"
*Nota bene*: if you have 64 bits hardware, better build an `amd64` image.
Then install this image on a USB stick.
# Dump the RAM
Grep'ing `/dev/mem` does not work on systems with large amounts of
memory, so let's use `dd`.
RAM_SIZE_IN_KB=$(free -k | awk '/Mem:/ { print $2 }')
dd if=/dev/mem of=$DUMP bs=1K count=$RAM_SIZE_IN_KB oflag=direct
where `$DUMP` is some large enough storage for dumping your entire RAM
into. It could be a USB drive, but I'd recommend a fast harddrive
unless you want to wait for half an hour or more. The longer the dump
takes, the more RAM may be overwritten, so speed is crucial, actually.
One problem is that the live system built above doesn't include
cryptsetup, lvm2 and friends, so you'll need an unencrypted partition.
The point is to get `$RAM_SIZE_IN_KB` exactly right -- it should be in
kilobytes of the 1024 bytes variant. The important thing is just to
get bs and count in such a way that dd reads as much of your RAM as
possible, but *NOT* more. Also, bs should be small since dd allocates
that much memory for its own buffer, and that will overwrite RAM.
oflag=direct will ensure that no cache is used, which otherwise would
start to over-write RAM for buffers.
[[!toc levels=2]]
# Prepare the needed tools
## Memory scrapping software
Sources are available there:
* http://citp.princeton.edu/memory-content/src/bios_memimage-1.2.tar.gz
* http://citp.princeton.edu/memory-content/src/bios_memimage-1.2.tar.gz.asc
0. Check the tarball signature, unpack.
0. On an amd64 system run:
$ make -f Makefile.64
## DHCP/TFTP server
If you already have a DHCP/TFTP server ready (e.g. thanks to libvirt),
all you need to do is to make your tftp root point to
`bios_memimage/pxe`, and set `scraper.bin` in the place of the
boot loader.
Else, dnsmasq will happily provide both a DHCP and a TFTP server,
using the following command line:
$ sudo dnsmasq --conf-file=/dev/null \
--interface=tap0 \
--dhcp-range=172.32.1.2,172.32.1.2,1h \
--enable-tftp \
--tftp-root=/tmp/bios_memimage/pxe \
--dhcp-boot=scraper.bin \
--no-daemon
(Adjust `tftp-root` and `interface` according to your setup.)
Don't forget to punch enough holes in your firewall so that DHCP, TFTP
and port udp/31337 will go through.
# Run Tails in qemu/kvm
* Start kvm (using a tap interface, in order to
be on layer 2 between host and VM, otherwise DHCP won't work.)
$ kvm -boot nd -net nic,macaddr=0:0:e8:1:2:3,model=rtl8139 -net tap -m 1024 -cdrom tails.iso
* Setup an IP address on your interface:
sudo ip addr add 172.32.1.1/24 dev tap0
sudo ip link set tap0 up
* Press 'Q' to disable PXE for the initial boot. Let the Tails CD boot.
# Dump the RAM
* At boot time, press 'N' to enable PXE boot. You should soon see
`Waiting for handshake...`
* Start the dumping process:
pxedump 172.32.1.2 | pv > tails.dump
# Final note
By replacing `tap0` with `eth0` in the previous examples, it should be
fairly easy to reproduce this for bare metal hardware, provided its
network adapter and BIOS are PXE-ready.
[[!toc levels=2]]
qemu -enable-kvm -boot c -m 4096 -cdrom tails.iso
* Open the qemu console (CTRL-ALT-2).
* Save physical memory to the `tails.dump` file (replace `0xF0000000`
(= 4GiB) with the amount of memory bytes assigned to the VM):
pmemsave 0 0xF0000000 tails.dump
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment