I have an SD card without obvious file system. I'm seeing if the data on there (largely) follows a particular file system's convention. In linux, I ran sudo dd if=/dev/mmcblk0 of=SDcard.bin

fdisk SDcard.bin gives

Disk SDcard.bin: 3.7GiB, 3965190144 bytes, 7744512 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 / 512 bytes
I/O size (minimum/optimal):512 / 512 bytes

doing sudo mount -o ro,loop SDcard.bin /mnt/SD results in a error:

mount: wrong fs type, bad option bad superblock on /dev/loop0, missing codepage or helper program, or other error

trying sudo losetup --partscan --find --show SDcard.bin responds with "/dev/loop0"

but I can't fsck /dev/loop0 or mount /dev/loop0 /mnt/SD, even trying several options for -t

I did an xxd SDcard.bin SDcard.hex and I see, in the middle of the file (e.g. around address 00400040) a2b2NO NAME FAT32 [00]. (spacing sic, [00] = no data) and some readable text earlier than that in several places.

Should I try to mount as Fat32 with offsets, e.g. losetup --offset 00400040 /dev/loop0 SDCard.bin*

*where I translate 00400040 from hex to dec first

  • 1
    You didn't say where the SD card is from or what you'd expect it to contain. Obviously it neither starts with a partition table, nor with one of the usual file systems. Try binwalk on it and see if it comes up with anything useful. – dirkt Jan 26 '17 at 7:46
  • thanks @dirkt - that shows an early-addressed mcrypt-encrypted data, with an 8bit keymode. Does that mean a single byte is the "password"? The algorithm is DES and the mode CBC. How would I "intelligently brute-force" this? Or will I have to decrypt essentially 4GB using multiple keys and look for english strings or common headers/signatures manually? Should I throw away the parts of the file that has stretches of >16 (or 100...) null characters? – mpag Jan 26 '17 at 19:22
  • 2
    Ask that at reverseengineering. Also note that binwalk sometimes produces false positives; if you don't have reason to assume that the contents of the SD card are encrypted (because of where it came from, which you didn't mention), this could be possibly one. The "NO NAME FAT32" bit is clearly not encrypted, and unless it's part of the mcrypt-header, I don't see how it fits. – dirkt Jan 27 '17 at 8:49

I'd try some tools like PhotoRec and Testdisk to try find files in the broken filesystem. I doubt anybody encrypting this would be using single byte password. Would ne funny. And as @dirkt said, you see plaintext in the middle anyway.

Check some article about using the tools: https://www.linux.com/learn/get-your-data-back-linux-based-data-recovery-tools

  • Do you think the OP waited this long? – Solar Mike Dec 29 '17 at 20:23
  • 2
    @SolarMike Future users with similar problem may appear. Any sane answer is for them. – Kamil Maciorowski Dec 29 '17 at 20:27
  • in my case, I concluded that it was a false-positive, and there wasn't any encrypted data. As I recall, there was plenty of other handy info in this (or another card's) binwalk/hexdump - an unencrypted Sqlite DB. Kamil is correct: someone else may find this help helpful, assuming it comes up in a search;) – mpag Dec 29 '17 at 21:15
  • I did not ask about future users... but that may be relevant for future users if sd cards stand the test of time... – Solar Mike Dec 29 '17 at 21:21
  • @SolarMike, it can be useful to anybody that wants to retrieve data from broken media. You inspired me to write a long answer (probably a pathetic one for that matter). If you like you can find it at: rboci.blogspot.bg/2017/12/why-am-i-necromancer.html – akostadinov Dec 30 '17 at 15:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.