Volshell uses virtual memory addresses, if you are searching or using offsets keep that in mind. Starting volshell without entering the context of a process is pretty straigh forward.

1

vol.py -f memory_img.raw --kdbg=$KDBG_OFSETT --profile=$VOLATILITY_PROFILE volshell

Getting some help for the first usage can be done by the hh() command.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

In [1]: hh()

Use addrspace() for Kernel/Virtual AS
Use addrspace().base for Physical AS
Use proc() to get the current process object
  and proc().get_process_address_space() for the current process AS
  and proc().get_load_modules() for the current process DLLs

addrspace()                              : Get the current kernel/virtual address space. 
cc(offset=None, pid=None, name=None, physical=False) : Change current shell context.
db(address, length=128, space=None)      : Print bytes as canonical hexdump.
dd(address, length=128, space=None)      : Print dwords at address.
dis(address, length=128, space=None, mode=None) : Disassemble code at a given address.
dq(address, length=128, space=None)      : Print qwords at address.
dt(objct, address=None, space=None, recursive=False, depth=0) : Describe an object or show type info.
find(needle, max=1, shift=0, skip=0, count=False, length=128) : 
getmods()                                : Generator for kernel modules (scripting).
getprocs()                               : Generator of process objects (scripting).
hh(cmd=None)                             : Get help on a command.
list_entry(head, objname, offset=-1, fieldname=None, forward=True, space=None) : Traverse a _LIST_ENTRY.
modules()                                : Print loaded modules in a table view.
proc()                                   : Get the current process object.
ps()                                     : Print active processes in a table view.
sc()                                     : Show the current context.

For help on a specific command, type 'hh(<command>)'

To list the processes you can run the ps() command within the interactive volshell prompt.

1
2
3
4
5
6
7

In [1]: ps()
Name             PID    PPID   Offset  
System           4      0      0x85c50958
smss.exe         280    4      0x86ecaa70
csrss.exe        412    404    0x86cfa540
wininit.exe      464    404    0x87d85d40
<snip>

This output gives you an overview about the name, the process id (PID), the parent process (PPID) and the offset of each process. The PID or the name can be used to change the context to a specific process, more on this can be seen below. For now we will work with the offset only.

In order to make structures like the Proccess Environment Block (PCB) accessible, volatility has its own structures. To view one of those structures you can use the dt() command.
If you would like to understand what the _EPROCESS structure contains use:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

In [5]: dt("_EPROCESS")
 '_EPROCESS' (728 bytes)
0x0   : Pcb                            ['_KPROCESS']
0x98  : ProcessLock                    ['_EX_PUSH_LOCK']
0xa0  : CreateTime                     ['WinTimeStamp', {'is_utc': True}]
0xa8  : ExitTime                       ['WinTimeStamp', {'is_utc': True}]
0xb0  : RundownProtect                 ['_EX_RUNDOWN_REF']
0xb4  : UniqueProcessId                ['unsigned int']
0xb8  : ActiveProcessLinks             ['_LIST_ENTRY']
0xc0  : ProcessQuotaUsage              ['array', 2, ['unsigned long']]
0xc8  : ProcessQuotaPeak               ['array', 2, ['unsigned long']]
0xd0  : CommitCharge                   ['unsigned long']
<snip>
0x1a8 : Peb                            ['pointer', ['_PEB']]
<snip>

As you can see above, at the offset of 0x1a8 in the _EPROCESS structure, the Process Environment Block (PEB) can be found. It is a pointer, pointing to a structure named _PEB. If we would like to understand the _PEB structure, we can again use the dt() command.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

In [6]: dt("_PEB")
 '_PEB' (584 bytes)
0x0   : InheritedAddressSpace          ['unsigned char']
0x1   : ReadImageFileExecOptions       ['unsigned char']
0x2   : BeingDebugged                  ['unsigned char']
0x3   : BitField                       ['unsigned char']
0x3   : ImageUsesLargePages            ['BitField', {'end_bit': 1, 'start_bit': 0, 'native_type': 'unsigned char'}]
0x3   : IsImageDynamicallyRelocated    ['BitField', {'end_bit': 4, 'start_bit': 3, 'native_type': 'unsigned char'}]
0x3   : IsLegacyProcess                ['BitField', {'end_bit': 3, 'start_bit': 2, 'native_type': 'unsigned char'}]
0x3   : IsProtectedProcess             ['BitField', {'end_bit': 2, 'start_bit': 1, 'native_type': 'unsigned char'}]
0x3   : SkipPatchingUser32Forwarders   ['BitField', {'end_bit': 5, 'start_bit': 4, 'native_type': 'unsigned char'}]
0x3   : SpareBits                      ['BitField', {'end_bit': 8, 'start_bit': 5, 'native_type': 'unsigned char'}]
<snip>
0x10  : ProcessParameters              ['pointer', ['_RTL_USER_PROCESS_PARAMETERS']]
<snip>

If we would like to know more about the process parameters we can learn that from the _RTL_USER_PROCESS_PARAMETERS structure, which is part of the Process Environment Block. For example it contains the command line the process was started with.
You can use these defined structures as an overlay for every offset. Volshell will than use the given structure and fill it with data starting the offset provided. As memory is just bits and bytes, the overlay can be applied to addresses not representing the corresponding structure. Be warned to double check your offsets and validate the output.
In order to use a structure as an overlay at a specific offset you have to tell volshell the offset. You can do this by providing it as a second parameter to the dt() command: dt(“$STRUCTUR_NAME”, $HEXADECIMAL_OFFSET)

So lets start to dig down and see what the command line of the process cmd process was. Fist step is to determine the offset by looking at the ps() command output

1
2
3
4
5

In [1]: ps()
Name             PID    PPID   Offset  
<snip>
cmd.exe          208    1208   0x860f2578
<snip>

Next use the _EPROCESS structure as on overlay at the offset of the process

1
2
3
4
5
6
7
8
9
10
11
12

In [2]: dt("_EPROCESS", 0x862f9a58)
[_EPROCESS _EPROCESS] @ 0x862F9A58
0x0   : Pcb                            2251266648
0x98  : ProcessLock                    2251266800
0xa0  : CreateTime                     2012-04-06 14:03:11 UTC+0000
0xa8  : ExitTime                       1970-01-01 00:00:00 UTC+0000
0xb0  : RundownProtect                 2251266824
0xb4  : UniqueProcessId                5192
0xb8  : ActiveProcessLinks             2251266832
<snip>
0x1a8 : Peb                            2147348480 
<snip>

Given the output above, we can see that the Process Environment Block points to 2147348480. This value is in decimal and we will convert it into hex in a standard bash shell:

1
2

~$ printf '0x%x\n' 2147348480
0x7ffdf000

If we are not changing the context to the process we are investigating we might get the following error.

1
2
3
4

In [7]: dt('_PEB',0x7FFDF000)
ERROR: could not instantiate object

Reason:  Invalid Address 0x7FFDF000, instantiating _PEB

So it is time to switch context and apply the above command again:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

In [8]: cc(pid=208)
Current context: cmd.exe @ 0x860f2578, pid=208, ppid=1208 DTB=0x7ecce4c0

In [9]: dt('_PEB',0x7FFDF000)
[CType _PEB] @ 0x7FFDF000
0x0   : InheritedAddressSpace          0
0x1   : ReadImageFileExecOptions       0
0x2   : BeingDebugged                  0
0x3   : BitField                       8
0x3   : ImageUsesLargePages            0
0x3   : IsImageDynamicallyRelocated    1
0x3   : IsLegacyProcess                0
<snip>
0x10  : ProcessParameters              3674456
<snip>

Our ProcessParameters are located at 3674456, which is 0x381158 in hex. Using the _RTL_USER_PROCESS_PARAMETER overlay and calculated offset, we can already see the command line used to start the process.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

In [12]: dt("_RTL_USER_PROCESS_PARAMETERS", 0x381158)
[CType _RTL_USER_PROCESS_PARAMETERS] @ 0x00381158
0x0   : MaximumLength                  1728
0x4   : Length                         1728
0x8   : Flags                          24577
0xc   : DebugFlags                     0
0x10  : ConsoleHandle                  2840
0x14  : ConsoleFlags                   0
0x18  : StandardInput                  628
0x1c  : StandardOutput                 624
0x20  : StandardError                  624
0x24  : CurrentDirectory               3674492
0x30  : DllPath                        C:\Windows\system32;C:\Windows\system32;C:\Windows\system;C:\Windows;.;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\
0x38  : ImagePathName                  C:\Windows\system32\cmd.exe
0x40  : CommandLine                    C:\Windows\system32\cmd.exe
0x48  : Environment                    3748560
<snip>
0x290 : EnvironmentSize                2484
0x294 : EnvironmentVersion             5

But what if we want to see the content of the environment variables of the process?

1
2
3
4
5
6

dt("_RTL_USER_PROCESS_PARAMETERS") shows us the following:
<snip>
0x48  : Environment                    ['pointer', ['void']]
<snip>
0x290 : EnvironmentSize                ['unsigned long']
0x294 : EnvironmentVersion             ['unsigned long']

So it seems we cannot apply a predefined structure to view the content of the environment variables. How about to dump them with the db() command? Again we converted the decimal pointer value (in this case to Environemt) to hex.

1
2
3
4
5
6
7
8
9

In [16]: db (0x3932d0)
0x003932d0  3d 00 43 00 3a 00 3d 00 43 00 3a 00 5c 00 57 00   =.C.:.=.C.:.\.W.
0x003932e0  69 00 6e 00 64 00 6f 00 77 00 73 00 5c 00 53 00   i.n.d.o.w.s.\.S.
0x003932f0  79 00 73 00 74 00 65 00 6d 00 33 00 32 00 5c 00   y.s.t.e.m.3.2.\.
0x00393300  64 00 6c 00 6c 00 68 00 6f 00 73 00 74 00 00 00   d.l.l.h.o.s.t...
0x00393310  41 00 4c 00 4c 00 55 00 53 00 45 00 52 00 53 00   A.L.L.U.S.E.R.S.
0x00393320  50 00 52 00 4f 00 46 00 49 00 4c 00 45 00 3d 00   P.R.O.F.I.L.E.=.
0x00393330  43 00 3a 00 5c 00 50 00 72 00 6f 00 67 00 72 00   C.:.\.P.r.o.g.r.
0x00393340  61 00 6d 00 44 00 61 00 74 00 61 00 00 00 41 00   a.m.D.a.t.a...A.

In order to view the complete content we need to overwrite the default returned size of 1024. Lucky for us the size of the environment is part of the _RTL_USER_PROCESS_PARAMETER structure.

1
2

In [17]: db (0x3932d0, 2484)
In [18]: db (0x3932d0, 0x9b4)

Both will return the complete content of the environment variables for the given process. This first command supplies the length db() should read and return in decimal form, the second used hexadecimal.

If you do not want to deal with the offsets, there is a different way as well.
We start volshell again and directly jump into the context of the process by supplying the -p $PID parameter, in our example we jump to the process used above (PID 208).

1

vol.py -f memory_img.raw --kdbg=$KDBG_OFSETT --profile=$VOLATILITY_PROFILE volshell -p 208

We are now already in the context of the process with PID 208 and we can reference the structures via “self” for the selected process. Of cause you can also reference structures via “self” if you manually switched the context to the process you are investigating via cc(pid=$PID_OF_CHOICE).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

In [2]: dt(self._proc)
[_EPROCESS _EPROCESS] @ 0x860F2578
0x0   : Pcb                            2249139576
0x98  : ProcessLock                    2249139728
0xa0  : CreateTime                     2012-04-04 18:43:24 UTC+0000
0xa8  : ExitTime                       1970-01-01 00:00:00 UTC+0000
0xb0  : RundownProtect                 2249139752
0xb4  : UniqueProcessId                208
0xb8  : ActiveProcessLinks             2249139760
0xc0  : ProcessQuotaUsage              -
0xc8  : ProcessQuotaPeak               -
0xd0  : CommitCharge                   426
0xd4  : QuotaBlock                     2281628672
0xd8  : CpuQuotaBlock                  0
<snip>
0x1a8 : Peb                            2147348480
<snip>

Printing the ProcessEnvironmentBlock now works easily by just adding the corresponding name.

1
2
3
4
5
6
7
8

In [3]: dt(self._proc.Peb)
[CType Peb] @ 0x7FFDF000
0x0   : InheritedAddressSpace          0
0x1   : ReadImageFileExecOptions       0
0x2   : BeingDebugged                  0
<snip>
0x10  : ProcessParameters              3674456
<snip>

THe ProcessParameter would be the next step in the journey:

1
2
3
4
5
6
7
8
9

In [4]: dt(self._proc.Peb.ProcessParameters)
<CType pointer to [0x00381158]>
0x0   : MaximumLength                  1728
0x4   : Length                         1728
<snip>
0x48  : Environment                    3748560
<snip>
0x290 : EnvironmentSize                2484
<snip>

As you have seen above, Environment is a pointer to data in memory not being parsed with an object overlay like the ProcessParameters for example. So running something like “dt(self._proc.Peb.ProcessParameters.Environment)” will cause an error. We have to use db to print the context, as we have already done above. From above we further know, we need to include the length wen want to read in order to print the whole environment variables.

1
2
3
4
5
6
7
8

In [5]: db(self._proc.Peb.ProcessParameters.Environment,2484)
0x003932d0  3d 00 43 00 3a 00 3d 00 43 00 3a 00 5c 00 57 00   =.C.:.=.C.:.\.W.
0x003932e0  69 00 6e 00 64 00 6f 00 77 00 73 00 5c 00 53 00   i.n.d.o.w.s.\.S.
0x003932f0  79 00 73 00 74 00 65 00 6d 00 33 00 32 00 5c 00   y.s.t.e.m.3.2.\.
0x00393300  64 00 6c 00 6c 00 68 00 6f 00 73 00 74 00 00 00   d.l.l.h.o.s.t...
0x00393310  41 00 4c 00 4c 00 55 00 53 00 45 00 52 00 53 00   A.L.L.U.S.E.R.S.
0x00393320  50 00 52 00 4f 00 46 00 49 00 4c 00 45 00 3d 00   P.R.O.F.I.L.E.=.
<snip>

By now we have successfully reviewed various data about a process and also printed out the hex representation of the process environment variable by using volshell.

1
2

#get bash history with timestamps
export HISTTIMEFORMAT="%d/%m/%y %T "

This will give you the following history output format:

1
2

1 25/11/18 15:36:58 less ~/.bashrc 
2 25/11/18 15:40:42 history

It might not be the best idea to save the traffic to the actual file system your pfsense is running on. In the past the file system was mounted read-only (that changed recently) but there are more reasons to that. It is simply not very handy. If you encounter an incident and you have to copy all the traffic over the network… might take too mutch time, the network might even no longer be available. But again: You decide.

I decided to use a external usb storage attached to the pfsense box. In case I needed the data, I can simply walk over, grep the usb stick/external hd and attach it to the analysis system. No copy, no impact on the running pfsense system - sneakernet for the win.

For the sake of testing I used one of my usb sticks floating around at my desk. It only has 8 GB and is not very fast, so definitely not enough for a real network. You should be able to adopt to any larger size after reading the rest of the post.

First thing to ensure is, we can run commands at boot time on our pfsense. Most simple way I found was to install the package “Shellcmd” via pfsense buildin package manager. If you read the description “The shellcmd utility is used to manage commands on system startup.” this is pretty much what we are going to do.

Next thing to do: compiling a small script we can use to call at startup

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88

#!/bin/sh
#
# Startup script for trdump via tcpdump
#
# description: trdump control script
# processname: tcpdump


# -size 100  count 72 capture 72 files of 100 MB; this will fit the 8 GB stick
PCAP=/mnt/netrec/trdump.pcap
SIZE=100
COUNT=72
INTERFACE=re0
PIDFILE=/var/run/tcpdump

start() {
        if [ -f $PIDFILE ]; then
                echo "PID File $PIDFILE exists"
                exit 1
        fi

  if (/sbin/mount | /usr/bin/grep -q /mnt/netrec ) then
      /usr/bin/logger "/mnt/netrec already mounted"
  else
      /sbin/mount -t msdosfs /dev/da1s1 /mnt/netrec/
      if($?) then
          # mount successfull
          /usr/bin/logger "/dev/da1s1 mounted to /mnt/netrec"
      else
          # mount not successfull
          /usr/bin/logger "mounting /dev/da1s1 to /mnt/netrec failed exiting"
          exit
     fi
  fi



  /usr/bin/logger "starting traffic dump"
  # if we reach the code here, our disk is mounted
  # start recording
  # -s 0 collect entire packet contents
  # -n Don't convert addresses (i.e., host addresses, port numbers, etc.) to names
  # -C 100 -W 72 capture 72 files of 100 MB; this will fit the 8 GB stick
  # filter out the ip of the the tor node
  /usr/sbin/tcpdump -i $INTERFACE -n -s 0 -C $SIZE -W $COUNT -w $PCAP 'not (src host 78.142.145.141 or dst 78.142.145.141)' >/dev/null 2>&1 &


        echo $! > $PIDFILE
        exit 0
}

stop() {
        if [ ! -f $PIDFILE ]; then
                echo "PID File $PIDFILE does not exist"
                exit 1
        fi

      /usr/bin/logger "stoping traffic dump"
        kill -HUP `cat $PIDFILE` && rm $PIDFILE
        exit $@
}

status() {
        if [ ! -f $PIDFILE ]; then
                echo "PID File $PIDFILE does not exist"
                exit 0
        fi
        ps -fp `cat $PIDFILE`
        exit 0
}

case "$1" in
  start)
        start
        ;;
  stop)
        stop
        ;;
  status)
        status
        ;;
  *)
        echo "Usage: $0 {start|stop|status}"
        exit 1
esac


exit

This script will do some logging, it will try to mount the usb stick (not the most fail-safe way, but good enough for now) and as a little extra it offers a start, stop and status command.
If you what to use the script you should be fine after adopting the parameter section in the beginning of the script, the mount command at line 25 and changing the tcpdump filter at line 45. I use this filter to not dump the traffic of my Tor node. Just removing everything between the single quotes and the single quotes itself should be fine.

Installing the “Shellcmd” package will add a menu item called “Shellcmd” in the “Services” menu. This is were the configuration is done to start the dump script if pfsense boots. By hitting the “add” button one can configure a new task. Put in the path to the script followed by a whitespace and the parameter “start”. See example below.

1

/usr/local/trdump.sh start

As Shellcmd Type just leave “shellcmd” and add a meaningful description in the corresponding field. Hit save and do not forget to make the script executable and attach you usb storage.
Test the script if it runs without errors by manually calling it and providing “start” as a parameter. If it works you can let it run or stop it and reboot your pfsense box and verify if it works on a reboot as well.

At the end a few words on the tcpdump flags:
-C $SIZE -W $COUNT
With SIZE equals 100 and COUNT equals 72, tcpdump captures 72 files of 100 MB. If 72 files exist, tcpdump will roll over and dump to the first file again.
This ensures that the storage (in this case the 8 GB usb stick) does not run out of space. It make sence to save the dump to smaller chunks and not one or two big files. If you do not believe me: dump a few GB of traffic and try to open it with wireshark for example.

Feel free to use the script etc. to build your own custom script or use it and adopt what is needed for your environment.

No luck for me.. I do no longer got a black screen but a awkward zoomed splash screen without the ability to enter my full-disk encrytion password. At this point in time my “GRUB_CMDLINE_LINUX_DEFAULT” looked like this:

1

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nomodeset"

But to be honest, how needs a splash screen and why booting quite if you have issues to fix. So I removed all three parameters, run “update-grub” again and rebooted.
Issue solved, got my verbose boot, the ability to enter my full-disk encryption password and use the NVIDIA driver which gave me my three screens back. Successfull config in the end:

1

GRUB_CMDLINE_LINUX_DEFAULT=""

The setup process is nearly the same as for the setup with wheezy:
Download the current version of Arch Linux for Raspberry Pi from the download page, extract the archive and copy it to your SD card.

1
2
3
4
5
6

unzip ArchLinuxARM-2014.01-rpi.img.zip
Archive:  ArchLinuxARM-2014.01-rpi.img.zip
  inflating: ArchLinuxARM-2014.01-rpi.img
.
.
sudo dd bs=1M if=ArchLinuxARM-2014.01-rpi.img of=/dev/sdb

Again you can use “df -h” before and after you connected you SD card to figure out which path you have to use for the “of” parameter of the “dd” command.
After copying is completed just insert the SD card into the Raspberry Pi, connect the network cable and power it up. Again you will be able to find out the IP address by looking at you DCHP server or you simply guess it based on your own IP address. We again assume the IP to be 192.168.1.139. connect to it and change the password.

1
2
3
4
5
6
7

ssh root@192.168.1.139
# default password: root
# accept the host key
.
.
passwd root
# follow on screen instructions.

Next steps on the way to a running tor relay are updating the system and installing tor.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

pacman -Syu
# wait until command is finished and follow on screen instructions
.
.
pacman -S tor
# same deal as above... follow instructions and wait until finished
.
.
#adding user for tor
useradd arch-tor
#change password, use some random here, we don't need it.
passwd arch-tor
.
#restart the Pi
systemctl reboot

After reboot is finished and you have reconnected with your new root password it is time to edit the tor config file. Open the file “/etc/tor/torrc” with you favourite editor and configure at least these settings according to your needs:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

RunAsDaemon 1 #makes Tor run as a deamon
ORPort 443
DirPort 80
ExitPolicy reject *:* # to be a node only
Nickname XXX # choose something here
RelayBandwidthRate 100 KB # Throttle traffic to 100KB/s (800Kbps)
RelayBandwidthBurst 200 KB # But allow bursts up to 200KB/s (1600Kbps)
ContactInfo XXX # enter your contact infos here
User arch-tor
DataDirectory /var/lib/tor
Address XXX # enter the external IP or the domain for your tor relay here 
## Send all messages of level 'notice' or higher to /var/log/tor/notices.log
#Log notice file /torlog/notices.log
## Send every possible message to /var/log/tor/debug.log
#Log debug file /torlog/debug.log

I recommend to have the “notices.log” enabled until you have seen your tor relay has successfully start up. After you are sure your relay runs correctly I recommend to disable logging completely.

Now for the final step we want to make sure that tor restarts after a reboot automatically. Therefore we need to edit the file “/usr/lib/systemd/system/tor.service” and correct the settings:

1
2
3

[Service]
User=root
Type=forking

After saving the file you need to run the following command to start tor after a reboot:

1

systemctl enable tor

Finally create a directory for the log-file according to your config and make sure it is read- and writable by the user “arch-tor”.

1
2

mkdir /torlog
chown arch-tor /torlog/

To test your new setup restart again and check the tor notice log (/torlog/notices.log) for errors or success. If you see warnings according to your system-clock in the notices log ignore them; tor will start correctly after your clock got synced. If your tor relay started correctly don’t forget to edit the config and remove logging. Restart again and you are up and contributing.

Take the PDF and make a backup copy of it.
Rename the PDF file to a PostScript file. (Change extension from pdf to ps)
Run the PostScript file through ps2pdf and ignore the errors.

1

ps2pdf input.ps output.pdf

Done.

Trying this sounds much better then buying software or upload the PDF to a could service. And anyhow this will only take a few minutes and if it fail, you can still buy software or put your sensitive information in the cloud and at risk.

1
2
3
4
5
6

wget http://http.us.debian.org/debian/pool/main/l/lua5.1/lua5.1_5.1.5-4_armel.deb
wget http://http.us.debian.org/debian/pool/main/t/triggerhappy/triggerhappy_0.3.4-2_armel.deb
wget http://archive.raspberrypi.org/debian/pool/main/r/raspi-config/raspi-config_20121028_all.deb
dpkg -i triggerhappy_0.3.4-2_armel.deb
dpkg -i lua5.1_5.1.5-4_armel.deb
dpkg -i raspi-config_20121028_all.deb

For those of you how are a bit familiar with the Raspberry Pi and the offered operating systems offered for it: “YES, you can simple install raspi-config and run it. And yes truly obvious!”
So the solution to my problem was to simply install & run raspi-config and use the functionality of it to resize and use the complete SD card.

My shopping list:
Power Supply link
SD card (2 GB or larger) link
Raspberry pi link
Housing for the pi link
extra cooler link

I added the links to amazon as well; not that this is always the best choice to buy, but it will get you an idea what to buy. I have chosen a bit of a faster SD card to not have to wait to long while copying the data to the SD card.
All sum-up to 82,27 € for the complete setup.

The additional cooler is completely optional. I usually order these extra coolers because they tend to be really cheap and therefore “Why not?”. To open the housing there are four clips on the bottom side. Just push them a bit to the outside and it will open.

Simply stick the cooler on the processor and push the Raspberry pi into the bottom housing. The complete assembly can be done without any screws, which is kind of nice. In the picture above you can see how it should look like after these steps. The picture below shows your new Tor node after closing the housing. I have chosen the backside because you are able to see the mentioned four clips in this perspective.

Having all this done you can start downloading the image for the SD card. I have gone with Raspbian “wheezy” which you can download here. While the download finishes you can start to search the SD card reader. I think I have more than 3 of these things, but I personally never can find one when needed. If you are on Windows you can use win32diskimager to clone the operating system to the SD card. I assume that you are sitting on a *nix box for the following commands. As image names or size may be changing over time the output should look similar to this but has not to exact this output:

1
2
3

unzip 2012 – 07-15-wheezy-raspbian.zip
Archive:  2012 – 07-15-wheezy-raspbian.zip
  inflat­ing: 2012 – 07-15-wheezy-raspbian.img

Now it is time to have a look to which device we would like to clone the freshly decompressed image file. df -h will show you which filesystems are present, now plug in your card reader/writer with the SD card inserted and run df -h again. From the difference of both outputs you will know which device you has to unmout to clone. It is simply that file system, that wasn’t present beforehand. Another hot tip on *nix: It should be something similar to /dev/sdb or /dev/sdc.

1
2
3
4
5
6
7
8
9

df -h 
.
.
.
df -h 
.
.
.
umount /dev/sdb

All data on the SD card will be overwritten, so please think now if there is data on it you might need later on. Otherwise, if the SD card is already empty or the data isn’t needed anymore, clone the OS to SD card.

1
2
3
4

sudo dd bs=1M if=2012– 07-15-wheezy-raspbian.img of=/dev/sdb
 1850+0 records in
 1850+0 records out
 1939865600 bytes trans­ferred in 198.319278 secs (9781528 bytes/sec)

After starting the cloning process, you can get yourself a coffee. There is enough time to get it while cloning. After the transfer is finished, take your SD card and insert it to the Raspberry pi. This is a thing I really liked, you are able to insert or remove the SD card without opening the housing.

Now it is time to wire up your Raspberry and connect power and Ethernet. It will boot up and fetch itself an IP Address form the DCHP server in your network. You can find out the IP Address by looking at the DHCP Server, ping through the whole network or you simple know which IP Address it has to get. Let’s assume that my node got the internal IP Address 192.168.1.139.

1
2

ssh pi@192.168.1.139
# default password raspberry

Default username for connecting is “pi” and the default password is “raspberry”. You definitely want to change the default password as the next step right?

1

passwd pi

This should do the trick and you can set a secure password now.

As a next step we want to add the Tor project package source and then add the gpg key used to sign the packages.

1
2
3
4
5
6
7
8

sudo vi /etc/apt/sources.list
# use new password for the pi user here
# add this line to your source list
deb http://deb.torproject.org/torproject.org wheezy main
# save file and exit
# know add the key
gpg --keyserver keys.gnupg.net --recv 886DDD89
gpg --export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 | sudo apt-key add -

Now we can get up really close to it. Install the Tor package and do not forget to update all packages before.

1
2
3
4

sudo apt-get update
sudo apt-get dist-upgrade
sudo apt-get install deb.torproject.org-keyring
sudo apt-get install tor

As the package is prepared to have Tor running with the user “debian-tor” you can either change the permissions to meet another user or you create this user on your system.

1
2

sudo adduser debian-tor
sudo passwd debian-tor

Let’s go for adding the “debian-tor” user to the system and set a random password for him. For editing the configuration of Tor you need to edit the file “/etc/tor/torrc”. Choose your favourite editor, which is either already installed or you should be able to install it via apt-get, and edit the configuration to fit your needs. At least you should have to have this lines adopted:

1
2
3
4
5
6
7
8
9

RunAsDaemon 1 #makes Tor run as a deamon
ORPort 9001 #or 443 if you can offer this service on that port
DirPort 9030 #or 80 if you can offer this service on that port
ExitPolicy reject *:* # to be a node only
Nickname xxx #you can chose whatever you like
RelayBandwidthRate 100 KB # Throttle traffic to 100KB/s (800Kbps)
RelayBandwidthBurst 200 KB # But allow bursts up to 200KB/s (1600Kbps)
ContactInfo \ # Do not use your day to day e-mail address here, make up a new one.
User debian-tor # give Tor the info under which user it should run

I personally prefer to disable all logging on that divice as much a possilble, there I commented every line regarding logging out. Saving the file and restart your raspberry.

1

sudo shutdown -r now

After your Pi has successfully restarted, the Tor process is already started and you should have a look at /var/log/tor/log for any problems around building circuits, connectivity or access on the configuration file. I recommend to setup a dedicated IP on your DCHP for the Tor node or configure your node to use a static one. As this highly depends on the DCHP server you are using I will not cover this here. And you are done. Incredibly easy right?

1

simple_search: https://duckduckgo.com/

After newly generating the content it simple works.

Starting the VM you get a warm welcome with the boot menu.

Let’s choose “Graphical install” for now. Having this choose a standard and not untypical installer process guides you through the setup of language, keyboard setting and so on. After giving the machine a hostname and domain where it is located in, the first “I like” moment appeared. You now have to set the root password within the install process.

To be honest… everyone dealing with a distribution made for pentesting should know that the default password has to be changed immediately and everyone dealing with a distribution made for pentesting should at least know how to google the needed command to change the root password … BUT how many of you have never ever run a backtrack machine with the root password “toor” ?

The next step brings me to the next “I like” moment. It is now a standard option to use encrypted LVM partitions. Very convenient!

So we go for it, choose to put all files in one partition and save the new partition schemata to the disk. Now we start waiting until the disk is fully erased. This took a bit longer than I expect, but after two “I like” moments so far, I don’t want to start complaining about peanuts. 30 GB of disk space needed nearly 90 minutes. You will be able to skip this step over by hitting the cancel button. I tried it without having any problems further on.
Afterwards you set your full disk encryption password and the installer guides us through the rest of the installation process. Nothing unusual or surprising.

And TADA…… nope that is not a running VM with Kali Linux. It is a VM starting up and throwing errors. I then tried to install Kali Linux several times without success and a bit of time went through. A few weeks later I got another day with enough motivation to work again on my VM problem.
I started to google around and found a blog post on raidersec.blogspot.co.at describing how to install Kali Linux on VirtualBox. At the end of the blog post the solution was described. You simple need to check one box that seems to be not activated by default. If you right click on your brand new VM, hit settings and select the “System” entry you will see a tab called “Processor”. Activate the “Processor” tab and check the box called “Enable PAE/NX”.

Save the settings and start your VM. It should now start without errors and present a login screen. I the end I would recommend to create the VM, enable PAE/NX and start to install the system afterwards.