Glen Pitt-Pladdy :: Blog
Transcend Wi-Fi SD Hacks (CF adaptor, telnet, custom upload)
I've been wanting a wireless way of getting data off cameras onto my workstation for post-processing, but being an older (too good to replace) semi-pro camera it only takes CF, plus added to that the initial Wi-Fi SD devices on the market were heavily locked down (in fact it appears to the point that some can't be used without registration!) with proprietary tools which means you have to accept the vendor dictating to you how you will work or its not going to be much use.
That all changed with the inexpensive Transcend Wi-Fi SD devices entering the market. Not only are these around half the price of many others on the market, but turn out to be running Linux.... and are very hackable as "Pablo" and others discovered. There is even an easy (shell script) hook for executing your own commands / code on the device.
At last a Wi-Fi SD with openness and flexibility - Well done Transcend!
There is huge potential for customization and adding additional features to this card and little doubt many more pages on this device will be popping up all over the web in the near future.
What I do here may well cause damage, both to kit and to data integrity. A good grasp of Unix fundamentals is a necessity. If you don't understand the whole of this and accept the risks completely then don't attempt any of this.
My approach is based on minimally changing or adding to the device firmware (volatile changes) and making no permanent firmware or configuration changes - all changes are done via hooks executed from the SD storage and deleting the contents of the SD should return the card to "normal" operation.
There is no guarantee however that this goal is achieved since there may be a lot of unknowns lurking still and my experience is that others looking at this card may already have fallen foul of some (see later).
WiFi Signal with SD-CF Adaptor
The first thing is to get the card working in my camera, and that requires a SD-to-CF adaptor. After some research I found an inexpensive one that others seemed to be reporting success with, and it works for me.
On putting it all in the camera I got very little signal - in fact it was dropping the connection further than about 1m from the AP. The problems become obvious when you look at it. From a ripped apart Transcend Wi-Fi SD we can see the antenna along to back edge of the card and in the adaptor the antenna will be barely sticking out beyond metal plates either side of it... not going to help:
So the first thing I did is to pry the covers off the adaptor which ensures that the antenna is not shielded (at least on the top):
... and this one is nicely made compared to most stuff I pull apart these days:
This has made a massive improvement to the signal and makes it usable now, however since the CF slot is effectively still in a screened cage the signal is far from perfect with the antenna hardly exposed:
None the less I'm getting 50+Mb/s connection speeds in the same room. The next logical step will be to try and put in some means to couple from the SD card antenna to the outside world, but that's for another time.
Setup & Frimware
Out the box I was able to connect to the card via Wi-Fi with a laptop and configure it with the web interface. It powers up at first as an Access Point with the SSID of "WIFISD" and password "12345678", acting as a DHCP Server. After connecting to the card's network, it is accessible on http://192.168.11.254/ with the username and password "admin".
Everything except the upload configuration (eg. to send photos to Facebook) seems to be configurable via the web interface including previewing and downloading photos and videos from the card. For upload configuration you will have to use the mobile app.
"Pablo" and others have already successfully got into the card and have discovered that if present, it will execute autorun.sh on the card at boot. This is a neat hook script that allows a lot of flexibility combined with being able to download a more functional busybox (ARM5) which can be put on the SD and which is mounted below /mnt/sd/ on the card.
My card came with version 1.7 and the mobile app prompted me to upgrade to 1.9 which I was a bit apprehensive in case the nice hooks had been removed, however after upgrading I can confirm the hook is still alive and well. It is worth noting that the upgrade resets the configuration to factory defaults even if the SD data was left intact.
Camera Power Saving
This is mentioned repeatedly in the paperwork with the card. The problem is that by default many cameras use aggressive power saving and shut down after a minute or less idle. Since this card is going to take 30-60 seconds (maybe more) from power up to being connected before it can even start uploading files, you will need to consider this setting on your camera and ensure that the card is kept running long enough to be useful.
The manual / paperwork says to disable power saving (ie. permanently on) but I've had success setting it to several minutes instead.
The packaging states (in find print) "When transferring data from card to computer directly, please only use the included Transcend RDP5 Card Reader."
That is important information worth heeding - I have had many corruptions with other readers. FAT32 is not a clustered filesystem, so in a case like this where multiple systems are accessing the same filesystem, presumably precautions are needed to ensure corruption does not occur.
The first step is to get into the OS, and out the box we already have telnetd available with the shipped busybox so an autorun.sh in the root of the SD card this will give you unauthenticated access:
Note: The first line is not necessary with busybox, but I'm in the habit of writing things for maximum portability
After boot you should be able to telnet directly to the device and get straight into a shell.
This is not something that will be wise when off a locked down network with only trusted users as it could result in public access to the contents of your card, but it is a good start for customization of the card.
As well as locking the card down (set a suitable SSID, Wi-Fi key, HTTP password), I've made my card enable services based on the network it finds it's self on. This hooks (appends) into the DHCP client script /etc/dhcp.script which is executed every time a DHCP even occurs (new leases, renewal, disconnect).
I have created a .custom/ directory in the root of the SD with all my scripts & tools and my autorun.sh looks like this:
This assumes you have downloaded the ARM5 busybox binary (see above) and put it in the .custom/ directory, then it appends customization to the DHCP client script, tweaks the refresh_sd script to make the SD mount read-only from the system (as a safety feature) and adds my custom autoupload tool (more about that later).
Customisation - NTP
As I want to use SSL/TLS (https://) to remotely upload files back to my server, I need the card to have a valid clock. By default /etc/init.d/rcS sets the date/time to 201201010000 on boot which invalidates SSL certificates which start later than that.
The busybox-extra added does contain a basic ntpd so we use this in the ntpd.sh snippet (appended to the DHCP client script) with:
# kill existing ntp daemon
This will use DHCP provided NTP servers if available else default to the ntp.org pool - change that as you wish.
Customisation - Shell & FTP Access, plus extras
When on a trusted network I want to have shell (and FTP, though the safety of this is suspect for accessint the SD) access to the card. The access.sh snippet (appended to the DHCP client script) looks like this:
# kill existing telnet & ftp daemons
This detects the SSID, the router IP and MAC and appends them together - you need to set the appropriate string in the case statement to match yoru network. For convenience it also logs the strings to /tmp/netid.log where you can check for what it gets on your network.
I can't be certain of FTP being safe for data integrity in this case, but if you want to risk it a simple way of mirroring the data using FTP from an arbitrary path on the the card to the current directory would be to use the lftp tool:
$ lftp -e 'set ftp:passive-mode false; mirror --loop --continue --no-perms SomePath/ .; bye' <WiFi SD IP>
In this case we disable passive mode, but you could set that true if required.
This is an experimental tool for mirroring the contents of the SD remotely via HTTP(S) and is intended for on-the-fly backups when running on public networks. It uses a Perl script on the device (yes, like almost everything this also runs Perl!) and relies on a PHP script on a publicly accessible web server to store the files. It would be sensible to secure this with authentication and SSL to avoid abuse.
This is best configured in a sub-directory (say tscardupload/)of a site as index.php for reasons that will soon become obvious. Configure your server with authentication for this directory first, then put the PHP file in renaming it to index.php
Now, the trick is that any uploaded file will need to fit within the PHP upload_max_filesize which in turn will need to fit within the PHP post_max_size which in turn will have to fit with the PHP memory_limit (normally OK). If your camera is higher spec and produces larger file sizes then you may have to adjust these limits and by using a sub-directory we can make them specific to that in the Apache config (example includes authentication):
You will also need to configure the path to store files to and creation modes in the PHP script. Ensure the path is writable by the webserver (eg. owner/group www-data on Debian and derivatives).
Then the Perl script for the SD Card can be added and customized with the curl command and URL appropriate to your site, CA and credentials.
After customization you can test this - it should upload any files from DCIM/ below a sub-directory for the authenticated user.
Download Tool (Wi-Fi Tether)
While the FTP option (above) is one (potentially risky) possibility, a bit of fiddling with Firebug, and replacing CGI on the card to capture information and I have all the tools needed for a simple mirroring tool usable when the card is on a local network (directly accessible).
This requires no customization to the device and uses the existing HTTP interface and should run on most Unix style systems (including Mac), possibly only requiring a few additional Perl modules to be installed on the system.
This will look in ~/.wifisdMirrorHTTP.conf for credentials and aliases (you get the default one built in so it will need to be overridden here). The format and an example is:
# Lines beginning "#" (comments) and blank lines are ignored
The mirror script may need a Proxy setting (optional - see top of script) and flags if the camera time is set to the local timezone (else UTC is assumed) and if filenames should be lower-cased.
Simply run the script with an argument of the hostname (will mirror DCIM/) or specify a path:
$ wifisdMirrorHTTP sd:DCIM/100CAMERA
Things to remember
Among the many pages on the web about hacking this card there are a few things I have discovered that need to be taken into account when dealing with this card any may not have been thought through fully (including with my work):
Copyright Glen Pitt-Pladdy 2008-2017