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
|
|
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 |
|
To list the processes you can run the ps() command within the interactive volshell prompt.
1 2 3 4 5 6 7 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
If we are not changing the context to the process we are investigating we might get the following error.
1 2 3 4 |
|
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 |
|
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 |
|
But what if we want to see the content of the environment variables of the process?
1 2 3 4 5 6 |
|
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 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 |
|
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
|
|
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 |
|
Printing the ProcessEnvironmentBlock now works easily by just adding the corresponding name.
1 2 3 4 5 6 7 8 |
|
THe ProcessParameter would be the next step in the journey:
1 2 3 4 5 6 7 8 9 |
|
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 |
|
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 |
|
This will give you the following history output format:
1 2 |
|
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 |
|
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
|
|
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
|
|
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
|
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
After saving the file you need to run the following command to start tor after a reboot:
1
|
|
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 |
|
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
|
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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
|
|
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 |
|
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 |
|
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 |
|
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 |
|
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
|
|
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?
]]>_config.yml
file the following way:1
|
|
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.
]]>