Get the (readable) certificate from a windows executable (PE)

I searched high and low for a simple (linux) solution on how to extract the certificate of an authenticode signed windows binary. I don't want to use wine, nor mono. This is what I came up with:

• Extract the certificate with 7zip: 7z e setup.exe CERTIFICATE
• remove the first 8 bytes: dd if=CERTIFICATE bs=1 skip=8 of=setup.exe.pkcs7
• Read it: openssl pkcs7 -in setup.exe.pkcs7 -inform DER -print_certs -text

How to get IPv6

There's 4 ways to get IPv6:

• Native (duh)
• Your ISP hands out native IPv6 addresses using dhcp6 or RA (router advertisement, some sort of auto-configure)
• Using a tunnel broker
• Like http://www.sixxs.net
• Using a 6to4 tunnel (see earlier post)
• Using 6rd (if your ISP implemented this)

6rd

This looks and works a lot like 6to4. A router on your local network establishes a tunnel to a v4 router that has IPv6 and encapsulates the IPv6 traffic in v4 packets to this router. With 6to4, the prefix (2002::) and tunnel endpoint IP (192.88.99.1) are always the same. With 6rd, these are owned (and thus maintained) by your ISP. You can't setup 6rd unless your ISP tells you the IPv6 prefix and the v4 endpoint address they use. A way to do this automatically is using the dhcp "option-212" response. To test this using isc-dhcp, add this to your dhclient.conf:

option option_6rd code 212 = { integer 8, integer 8, integer 16, integer 16, integer 16, integer 16, integer 16, integer 16, integer 16, integer 16, array of ip-address };

request option_6rd; # add the option_6rd to the list of other request options

If the ISP has a limited set of IPv4 addresses, with the same prefix, they can choose to use a longer (base) IPv6 prefix. In the first picture, the full IPv4 address is used to build the full IPv6 address:

Here the IPv6 ISP prefix is 2011:1001::, the IPv4 address from the customer is 129.10.11.12 and to complete the IPv6 address, the MAC address of the customer (interface ID) is converted and added to this.
In the next picture, only part of the IPv4 address is used, so the ISPs IPv6 network used can be smaller:

Here the IPv6 ISP prefix is 2011:1001:01, the IPv4 address part used is 10.11.12 and the rest is the interface ID as in the previous example.

Images taken from: http://meetings.apnic.net/__data/assets/pdf_file/0017/31148/APRICOT-6rd-final.pdf

Getting access to IPv6 for everyone using 6to4

Using 6to4 seems deprecated, but it still works as tunnel servers are still available. 

If you get your Internetz from a 19-century ISP who hasn't implemented IPv6 yet (read: almost all). You have a couple of choices to get access to IPv6.

• Using a tunnel broker (recommended)
• www.sixxs.net is a good one
• Using 6to4 tunneling

To configure 6to4 tunneling, first see if you can reach a tunnel server by doing a ping or traceroute to  192.88.99.1. This IP exists on multiple networks, so you should be able to reach one.

Now to setup the tunnel, you first need to calculate your 6to4 IPv6 address:

printf "2002:%02x%02x:%02x%02x::1\n" `echo YOURv4ADDRESShere | tr . ' '`

Now build the tunnel:

ip tunnel add tun6to4 mode sit remote any local 188.142.102.38

ip link set dev tun6to4 mtu 1472 up

ip -6 add add YOURv6ADDRESShere/16 dev tun6to4

ip -6 route add ::/96 dev tun6to4 metric 1 

ip -6 route add 2000::/3 via ::192.88.99.1 dev tun6to4 metric 1

Now test this:

ping6 google.com

To break down the tunnel:

/sbin/ip -6 route flush dev tun6to4

/sbin/ip link set dev tun6to4 down

/sbin/ip tunnel del tun6to4

Info taken from http://www.wlug.org.nz/6to4

If you like, you can setup reverse DNS and register it at https://6to4.nro.net/ (visit this page using your new 6to4 address to make this work).

Nokia N900 - charging a depleted battery that causes a bootloop

So I have this Nokia N900 laying around. I once tried to flash something on it, which failed and caused a bootloop. I was dumb enough to leave it looping (had to catch a train and left it), which then depleted the battery.
The N900 needs a booted OS to charge the battery, and needs a charge in the battery to boot.. so there's the problem, I wrecked the OS, so it wouldn't boot up and thus wouldn't charge.  Flashing the original OS would fail, as the battery was depleted and you can't flash on only the USB power.
I tried backing the battery with another 3.7V from another phone that I had somewhere, but that wouldn't help.
Finally I found the solution in using the rescueOS image. This image isn't flashed but just loaded and then booted. It's initrd contains a script to charge.
Here's how I got it working:

• Download the newest kernel and initrd image from http://nin101.uni.cx/N900/rescueOS/
• Download the flasher for your OS (see: https://wiki.maemo.org/Updating_the_tablet_firmware)
• Start the flasher: sudo /usr/bin/flasher-3.5k 2.6.37 -n rescueOS-initrd-0.5.3.img  -l -b"rootdelay root=/dev/ram0"
• Remove battery and USB from the N900
• Make sure to have the wall charger ready to go as the USB power won't be enough
• Insert the battery
• Press and hold the 'u' key on the N900 keyboard
• Connect the N900 to the PC with the USB cable
• Expect the following output:

flasher v2.5.2 (Nov 25 2009)

Suitable USB device not found, waiting.

USB device found found at bus 002, device address 005-0421-0105-02-00.

Found device RX-51, hardware revision 2101

NOLO version 1.4.14

Version of 'sw-release': RX-51_2009SE_21.2011.38-1_PR_MR0

Sending kernel image (1901 kB)...

100% (1901 of 1901 kB, avg. 27559 kB/s)

Sending initfs image (12548 kB)...

100% (12548 of 12548 kB, avg. 27761 kB/s)

Using kernel command line: "rootdelay root=/dev/ram0"

• Remove the USB cable once the image has booted and insert the wall charger
• Now start the charger script: /rescueOS/charge21.bash (see http://nin101.uni.cx/N900/rescueOS/documentation.txt)
• Wait and see ;o) Voltage should be close to 4V and the battery level increasing within minutes

Booting a 'broken' macbook pro

So I got a 'broken' macbook pro with a broken screen. When powering up the machine, the sleep light lights faintly, the CD-ROM drive spins and the fans come on. The HD doesn't start up.
Reading through a lot of forum posts, this is what finally got it back to work:

• remove battery and power cable
• press and hold the power button for over 10 seconds
• remove the memory
• press and hold the power button for over 10 seconds
• replace memory and battery
• replace power cable
• power on

Some other reset procedures that found for the macbook pro:

Resetting the SMC

1. Shut down the computer.
2. Unplug the computer's power cord.
3. Wait fifteen seconds.
4. Attach the computer's power cord.
5. Wait five seconds, then press the power button to turn on the computer.

Resetting PRAM

1. Shut down the computer
2. Press the power button to tun on the computer
3. Immediately press and hold CMD, Option (alt), P and R
4. Wait until you hear the gong for the second time
5. Release the keys

Booting in safe mode

Press and hold shift after powering up. This forces the mac to check things instead of assuming that hardware has not changed. Note that some drivers, like the WiFi, aren't loaded.

Tuning for a high-latency, high-speed link.

So we got a link from Amsterdam to the US, a fiber link with about 100ms RTT.
Initial speed testing (DONT USE SSH/SCP) gave us 25.9M/s.
That's with a defaul linux centOS5 install with the following settings:

ipv4/tcp_mem: 196608 262144 393216
ipv4/tcp_rmem: 4096 87380 262144

ipv4/tcp_wmem: 4096 87380 262144

core/rmem_default: 262144

core/rmem_max: 262144
core/wmem_default: 129024
core/wmem_max: 131071
core/optmem_max: 20480
ipv4/tcp_window_scaling: 1
ipv4/tcp_timestamps: 1
ipv4/tcp_sack: 1
core/netdev_max_backlog: 1000
interface tx/rq queuelen: 1000

Tuning this, I get the full 111M/s. I used these settings:

ipv4/tcp_mem: 196608 262144 393216
ipv4/tcp_rmem: 4096 87380 26843546
ipv4/tcp_wmem: 4096 87380 26843546 
core/rmem_default: 262144
core/rmem_max: 26843546
core/wmem_default: 129024
core/wmem_max: 26843546
core/optmem_max: 20480
ipv4/tcp_window_scaling: 1
ipv4/tcp_timestamps: 1
ipv4/tcp_sack: 0
core/netdev_max_backlog: 10000
interface tx/rq queuelen: 10000

For the max tcp buffer settings, I used: 2 * 1024 * 1024 * 1024 *0.1 / 8 (2 times bandwidth times RTT)
Now it takes about 15 seconds to get to the full speed, as the tcp congestion is still set to the default (BIC). When changed to HTCP (highspeed TCP), this only takes 8 seconds (echo htcp > /proc/sys/net/ipv4/tcp_congestion_control).

How cool is this? a 1Gb/s connection overseas? :)

Apple netboot

I tried updating an old Apple macbook (this one) to Mac OS Snow Leopard. I lost my install DVD a long time ago, but I did have an image of it.
First, I tried fitting the DVD image to a single layer DVD-r. I managed to do so, but it wouldn't boot. Next I tried booting from an IDE disk with the contents of the image via USB, it booted but hanged while starting the OS.
So there was one thing left to try: netbooting!
I once noticed this 'Remote Install Mac OS' in Applications/Utilities. So I started it, clicked through the menu and fired up the macbook in netstart mode. I don't know what this application does, but it doesn't even respond to DHCP / BOOTP. Maybe this does work for newer macbooks, but it doesn't work for this one. Googling away, I found some guides on how to use a Mac OS server as bootserver, but I don't own one. You can, however download the server package which contains the 'System Image Utility' (go to support.apple.com and look for 'Server Admin Tools'. This, together with a linux box, finally allowed me install the macbook.
On the linux box, you will need apache, tftp and dhcp.
To setup the image, mount the disk image and start the System Image Utility. Select netinstall, next, create. When done, copy the files in '/Library/NetBoot/NetBootSP0/xxxx.nbi/i386/' (xxxx being the name of the created image) to /srv/tftp/macnbi-i386/ on the linux box. Copy the dmg file to your webroot.
Now, setup DHCP with this config:

class "AppleNBI-i386" {
match if substring (option vendor-class-identifier, 0, 14) = "AAPLBSDPC/i386";
option dhcp-parameter-request-list 1,3,17,43,60;
if (option dhcp-message-type = 1) { option vendor-class-identifier "AAPLBSDPC/i386"; }
if (option dhcp-message-type = 1) { option vendor-encapsulated-options 08:04:81:00:00:67; }
filename "macnbi-i386/booter"; # the kernel to boot from
option root-path "http://xx.xx.xx.xx/yyy.dmg"; #xx.xx.xx.xx being the IP of the web server and yyy.dmg the name of the dmg file
}
allow booting;
allow bootp;

Setting up a driver as dkms in Debian 6

So I have this weird intel 4-port network card. It uses the igb driver. Now after switching from Ubuntu to Debian 6, I could not get any traffic over the ports. It seems the version delivered with Debian is too old to correctly support my card. So I decided to add the current driver, which can be downloaded here, as a dkms package. This means that the driver is automatically recompiled every time the kernel is updated. Here's how I did this:

• first prepare the driver source. In this case, the tar.gz contains a src directory, so I moved everything from the src directory to the main directory: cd igb-3.2.10; mv src/* .
• next, we need a dkms.conf file (place this inside the source code's tree), here's mine:
  PACKAGE_NAME="igb"
PACKAGE_VERSION="3.2.10"
CLEAN="make clean"
BUILT_MODULE_NAME[0]="igb"
DEST_MODULE_NAME[0]="igb"
DEST_MODULE_LOCATION="/updates"
AUTOINSTALL="yes"
• from the directory where you extracted the source (and added the dkms.conf file), execute the command to 'add' this source as a dkms:dkms add -m igb -v 3.2.10
• now build and install the source: dkms build -m igb -v 3.2.10; dkms install -m igb -v 3.2.10
• finally, create the dsc and the .deb file: dkms mkdsc -m igb -v 3.2.10 --source-only; dkms mkdeb -m igb -v 3.2.10 --source-only
• now we need to install the dkms on the local machine. But before we do that, we need to remove the created dkms from the system as it conflicts with the created package. mv the .deb file and install it: cp /var/lib/dkms/igb/3.2.10/deb/igb-dkms_3.2.10_all.deb ~; rm -r /var/lib/dkms/igb; dpkg -i ~/igb-dkms_3.2.10_all.deb

msp430-rf2500 & linux

I bought the msp430-rf2500. A development kit for the msp430 with a wireless 2.4 GHz transceiver. This is an USB programmer with 2 development boards containing an msp430F2274 microcontroller and a CC2500 transceiver. The USB programmer allows to communicate with the UART in the msp430. Under Windows this works fine. Under Linux however, it does not.
After searching high and low, I found a way to successfully connect to the UART without issues. I did this using Debian 6.0.3, kernel version 2.6.32-5-686.
Here's how:

• disconnect the development board from the USB programmer
• put the USB programmer (only the programmer!) in the USB port
• use dmesg to find the device that it registered (/dev/ttyACM0 in my case).
• now type (replacing ttyACM0 with the device name you found earlier): stty 9600 -brkint -icrnl -imaxbel -opost -onlcr -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke -F /dev/ttyACM0
• next open the port and start reading from it (for example using minicom, or cat /dev/ttyACM0)
• and NOW you can put the development board in.

The issue seems to be that the UART is flooding the ACM device, which then decides to disconnect.

Happy hacking!