Wednesday, December 30, 2009

Fun with the iGala picture frame



NOTE: This is an old article that I never got around to finishing. So it might or might not still be relevant. Turns out iGala is about to launch Android support for the frame, but until then, I suspect the following could still be of interest to some.

One of the most geeky of shopping sites must be thinkgeek.com. They have many wonderful and useless items to appeal to the geek inside of you, hell even my wife had a blast reading their catalog. Anyway, one of the items they sell (exclusively apparently) is the iGala digital picture frame, from Aequitas Technologies. Now I've come across countless of these, but the iGala is one of the few ones running an easy-to-access embedded Linux. In the following I will show what I mean and provide some documentation that I have collected.


Probing the frame from outside
It's an 8" LCD, capable of a 800x600 resolution and with a resistive touch membrane in front. Apart from that, not much info is given to the consumer - in spite of this frame being marked as "Linux inside". You can find the device on your local LAN, by doing an IP broadcast or using nmap. Here's how I found mine:

casper@workstation:~$ nmap -sP 192.168.0.1-254
Starting Nmap 5.00 ( http://nmap.org ) at 2009-12-30 02:06 CET
Host 192.168.0.1 is up (0.0018s latency).
Host 192.168.0.10 is up (0.086s latency).
Host 192.168.0.101 is up (0.00015s latency).
Host 192.168.0.105 is up (0.0025s latency).
Nmap done: 254 IP addresses (4 hosts up) scanned in 12.88 seconds



I happen to know that the 192.168.0.1 router, the 192.168.0.10 is a wifi web-cam, 192.168.0.101 is my own computer so that leaves only 192.168.0.105 as the frame. Once we located it on the LAN, let's probe it a bit with the nmap tool.

casper@workstation:~$ nmap 192.168.0.105 -p1-65535
Starting Nmap 5.00 ( http://nmap.org ) at 2009-12-30 02:11 CET
Interesting ports on 192.168.0.105:
Not shown: 65532 closed ports
PORT      STATE SERVICE
21/tcp    open  ftp
514/tcp   open  shell
65534/tcp open  unknown



Ok, it appears to be running an FTP server on port 21, an (unencrypted) telnet service at port 514 as well something unknown on port 65534. Let's check out the FTP server real quick.

casper@workstation:~$ telnet 192.168.0.105 21
Trying 192.168.0.105...
Connected to 192.168.0.105.
Escape character is '^]'.
220 localhost.localdomain FTP server (GNU inetutils 1.4.1) ready.
USER anonymous
530 User anonymous unknown.
USER igala
530 p
...



Ok so no anonymous account. We'd have to use exhaustive trial and error to get in here so let's move on to the next.

casper@workstation:~$ rsh -l igala 192.168.0.105 514
Login incorrect.
casper@workstation:~$ rsh -l root 192.168.0.105 514
514: not found
...



Not much better. Again, we'd have to start some brute-force attack against the device to get in. Off to the 3'rd one.

casper@workstation:~$ telnet 192.168.0.105 65534
Trying 192.168.0.105...
Connected to 192.168.0.105.
Escape character is '^]'.

BusyBox v1.4.1 (2008-12-29 10:57:28 CST) Built-in shell (msh)
Enter 'help' for a list of built-in commands.

root:/>



Whoa, bingo! Someone left a BusyBox telnet service listening on one of the very last possible ports.


Probing the frame from inside
Let's fire off some commands to see what we're dealing with here.

root:/> uname -a    
Linux blackfin 2.6.22.16-ADI-2008R1-svn #2477 Wed Dec 31 13:02:59 CST 2008 blackfin unknown



Interesting, Linux kernel 2.6.22.16 for the Blackfin processor.

root:/> cat /proc/cpuinfo
processor : 0
vendor_id : Analog Devices
cpu family : 0x27a5000
model name : ADSP-BF531 540(MHz CCLK) 108(MHz SCLK)
stepping : 5
cpu MHz  : 540.000/108.000
bogomips : 1073.15
Calibration : 536576000 loops
cache size : 16 KB(L1 icache) 16 KB(L1 dcache-wt) 0 KB(L2 cache)
dbank-A/B : cache/sram
icache setup : 4 Sub-banks/4 Ways, 32 Lines/Way
dcache setup : 1 Super-banks/4 Sub-banks/2 Ways, 64 Lines/Way
No Ways are locked
board name : ADDS-BF533-STAMP
board memory : 65536 kB (0x00000000 -> 0x04000000)
kernel memory : 63476 kB (0x00002000 -> 0x03dff000)



A fairly fast CPU - substantially faster than the 108MHz ARM inside my Samsung SPF-105V frame.

root:/> mount
rootfs on / type rootfs (rw)
proc on /proc type proc (rw)
ramfs on /var type ramfs (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw)
usbfs on /proc/bus/usb type usbfs (rw)
debugfs on /sys/kernel/debug type debugfs (rw)
securityfs on /sys/kernel/security type securityfs (rw)
/dev/mtdblock1 on /mnt/flash type yaffs (rw)
/dev/mtdblock2 on /mnt/fdisk type yaffs (rw)



A good deal of various filesystems, of which /dev/mtdblock1 and /dev/mtdblock2 are probably the most interesting in regard to modding.

root:/> netstat
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 192.168.0.105:50350     www.flickr.vip.mud:http TIME_WAIT   
tcp        0      0 192.168.0.105:50348     www.flickr.vip.mud:http TIME_WAIT   
tcp        0      0 192.168.0.105:50351     www.flickr.vip.mud:http TIME_WAIT   
tcp        0      0 192.168.0.105:50353     www.flickr.vip.mud:http TIME_WAIT   
tcp        0      0 192.168.0.105:50352     www.flickr.vip.mud:http TIME_WAIT   
tcp        0      0 192.168.0.105:50345     www.flickr.vip.mud:http TIME_WAIT   
tcp        0      0 192.168.0.105:50347     www.flickr.vip.mud:http TIME_WAIT   
tcp        0      0 192.168.0.105:50346     www.flickr.vip.mud:http TIME_WAIT   
tcp        0    164 192.168.0.105:telnet    192.168.0.101:57949     ESTABLISHED 
tcp        0      0 192.168.0.105:50349     www.flickr.vip.mud:http TIME_WAIT   



A busy device indeed. For some reasons, the frame have multiple idle connections to flickr.

root:/> dmesg
Hardware Trace:
0 Target : <0x000059f4> { _trap_c + 0x0 }
Source : <0xffa0860c> { _exception_to_level5 + 0xb4 }
1 Target : <0xffa08558> { _exception_to_level5 + 0x0 }
Source : <0xffa084b0> { _ex_trap_c + 0x5c }
2 Target : <0xffa08454> { _ex_trap_c + 0x0 }
Source : <0xffa086ac> { _trap + 0x28 }
3 Target : <0xffa08684> { _trap + 0x0 }
Source : <0x0061ef62> [ /lib/libuClibc-0.9.29.so + 0x1ef62 ]
4 Target : <0x0061ef46> [ /lib/libuClibc-0.9.29.so + 0x1ef46 ]
Source : <0x0061ef3e> [ /lib/libuClibc-0.9.29.so + 0x1ef3e ]
5 Target : <0x0061ef30> [ /lib/libuClibc-0.9.29.so + 0x1ef30 ]
Source : <0x036257f8> [ /mnt/flash/abies/lua + 0x257f8 ]
6 Target : <0x036257f0> [ /mnt/flash/abies/lua + 0x257f0 ]
Source : <0x0362f49e> [ /mnt/flash/abies/lua + 0x2f49e ]
7 Target : <0x0362f488> [ /mnt/flash/abies/lua + 0x2f488 ]
Source : <0x0366a3a8> [ /mnt/flash/abies/lua + 0x6a3a8 ]
8 Target : <0x0366a39c> [ /mnt/flash/abies/lua + 0x6a39c ]
Source : <0x0362f484> [ /mnt/flash/abies/lua + 0x2f484 ]
9 Target : <0x0362f45c> [ /mnt/flash/abies/lua + 0x2f45c ]
Source : <0x0362f456> [ /mnt/flash/abies/lua + 0x2f456 ]
10 Target : <0x0362f450> [ /mnt/flash/abies/lua + 0x2f450 ]
Source : <0x0362f444> [ /mnt/flash/abies/lua + 0x2f444 ]
11 Target : <0x0362f42e> [ /mnt/flash/abies/lua + 0x2f42e ]
Source : <0x0362f420> [ /mnt/flash/abies/lua + 0x2f420 ]
12 Target : <0x0362f3a4> [ /mnt/flash/abies/lua + 0x2f3a4 ]
Source : <0x0362f39a> [ /mnt/flash/abies/lua + 0x2f39a ]
13 Target : <0x0362f394> [ /mnt/flash/abies/lua + 0x2f394 ]
Source : <0x0362f382> [ /mnt/flash/abies/lua + 0x2f382 ]
14 Target : <0x0362f32e> [ /mnt/flash/abies/lua + 0x2f32e ]
Source : <0x0362f2e4> [ /mnt/flash/abies/lua + 0x2f2e4 ]
15 Target : <0x0362f2d4> [ /mnt/flash/abies/lua + 0x2f2d4 ]
Source : <0x0366a3fa> [ /mnt/flash/abies/lua + 0x6a3fa ]



Looks like we have the omnipresent libC library servicing Lua code located in /mnt/flash/abies/

root:/> top
Print certain system information.  With no OPTION, same as -s.
Mem: 45392K used, 15304K free, 0K shrd, 0K buff, 5600K cached
Load average: 2.69 2.42 2.22
PID USER     STATUS   VSZ  PPID %CPU %MEM COMMAND
438 root     R      27536     1 71.7 45.0 lua
21151 root     R        844 13454  7.2  1.3 top
495 root     S      27536   460  3.2 45.0 lua
343 root     S       2806     1  0.8  4.5 nano-X
13453 root     S        508   276  0.8  0.8 telnetd
349 root     SW         0     2  0.8  0.0 rt73
460 root     S      27536   438  0.0 45.0 lua
359 root     S        836     1  0.0  1.3 syslogd
360 root     S        836     1  0.0  1.3 klogd
194 root     S <      800     1  0.0  1.3 udevd
1 root     S        568     0  0.0  0.9 init
547 root     S        516     1  0.0  0.8 dhcpcd
277 root     S        484     1  0.0  0.7 udisk_mount

Some Lua processes, a nano-X server, a few telnet deamons, a DHCP client deamon and a udisk mount service. So anyway, since today is not the day for me to learn Lua, I will proceed playing with just shell scripting. Let's mod the frame to download some custom telemetry data or public weather satellite picture once a minute.
rm /mnt/flash/abies/default/*.*
cp /mnt/flash/wait.png /mnt/flash/abies/default/chart.png
sleep 30
while [ 1 ]
do
rm /mnt/flash/abies/default/chart.png
wget -O /mnt/flash/abies/default/chart.png http://www.ntua.gr/weather/sat.jpg
sleep 60
done

The above script takes advantage of the fact that the frame by default cycles between 4 preinstalled images located under /mnt/flash/abies/default/. So first it clears this picture index, then it copies a waiting image into the picture area, which makes the frame show a nice image while we wait for the actual live data. Then we loop indefinitely, and in this loop the old image is deleted, a new image is downloaded and then we sleep for 60 seconds.

The above image shows live telemetric data from my house, in the form of temperature, humidity etc. as 24h charts. In principle there's no limit to what you can render on the frame, as long as you are capable of producing 800x600 image representations.

Turns out, it's even possible to use the official update mechanism and create an update package which does this modding on a frame just by inserting a USB stick with the software on - just be aware of updates being pulled down from iGala's website which may conflict (you can block this of course, but then you might as well simple write your own Lua hosting application).

Wednesday, December 23, 2009

Android debug bridge on ubuntu 9.10

It turns out the latest Ubuntu release makes it a bit more difficult to connect the multi purpose Android debug bridge to your Android device. The following is really just an update of my older entry, to remind myself of the changes in Ubuntu 9.10. This stuff is pieced together from various other sources online (mostly android-discuss) and thus not particularly original.

Ok so first of all, there are quite a few more vendors and devices now (yay). In order to identify your device, make sure your device is not connected and then execute the Linux command lsusb.


casper@workstation:~$ lsusb
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 004: ID 07cc:0501 Carry Computer Eng., Co., Ltd Mass Storage
Bus 001 Device 002: ID 0409:005a NEC Corp. HighSpeed Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 002: ID 051d:0002 American Power Conversion Uninterruptible Power Supply
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 002: ID 046d:c51a Logitech, Inc. MX Revolution/G7 Cordless Mouse
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub


Now connect the device and make sure USB debugging is enabled, and run the command again. You should have one more line:


casper@workstation:~$ lsusb
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 016: ID 0bb4:0c02 High Tech Computer Corp.
Bus 001 Device 004: ID 07cc:0501 Carry Computer Eng., Co., Ltd Mass Storage
Bus 001 Device 002: ID 0409:005a NEC Corp. HighSpeed Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 002: ID 051d:0002 American Power Conversion Uninterruptible Power Supply
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 002: ID 046d:c51a Logitech, Inc. MX Revolution/G7 Cordless Mouse
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub



So now we learned that HTC stands for High Tech Computer. :) We then need to install the rule for the device, by creating a file under /etc/udev/


gksudo gedit /etc/udev/rules.d/51.android.rules


Enter the following, but adjust vendor id and product ID according to what you just found out in the previous step. The device entry below will likely only work if you also happen to have an HTC Magic/Saphire A6161/Nordic (32a).


SUBSYSTEM=="usb", ATTRS{idVendor}=="0bb4", ATTRS{idProduct}=="0c01", MODE="0666"


Make sure everyone can access and execute it:


sudo chmod a+rx /etc/udev/rules.d/51.android.rules


Now reload the udev service:


sudo service udev reload


Now you are ready to start the adb service. Note that due to a change/bug in the security policies of Ubuntu 9.10, you won't have access to the device unless you execute adb (or rather, the adb service) as a super user. This is mildly annoying:


casper@workstation:~/development/android-sdk-linux/tools$ adb devices
* daemon not running. starting it now *
* daemon started successfully *
List of devices attached
???????????? no permissions


Instead what you will have to do is start the server manually in super user mode (make sure to kill any existing server first, with sudo adb kill-server):


casper@workstation:~/development/android-sdk-linux/tools$ sudo ./adb start-server
* daemon not running. starting it now *
* daemon started successfully *


And now you may use adb as per usual:


casper@workstation:~/development/android-sdk-linux/tools$ adb devices
List of devices attached
HT95PKF00221 device


Not really groundbreaking stuff, but I thought it might be useful and save time for others running Ubuntu 9.10 and wanting to get ADB up and running.


Update
The Nexus One, Google's latest Android beast, appears to be identified as 18d1:4e11 but without any vendor string. Interesting since the Nexus One is also hardware produced by HTC. However using adb, it will list with serialid: HT9CRP805273 so HTC is not entirely hidden. It appears that internally the phone is referenced as the Passion and/or Mahimahi.