Under The Covers
Figure 19 shows the main board of the N2100 after the disk cage has been taken out. It's a bit hard to see, but the CPU in the box is a 600 MHz Intel 80219 Xscale processor. The Ethernet controllers are provided by Realtek, and the SATA controller is from the Silicon Image SataLink family.
Figure 19: Main Board - Click to Zoom in (click to enlarge)
Note the empty mini-PCI slot on the board, which is designed to be consumer-populated by wireless cards based on the Ralink RT2561 chipset. Wireless USB dongles based on the ZyDAS ZD1211chipset are also supported. Near the top of the image, you can see a 128 MB memory module in the single slot.
I was fairly certain that this box was running Linux internally, but I wanted to poke around a bit to be sure. A port scan of the device turned up nothing interesting, but a fingerprint scan identified the OS as being based on a Linux kernel. The documentation included copyright notices for several GPL components, but not for Linux. Time to dig deeper.
I've had a bit of success lately finding and using NAS CGI security holes to poke around the operating system. It turns out that like the other boxes I've played with, the N2100 has at least one such error as well. When you use the Web interface to browse the file system, you are supposed to be restricted to the shared directories, but it was fairly straightforward to break out of the standard structure. I noticed that when I fetched a file, the relative path of the file appeared in the browser URL.
After a bit of trial and error, I found that as a non-admin user, I could view almost any file I wanted to by first going up two directories and then back down. For example, using the following URL, I could fetch the password file: http://192.168.1.100/cgi-bin/download.cgi?album%2F/../../etc/passwd
Rummaging around like this told me that the box was indeed running Linux. I couldn't get a directory listing, but knowing the typical structure of a Linux system, it was fairly easy to make my way around. I started with the first startup file, inittab, and then worked my way, script-by-script, through the entire boot sequence, finding some interesting things along the way. An ssh daemon was present on the box, and it appeared to be started up at boot time. Unfortunately, I could find no evidence of it when the box was fully booted.
I found that the iTunes server used was mt-daapd. Viewing the proc filesystem gave me info about disk mount points, memory usage, kernel version (2.6.9), and so on. One interesting feature I noticed was a script that, with a bit of effort, could give a user the ability to completely control the box.
A "module-boot" script loads modules and executes scripts from a designated directory on the hard drive. To access this, you'd probably need to mount the drives on a standard Linux box, properly populate the "module" directory with your customizations, and then replace the drive. This way you could add your own Telnet server, ssh server, device drivers, etc. There are lots of possibilities.