Hacker News new | past | comments | ask | show | jobs | submit login
Hacking Transcend WiFi SD Cards (haxit.blogspot.com)
199 points by vsrev on Aug 11, 2013 | hide | past | favorite | 54 comments



My experience with embedded systems allows me to be fairly certain that this bugfest is due to an electronics engineer writing the software for the card. Way too often small R&D teams, especially working on new products, have EE people being assigned to part-time-embedded-programmer roles.

This is especially scary as some of these teams work on internet-facing pieces of hardware - home routers/gateways, etc. One cool weekend project to have is trying to get hold of an image of the firmware of your home router, run binwalk on it, try to extract the filesystem, and count the number of remote exploits you can spot in the CGI perl scripts (like they are, in 99% of the cases) found there. Yet another reason to run OpenWRT ;).


As someone who's written software for all his life, I'll posit that most "software engineers" write code like this. People don't test corner cases; they just shit out code, check that it works in the browser, and ship it. That's why the regexes like /.PNG/ are in there: they work, but they don't prevent the security problems they intend to prevent. If the engineer writing the code had written unit tests that checked various filenames, he would have discovered the bug immediately. If there were code reviews by someone who knew even the tiniest bit of Perl, the `$user_controlled_command > file` bug would be gone. If the programmer had run Perl with taint mode enabled, he would have discovered this bug instantly.

I think it's a mental thing: most people writing code never think "how could this go wrong", since they assume that they don't make mistakes. If you don't have a healthy fear of the code you write, you're not going to test the corner cases or not write complex features.

Ultimately, I'm not complaining, because buggy software is great in the context of devices that try to prevent you from doing something with your own property. I especially encourage people to write their system-level software in C and use lots of strcpy calls. It ensures that I can root my phone even though the carrier doesn't want me to.


Another explanation is that there is no benefit to the manufacturer in writing tighter code. Tighter code means more time spent on testing and review, but probably wouldn't increase sales. From a bottom line point of view, the mantra is get it working and ship it.


Yep. Whenever you work in an industry that involves churning out software as quickly as possible, it's easy to appreciate that commercial pressures are often too great to test properly. Whereas with start-ups (for example), they're usually well funded and have a strong focus on building great software.


I don't think it's that they assume they don't make mistakes, but simply that they literally can't do any better. For some programmers, making something work at all is a mighty struggle, and once it does work, that's the best the can do.

We were all there once. It's a stage you hit when learning to program. Some of us passed through it, while others simply remain there forever.


Ultimately, I'm not complaining, because buggy software is great in the context of devices that try to prevent you from doing something with your own property. I especially encourage people to write their system-level software in C and use lots of strcpy calls. It ensures that I can root my phone even though the carrier doesn't want me to.

Reminds me of claims of deliberate backdoors. Of course, these can often be used for bad things too.


How can I as a developer be sure my unit tests are complete? How can we develop or improve that ability to think "what could go wrong?"

I don't think they developers of Android, iOS, or the PS3 (and many others) were using insecure coding practices. They still got rooted over and over again.


There's an old saying I don't hear much these days: never give a software engineer a soldering iron and never give a hardware engineer a compiler.


I can attest to the low quality of router firmware, go grab the source from Billion or Netgear and have a look.

Homework question: What's running on your blu-ray player?


Java. Oh, don't worry, that's like totally secure.

[tries to keep straight face, fails utterly]


I really should start blogging - one of my many unfinished projects is a teardown and reverse engineering effort of a Philips BD player. Java isn't even the half of it.


I really do hope you consider writing that blog post. Everyone here, and on several other sites, would love to read the trials and tribulations of hacking something like a BD player. :) Even if its just a quick run down with some pictures and a little story, it would be worth it.


I'd really appreciate some early feedback on the stuff I'm writing, but you don't have any contact details in your profile - send me an email if you want a preview.


Please, do so. It would be interesting to read.


Please do!


This is awesome. A few years back I originally wrote an open source EyeFi server in Python (http://returnbooleantrue.blogspot.com/2009/04/eye-fi-standal...). I could not actually hack into the card though and get root which is what I really wnated.

These memory cards are super fun and I've been meaning to pick another up to give it another go.


We use your eyefi server at our local hackerspace (hackerspace.pl). I haven't really touched the card myself (the setup was done by a fellow hacker), but I'll probably take a look at it some day, if there is at least some vague promise of RCE hidden somewhere.

Thank you for your great piece of software.


Awesome. I've been using your software since mid 2009. I've transfered ~100GB of pictures using it. Thanks!


> After navigating the filesystem and downloading scripts, it is obvious, and not surprising, that this system is using busybox...

Does anyone know whether Transcend provides source code [0] upon request? The EULA in the user manual for the product [1] mentions that it might contain "GPL Components", but I could not find any additional details.

[0]: http://www.busybox.net/license.html

[1]: http://www.transcend-info.com/files/Manual/WiFiSD_Manual_v1....


There is a >50 MB "GPL download" on the Transcend website. So I guess they are at least partially complying with it.


Do you have a link? The only GPL-related download I could find was for their RecoveRX data recovery software: http://www.transcend.de/products/RecoveRXTool/GPL.asp



"Perl has a nice feature when opening a file with the open() library call, because it not only opens files, but runs programs if the file path is not a path, but a shell command ending in a pipe."

I thought only PHP did things like that :)

I hope this is disabled in mod_perl? Because if not I need to let someone know they need to audit their code.

PS. I get how useful this is, and it's well documented, but this functionality should be in the ancillary function (i.e. used when needed), not in the default one.


Perl has the three argument open that is safe. The issue is well known by perl developers and well explained in the popular free book "Modern Perl".


And the three argument open has been in Perl since at least 5.6, which was released 13 years ago. No reason to use anything else.


I believe it's enabled under mod_perl. If that someone was allowing user input to make it to an open, system, or back tick call unfiltered then this is just one thing to worry about. It's as bad or worse than taking unfiltered input and building an SQL query with it.

Moreover, this isn't a Perl issue. I can think of ways to do similarly I'll advised things with C#'s process.start or C/C++'s System command.


I don't know what they did, it's not my code, but they are not experienced and I suspect they don't know to watch out for this.

> Moreover, this isn't a Perl issue. I can think of ways to do similarly I'll advised things with C#'s process.start or C/C++'s System command.

Obviously every language has ways to cause this. It's just that open is the default command. This extra functionality should be in a openshell command or something, and the regular open not have it. (And yes I'm aware it's way too late to change it.)


As pointed out over at http://www.mikrocontroller.net/topic/303547

the most simple way of starting the fun:

Create a file called autorun.sh on the card, put

telnetd -l /bin/sh &

in that file and boom. telnet 192.168.11.254 and enjoy.


this was posted to /r/netsec too, the conversation here has more details about the embedded system: http://www.reddit.com/r/netsec/comments/1k4zhz/i_rooted_my_t...


Googling the hardware name from /proc/cpuinfo, "KeyASIC Ka2000 EVM", I found out that this isn't the first person to hack into these half-SD-half-WiFi cards: http://colas.sebastien.free.fr/index.php/category/transcend-... http://blog.toshikatsu.tanimula.net/2013/03/aircard.html http://lemoidului.wordpress.com/2013/02/11/linux-is-everywhe... etc. etc.

I don't read French or Japanese but even the shell outputs are interesting reads.


Thanks for posting. I love articles like this which follow the thought processes of someone trying to hack a device. Keep 'em coming!


I'm working on an article like this (but with less success at the end) for my Blu Ray player. Email me if you want a preview!


This is cool. Unfortunate in some ways that it has an AR6003 wifi, since ath6kl (the OS driver for the AR6003) doesn't have monitor or promiscuous mode support yet which means no sniffing or injection.

Because if it did, it would be an interesting choice for pen testing. You could recase it, and it's small enough that properly installed and configured, it would be difficult to find. Processor is fast enough to get some cool tricks going.

Of course, it's possible some clever kernel hacker will get those working on the AR6003 at some point, which would open up this, as well as a bunch of devices, to some cool uses.


A pen testing pen.


I love articles like this. Thanks for posting this; good hacks :)

In the same vein, though I can't find the video for it right now: http://www.khanfu.com/m/plain/29/event/1978 (this was also presented at Defcon 21)


It's very cool to be able to write remotely on a SD Card when you have for example a Makerbot 3D Printer, or any device with a SD Card reader but without wifi / ethernet connection: never plug in / out the SD Card anymore !


What are the specs (CPU, RAM) for the card?


According to author's post in the Reddit thread, it has a 400MHz arm9 with 30MB of RAM.


That's actually pretty decent considering what it is.

Do you think you could run owncloud or something similar to use it as a sort of wireless flash drive?


or maybe it could be used as a ultra low energy bittorrent client: the cpu should be fair enough (many router/nas use 800mhz-1ghz ARM cpu and they offer bittorrent and other clients) and even though this device is low on memory (32MB RAM) it looks like transmission client can use only 10MB or RAM: http://pastehtml.com/view/5tx16jw.html so MAYBE it could work.


Contrived, sure, but you could use these exploits to upload all files added to the card somewhere, assuming it can find a wireless network to connect to. Maybe even just keep a hidden copy on the part of the FS invisible to the host system if there is enough free space.

"Oh sure I've got an SD card you can borrow..."


You could do a lot of neat things - like make an SD card that automatically GPG-encrypts every file that gets stored on it.


How are these cards powered?


A quick look at the pinout for the cards shows a 3.3v line, so it simply draws power from the host device.


I wonder how long this thing would run off a pair of AA batteries?


The same way the flash chip is powered?



Excellent post. Thanks! Hopefully these will become dirt cheap (or, worth hacking because they'll be cheaper than the electric imp).


That thing was put together in a hurry. I bet nobody even considered security but that's the good news for us :)


Thank you for the blog post. Very interesting and good lessons to learn in there.


Is it possible to stream data to these cards?


a kickstarter project, with a more powerful hardware and easy to hack system, would be great


Wouldn't that just be a raspberry pi?


The point is to have small device that would fit in a SD slot and AFAIK the Raspberry Pi can't be reduced that small.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: