39 posts from 2008

I did some testing this morning with the GL2 and I'm really happy with the results. What a deal. Just a quick hand held shoot around Cal Arts at like 7am. I did a few tests but shot it mostly using a Merkury x2 wide angle lens and Tiffen UV filter in 24F mode. The vignette caused by the wide angle lens is bugging me, I think I can adjust the aperture to fix that but I'll figure that out later.

I'm going to avoid apologizing for lack of posts lately simply because I think you probably get the idea. Cal Arts is serious business.

I overheard a classmate saying you can either sleep or get your work done and frankly they are 100% correct in my eyes. Some of you super kids might be able to pull this off with ease but this school is kicking my ass and I'm happy for it.

Every assignment I feel Icould do 10x better if you had just a few more hours (and a functional right hand!) but there simply aren't enough hours in the day or marbles in the sanity jar.

So I present to you a sampling of assignments I was proud of:

Also, THE DEAL OF THE CENTURY!!! I love Canon cameras. I just do. I also love craigslist. Together with $895 they created this:

I finally found some time to fix my camera. Unfortunately It required a donor but one brave little soul answered the call of duty from ebay and gave his life. Let us take a moment of silence while we stare at his guts.

Okay, now for the show. What follows is my 2008 accepted Cal Arts portfolio, all artwork was created in about  4 months from September to December 2007.

Thought this was kind of funny; ascii art stop sign in the first sector of the first partition on an iPod Nano.

# xxd /dev/sda1| head
0000000: 7b7b 7e7e 2020 2f2d 2d2d 2d2d 5c20 2020  {{~~  /-----\
0000010: 7b7b 7e7e 202f 2020 2020 2020 205c 2020  {{~~ /       \
0000020: 7b7b 7e7e 7c20 2020 2020 2020 2020 7c20  {{~~|         |
0000030: 7b7b 7e7e 7c20 5320 5420 4f20 5020 7c20  {{~~| S T O P |
0000040: 7b7b 7e7e 7c20 2020 2020 2020 2020 7c20  {{~~|         |
0000050: 7b7b 7e7e 205c 2020 2020 2020 202f 2020  {{~~ \       /
0000060: 7b7b 7e7e 2020 5c2d 2d2d 2d2d 2f20 2020  {{~~  \-----/
0000070: 436f 7079 7269 6768 7428 4329 2032 3030  Copyright(C) 200
0000080: 3120 4170 706c 6520 436f 6d70 7574 6572  1 Apple Computer
0000090: 2c20 496e 632e 2d2d 2d2d 2d2d 2d2d 2d2d  , Inc.----------

In order to patronize a tracker that uses SSL encrypted announces and self-signed certificates with rtorrent you need to add the servers' CA certificate to your trusted list. There are a few guides I found but none of which that directly address Gentoo linux so I'll go ahead and show you how.

You'll know there's a problem if you receive this error message when trying to download a torrent with an https announce url

* Tracker: [Peer certificate cannot be authenticated with known CA certificates]

The following shell script should be run as root. Don't forget to define the name of your tracker before you execute it

-----BEGIN cert.sh -----

#!/bin/sh
TRACKER=my-secure-tracker.tld

openssl s_client -connect $TRACKER:443 </dev/null 2>/dev/null | sed -n '/BEGIN CERTIFICATE/,/END CERTIFICATE/p' >> /etc/ssl/certs/$TRACKER.crt
openssl x509 -in /etc/ssl/certs/$TRACKER.crt -out /etc/ssl/certs/$TRACKER.der -outform DER
openssl x509 -in /etc/ssl/certs/$TRACKER.der -inform DER -out /etc/ssl/certs/$TRACKER.pem -outform PEM
c_rehash
unset TRACKER

-----END cert.sh -----

You can verify the results by using curl like so:

$ curl -I --capath /etc/ssl/certs https://my-secure-tracker.tld

HTTP/1.1 302 Found
Date: Mon, 18 Aug 2008 05:45:45 GMT
Server: Apache
Location: /
Connection: close
Content-Type: text/html; charset=iso-8859-1

Ever use a bittorrent tracker that disallows certain clients? Or maybe it allows your favorite bittorent client but only allows certain versions to make connections to the tracker. I can't imagine I'm alone in feeling unmotivated to downgrade my client or use an unfamiliar client just to satisfy one picky tracker admin.

In theory, a tracker admin will do this because they believe a certain client either doesn't report statistics fairly or any other reason that affects the operation of the tracker. Obviously they should be allowed to do this because they're maintaining a tracker you patronize but when a tracker admin only allows a certain exploitable version of your favorite client, well then it's time to take matters into your own hands.

Most executable files are packed and utorrent is no exception. We start by wget'ing the latest version of utorrent.exe and then upack it with upx.  We know that it's packed with upx and not another packer by examining the header of the file

My next step is to run it through strings and even see if -UT1770- the, "user-agent" if you will, of bittorent exists in the unpacked binary.
Sure enough "-UT1770-" exists in the file, so this means we're hot on the trail of patching this binary to lie to our tracker about the version number. We then make a hex dump of this file using xxd and patch the bytes using a text editor. It's okay if you don't know the ascii table by heart, we can echo the text we wish to patch through xxd to get the proper hex.

Now all that's left is to revert the .xxd dump back to binary and then optionally recompress it with upx.

Now we transfer the file back to windows and take it for a test drive...

Victory. So now our patched version of utorrent sends -UT1610- as a "user-agent" to the tracker, which is whitelisted and the tracker allows us to send and receive data with other peers in our swarm.

My entire night has been consumed with trying to coerce atftpd to play nicely with the latest version of the Tomato Firmware.

I began by enabling my /jffs partition. /jffs is a small writable filesystem that's stored on the left over flash rom on most wrt distributions that don't consume the full flash area. Tomato is a mere 2.6MB with a 4MB flash room so there's just enough room for small files.

I grabbed the atftpd .ipkg (which is just a .tar renamed) and it's dependencies from the openwrt repository. I extracted them on my computer and took the four important files and stftp'd them to the /jffs partition on my wrt54gl. With my fingers crossed I tried to execute atftpd.

# chmod 700 atftpd
# ./atftpd
./atftpd: can't load library 'libpthread.so.0'

Well, would have been nice if it were that easy but not everything works on the first try so I attempted it again with LD_LIBRARY_PATH=/jffs/lib:/usr/lib but that gave me a nice:

# ./atftpd
Segmentation fault

So I quickly peeked inside of atftpd to see if maybe the paths were hard coded inside the binary

$ xxd atftpd| less
...
00000f0: 0400 0000 2f6c 6962 2f6c 642d 7543 6c69  ..../lib/ld-uCli
0000100: 6263 2e73 6f2e 3000 f400 00b2 0000 0000  bc.so.0.........
...

No such luck. The only path I found was to /lib/ld-uClibc.so and this path is correct. The root filesystem on my WRT isn't writable or else I'd simple modify ld.so.config and work from there. So now I have the option of either rolling my own firmware image with atftpd hacked in OR trying to compile atftpd with statically linked libraries. The latter is preferred because I wouldn't have to rebuild a firmware image for every new release of Tomato but the former is a lot easier because for the life of me I couldn't find the broadcom mips sources for atftpd or it's dependencies.

So now that I've decided that the best course of action is to try to roll my own firmware image, I tried the easiest approach first. With nothing more than the simple build instructions from the Tomato sources, and an overheating linux box 350 miles away, I began my journey.

README

Please note that the following is unsupported. If you need help with programming,
setting up Linux, etc., please use your favorite Linksys/programming/Linux
discussion group instead. If it's really messed up, let me know by going to
http://www.polarcloud.com/tomato/.

* You need a Linux-based OS on an x86 computer or VM.

* You need Linksys' source code:

  ftp://ftp.linksys.com/opensourcecode/wrt54gl/4.30.11/WRT54GL_v4.30.11_11_US.tgz
  (180MB)

* Extract Linksys' source, then rename the top directory to "tomato".

* Remove the following:

  release/src/
    et et.4702 wl rts tools .model

  release/src/router/
    busybox cron dnsmasq httpd iproute2 iptables ipupdate lib libnet libpcap
    mipsel-uclibc misc nas netconf ntpclient nvram others rc ses shared
    traceroute udhcpd upnp utils www

* Extract tomato.tar on top of the Linksys source. Extract tomato_ND.tar if you
  want to build with newer drivers.

* Create a symlink in /opt/brcm to tomato/tools/brcm/.

* Add the following to your PATH:

  /opt/brcm/hndtools-mipsel-uclibc/bin
  /opt/brcm/hndtools-mipsel-linux/bin

* Run make from tomato/release/src/.

* tomato/release/src/image/ will contain the final images.

After skimming the README I realized this won't be so scary after all. I grabbed the linksys gpl sources for the wrt54gl, removed some directories, overwrote with tomato code and was on my way.

After dancing around the directory structure I quickly found exactly the file I was looking for:

tomato/release/src/router/rom/rom/etc/ld.so.config

I decided I'd first try to just append the writable file system path, /jffs to /etc/ld.so.config like so:

/opt/lib
/opt/usr/lib
/lib
/usr/lib
/jffs
/jffs/lib

I created a symlink, and appended the toolchain to my path and after building the firmware, flashing it to my WRT and mounting /jffs AND uploading the files, atftpd still wanted to know, "Where 'da libraries at?"

# ./atftpd
./atftpd: can't load library 'libpthread.so.0'

Well that sucks. I guess ld.so.config doesn't do what I thought it did. Alright, that's fine. We'll just go about this a different way. After all, it's linux and we can do this a billion different ways and they're all "right". Right?

I quickly devised a plan that was going to make me very popular on the internets. Forget this silly /jffs business. We've got the firmware sources, lets just roll in atftpd from the ground up. We've got plenty of flash left.

So I went about doing exactly that. I searched up and down the directory structure again and found a nice folder called "prebuilt".
 
tomato/release/src/router/prebuilt

Hrm, this looks useful. It had a cute little Makefile too:

all:

clean:

install:
        install -d $(INSTALLDIR)/usr/sbin

        install -m 0755 nas $(INSTALLDIR)/usr/sbin/nas
        $(STRIP) $(INSTALLDIR)/usr/sbin/nas
        cd $(INSTALLDIR)/usr/sbin && ln -sf nas nas4not

        install -m 0755 igmprt $(INSTALLDIR)/usr/sbin/igmprt
        $(STRIP) $(INSTALLDIR)/usr/sbin/igmprt

        install -m 0755 wl $(INSTALLDIR)/usr/sbin/wl
        $(STRIP) $(INSTALLDIR)/usr/sbin/wl

        install -m 0755 et $(INSTALLDIR)/usr/sbin/et
        $(STRIP) $(INSTALLDIR)/usr/sbin/et

        install -m 0755 wlconf $(INSTALLDIR)/usr/sbin/wlconf
        $(STRIP) $(INSTALLDIR)/usr/sbin/wlconf

        install -d $(INSTALLDIR)/usr/lib

        install libbcmcrypto.so $(INSTALLDIR)/usr/lib

So without further delay, I went about hacking my own custom Makefile which injected the atftpd binary into /usr/sbin and the libraries into the proper library path /usr/lib. Oh man, this is perfect. Exemplary even. At least until I hit this error when I was building the firmware:

busybox/examples/depmod.pl -k /tomato/release/src/linux/linux/vmlinux -b /tomato/release/src/router/mipsel-uclibc/target/lib/modules/2.4.20/
---
Unable to resolve _stdio_user_locking used by libpthread.so.0.9.27
make[1]: *** [install] Error 1
make[1]: Leaving directory `/tomato/release/src/router'
make: *** [all] Error 2

What. That wasn't supposed to happen, I was just about celebrate. :(

Alright, setbacks, setbacks. Let's see what's going on here. At first I thought maybe it had something to do with the $(STRIP) command. You see, file space on embedded devices is in high demand, so what developers usually do is strip their binaries of any verbose data that could possibly shave off a few extra bytes for something more useful...mm like 32bit high-resolution Tux logos!

I promptly removed the $(STRIP) before atftpd in the makefile, thinking this might have been the problem and rebuilt.

busybox/examples/depmod.pl -k /tomato/release/src/linux/linux/vmlinux -b /tomato/release/src/router/mipsel-uclibc/target/lib/modules/2.4.20/
---
Unable to resolve _stdio_user_locking used by libpthread.so.0.9.27
make[1]: *** [install] Error 1
make[1]: Leaving directory `/tomato/release/src/router'
make: *** [all] Error 2

The problem persisted. Ugh.

"Never give up, trust your instinct" -Peppy, StarFox64

I searched inside of depmod.pl for "_stdio_user_locking" There were no results. I searched inside of the internet for which google only responded in chinese, and character maps I don't have installed.

Alright.... Lets try to build it WITHOUT libpthread.so.0.9.27 and lets just symlink it from /jffs/lib. How do you like THAT!...linux.

Creating TRX: image/tomato.trx
Creating Linksys W54G: image/WRT54G_WRT54GL.bin
Creating Linksys W54S: image/WRT54GS.bin
Creating Linksys W54s: image/WRT54GSv4.bin
Creating Linksys W54U: image/WRTSL54GS.bin
Creating Motorola 0x10577050: image/WR850G.bin

TRX Image:
 Total Size .... : 2822144 (2756.00K)
   Images ...... : 2819852
   Padding ..... : 2292
 CRC-32 ........ : FBC0EC35
 128K Blocks ... : 22
 Offsets:
   0: 0x0000001C
   1: 0x000A270C
   2: 0x00000000

-----------------
 1.19.0004  ready
-----------------

Hurray! it built this time. I quickly flashed this to my router, reformatted /jffs (since the image is larger it has a lot less room now!), and tried to run /usr/bin/atftpd....drum roll please...

# atftpd
/usr/sbin/atftpd: /usr/sbin/atftpd: 1:ELF
: not found

WHAT THE CHRIST

alright, don't panic. It'll work when we try to run it from /jffs

# ./atftpd
Segmentation fault

!@#$%^

*sigh*

TO BE CONTINUED...

I got a little carried away on my friend's graffiti wall...

Check out this default setting in CS3.