Local Links

External Links

Contact

Search this site

RICOH / PENTAX FluCard Reverse Engineering

The PENTAX FluCard O-FC1 is a Wireless memory card for the Pentax K-3 (and later models).

It mainly offers remote control operations (preview, adjust a few settings, release shutter) over a http cgi-bin interface, which is mainly served as a web page to be used with mobile devices such as an iPhone.

The card is based on the FLUcard by TREK(?). On their website, it listed a few custom http commands I wanted to try myself, but found that (a) the website was not longer fully operational - which I solved by looking it up on archive.org - and (b) some of the commands did not work.

For instance, the "filelist" command did not work at all. It never listed any files, but responded with "No files found". After updating the card's firmware from 00.00.00.00 to 00.01.00.02, this command started working. However, it was not working to spec, e.g. the "plain text" version was still rendered as a html page, and the html version still says "No files found" twice at the top, even though it then lists the image files.

But the presense of a firmware update made something else possible: Figuring out what's going on on the card.

Contents of a firmware update

The list of files from the firmware update are as follows: 

autorun.sh
code/
  caution.png
  icon.png
  index.html
  version
html
initramfs3.gz
program.bin

Analysing the various files...

  • autorun.sh is not a text file but binary with an "ELF" header. Opening this file with Hopper, I learned that this is ARM7 code, meaning that that this SD card runs on a ARM CPU.
  • index.html is not a text file either but binary again. Sadly, this one had no header nor any other textual fragments, suggesting that it's encrypted.
  • version is a small text file with these bytes inside, no idea what they mean: 76 CA C9 9B 96 ED 9B 9E 30 60 B8 81 13 C5 0C 18 2E 60 C8 71 03 06 8B 18 30
  • html is an ELF binary file that references /code/version and appears to have functions such as HTML_CreateVersionFile() and HTML_DecodeHTMLContents().
  • initramfs3.gz is something used by Linux systems as a container for a complete Linux file system. More on that below.
  • program.bin appears to be an executable file without a particular identifying header, though. Text inside suggests that this is a boot loader ("U-Boot") for the Linux system inside initramfs3.gz.

Unpacking the initramfs3.gz was a bit tricky due to it having an extra 8 byte header. This article helped me unpack it. On my Mac, I had to use this shell command to unpack the file system: cpio -i -d < ../initramfs3.cpio.

The files inside the code directory get copied to /mnt/mtd/www. And in turn, at every linux boot, the contents of /mnt/mtd/www get copied to /www (as part of the rcS script, see below). I wonder why that is done, because it also appears that the main file system (or at least /www) is persistent, i.e. what gets stored there remains there even if power is lost.

The http (cgi-bin) command set

The Linux web server files are located inside the www folder. The commands the card responds to are inside its cgi-bin folder. Here's a list at all of them:

card_config, card_status, datetime, download, download_multi, folderOpt, host_operation, htmlcgi, input, jpeg_frame, logpage, mjpeg_video, motion_cgi, output, photo, photolist, playNote, preview, refresh, rename, restore, status, thumb_video, thumbNail, thumbRaw, upload, upload_sd, upload_to_sd, video

And, indeed, if you are connected to the card wirelessly and try the command, e.g. open http://192.168.1.1/cgi-bin/status, then you'll get a page back showing some of its internal LAN, WLAN and Firmware status values.

Now, it appears that every of these cgi-commands is a symlink to the busybox executable. Meaning that the busybox code has to be disassembled to learn how these commands work and which parameters they expect (I must admin I am not having the patience for this). The other alternative is simply trying them commands out, trying to deduct how they might work from other known commands.

Another way to learn about most of these commands is to look at the javascript that gets send to the browser when opening the main page (http://192.168.1.1) from the card. That way, we'll also get to see their parameters. Many of the above commands appear in the js code, but these do not:

datetime, download, download_multi, folderOpt, htmlcgi, input, jpeg_frame, logpage, motion_cgi, output, playNote, preview, rename, status, thumb_video, upload, upload_sd, upload_to_sd, video

Detailed command descriptions

This is a list of commands I've so far tried out. It's not complete (yet). Each of these commands is added to the http request http://192.168.1.1/cgi-bin/

status
Shows LAN, Wireless and Firmware values, such as versions and addresses.
card_status
Responds with m1=idle
photo
Displays an nicely rendered overview of all folders and their pictures with the option to download them. It includes a Java plugin for the web browser, but I was not able to make it work ("ClassNotFoundException", "download.class") - I suspect the Java code is for providing additional commands, e.g. deletion of items, because it's also possible to checkmark folder and pictures, and there's no other interface given to operate on these selected items.
video
Similarly to photo, it displays an overview of all video files.
photolist
Gives a textual list of every picture's URL.
playNote?fn=<frequency>
Plays a short note with the card's buzzer. Example: http://192.168.1.1/cgi-bin/playNote?fn=262
thumbNail?fn=/<foldername>/<filename>
Returns a thumbnail image of the picture. The path can be inquired with the photolist command.
folderOpt?fn=<operation>&fd=<path>
Creates or deletes a folder. Use 'c' or 'd' for <operation>.
rename?fn=<source_dir>&fd=<dest_dir>
Renames files and folders.
datetime?action=get
Returns the time on the card.
datetime?action=set&yyyy=<year>&mm=<month>&dd=<day>&hh=<hour>&min=<minute>
Sets the time on the card.
host_operation?action=
This deals with all the camera functions. It takes additional parameters. The parameter seq is a request number that must always be included and incremented with every request. Further parameters are:
get-camera-config&config-entry=<conf>
Returns camera settings. <conf> can be: status, capability
live-view-restart
Returns an error but engages LV regardless. Seems to be wanting more, or maybe expect someome requesting the stream. Update: Resumes LiveView after live-view-pause.
live-view-stop
Stops LV mode.

More hacking options

The firmware's /etc/init.d/rcS file is a shell script that runs at every start of the card. It contains these lines: 

if [ -f /mnt/sd/autorun.sh ]
then
	sleep 1
	chmod 777 /mnt/sd/autorun.sh
	/mnt/sd/autorun.sh
	rm /mnt/sd/autorun.sh
	sync
fi

This means that we can store a shell script named "autorun.sh" on the card and it gets executed whenever we power it on by inserting it into a computer or a camera. After that, the file gets deleted, so we'll have to make the script copy whever it wants to make permanent over to the file system.

Telnet into the Linux running on the FluCard

So the next step would be to get some sort of ssh or other terminal service running over the wifi connection so that one can work interactively with the linux system on the card. Luckily, someone else already figured this out for me: Hacking Transcend WiFi SD Cards. It even suggests a way to start a telnet server via autorun.sh. There is just one little glitch with it: The script tries to invoke the bash shell, which this system doesn't include. But with sh instead, it works. So, here's how to access the FluCard's Linux shell:

Put a text file named "autorun.sh" into the root of your FluCard (and keep a copy of it, as it'll be erased from the card next time you insert it into the computer or camera!), with the following contents: 

chmod a+x /mnt/sd/busybox-armv7l
/mnt/sd/busybox-armv7l telnetd -l /bin/sh &

Also, put the latest busybox file for arm7l into the root of your card (this won't get deleted).

Now unmount / eject your FluCard and re-insert it, to power it up again. Then connect to the card wirelessly as usual. Finally, start the telnet command. On OSX or Linux, this would be done with the command:

telnet 192.168.1.1

For Windows, ask Google.

Now you should get a connection and see the "#" prompt, allowing you to enter Linux commands.

A new tool to modify the Linux file system permanently

In order to make changes to the Linux FS, one would use some terminal command to unpack and re-pack the initramfs file. But that's not for everyone. So I spent a rainy sunday's afternoon to write a GUI app for this: InitRAMFS Updater. It is made with Xojo and should be able to run on OSX, Windows and Linux, though I have only tested it on OSX so far. It lets you open a initramfs.gz file, browse its contents and extract single files as well as update files inside (there's currently no way to add new files as that requires a bit more work to make sure all the file attributes are set correctly). With that, you can conformtably extract the init script (/etc/init.d/rcS), edit it in your preferred text editor and then re-insert it into the initramfs. Then you can perform a firmware update with it, following the normal instructions for a firmware update.

You can get the OSX version of the app here:

If you like to try this on a Windows or Linux computer, contact me and I'll send you the right app.

Wifi configuration

The Linux system comes with several scripts that configure the wireless network in various ways:

/usr/bin/w0
Stops all network servers (httpd, dnsd, telnetd), unloads network drivers takes mlan0 down.
/usr/bin/w1
Loads drivers, starts mlan0 and creates an empty file at /wifi_flag.txt
/usr/bin/w2
Reads /etc/wpa.conf or /etc/wep.conf
/usr/bin/w2_receiver
Reads /etc/wpa.conf or /etc/wep.conf
/usr/bin/w3
Sets up Ad-hoc network, it appears.
/usr/bin/w3es
Sets up Ad-hoc network, it appears.
/usr/bin/w4
Sets up Ad-hoc network, it appears. Reads /param_value.txt
/usr/bin/w5
Sets up a network at 192.168.0.0 (gw .1), mlan0 mode "Managed", essid "Any". Runs uhdcpd.
/usr/bin/uap
?
/usr/bin/uap_sender
?
/usr/bin/uap_tmp
?

They all seems to be leftovers from the original Flucard (before modifications made for/by Pentax), as the startup script (/etc/init.d/rcS) does not invoke any of these. Also, the card's SSID (network name) is hard-coded in the busybox binary and does not appear in any of the other scripts or config files.

Still, I wonder if any of these scripts can be used to get the card to connect to my local Wifi network.

Goals

What can be done with these findings? Here are some ideas:

  • How does the Flucard communicate with a Pentax DSLR, and are there more options to control the camera that the current code doesn't make use of? This may also require some work on the Pentax firmware side. See also: Resurrecting Pentax firmware hacking
  • Are there commands the card currently supports but doesn't exploit through its web browsing interface?
  • Would it make sense to modify the web browsing interface, adding more features or making it more user-friendly or just have it work better on mobile devices.

Further findings

This is just a list of notes I took from reading various web pages, forums, and e-mails.

  • Serial port on card uses 3.3v logic, 38400 8N1.
  • The cmd buzzer -t 1 starts an endless loop of tones until buzzer -t 0 is issued.

References

Final words

If you are making some findings on your own, please post them somewhere or email them to me and I'll post them here. Keep me updated either way.

Page last modified on 2015-06-02, 19:25 UTC (do)
Powered by PmWiki