Still though, it’s great fun. However, not so great for road cycling. The road tyres are just a bit too thin for all that snow. Mountain bikes now, that’s the way to do it. So on Saturday, two weeks ago, myself and two others from the Cycling forum on boards.ie decided to see how far we could get into Wicklow.  We set out on our mountain bikes and one studded-tyre equipped cyclo-cross bike. I brought my Nikon D50 with me and got some good photos.

Studded Cyclocross

We set off from Dundrum, went out by Enniskerry and from there towards Djouce and Balinastoe. There was snow on the side of the road on the way out, but nothing too bad. Then we got to the turn off for Djouce/Balinastoe. The road was covered in compacted snow and ice.

After some slipping and sliding, it was off the bike and letting some air out of the tyres. Sorted, off we went. We stopped just before the hill going up by Djouce and got some photos.

Snow Fields

This was just a field, covered in snow, with the hills in the background. Fantastic. So on we went, the hill by Djouce wasn’t a problem like we thought it would be. On past Balinastoe and we got to the junction of the road going to the Sally Gap. One of the hearty trio departed and the two of us went on to see how far we could get.

Heading toward the Sally Gap

We encountered snow pretty quickly, but kept going. Once we got to the base of Luggala, that was when the snow really started to pile up ! Back off the bike, more air out of the tyres. Almost running on nothing at this stage.

Heading up Luggala

Unfortunately we got almost two thirds of the way to the top, but could go no further on the bikes.

Had to walk up the bikes !

We were determined to get to the top though and see Lough Tay. So we left the bikes and continued on foot. We bumped into some entertaining sights along the way

A guy just cruised down past us on his snowboard !

Eventually we got to the top and the view were just stunning. I’d never seen that much snow in Ireland before.

The view of Lough Tay

View over the hills

Back down we went then, skidding and slidding on the bikes, really great fun. A bit of a slog on the way home, but absolutely worth it. One of the best cycles I’ve ever been on

Manitou Axel Plus

If you have a Specialized 2004 Rockhopper, you may have a Manitou Axel fork on it. My basic Rockhopper has the Axel Plus fork. If one searches for this fork, one tends to find squat ! The Axel Plus doesn’t seem to exist. However, you may come across a service manual for the 2003 Manitou Axel range. The Comp, Elite and Super. I believe the Axel Plus is the Comp and the 2004 range seems identical to the 2003 range. As my fork started making strange clunking noises recently, I decided I better have a look at it. The fork would compress, but then not de-compress fully until receiving a whack. This de-compression was the clunk noise and tended to only happen when going at a bit of speed downhill. Slightly worrying.

I had a look at the service manual, bought some suspension fluid and also on a gamble, bought a softer spring for the 2004 Manitou Super. The manual said that my weight was just within range for the softer spring and I thought it might make a bit of a difference. So first off, remove the fork from the bike.

Fork Legs

To remove the lower legs, remove the bottom hex key bolts. The right leg (left side in the picture) takes a 2mm hex key. When this is removed, pull out the adjusting knob. Then use a 8mm hex key, inserted into the fork to remove the small bolt.

On the other leg, just use a 4mm hex key to remove the bolt. Grab the shiney metal stanchions in both hands and use your thumbs to push down the on the lower legs, pushing against the rubber seals. Keep pushing it down until the lower legs come off completely.

You should be able to clean the upper legs and the containing lower legs. I didn’t clean mine thoroughly as I didn’t have appropriate replacement grease for the inside. They were fairly clean anyway. It’s probably a good idea to re-attach the legs at this point as it makes things easier when replacing the suspension fluid and the spring.

To change the spring, unscrew the top left cap. (The one with the 2mm hex bolt in it.) Remove the bolt and pop the cap off. You can use an adjustable spanner then to open the 20mm knob (if you don’t have a 20mm socket). As this unscrews, the spring will pop out, attached.

Fork spring

You can clean and re-grease the spring. I tried to replace it with the spring I bought, but the spring appeared to be too small, and didn’t decompress the fork fully. I re-install the original spring.

Fork Fluid

To replace the suspension oil, remove the top right cap. Again, I just used the adjustable spanner. Pour out the old fluid. Take a long hex key or something long and push it into the open fork leg. This will force down the internal plunger and force the remaining fluid up. Pour this out. Pump the fork, pour out, push the internal plunger and pour out, repeating until no more fluid comes out. Pour in the correct amount, doing the same plunging technique to ensure the fluid goes everywhere it should. Re-insert the cap and tighten.

This is where I encountered a wee problem. The adjuster knob on the bottom of the right leg should screw in. Unfortunately I could not get the screw to remain attached after I screwed it in and then compressed the fork. Perhaps the internal plastic it screws into was damaged, but it didn’t appear so. The fork functions without it, so I just had to leave it.

Re-attach the fork to the bicycle. Be careful not to be a complete moron and put the fork on the wrong way around.

I saw a deal on komplett.ie last week for 16GB memory keys. They were selling them for 150 euro. I thought to myself,

“Wow ! 16GB, I didn’t realise they had ones that big. I’ll have a gander at eBay and see how much they cost.”

And there were several on eBay, a good bit cheaper than Kompletts 150 euro. In a moment of madness I decided to buy one. I found a gent selling them from Korea.

Now. In the past, my brother had bought a 4GB memory key while travelling through China. The 4GB key in fact turned out to be a 64MB key. Something of a disappointment for him (and for me because he gave it to me). So I was a bit wary of buying this 16GB key, as it looked very similar to the previous. However, the gents feedback was good, so I said right I’ll go for it. 79 euro, 21 of which was postage.

Around a week later, the USB key arrived in the Post. (This is a miracle in itself, An Post has a habit of losing/delaying my post). I whipped out the key from the generic, no-name brand packaging and took off the cap to stick it into the computer. The cap remained where it was and the rest of the casing came off, exposing the PCB. I was rather surprised.

I put the casing back on, gently removed the cap and put it into the USB slot. The drive popped up on my desktop. So I decided to test it properly. I used dcfldd to write a 14 GB file of text to my /tmp partition and then used split to break this file into 14 1GB files and then md5sum to get hashs for each file. I copied all the files onto the memory stick and then rehashed them. The last two files hashed correctly, none of the others. “Arse”. The stick was only around 2GB large.

I emailed the guy I bought it off, who promptly offered me a refund of my money (minus the postage costs). I said no thanks, I’d like a genuine 16GB key please. He said

Hello.

First of all, we truly apologize for this matter.
Please understand the fact that we have actually never opened the package
and therefore, did not know it has the problem.

Most of problems occur due to the incompetibility of motherboards and
USB-HC technology
since 16GB is the new model with completely new technology.

He also wanted me to send back an RMA form which listed the details of my motherboard.

So USB-HC ? What is USB-HC, I’ve never heard of this. I googled for this new USB protocol and of course found nothing. USB HC is Host Controller. It means nothing, it is not some new USB standard. I replied saying this and again that I would like a genuine 16GB memory stick.

The response to this was

Sorry once again for the terrible inconvenience.
Can you please complete the RMA we sent you?

We will check with your motherboard first.

Thank you very much.

At this stage it seemed obvious that the guy was going to get my motherboard model and say “Oh ! Sorry, not compatible, can’t send you a new one, we’ll just refund you”. I needed something more than saying that USB-HC was nonsensical. I opened the memory stick and took a photo of the memory chip on it and sent it to another of my numerous brothers.

The chip was a Samsung flash NAND chip. He found a sheet on the Samsung website describing the serial number. This sheet told us that the solitary chip onboard was in fact a 2GB chip as I’d already thought.I emailed the guy back with this new information saying

According to the Samsung website, the details for that particular chip
state it as being 2GB large.

I’m afraid it is not an issue of incompatability with my motherboard.

Could you please send me a genuine 16GB memory key.

He replied saying that the stick has multiple memory modules to make up the 16GB and that the rest must have failed, only one was still working. More crud. There is definitely only a single flash chip on that PCB. He then followed up with another email saying

You mean by Genuine which I believe is refering to normal USBs using one
nand tech not the USB HC tech.

Sorry but we have HC technology ones only.
I don’t think there is any one nand 16gb available yet.

So, it was obvious at this stage I wasn’t going to get my new USB key. I got the cost of the key refunded. If I post the key back, I will get the cost of delivery (21 Euro) refunded. I don’t think I will post it back, seeing as it will cost me money to post the key to Korea. 21 Euro for a 2GB USB key is not terribly unreasonable.

After some quick looking around I discovered that fake USB keys are actually a big problem, not just on eBay or dodgy Chinese back allys. This is a good article about someone buying one from a store in Canada. There is also an eBay page describing the problems with USB keys.

The seller of the USB key certainly sounded genuine and did refund me the money. He also does have a high rating for other items. It is possible he was fed the USB-HC and multiple module stuff from his wholesale seller. He did ask me to describe in detail the problem so as he could deal with the manufacturer. I did this and also suggested cancelling his current sale of the 16GB keys.

He has not done this as yet. My brother also pointed me at toolhaus.org. As such I suspect he is well aware of the nature of the memory keys.

Addendum: I changed my mind and will post it back. 78 cent from AnPost and the guy will refund me as soon as I send a photo of the key in the envelope. This way I can use the 21 euro to buy a genuine 2GB key with a casing that doesn’t fall apart !

Update 15/May/2007 As soon as I sent the above photo, my postage cost was refunded.  

I don’t recall exactly how I ended up encountering the TiddlyWiki tool, I think I was reading through a Nokia 770 email list and saw it mentioned. I was really impressed when I saw what it could do.

Tiddlywiki is a wiki, just like MediaWiki, TWiki etc. The difference with TiddlyWiki is that it is completely client side software. The wiki consists of a single file with a good deal of javascript in it. When a new entry is added to the wiki, that file itself is edited by the Javascipt and the new entry stored in a div. This means you only need to use your browser to manage and store your information, todo, notes, ideas, documentation etc.

There are several tutorials linked from the tiddlywiki website which explain how to get going. It does take a bit of getting used to before one starts getting things done, but the learning curve is well worth it. Data is entered into constructs called Tiddlers. By typing in a wiki formatted word like AnExampleOfAWikiWord, this word becomes a link to a new Tiddler called AnExampleOfAWikiWord. Clicking on the link bring up the tiddler, you edit it and save your data, nice and simple.

Another great thing about TiddlyWiki is how extensible it is. Numerous plugins have been written for it, from simple things like adding timestamps by inserting a {ts} to comprehensive calendering and ToDo systems. A neat thing about the plugins is how easy it is to install them. A plugin distributed with the default wiki file is an import plugin. If you see a tiddlywiki you like, point the import plugin at the url of the wiki page and it will list every Tiddler on the page. You can pick which ones you want to import and it will save them into the local file. A decent plugin website is http://www.tiddlytools.com. The trick is to keep your Tiddlywiki as simple as possible. There are an awful lot of plugins out there that are just useless and slow the system down.

Along the same lines, there are also plenty of nice themes for TiddlyWiki. Check out http://tiddlythemes.com/ for a very nice site with some decent themes.

Of course, there are serverside implementations of TiddlyWiki so as to write data back to a server, at the moment I carry mine around on a usb key and store it in a version control repository. I’ll probably move it onto a web server soon enough.

Topology

The topology is very simple, as is demonstrated in the image below. In my test simulation, I have one http client, 1 Tor proxy, 3 Tor routers, one Tor exit router and a http server.

The real Tor implementation runs as a SOCKS proxy, typically on the local machine. This means that data leaving the client machine is encrypted and divided into 512 byte Tor cells before any attacker can view it. In the image above, the proxy is a seperate entity. This was the easiest way to implement it using the SSFNet simulation software. For my purposes it is essentially the same, I merely put my ‘tap’ on the link from the Tor proxy to the first Tor router. I also ‘tap’ the connection between the http server and the last Tor router, or exit router.
This is one of many attacks surmised against Tor, basicly treating the Tor network as a blackbox and analysing traffic streams  entering and leaving the network.The traffic streams should have the same ‘fingerprint’ throughout the network, thus identifying them a trivial task.

The below is a tcpdump output from the tor proxy interspersed with tcpdump from the http server:

00:00:01.000132 0.0.0.9.10001 > 0.0.0.10.1070: S 0:0(0) win 0
00:00:01.000132 0.0.0.10.1070 > 0.0.0.9.10001: S 0:0(0) ack 1 win 16384
00:00:01.000396 0.0.0.9.10001 > 0.0.0.10.1070: . ack 1 win 16384
00:00:01.000396 0.0.0.10.10001 > 0.0.0.3.1080: S 0:0(0) win 0
00:00:01.001072 0.0.0.3.1080 > 0.0.0.10.10001: S 0:0(0) ack 1 win 16384
00:00:01.001072 0.0.0.10.10001 > 0.0.0.3.1080: . ack 1 win 16384
1) 00:00:01.001072 0.0.0.10.10001 > 0.0.0.3.1080: . 1:513(512) ack 1 win 16384
00:00:01.001228 0.0.0.9.10001 > 0.0.0.10.1070: . 1:1001(1000) ack 1 win 16384
00:00:01.001228 0.0.0.10.1070 > 0.0.0.9.10001: . ack 1001 win 16384
1) 00:00:01.002764 0.0.0.3.1080 > 0.0.0.10.10001: . 1:513(512) ack 513 win 15872
00:00:01.002764 0.0.0.10.10001 > 0.0.0.3.1080: . ack 513 win 16384
2) 00:00:01.002764 0.0.0.10.10001 > 0.0.0.3.1080: . 513:1025(512) ack 513 win 16384
00:00:01.003996 0.0.0.3.1080 > 0.0.0.10.10001: . ack 1025 win 16384
2) 00:00:01.005867 0.0.0.3.1080 > 0.0.0.10.10001: . 513:1025(512) ack 1025 win 16384
3) [..]1.005867 0.0.0.10.10001 > 0.0.0.3.1080: . 1025:1537(512) ack 1025 win 15872
00:00:01.007036 0.0.0.3.1080 > 0.0.0.10.10001: . ack 1537 win 16384
3) [..]1.010053 0.0.0.3.1080 > 0.0.0.10.10001: . 1025:1537(512) ack 1537 win 16384
4) [..]1.010053 0.0.0.10.10001 > 0.0.0.3.1080: . 1537:2049(512) ack 1537 win 15872
00:00:01.011222 0.0.0.3.1080 > 0.0.0.10.10001: . ack 2049 win 16384
4) [..]01.015323 0.0.0.3.1080 > 0.0.0.10.10001: . 1537:2049(512) ack 2049 win 16384
5) [..]01.015323 0.0.0.10.10001 > 0.0.0.3.1080: . 2049:2561(512) ack 2049 win 15872
00:00:01.016491 0.0.0.3.1080 > 0.0.0.10.10001: . ack 2561 win 16384

00:00:01.017942 0.0.0.5.10001 > 0.0.0.1.80: S 0:0(0) win 0
00:00:01.017942 0.0.0.1.80 > 0.0.0.5.10001: S 0:0(0) ack 1 win 16384
00:00:01.018177 0.0.0.5.10001 > 0.0.0.1.80: . ack 1 win 16384

5) [..]01.020531 0.0.0.3.1080 > 0.0.0.10.10001: . 2049:2561(512) ack 2561 win 16384
00:00:01.020531 0.0.0.10.10001 > 0.0.0.3.1080: . 2561:3073(512) ack 2561 win 15872
00:00:01.0217 0.0.0.3.1080 > 0.0.0.10.10001: . ack 3073 win 16384
00:00:01.0217 0.0.0.10.10001 > 0.0.0.3.1080: . 3073:3585(512) ack 2561 win 16384
00:00:01.02331 0.0.0.3.1080 > 0.0.0.10.10001: . ack 3585 win 16384

00:00:01.026434 0.0.0.5.10001 > 0.0.0.1.80: . 1:1001(1000) ack 1 win 16384
00:00:01.026434 0.0.0.1.80 > 0.0.0.5.10001: . 1:1001(1000) ack 1001 win 15384
00:00:01.026749 0.0.0.5.10001 > 0.0.0.1.80: . ack 1001 win 16384
00:00:01.026749 0.0.0.1.80 > 0.0.0.5.10001: . 1001:2025(1024) ack 1001 win 16384
00:00:01.026749 0.0.0.1.80 > 0.0.0.5.10001: . 2025:3049(1024) ack 1001 win 16384
00:00:01.027223 0.0.0.5.10001 > 0.0.0.1.80: . ack 2025 win 16384
00:00:01.027223 0.0.0.1.80 > 0.0.0.5.10001: . 3049:3463(414) ack 1001 win 16384
00:00:01.027255 0.0.0.5.10001 > 0.0.0.1.80: . ack 3049 win 16384
00:00:01.027896 0.0.0.5.10001 > 0.0.0.1.80: . ack 3463 win 16384
00:00:01.027896 0.0.0.1.80 > 0.0.0.5.10001: F 3463:3463(0) ack 1001 win 16384
00:00:01.028131 0.0.0.5.10001 > 0.0.0.1.80: . ack 3464 win 16383

00:00:01.031124 0.0.0.3.1080 > 0.0.0.10.10001: . 2561:3073(512) ack 3585 win 16384
00:00:01.031124 0.0.0.10.10001 > 0.0.0.3.1080: . ack 3073 win 16384
00:00:01.032293 0.0.0.3.1080 > 0.0.0.10.10001: . 3073:3585(512) ack 3585 win 16384
00:00:01.032293 0.0.0.10.1070 > 0.0.0.9.10001: . 1:1001(1000) ack 1001 win 16384
00:00:01.032293 0.0.0.10.10001 > 0.0.0.3.1080: . ack 3585 win 16384
00:00:01.033357 0.0.0.9.10001 > 0.0.0.10.1070: . ack 1001 win 16384
00:00:01.034293 0.0.0.3.1080 > 0.0.0.10.10001: . 3585:4097(512) ack 3585 win 16384
00:00:01.034293 0.0.0.10.10001 > 0.0.0.3.1080: . ack 4097 win 16384
00:00:01.035461 0.0.0.3.1080 > 0.0.0.10.10001: . 4097:4609(512) ack 3585 win 16384
00:00:01.035461 0.0.0.10.1070 > 0.0.0.9.10001: . 1001:2025(1024) ack 1001 win 16384
00:00:01.035461 0.0.0.10.10001 > 0.0.0.3.1080: . ack 4609 win 16384
00:00:01.036545 0.0.0.9.10001 > 0.0.0.10.1070: . ack 2025 win 16384
00:00:01.037481 0.0.0.3.1080 > 0.0.0.10.10001: . 4609:5121(512) ack 3585 win 16384
00:00:01.037481 0.0.0.10.10001 > 0.0.0.3.1080: . ack 5121 win 16384
00:00:01.038649 0.0.0.3.1080 > 0.0.0.10.10001: . 5121:5633(512) ack 3585 win 16384
00:00:01.038649 0.0.0.10.1070 > 0.0.0.9.10001: . 2025:3049(1024) ack 1001 win 16384
00:00:01.038649 0.0.0.10.10001 > 0.0.0.3.1080: . ack 5633 win 16384
00:00:01.039732 0.0.0.9.10001 > 0.0.0.10.1070: . ack 3049 win 16384
00:00:01.040669 0.0.0.3.1080 > 0.0.0.10.10001: . 5633:6145(512) ack 3585 win 16384
00:00:01.040669 0.0.0.10.1070 > 0.0.0.9.10001: . 3049:3463(414) ack 1001 win 16384
00:00:01.040669 0.0.0.10.10001 > 0.0.0.3.1080: . ack 6145 win 16384
00:00:01.041264 0.0.0.9.10001 > 0.0.0.10.1070: F 1001:1001(0) ack 3463 win 15970
00:00:01.041264 0.0.0.10.1070 > 0.0.0.9.10001: . ack 1002 win 16383

The dark blue lines are traffic between the HTTP client and the Tor proxy. Red lines are the traffic from the HTTP server I added in manually. Some of the times were chopped slightly so as to fit onto the page nicely.
We can see the steps all the way through. The initial blue lines show the syn, syn/ack, ack tcp conversation between the HTTP client and the Tor proxy. When this connection is established, the Tor proxy now creates a Tor circuit. The bold lines show the Tor packets being sent back and forth establishing the circuit.

Circuit Creation

1. The first packet sent creates a circuit with the first router. This router respones with a connection succeeded packet
2. The next packet is an extension, it tells the Tor router we are already connected to, to extend the circuit onto another router. Again, a packet is sent in response to confirm the extension.
3. This is done once more to the third router
4. We extend again to the fourth router
5. The fifth communication sends the ip/port of the TCP (HTTP in this case) server we want to connect to. We can see the connection request being sent, and then the red lines of the server side. This is the exit router establishing a TCP connection to the http server.

Data transmission

Now that the circuit has been established, the data can be sent over the circuit between the client and the server. At time 00:00:01.001228 we see that the HTTP client has sent a 1000 byte packet to the proxy. As the circuit is still being established at this time, this packet is left waiting. Eventually, immediately after the circuit has been established, at time 00:00:01.020531,we can see two 512 byte Tor cells being sent across the circuit. These contains the initial 1000 byte HTTP REQUEST packet. They arrive at the Tor exit router, are put back together and sent onto the HTTP server at time 00:00:01.026434. The HTTP server responds with a number of packets, rapidly sending the packets one after the other and then closes the TCP connection with the tor exit router.

These packets are recieved by the Tor exit router, are chopped into Tor cells and sent back over the circuit to the Tor proxy where they are put back together and delivered to the HTTP client.

One interesting thing that the block of red lines demonstrates is the slowness, or latency introduced by the Tor circuit. The server is able to send all its data and close the connection before even a single packet of that data stream reaches the Tor proxy.

You might notice some odd things in the tcp trace as well ….

The correct way to solve this problem is for the application writer to sign the java application with a certificate, obtained from the likes of Thawte or Verisign. The problem with this is:

• It costs money to get a certificate
• It appears that only a commerical entity can purchase a cert. for signing j2me applications.

There are alternatives to this that I spent most of the day investigating. The best way seemed to be to creates ones own private key and certificate. Upload the certificate to the root store on the mobile phone and sign the application with the private key. Tedious perhaps, especially seeing as I’d have to sign every application and every new version of the application I’d put on the phone, but I was happy enough to do that.

However. There is no support for adding ones own certificates to the K750i/W800i. No official support that is. After much googling and trawling through the forums at http://www.esato.com I found software to do this. An application called FAR Manager in conjunction with plugin called SEFP. The FAR Manager application is a generic file system manager, but it supports plugins for accessing various filesystem types other than a standard hard drive. Network filesystems, FTP, etc.

The SEFP, Sony Ericsson Flash Plugin, is able to connect to a K750i/W800i phone over the stock DCU-60 cable and offer access to the filesystem on the onboard flash memory.

There is a brief guide available showing the basics of using FAR Manager in conjunction with the SEFP.

Once this is up and running on the mobile phone (You’ll need to install the Sony Ericsson Update Manager first if you haven’t already. This contains the USB flash drivers the plugin uses to access the phone), it’s possible to copy files to/from the mobile phone flash memory. It’s then a simple matter of uploading a .cer file to the correct directory on the phone, modifying a customize.xml file on the phone to list the certificate, and reseting the phone using a master reset.

Supposedly. This doesn’t actually work. The certificate does not get added to the root repository as some import function needs to be run. I couldn’t figure out how to do this, it appears that the phones firmware needs to be completely flashed and the certificate copied over before the phone is started. This way, when it’s started for the first time with the new firmware, it initializes the certificate database.

So I returned to the forums and kept trawling. I found an easier method, but this is a real hack. The flash plugin has some extra features that allow one to edit the raw flash memory directly, at a bit level. (Extremely useful for obtaining a good forensic image of a Sony Ericsson mobile phone I’d imagine). The plugin also has support for small .vkp scripts that when run, will patch a location in the flash with certain values, so simple automation of memory editing. A number of these scripts have been created that perform a number of actions. And one of those actions is.. you’ve guessed it, to disable requests for file system access.

I downloaded the script from this forum article and installed it using the FAR Manager with plugin. (In the application, press enter on the flash link, press tab to select the other pane, browse to and select the .vkp file. Press F5 to copy and when prompted select the run .vkp file option.)

Success ! No more filesystem prompts. Now I just need to figure out where j2memap looks for map files on the memory card and I’m away in a hack.

The title of the thesis is “Anonymity and traceability in cyberspace” and mostly deals with the issue of traceability.

IP TCP Stream Spoofing

Ip TCP spoofing isn’t as impossible as it should be. The problem with spoofing a complete conversation is that the ACK numbers on each packet being sent out need to be correct. They need to be the same as the sequence numbers recieved. To prevent easy guessing of the sequence numbers, the initial sequence number is randomised. So the attacker must guess a 2^32 value correctly in order to spoof a conversation. This sounds great, the problem is that equipment vendors don’t follow this rule all the time. Alcatel equipment for example does not use a random value, instead a chosen value is incremented by 64,000 every millisecond. This is all detailed on pg27, and a CERT Advisory

ADSL Authentication

When authenticating a DSL connection, the users DSL modem connects to a DSLAM in the telephone exchange. The DSLAM creates a Permanent Virtual Circuit (PVC) to a “Home Gateway”. The authentication details are then offered to the Home Gateway by the DSL Modem which in turn will hand them onto the correct ISP RADIUS server. The ISP RADIUS server is chosen based on the username of the authentication details. e.g gavin@eircom.net will go to Eircoms ISP, gavin@esatbt.ie will go to ESAT BTs RADIUS server etc. The RADIUS server will authenticate the user and then allocate them an IP using DHCP.

The issue with this is that I can borrow another persons authentication details and commit some nefarious act on the Internet. When the IP used in the nefarious act is traced back, it will lead to the owner, and not me. The only way to verify in fact I was the one using that IP is to check the logs of the Home Gateway. This will show what PVC was used to pass on the authentication details, back to the DSLAM and back to the physical socket connecting my telephone to the DSLAM.

The only problem is that apparently the Home Gateway may not actually log this information. Pg43.

Playing with reverse DNS

Plenty of interesting things one can do with reverse DNS it seems. For example Apache logs use an IP address at the start, or can reverse resolve this IP and use the DNS instead. If the reverse DNS address looks like an IP, then effectively a fake IP can be substituted in the logs. There are options to disable this, or do full IP checking in Apache. Reverse DNS is disabled by default, and if enabled double DNS lookups can be performed. Indeed any sort of string could be inserted into the logs with this trick. Pg50 and this article

The same sort of trick can be performed on an IRC server. The server should log just the IP, but this isn’t always the case. Pg55.

And again, in e-mails, to fool someone that doesn’t thoroughly investigate the headers. In this case an ip was configured to resolve to bay15-f8.bay15.hotmail.com and extra hotmail specific information such as X-Originating-IP: added. The IP for x-originating of course was a false one. Pg59

HopFake

A simple trick for creating false traceroutes. When an ICMP echo packet arrives at the local machine and the TTL value is zero, don’t respond with an echo, respond with a TTL exceeded and a different IP address. The machine sending the traceroute packet assumes that your machine is a router and will send another ICMP echo packet with TTL+1. You can then respond to this new ICMP echo with either an echo and a different IP address, or send back another TTL and continue on the traceroute. Nice little trick. Pg54 and a copy of hopfake

That’s just small small knick knacky things from the thesis, I have yet to read the remaining two thirds.

An example I uploaded to Youtube is below, music courtesy my eccentric eclectic flatmate.

Update: Dec 4th, 2006.

I finished creating the video I was hoping to create. That is, a mockery of my CounterStrike playing peers. The YouTube version below is quite poor quality unfortunately. A full quality 720×576 version is available though. BotSlaughter-720×576 (95MB).

It’s very simple, the tcpClient sends a request for some data and the tcpServer sends data of that size back. When the tcpClient recieves the data, it disconnects and the established torCircuit is torn down. (Well it should be. At the moment, everything just dies when the connection closes)

Obviously the most important part of the simulation for me is getting results from it. At the moment what I’m interested in is obtaining packeting timing information which will allow me to compare streams on one part of the network with streams on another part.

There is a measurement infrastructure in place in SSFNet, however I got a tad confused with the documentation for it. It’s actually extremely straightforward though. I thought I’d document what I’ve done so far. The SSFNet community in general is quite small, the tool doesn’t appear to be actively developed, so I figured any spur to this might help. It’s also handy for me for logging what I’ve done.

Utilising a BasicRecorder via a ProbeSession

In the DML file for your simulation, add the following to the graph section

ProtocolSession [
name probe use SSF.OS.ProbeSession
file "/tmp/mystream.dat"
stream "My Stream"
]

This will create a ProbeSession “pseudo-protocol” within the graph. This can then be accessed like below

if(this.recorder == null)
{
ProbeSession probe = (ProbeSession)this.owner.inGraph().SessionForName(”probe”);
this.recorder = (StreamInterface)probe.getRecorder();
}

Where this.owner is a class extending the ProtocolSession class. The StreamInterface returned is actually an object of type BasicRecorder, this isn’t mentioned anywhere in the documentation. I haven’t quite figured out how to get a different StreamInterface implementing class returned.

Once this recorder has been obtained, it can be written to quite easily using the send() method.

byte[] nothing = new byte[10] ;
String writer = owner.localNHI;
String type = VIRTUAL ;
int nWriter = this.recorder.getRecordSourceCode(writer);
int nType = this.recorder.getRecordTypeCode(type);
this.recorder.send(nType,nWriter, owner.localHost.now()/(double)SSF.Net.Net.seconds(1.0),nothing,0,10);

It took me a while to figure out where the BasicRecorder class was getting the int values from for the Code strings. It just creates internal numbers, ints, to store the string the first time it’s called and subsequently uses that int for every other call. Everything is figured out by looking at the code of course, luckily most of SSFNet is opensource.
To view the outputed log in /tmp/mystream.dat, you can use the BasicPlayer class. The stream identifier is as defined in the DML file, “My Stream”. with a 0 appended.

gavin@gavbot:~/workspace/ssfnet/bin$ java SSF.Util.Streams.BasicPlayer “My Stream.0″ /tmp/mystream.dat.0 > output.tmp
{Player processed 825 records, 8210 bytes, in 0.1 seconds (82 KB/s)}
gavin@gavbot:~/workspace/ssfnet/bin$ head -5 output.tmp
[type=3 ("Real") source=2 ("2") time=1.276107562 bytes=10]
[type=3 ("Real") source=4 ("3") time=1.278110762 bytes=10]
[type=3 ("Real") source=2 ("2") time=1.280161322 bytes=10]
[type=3 ("Real") source=4 ("3") time=1.286252842 bytes=10]
[type=3 ("Real") source=5 ("4") time=1.288256042 bytes=10]
gavin@gavbot:~/workspace/ssfnet/bin$

My next step is to hook the stream recording and playback up to the RaceWayViewer tool, so as I can actually see what’s going on in the network. It’s not particularly important, or remarkably useful, but it is handy to demonstrate how the simulation works. Beyond that lies creating larger networks, testing the simulation in comparison with the real tool and then starting to analyse results if the simulation output approximates the Tor output.