How would I go about gaining access to a locked-down Linux device I own.
How would I go about gaining access to a locked-down Linux device I own.
Five years ago, I bought a Supernote A5. It was (and mostly still is) a great device for reading and writing on an eInk display, and it runs plain old linux.
The deciding reason I went for this device instead of the competition is that I was "under the impression" that they were about to enable full SSH access to the device! Awesome!
"Why were you under that impression?", I hear the skeptics ask. Well, their spokesperson has stated that they would do so. Via mail, and on reddit, publicly, multiple times. I was still torn, so sent them a DM, asking if this was ineed factual. "Yes", they said, "the next quarterly update will enable SSH access!".
Great!
Well, it's been 5 years. They did not follow through. A couple updates were published, none contained the promised functionality, the spokesperson stopped answering questions about SSH. The last software update I received is from 2.5yrs ago. Mentions of the original Supernote A5 have largely been scrubbed from their website.
Let me be clear, the device still functions perfectly. But it is in danger of becoming e-waste because it is so needlessly complicated to get stuff on the device. I'm currently in need of an ebook reader with (ideally) OPDS capability, and I am pretty confident I'd be able to get something like koreader running on this, or at least just run a script to sync files over SSH. Also, I frankly feel wounded in my pride having a Linux device in my possession which refuses to do my bidding (I'm joking of course, but also I am 100% serious).
Here's all I know:
- plugging it in via USB, the device reads as an MTP device, with access only to the documents/books/... stored on it
- you can place an
update.zipfile (obtained from the SN website) into the root of that MTP directory, and upon reboot, the device will update. To me, this appears to be the most promising route of gaining access. - unfortunately, the zip file is encrypted. The decryption key clearly has to be known to the device, but since I have no access to it,...
I'm a software engineer, but I have zero knowledge of the "dark arts", so to speak. If anyone could help me (or point me into the right direction!), I would really be grateful. I don't want this (generally nice) product to turn into a paperweight instead of a paper replacement :(
Sounds more like an android device that an actual Linux device. Especially since it gets detected as an MTP device via USB.
Maybe
adbcan see it.The entries in
update.zipare encrypted using the weak ZipCrypto scheme, which is known to be seriously flawed. If you feel motivated, and can guess at least 12 bytes of plaintext for an entry, it is possible to recover the internal state of the generator, which is enough to decipher the data entirely, as well as other entries which were encrypted with the same password. The bkcrack project implements this attack.Since some of the entries are zip files themselves, it is within the realm of possibility to guess 12 bytes of plaintext. Parts of the zip local file header are pretty static, and you can use some of the values from the local file header of
update.zipitself. Still, this would require a bit of luck / inspired guesswork.Oh, wow. I am so giving this a try. Huge kudos for checking the zip itself, btw! Thank you :D
Just for clarification though, do I need 12 bytes of the original content or of the compressed (but unencrypted) byte-representation of the zip file?
Edit: Ah, the repo links the paper. Reading now :)
The attack worked, the password is
cmF0dGEK.This was obtained by generating 32 possible plaintexts for the first 10 bytes of system.zip (based on the different values in the headers of ~300 zip files on my system), plus three null bytes for the high bytes of compressed size, file name length and extra field length.
The inner zip files are just stored, uncompressed:
Archive: update.zip Index Encryption Compression CRC32 Uncompressed Packed size Name ----- ---------- ----------- -------- ------------ ------------ ---------------- 0 ZipCrypto Store d1bca061 65761967 65761979 system_lib.zip 1 ZipCrypto Deflate 64a3f383 2183 741 config.json 2 ZipCrypto Store 3731280f 89300292 89300304 app.zip 3 ZipCrypto Store a2bd64f5 135518964 135518976 app_lib.zip 4 ZipCrypto Store 700eb186 5996410 5996422 system.zipSo 12 bytes from the original content.
I had the same idea, and I'm trying it right now... Not something I've ever done before though.
Taking this to an extreme, if you can't gain access via software (unlikely if it hasn't been updated in 5 years), you could disassemble it, locate the SPI interface for the NAND (assuming it uses SPI), and use something like an arduino with a loaded SPI reader sketch to read it. You can then pick it apart to find vulnerabilities, or just replace it.
Theoretically... But this is 5 levels of knowledge above my head, I fear :D
Maybe start with trying to understand this first:
https://github.com/TA1312/supernote-a5x
Good news: apparently, it has bad security 😇
If you get an OTG dongle, you might be able to get a keyboard on it and interrupt the bootloader, and/or boot to a USB thumbdrive.
Have you checked for open ports?
There's a non-zero chance that there's a long out of date apache or something running on it.
Yeah, good idea. They added a network "mirroring" functionality at some point, so SOMETHING is listening on some port.
This repo claims to have found a way to get root on the device: https://github.com/TA1312/supernote-a5x/blob/master/sideload.md
Thanks, but that's the A5x, a newer Android version of the tablet (hard- and software are different)
Oh FBI...
I own the goddamn device, I should be able to do whatever I want with it...
Are you able to see what kernel version it's running?