So I signed up for Mobile Me a couple months ago, purely for the automatic syncing and push email. I don't have a mac at the moment, so it's purely been used for my iPhone 3G. I've been frustrated, though, as a linux user that I have been unable to access the Mobile Me website. Attempting to use the site with Firefox 3 on Linux brings up the Unsupported Browser Page.

Well today, I came up with a work around: altering your user agent string. I'm sure there will be compatibility consequences for this down the line somewhere - but so far everything seems to be fine (regular browsing is fine; javascript intensive sites like facebook and mobile me work fine, you tube works fine, etc).

The steps are pretty simple:

1. In the firefox address bar, enter: about:config
2. Right click and select New->String
3. The preference name should be: general.useragent.override
4. Property value should be: Mozilla/5.0 (Windows; U; Windows NT 6.0; pl-PL) AppleWebKit/525.19 (KHTML, like Gecko) Version/3.1.2 Safari/525.21
   • I imagine any safari 3 user agent string would be fine - but this one works for me.

And there you go - you can now use the Mobile Me website with Firefox on Linux!

About a week ago, maybe two, instructions were posted on the net to tether your iphone's EDGE connection -- allowing you to make full use of your unlimited data plan via your laptop. A notably missing feature in the iPhone, as every other EDGE enabled device I've ever owned allows you to do this with ease.

The instructions were posted for Windows and Mac though, and while I love my Mac, my laptop runs RHEL 5... as such, here's the instructions to tether your iphone's EDGE to your linux box.

Assumptions

1. You have a jailbreak'd iphone.
   • How to escape jail using iPHUC
   • Instructions for installing dropbear *optional*
2. You're comfortable with Linux, and have wireless-tools installed in your distro

The Process...

First, download the iPhone Tether Kit. DO NOT run the scripts in this zip. Copy the srelay binary to /usr/bin on your phone, and net.sourceforge.socks-relay.srelay.plist into /System/Library/LaunchDaemons on your phone... you can accomplish this using scp if you installed ssh, otherwise, use iPHUC.

NOTE: if you copied the files using iPHUC, you'll need to set the executable bit on /bin/srelay using chmod. This sounds easy, but it's a process documented elsewhere (see the installing ssh instructions).

Reboot your iPhone, and you'll have an open socks relay server!

That's the easy part, and this next one's even easier...

Open up a command line terminal, and identify your wireless adapter using iwconfig. Mine's eth1, so we'll do the following:

ifconfig eth1 down
iwconfig eth1 mode ad-hoc
iwconfig eth1 essid "My AdHoc Network"
ifconfig eth1 up
ifconfig eth1 10.3.3.1

This sets up an adhoc wireless network with ESSID "My AdHoc Network". Pretty simple.

All you need to do now is connect your iPhone to it. In Settings->Wi-Fi, select "My AdHoc Network" from the list, and edit it's settings. Press "STATIC" to set a static IP with no router... I entered "10.3.3.2" for my IP and "255.255.255.0" for my subnet mask, and left the other values blank.

This will connect your iPhone to your adhoc network, and the Phone will use EDGE for its data connection. Now all you need to do is tell your client apps on your laptop to use the SOCKS proxy at 10.3.3.2:1080, and voila! You're accessing the internet via iPhone's EDGE connection on your laptop.

Many thanks to:

• NerveGAS
• NightWatch
• Everyone at #iphone

As part of a course I'm taking on network security at Clarkson University -- I had the opportunity to learn a lot about creating virtual filesystems and virtual disk images in Linux.

A virtual filesystem is filesystem that exists in a file, which in turn exists on a physical disk. There's a lot of great things you can do with virtual file systems; the reason I was messing with them was to configure a virtual machine on a linux host. Other uses include encrypting filesystems without encrypting entire disks; Mac OS X's File Vault encrypts users home directories this way. Maybe you went ahead and made yourself one giant partition and then realized for one reason or another that you want multiple partitions! Virtual filesystems can help (to some extent) with that as well.

So how do you make a virtual file system? Easy. The first thing you need to do is make a file for the filesystem to live in. This is where 'dd' starts to come in. Consider, for example, the following command:

dd if=/dev/zero of=~/myFileSystem.img bs=1024 count=1048576

This command will read 1,048,576 blocks from /dev/zero and write them to ~/myFileSystem.img; each block is 1024 bytes, resulting in a 1 gigabyte file containing all zeroes. The actual values that you use for the blocksize (bs) and count aren't really important, the key is to get your math right: bs * count = imageSize.

So now you have your file; great. It's time to make a file system! this part is even easier... we'll create an EXT2 filesystem, using the following command:

mke2fs myFileSystem.img

You may notice a warning prompt, saying that myFileSystem.img is not a block device, would you like to proceed? We'll get to that in just a second, for now, go ahead and say yes. Everything should go smooth, it'll look just as if you'd created a filesystem on an actual disk drive. You now have a virtual file system! The only thing left to do is mount your filesystem so you can access it...




mkdir /mnt/virtual
mount -o loop ~/myFileSystem.img /mnt/virtual




Now any file you put into /mnt/virtual is actually being put directly into myFileSystem.img! Wasn't that easy?

Fantastic. Now that you know how to make a virtual filesytsem, why not make a while virtual disk image? What's the difference you ask? A disk image is going to have a partition table that defines some number of partitions, and each partition contains its own filesystem; so a virtual filesystem is essentially a \"virtual partition\" of a virtual disk image; the virtual disk image contains multiple virtual filesystems, and a virtual partition table that describes where the bounds of each partition are.

Creating a virtual disk image starts out the same; the first thing you need is a big empty file, just you created above. This time, though, instead of making a file system, we'll want to partition the file using fdisk. To make things a little nicer though, we're going to throw loopback devices into the mix. You should make sure you have loopback device support enabled in your kernel (most distributions do by default; but if you're a kernel compiling linux junky, you might wanna check :)). So we'll create a big file, and attach it to a loopback device, as follows:




dd if=/dev/zero of=~/myDisk.img bs=1024 count=1048576
losetup /dev/loop0 ~/myDisk.img




By attaching the disk image to the loopback device, we can use /dev/loop0 the same way we would use ~/myDisk.img; the main difference is that /dev/loop0 is a what's known as a \"block device\". You'd have to ask someone with more experience than I've got what precisely this gets you, but what I do know is that the filesystem utilities work better with block devices than they do with the flat files. Plus, it's fun.

So good, we've got a big empty file attached to a loopback device (/dev/loop0)... now it's time to create partitions in the disk image. To do this, we'll run fdisk on our loopback device:

fdisk /dev/loop0

Lets create three partitions... if you're following this, you should already be familiar with fdisk, so go ahead and create the following:

      Device Boot      Start         End      Blocks   Id  System
/dev/loop0p1               1          17      136521   83  Linux
/dev/loop0p2              18          80      506047+  82  Linux swap
/dev/loop0p3              81         130      401625   83  Linux

Once you've made your partitions, write your changes and quit fdisk. What we'll need to do next is create filesystems on each partition. Remember how easy that was back with Virtual Filesystems? Not quite so much anymore...

Not to panic though... the trouble is that \"mkfs\" can't \"reach into\" our virtual disk image and make a filesystem just on individual partition. Infact, if you try, you'll probably wind up wiping our your virtual disk image and having to rerun fdisk :). So what to do... what to do?? Loopback devices to the rescue. What we'll do is attach a loopback device to the myDisk.img file at the specific offsets where each partition begins.

It's helpful then to look at the partitions in terms of blocks. Execute the following command:

fdisk -ul /dev/loop0

should look (hopefully exactly) like this:

Disk /dev/loop0: 1073 MB, 1073741824 bytes
255 heads, 63 sectors/track, 130 cylinders, total 2097152 sectors
Units = sectors of 1 * 512 = 512 bytes
      Device Boot      Start         End      Blocks   Id  System
/dev/loop0p1              63      273104      136521   83  Linux
/dev/loop0p2          273105     1285199      506047+  82  Linux swap
/dev/loop0p3         1285200     2088449      401625   83  Linux

These numbers are important for the math... we'll use the losetup command like we did before, only this time we'll reach in specifically to the start of each of the three partitions. losetup takes offsets as the number of bytes to skip at the beginning of the file. The output from fdisk -ul /dev/loop0 shows us that the first partition starts at block 63, and that each block is 512 bytes. So partition 1 starts at byte 32,256

losetup -o 32256 /dev/loop1 /dev/loop0

That command reaches 32,256 bytes into /dev/loop0 and mounts it at /dev/loop1. Remember that since /dev/loop0 is attached the myDisk.img file, this is the same as reaching 32,256 bytes into that file... follow? Ok, good. Same logic for partitions 2 and 3:

losetup -o 139829760 /dev/loop2 /dev/loop0
losetup -o 658022400 /dev/loop3 /dev/loop0

So now we have four loopback devices set up; /dev/loop0 is attached to the myDisk.img file. /dev/loop1 is the first partition of the virtual disk represented by /dev/loop0; /dev/loop2 is the 2'nd, and /dev/loop3 is the 3'rd.

Now it's finally time to make those file systems! This is now just as easy as making a regular filesystem, since that's all we're doing. Remember, mkfs doesn't know the device isn't a physical device! We'll make three kinds of file systems, an ext2 file system for partition 1, a swap filesystem for partition 2, and an XFS fileystem for partition 3:

mkfs /dev/loop1
mkswap /dev/loop2
mkfs.xfs /dev/loop3

Since loop1, loop2, and loop3 are tied directly to loop0, and loop0 is ~/myDisk.img, everything that we just did to loop1, loop2, and loop3 affected myDisk.img directly! We can now mount /dev/loop3, for instance, on /mnt/virtual as an XFS file system, and use it as a regular file system!

So I hope you found that helpful... you can do some pretty neat things with virtual file systems and virtual disk images; and loopback devices make a world of difference for making things go smooth.