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).