I recently played around a little bit with volshell, as I had realized I do not have sufficient notes on how to use it. I’ll share the notes below.
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.
Getting some help for the first usage can be done by the hh() command.
1234567891011121314151617181920212223242526
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.
1234567
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:
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.
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
12345
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
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:
12
~$ 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.
1234
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:
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.
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.
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.
12
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).
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).
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.
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.
First of all, if you might ask yourself the question “Why should I?” here are two answers - you choose which one works best for you:
1) Because you can.
2) In case of an incident it might be very helpful and there is no traveling back in time and get a second chance.
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
#!/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 stickPCAP=/mnt/netrec/trdump.pcap
SIZE=100
COUNT=72
INTERFACE=re0
PIDFILE=/var/run/tcpdump
start(){if[ -f $PIDFILE];thenecho"PID File $PIDFILE exists"exit 1
fiif(/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"exitfifi /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$! > $PIDFILEexit 0
}stop(){if[ ! -f $PIDFILE];thenecho"PID File $PIDFILE does not exist"exit 1
fi /usr/bin/logger "stoping traffic dump"kill -HUP `cat $PIDFILE`&& rm $PIDFILEexit$@}status(){if[ ! -f $PIDFILE];thenecho"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
esacexit
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.
I had to update my xubuntu install to xubuntu 16 recently, as 15 is not longer supported. Running through the do-release-upgrade without any error I unfortunately ended up with a black screen after rebooting. This seem to be a persistent problem, as it survived several reboots. Not using the NVIDIA driver wasn’t an option either, as it was killing my 3 monitor setup. Searching google/duckduckgo brought the tip to add “nomodeset” to the kernel boot options. So fire up vim /etc/defaults/grub and add “nomodeset” to “GRUB_CMDLINE_LINUX_DEFAULT”. Save it, run “update-grub” and hope for the reboot…
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:
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:
It seems my recent tor relay setup is broken, cause the corresponding tor package for wheezy keeps throwing sec faults.
My new setup is still with the Raspberry pi but I moved from wheezy to Arch Linux now.
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.
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.
1234567
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.
123456789101112131415
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 toruseradd arch-tor
#change password, use some random here, we don't need it.passwd arch-tor
.
#restart the Pisystemctl 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:
123456789101112131415
RunAsDaemon 1 #makes Tor run as a deamonORPort 443
DirPort 80
ExitPolicy reject *:* # to be a node onlyNickname XXX # choose something hereRelayBandwidthRate 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 hereUser 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:
123
[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”.
12
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.
I did not tested this extensively and it might be old but when I needed this and searched for it I did not found this solution. So it might not work for you and I might be bad in search on the Internet.
But as I tend to forget things like this I write this quick post and next time I need to remove print etc. protection from a PDF file: I know where to look.
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.
… or why sometime the solution is so obvious that I' am unable to see it.
I was recently set up my other Raspberry Pi to be a pentesting box, just for the sake of doing it. So I dd'ed the image to the SD card, stated the Pi and was unhappy. I wasn’t able to use the whole SD card. Only the original image size was available to get used by me.
So how to solve it?
I asked the world wide web and found something, but it didn’t worked out for me. I' am pretty sure it was me doing the procedure wrong. But anyways - My problem wasn’t solved. After a bit of further search the net I found an easy solution. I didn’t documented the link, but the steps.
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.
If you ever though about running a Tor node and contribute some bandwidth to the community, but you don’t have a dedicated machine to do so or the machine would be terribly loud, there is an incredible easy way available for you.
You can buy yourself one of these tiny, power-saving and absolutely quite Raspberry pi’s and setup a Tor node with it. I will describe how I have done this in the following.
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:
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.
123456789
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.
1234
sudo dd bs=1M if=2012– 07-15-wheezy-raspbian.img of=/dev/sdb 1850+0 records in 1850+0 records out 1939865600 bytes transferred 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.
12
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.
12345678
sudo vi /etc/apt/sources.list# use new password for the pi user here# add this line to your source listdeb http://deb.torproject.org/torproject.org wheezy main# save file and exit# know add the keygpg --keyserver keys.gnupg.net --recv 886DDD89gpg --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.
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.
12
sudo adduser debian-torsudo 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:
123456789
RunAsDaemon 1 #makes Tor run as a deamonORPort 9001 #or 443 if you can offer this service on that portDirPort 9030 #or 80 if you can offer this service on that portExitPolicy reject *:* # to be a node onlyNickname xxx #you can chose whatever you likeRelayBandwidthRate 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?
I recently changed the search engine of this blog to duckduckgo. I thought it would be a good idea, cause duckduckgo promise not to be the omnipresent data collector. If we could believe them…. I think it does not matter if we believe them or not. We can simply choose between a) we know they collect and b) the promise not to collect. What is the worst case for b)? They collect and lie to us. So worst case for b) is, it is equal to a). I personally would go for b) then.
Therefore I change my _config.yml file the following way:
1
simple_search: https://duckduckgo.com/
After newly generating the content it simple works.
A while ago Kali Linux was released by offensive security. Kali Linux is the successor of the broadly known pentest distribution BackTrack. More info on Kali Linux can be found on www.kali.org.
As I was curious about the new look and feel I started to create a VM with VirtualBox and install Kali Linux to it.
I choose to start with the 32 bit version, cause I still need a fully installed Windows to update the BIOS of my actual working machine.
But 3 GB Ram, 1 core and 30 GB of disk space should fit the needs very well.
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.
