I have a couple new projects in the works that might get a public release (maybe one of them) as it seems like something that could be useful to the general public. New linux projects, new windows projects, and maybe new android projects too! A new year needs some new things and hopefully I’ll get enough time to myself to allow for some of these to see the light of day!

On a side note the reason I haven’t released rcrypt 1.5 officially is because there is literally no feature difference between it and 1.4 with the exception of 2 things.

1) rcrypt now evades AVG

2) i fixed a relocation miscalculation that causes relocation to fail if it is required (could definitely happen on occasion).

Until I add an actual valid new feature I probably won’t release 1.5 but we’ll see.

Version 1.4 adds support for eof data. I hadn’t realized until someone commented but rcrypt destroyed any extraneous data which caused issues with any binaries that made use of this data. This has since been fixed!

MD5 Sum: 40fba75715011b13fd4521163151dbb9
SHA1 Sum: c95dc3708ba8ffafb37e21d5f12b635806fd4a00
Download: rcrypt 1.4

archive pw: 0xrage.com

This is a writeup I did about rcrypt a few months back in PDF format for those interested in how rcrypt works. In addition to some general information this writeup shows some reverse engineering analysis and a test case given a sample of known malware in the context of AV evasion. Fun for the whole family!

File: rcrypt writeup

MD5 Sum: 10c73cc7f922c7baea6d33c35180d19a

SHA1 Sum: c05775934ab46c69bb53164a7c3fca3d9ec75b15

 

 

So I’ve been interested in the chromecast device since I had heard of it a while back and finally got around to ordering one. For $35 before shipping its not bad, even if its just to play with briefly.

Mine finally arrived today! I am going to share some very quick things I’ve discovered about this nifty little device.

Let me first start off by mentioning that I have NOT gotten this device to successfully connect to my wireless network. Part of the reason I even investigated this (and thus decided to share some of my findings here) are due to being unable to get this sweet little device onto my wifi network. That being said I think looking under the hood allows us to peer into how Google designed this device and how it works!

So step 1? Plug the thing into a power source and stick it into one of my TVs many HDMI ports and see what comes up!

The first thing that comes up is a welcome screen showing you the name of the device which is always ChromecastXXXX where the Xs are four randomly generated numbers. At this point I downloaded the android app and proceeded with the configuration which allowed me to do the following things:

1. detect my chromecastXXX device
2. configure it to connect to my wifi network
3. connect to it via my wifi network for the main functionality provided it can now connect to my wifi network.

It was step 3 that kept failing no matter how many times I tried (and rebooted the device) so I decided to see exactly how this setup process worked.

So I grabbed one of my smaller laptops (this one) and decided to try the “manual setup” which is decribed at (https://cast.google.com/chromecast/setup?np=manualsetup).

So how does step 1 work? How was my app able to detect the presence of my ChromecastXXXX device? I assumed it was bluetooth and that configuration occured over a paired bluetooth channel. As it turns out that is not the case. It’s actually good old wifi!

chromecast_ap

So step one in the manual setup process is to connect to the wireless network with the SSID that represents your device name. In the case where I actually took note of this my device SSID was Chromecast8991.

So the little thing starts up an AP and lets you configure it somewhat like a router! Cool. So I connected to this AP and requested an IP address with dhclient. After [forever] I got one.

I got an IP of 192.168.255.250 and the device itself turned out to be 192.168.255.249. Of course the first thing I did was check for open ports. The following ports were open:

53 (non working DNS)
8008 (main communications)

As soon as you connect to the device as a client it will give you a random 4 digit code on screen which I imagine is used for further communications in the case someone else decides to connect to your unencrypted and open device SSID. It will prevent someone unable to see your TV screen to configure your device but thats about it. Once I get this thing working I will take a look at sniffing network traffic to see if I can “cross the streams” on other people’s chromecasts so to speak. Would be hilarious.

chromecast_connected_to_ap

Anyway once you get this code the first step in the configuration begins. All communication with the device at this point is done over json encoded data over HTTP.

The next phase involves telling the device to scan for wireless networks so you can tell it which to connect to and with what security mechanisms. The network traffic looks like this:

GET /setup/eureka_info HTTP/1.1
Host: 192.168.255.249:8008
Connection: keep-alive

HTTP/1.1 200 OK
Access-Control-Allow-Headers: Content-Type
Cache-Control: no-cache
Access-Control-Allow-Origin: https://cast.google.com
Content-Type: application/json
Content-Length: 852

{“build_version”:”12072″,”connected”:false,”has_update”:false,”hdmi_control”:true,”hotspot_bssid”:”FA:8F:XX:XX:XX:XX”,”locale”:
“en_US”,”mac_address”:”D0:E7:XX:XX:XX:XX”,”name”:”Chromecast8991″,”opt_in”:{“crash”:true,”device_id”:false,”stats”:true},”publi
c_key”:”MIIBCgKCAQEAyoaWlKNT6W5+/cJXEpIfeGvogtJ1DghEUs2PmHkX3n4bByfmMRDYjuhcb97vd8N3HFe5sld6QSc+FJz7TSGp/700e6nrkbGj9abwvobey/I
rLbHTPLtPy/ceUnwmAXczkhay32auKTaM5ZYjwcHZkaU9XuOQVIPpyLF1yQerFChugCpQ+bvIoJnTkoZAuV1A1Vp4qf3nn4Ll9Bi0R4HJrGNmOKUEjKP7H1aCLSqj13
FgJ2s2g20CCD8307Otq8n5fR+9/c01dtKgQacupysA+4LVyk4npFn5cXlzkkNPadcKskARtb9COTP2jBWcowDwjKSBokAgi/es/5gDhZm4dwIDAQAB”,”release_tr
ack”:”stable-channel”,”setup_state”:11,”ssdp_udn”:”82c5cb87-27b4-2a9a-d4e1-5811f2b1992c”,”ssid”:””,”uma_client_id”:”4DE23B6E-B2
B0-7DBC-7BFB-F29D84AF87EF”,”uptime”:83.5,”version”:4,”wpa_configured”:false,”wpa_state”:3};,`* cSc52{zerogoki7w,/y*;,`* cSc52{z
erogoki7w,/y*GET /setup/eureka_info HTTP/1.1
Host: 192.168.255.249:8008

Based on the traffic you can see that the /setup/eureka_info URL is used to request the initial scan/results. You can also see various information about the bssid/ssid as well as some of its current configuration, the hostname of the system connected to it, and a bunch of IDs. Also that I’ve somehow opted into sending Google information when there is a crash as well as for stats is noted. Fun. You can see that there seems to be public key crypto which is good if we’re going to be sending our wifi network details over an open and unencrypted wireless network.

I did notice during the multiple times I’ve tried to connect this to my wireless network that the public key changes so it is generated by the device and not hardcoded (which is just fine). What I did find very interesting is that this very request the last couple of times included GPS data which means this device has GPS????? Here is a snippet of a previous response:

HTTP/1.1 200 OK
Access-Control-Allow-Headers: Content-Type
Cache-Control: no-cache
Access-Control-Allow-Origin: https://cast.google.com
Content-Type: application/json
Content-Length: 998

{“build_version”:”12072″,”connected”:false,”has_update”:false,”hdmi_control”:true,”hotspot_bssid”:”FA:8F:XX:XX:XX:XX”,”locale”:”en_US”,”location”:{“latitude”:39.XXXXXX,”longitude”:-76.XXXXXXX},”mac_address”:”D0:E7:XX:XX:XX:XX”,”name”:”Chromecast6603″,”noise_level”:-84,”opt_in”:{“crash”:true,”device_id”:false,”stats”:true},”public_key”:”MIIBCgKCAQEA1eq2miUMleKr/vjbb/3cd3rMkSZG0PnerBYpAjkHPA02FM8OCoMe+OIV0t6OJ3BFNnf3nJLThSw/ckQ+h6CpWfxVlc/d5ETKdl5RMuco3y0pos3Boz83ZUlXyGgfZeSUAh1oopf+xdterfc2E9S6GUdfY0yrwwpah0BxBAze6Bwk4kfPNJnH5Vvew8f8S3uLhXIIV7loyxzdf+XVd1eXyeMU61BI32X2Ft81wZI116LzirloUsUju7E1DZZTMHSDzqkZezOwGUDkFZZxPDrNcZnU1kEcxpXtXaaxNeWWGFvhf1QYPegu9J9bxWAvz5ZimlW8qOnCxgYBdr75jXAidwIDAQAB”,”release_track”:”stable-channel”,”setup_state”:11,”signal_level”:-46,”ssdp_udn”:”63023a09-fa02-e49e-9289-6edd183146f1″,”ssid”:”myssid”,”timezone”:”America/New_York”,”uma_client_id”:”C23C5542-B402-A470-FBD2-C0E8701D4E6B”,”uptime”:3284.05,”version”:4,”wpa_configured”:false,”wpa_id”:0,”wpa_state”:1}

I’ve verified that that lat/long is exactly where I live. EXACTLY. Very creepy.

Next we see some more data about the public key to use:

{“build_version”:”12072″,”connected”:false,”has_update”:false,”hdmi_control”:true,”hotspot_bssid”:”FA:8F:XX:XX:XX:XX”,”locale”:”en_US”,”mac_address”:”D0:E7:XX:XX:XX:XX”,”name”:”Chromecast8991″,”opt_in”:{“crash”:true,”device_id”:false,”stats”:true},”public_key”:”MIIBCgKCAQEAyoaWlKNT6W5+/cJXEpIfeGvogtJ1DghEUs2PmHkX3n4bByfmMRDYjuhcb97vd8N3HFe5sld6QSc+FJz7TSGp/700e6nrkbGj9abwvobey/IrLbHTPLtPy/ceUnwmAXczkhay32auKTaM5ZYjwcHZkaU9XuOQVIPpyLF1yQerFChugCpQ+bvIoJnTkoZAuV1A1Vp4qf3nn4Ll9Bi0R4HJrGNmOKUEjKP7H1aCLSqj13FgJ2s2g20CCD8307Otq8n5fR+9/c01dtKgQacupysA+4LVyk4npFn5cXlzkkNPadcKskARtb9COTP2jBWcowDwjKSBokAgi/es/5gDhZm4dwIDAQAB”,”release_track”:”stable-channel”,”setup_state”:11,”sign”:{“certificate”:”—–BEGIN CERTIFICATE—–\nMIIDqzCCApOgAwIBAgIEUf6McjANBgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJV\nUzETMBEGA1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwNTW91bnRhaW4gVmlldzET\nMBEGA1UECgwKR29vZ2xlIEluYzESMBAGA1UECwwJR29vZ2xlIFRWMRgwFgYDVQQD\nDA9FdXJla2EgR2VuMSBJQ0EwHhcNMTMwODA0MTcxNjM0WhcNMzMwNzMwMTcxNjM0\nWjCBgDETMBEGA1UEChMKR29vZ2xlIEluYzETMBEGA1UECBMKQ2FsaWZvcm5pYTEL\nMAkGA1UEBhMCVVMxFjAUBgNVBAcTDU1vdW50YWluIFZpZXcxEjAQBgNVBAsTCUdv\nb2dsZSBUVjEbMBkGA1UEAxMSWktCVjIgRkE4RkNBM0EwQ0QwMIIBIjANBgkqhkiG\n9w0BAQEFAAOCAQ8AMIIBCgKCAQEA+HGhzj+XEwhUT7W4FbaR8M2sNxCF0VrlWsw6\nSkFHOINt6t+4B11Q7TSfz1yzrMhUSQvaE2gP2F/h3LD03rCnnE4avonZYTBr/U/E\nJZYDjEtOClFmBmqNf6ZEE8bxF/nsit1e5XicO0OJHSmRlvibbrmC2rnFwj/cEDpm\na1hdqpRQkeG0ceb9qbvvpxBq4MBsomzzbSq2nl7dQFBpxDd2jm7g+4EC7KqWmkWt\n3XgX++0qk4qFlbc/+ySqheYYddU0eeExvg93WkTRr5m6ZuaTQn7LOO9IiR8PwSnz\nxQmuirtAc50089T1oyV7ANZlNtj2oW2XjKUvxA3n+x8jCqAwfwIDAQABoy8wLTAJ\nBgNVHRMEAjAAMAsGA1UdDwQEAwIHgDATBgNVHSUEDDAKBggrBgEFBQcDAjANBgkq\nhkiG9w0BAQUFAAOCAQEAXmXinb7zoutrwCw+3SQVGbQycnMpWz1hDRS+BZ04QCm0\naxneva74Snptjasnw3eEW9Yb1N8diLlrUWkT5Q9l8AA/W4R3B873lPTzWhobXFCq\nIhrkTDBSOtx/bQj7Sy/npmoj6glYlKKANqTCDhjHvykOLrUUeCjltYAy3i8km+4b\nTxjfB6D3IIGB3kvb1L4TmvgSuXDhkz0qx2qR/bM6vGShnNRCQo6oR4hAMFlvDlXR\nhRfuibIJwtbA2cLUyG/UjgQwJEPrlOT6ZyLRHWMjiROKcqv3kqatBfNyIjkVD4uH\nc+WK9DlJnI9bLy46qYRVbzhhDJUkfZVtDKiUbvz3bg==\n—–END CERTIFICATE—–\n”,”nonce”:”Aw4o0/sbVr537Kdrw9YotiXxCLIaiRrDkHeHrOpih3U=”,”signed_data”:”fcTwn3K4I/ccok1MeZ5/nkM0pI5v4SrTv3Q4ppOQtVL5ii3qitNo+NLhY+DM9zmnP6ndNMZbkyIEyMm7LjganoDoE+o0e0/r4TyGEGLxYlfWSzf+Z3cSdNe4+MyHx/7z02E0/3lLsOFuOEPSgR26JFtyhDLCJ9Y8Cpl3GZMUqm4toaTNaIbhNMR9Bwjkz4ozKXzFl9dF5FTU6N48KeUP/3CuYqgm04BVUGxg+DbBmTidRnZE4eGdt9ICJht9ArUNQDL2UdRYVY2sfgLmF29exTaSrVkBZb/MsbDxN5nYpF1uE7IhzJnT5yFM9pmUOIKKTfeVaLVLGgoWd+pjEbOv+Q==”},”ssdp_udn”:”82c5cb87-27b4-2a9a-d4e1-5811f2b1992c”,”ssid”:””,”uma_client_id”:”4DE23B6E-B2B0-7DBC-7BFB-F29D84AF87EF”,”uptime”:101.98,”version”:4,”wpa_configured”:false,”wpa_state”:3}GET /setup/eureka_info HTTP/1.1
Host: 192.168.255.249:8008

After this the device knows you are ready to configure it and returns the next bit of data which represents the results of a successful wireless scan of potential SSIDs to connect to:

[{"bssid":"c8:xx:xx:xx:xx:xx","signal_level":-41,"ssid":"myssid","wpa_auth":7,"wpa_cipher":4},{"bssid":"5c:0a:xx:xx:xx:xx","si
gnal_level":-42,"ssid":"myotherssid","wpa_auth":7,"wpa_cipher":4},{"bssid":"30:46:xx:xx:xx:xx","signal_level":-53,"ssid":"Hooters","wpa_auth":7,"wpa_cipher":4},{"bssid":"00:1d:xx:xx:xx:xx","signal_level":-61,"ssid":"neighborsssid","wpa_auth":7,"wpa_cipher":4},{"bssid":"b8:9b:xx:xx:xx:xx","signal_level":-64,"ssid":"anotherRetardedNeighborSSID","wpa_auth":7,"wpa_cipher":4},{"bssid":"06:27:xx:xx:xx:xx","signal_level":-42,"ssid":"free open wifi1","wpa_auth":1,"wpa_cipher":1},{"bssid":"06:27:xx:xx:xx:xx","signal_level":-44,"ssid":"more free open wifi","wpa_auth":1,"wpa_cipher":1}]&,* cSc52{zerogoki7w,/y*&,* cSc563:T`;&,* cSc562zerogoki7w,/y*&,* cSc563:T`;zerogokiwwwwgooglecom

wifisetup

A fun thing to note is that I’ve opted for not sending any information but this is conveniently ignored and I am still opting in for submitting data when there is a crash and for stats. Anyway, you can see SSID signal levels and other information. At this point you configure the device to connect to a wifi network by telling it the SSID and password.

This looks like the following:

POST /setup/connect_wifi HTTP/1.1
Host: 192.168.255.249:8008
Connection: keep-alive
Content-Length: 450
Origin: https://cast.google.com
User-Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.57 Safari/537.36
Content-Type: application/json;charset=UTF-8
Accept: */*
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8

{“bssid”:”5c:0a:xx:xx:xx:xx”,”signal_level”:-42,”ssid”:”myotherssid”,”wpa_auth”:7,”wpa_cipher”:4,”enc_passwd”:”AKWQ1K76dYzBzd5XLCkieFepJq+jvWcDMzTWGud7U66iWpfHS5LN4hhzEEcCdrWGyRC2pw0FRbx6dXUILPr40Os2ysp7AYqIloazqc6JsKAP+aLVv9OW8UpJJTEQVbkgcJiuh9+tPLZrmnHTURWHpXlBuYSJkwZDkW8ywnTcg8+wnrRho6BtMtKyXvNH3QIJhk+nXKHxLh154aMdA9+N3R4ZfH+4SNHrFiHhILXPiBgVmsMCM64kEgNQTRNu3Fzasyfea6XVVaQdWRB2DZC+euapWM1G/Pr9dXz1MraUc2tlEaO1LvDoDmy+08+k/ATwuOQO0DjIExsrEcHQIVXfPY=”}HTTP/1.1 200 OK
Access-Control-Allow-Headers: Content-Type
Cache-Control: no-cache
Access-Control-Allow-Origin: https://cast.google.com
Content-Length: 0

At this point you can see that the request to connect uses the URL /setup/connect_wifi and is encrypted with the public key of the router (thankfully). You can see the target SSID/BSSID cipher type and password in the request.

It is at this point that the on screen display says: Connecting to “myssid” and for me it sits there FOREVER and never connects. I even tried to connect to a router I setup 5 feet away and ended up with this being the furthest it would go.

chromecast_cant_connect

Obviously once I get this connected I’ll continue my review of this cool little device and more importantly see what kind of fun things we can discover by analyzing its network traffic. For example I don’t even see the 4 digit code used in the communication between the client and the device but who knows? Maybe it is used in some obscure way that I haven’t seen. Another interesting thing is that although you can see that the http traffic is local between you and the device, it is facilitated over a connection to the public internet URL (https://cast.google.com/chromecast/setup?np=manualsetup) that uses local IP links/requests. I havent’ even looked at the website/js that performs these actions yet but I’m sure it would be interesting as well. Especially since I’m sure it takes note of the various responses returned from your GPS enabled device.

All in all, very impressive for a $35 device. Its tiny and comes with a built in AP used for configuration. I look forward to checking out its actual functionality once successfully connected!

rcrypt 1.3

Added functionality:
- breaks certain automated analysis engines
- added polymorphism to various other existing functionlities

If you don’t know what rcrypt is check out the original post

md5 sum: 80cc3105b0f035daa0cd19e85bc7c379
sha1 sum: 345fb729fcda1ef5bf004869abc1634092685718

download rcrypt

archive pw: 0xrage.com

Greetings.

Last time I posted about this topic I had planned to support tuxonice for suspend to RAM and disk. However since then I’ve decided to drop that aspect for two reasons.

1 TOI is way behind in terms of kernel versions

2 The default in kernel suspend to RAM/disk seems to work just fine

Instead of just continuing from the last post I wanted to create a new one that is hopefully a bit more clear. Again we will start at the part of the Gentoo handbook installation where we partition our disks.

Normally we’d create partitions for boot, swap, and root. Instead we will create two partitions. One for boot and the other for encrypted LVM. This LVM partition will use logical volume management to contain an arbitrary number of logical volumes which in our case will be used for swap and root.

Creating your encrypted partition

As before using fdisk (or whatever partition tool you prefer) create to partitions.

/dev/sda1

/dev/sda2

sda1 above is set to bootable and is of filesystem type 83 (linux). sda2 is of the same filesystem type.

I normally use ext2 for my boot partition but you can use whatever you like.

mkfs.ext2 /dev/sda1

Now we will prepare our encrypted partition. Load the following modules if they aren’t already available.

modprobe dm-crypt
modprobe aes
modprobe sha256

Now format the partition with cryptsetup.

cryptsetup luksFormat /dev/sda2

Create your password and be sure to memorize it.

Now open the encrypted partition.

cryptsetup luksOpen /dev/sda2 main

Enter your password.

You will now have access to your partition in /dev/mapper/main. Keep in mind the name “main” was chosen randomly and is just the name of the file that will represent the unlocked partition. You can change it every time you unlock it if you want.

Now create the physical volume and volume group.

pvcreate /dev/mapper/main
vgcreate [vgname] /dev/mapper/main

Now we create two logical volumes in our new volume group [vgname].

lvcreate -L 1G -n swap [vgname]
lvcreate -L XG -n root [vgname]

Here I chose 1G for the swap partition size. X is just the size of the remaining space available to be for the root partition. You can find the remaining space available with the following command.

vgdisplay

If you look at the value for the field “PE Total” you will see how much space is available for allocation. Other fields can also be helpful to such as “allocated” and “free”.

At this point you now have two logical volumes for swap and root respectively. You can now format them as you normally would.

mkswap /dev/vg/vg-swap
mkfs.ext4 /dev/vg/vg-root

At this point the rest of the gentoo handbook applies as normal. The exception is that you will need an initramfs to perform the unlocking of your encrypted partition. After you create your initramfs you will need to make sure to reference it in your grub config or whatever you use to bootstrap your OS installation.

Creating the initramfs

Now onto creating the minifilesystem loaded by the kernel first. This is necessary to decrypt your encrypted partition to allow the boot process to continue.

Create a directory to work under, as we’ll be creating a filesystem.

mkdir initramfs
cd initramfs

Now create the directories with the following.

mkdir -p bin lib dev etc mnt/root proc root sbin sys

Now copy of the usual device nodes from your existing filesystem into your initramfs.

cp -a /dev/{null,console,tty,sda1,sda2} .

Feel free to copy other devices as needed. Also if your drive is not sdaX change it accordingly.

You will want to copy over various utilities that you might want to use as well. Just be sure they are compiled with the “static” use flag as any dependencies binaries have will also need to be copied. To avoid copying over huge chains of dependencies just compile the files you want statically so you won’t have to worry about this.

Since we are using cryptsetup and lvm we will need to copy our cryptsetup and lvm binaries (built statically)  onto the filesystem.

Once you build them statically just copy them into the ./sbin directory.

Its also typical to build busybox and add it to ./bin so feel free to customize.

The main part of the initramfs is the init script in the root of the initramfs. It is what gets executed immediately after the kernel boots and then it, once the real root partition is decrypted, calls the main init script.

Below is part of my initramfs init script. This is the minimum requirement to accomplish the decryption and booting we need.

#mount proc and sys filesystems

mount  -t proc none /proc

mount -t sysfs none /sys

echo 0 > /proc/sys/kernel/printk

# decrypt

/sbin/cryptsetup luksOpen /dev/sda2 main

/sbin/lvm vgscan –mknodes

/sbin/lvm lvchange -aly vg/swap

/sbin/lvm lvchange -aly vg/root

#mount

mount /dev/mapper/vg-root /mnt/root

#cleanup

umount /proc

umount /sys

# and we continue

exec switch_root /mnt/root /sbin/init

Save this into your init script.

chmod u+x init

Some of the things I put in here could use a bit of explanation.

The echo 0 disables kernel printk debug messages. I did this because these kernel messages come up a lot, even during typing of my password. I found it irritating so I disabled it during the initramfs process.

The cryptsetup line is pretty straightforward as it lets us unlock our encrypted partition. The following lvm lines are to enable our logical volumes and make the representative device nodes in /dev/mapper.

The final part is where the script hands off control to the decrypted init script on the root partition. Keep in mind that there is a space between the /mnt/root and /sbin/init.

Once you’ve created the filesystem to your needs you must build this mini filesystem into an initrd gzipped cpio type file to be included along with your kernel. To build the initramfs file you can issue the following command.

find . -print0 | cpio --null -ov --format=newc | gzip -9 > /boot/my-initramfs.cpio.gz

Name your initramfs.cpio.gz file however you like and make sure to include it in your bootloader. For grub it would look something like the following.

title=My Linux

root (hd0,0)

kernel /boot/my-kernel

initrd /boot/my-initramfs.cpio.gz

At this point you can reboot your system and test your setup. Your initramfs should load and allow you to enter your encrypted partition password. After that bootup should continue as usual. You can of course make your init script smarter by checking for a correct login or spawning a busybox shell if you need to. These options are left to you.

LVM device nodes

Another thing you might want to do is add a startup script to be executed by your system during boot that will re-create the lvm device nodes as they will no longer exist when the initramfs is removed from memory after it is done. If you use swap your system won’t be able to find /dev/vg/swap since the node for it wouldn’t have been created. I’m not sure why lvm doesn’t automatically see this but I added a simple script to my /etc/local.d/ called 40_fixlvmnodes.start that has the following contents.

#!/bin/bash

echo “creating lvm nodes”

/sbin/lvm vgscan –mknodes

echo “enabling swap”

swapon /dev/vg/swap

Don’t forget to make this script executable too.

chmod u+x 40_fixlvmnodes.start

Be sure to update your /etc/fstab with your root and swap filesystems with the appropriate device paths. Mine looks like this.

/dev/vg/root / ext4 noatime 0 1

/dev/vg/swap none swap sw 0 0

Additional LVM usage

It is useful to become more familiar with lvm as it can be needed if you have to make any changes. For example when I did this on my new laptop I had created the root logical volume too small. It was using only 172G leaving over 500G unallocated! Using lvextend you can add unallocated space to a logical volume provided the physical volume can accommodate it.

lvextend -L+500G /dev/vg/root

Using lvextend I was able to use the full free space for my root partition as I had originally intended. The filesystem used for my root partition is ext4. In order for this already existing filesystem to see the available space I had to expand the filesystem as well.

I was able to do this, after resizing the logical volume above, with the following.

resize2fs /dev/mapper/vg-root

Keep in mind I did this from my livecd so the filesystem was not mounted during these operations. I’ve read that ext4 can be resized during runtime however I prefer not to chance potential filesystem corruption.

Once this was done I just rebooted and verified that my root partition was as large as it should be. All was good.

Final notes on full disk encryption

Other notes are that this is not entirely full disk encryption. The boot partition is obviously left unencrypted. If you truly want your entire disk to be encrypted you would have to perform the same operations but for all things involving the /boot partition you would use a USB drive of some kind. You will need this USB disk to boot your system. This offers more protection but managing a physical item is overkill for me. I just want to mention it in case someone is interested in doing this.

Now your root and swap partitions are fully encrypted at rest! Once your system is on however the disk is obviously unencrypted so disk encryption is only really useful “at rest”. This means if you shut down your system your content is safe. However once you boot up your filesystem is available if you are, say, nabbed while your system is on. In addition to this your crypto key is in memory at a probably known location (cryptsetup/dm-crypt are open source afterall). Its unlikely you will be in a scenario where this matters as only feds and those with some fun tools can make use of this information. I just want to be complete with this article so you are more aware. Knowing the ins and outs of security is very important.

That said, enjoy!

 

 

rcrypt version 1.2 is now released!

rcrypt is a Windows PE binary crypter (a type of packer) that makes use of timelock techniques to cause a delay in execution. This delay can cause analysis to fail on time constrained systems such as on disk scanners. rcrypt can pack exes and dll files. PEs that use tls or other interesting features of the PE spec are not currently supported. I may add support for more spec features as time permits. In version 1.0 and 1.1 your funky active X and COM files will not work. If there is enough interest I will consider adding other features/support.

rcrypt features include:

encryption of all code/data

timelock puzzle

This is just a proof of concept tool to showcase the potential use of these techniques as well as potential shortcomings of various detection systems.

rcrypt is being released for educational purposes. I do not condone malicious or illegal use of this tool. Using this tool might also cause you to experience light headedness or fatigue. I also take no responsibility for any of these potential outcomes. Use your own discretion.

rcrypt 1.2

Minor re-addition of some internal functionality that was removed from versions 1.0 and 1.1 due to issues with windows xp/7 and 32/64 bit. Issues resolved and 1.2 is now out.

File MD5 sum: 1c0989a751038a49052a4e37f8879f43

File SHA1 sum: 4c22b51e466fd2516c68c94c2dd5f4dbf1bc395b

rcrypt v1.2 (File archive password: 0xrage.com)

 

rcrypt 1.1

Added in rcrypt version 1.1 is the optional switch -trick0. Read the readme for details.

File MD5 sum: 6c53c7d7dc6b342174b1eda13597c771

File SHA1 sum: 30f6fbf6c615269b6c894f7eec125a03c4cd5afd

rcrypt 1.1 (File archive password: 0xrage.com)

 

Hey guys. So after much speculation that most people won’t just run arbitrary binaries that require root (despite being signed etc) I’ve decided to release the source to sessionlist on github! I guess after deving for windows all these years I just assumed people just double click everything and select ok ;P

Anyway if you don’t know what sessionlist is see the post below. Feel free to use this tool as you see fit, and if you find bugs and feel like sharing I’d be grateful! I’m sure this tool can be improved upon so let those creative juices flow!

Github: https://github.com/iamrage/sessionlist

Enjoy!

 

It’s been a little while huh. Well I’ve decided to release the finished v0.1 beta of my sessionlist tool.

A little about it and why I created it.

HTTP is a simple protocol, and many use it to create “program-like” websites. With asynchronous requests available in almost every browser (including mobile ones) it’s no surprise that many people create a zillion and one sites for almost any purpose. The underlying issue with HTTP is that it is stateless. How do you create the illusion of program state in a naturally stateless protocol? The correct answer is to create a new protocol that is designed for this purpose however that didn’t happen. Instead we have silly hacks that allow us to pretend to have state while using HTTP. How is this accomplished? Well, we pass variables and their values back and forth with every single request! It will cause overhead but they’re websites not real programs! To make this more manageable many web scripting languages support sessions which can reduce the overhead by storing a session id in browser cookies instead of all the variables/values and use the session id to look up server stored variable/values. Of course now all you need to facilitate authentication is the session id.

So if a website relies on cookies to store authentication details, be it via session id or other state information, a user can simply nab this information and present it as if they were the user and they should be authenticated as if they logged in with valid credentials.

Sessionlist v0.1 is a network sniffer that simply observes cookies sent over HTTP (via port 80 or user configured port via cmd line) and keeps track of them. It will save a list of sites and cookie data along with user-agent strings which should be sufficient to effectively spoof the user who generated the traffic. All you need is a plugin that allows you to set your own user agent and cookie data. I personally have found Firefox’s modify headers plugin to work perfectly but I’m sure others are fine as well. Using this tool to sniff traffic you can basically collect authentication data as it passes over the wire (or air). This will work on unencrypted HTTP traffic but if you’re familiar with SSL MITM attacks you can make this work on those sites as well. Generally for wireless sniffing you don’t need to perform any MITM attack but if you’re on a switched network then obviously a regular MITM attack will be needed. There are many tools that perform those functionalities so use your favorite.

As mentioned before this tool is a beta so there are bound to be bugs so please let me know as you find them so I can squash them and make this a better tool! I’ve included 32 and 64 bit builds. I may release this tool as open source sometime in the future.

The release archive is signed with my public pgp key which you can find on my about page. Click [here] for that. Once you’ve imported my public key simply run:

gpg [thefile.gpg]

If the signature is good then you’re set. If the signature fails then you are probably dealing with a tampered file (or you incorrectly imported my key somehow).

All feedback is appreciated and enjoy!

UPDATE:

Released version 1.0 with MORE bug fixes and UI changes! Threading issues have been fixed as well!

sessionlistv1.0

Older versions:

(v0.2 changelog)

Released version 0.2 with minor bug fixes and a much better capture engine (removed idiotic threading crap; until another version pthread will remain linked).

sessionlistv0.2

sessionlistv0.1