2

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

Improve this question
3
  • 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
    Commented Jan 26, 2017 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
    Commented Jan 26, 2017 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
    Commented Jan 27, 2017 at 8:49

1 Answer 1

Reset to default
1

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

Improve this answer
6
  • Do you think the OP waited this long?
    – Solar Mike
    Commented Dec 29, 2017 at 20:23
  • 2
    @SolarMike Future users with similar problem may appear. Any sane answer is for them.
    – Kamil Maciorowski
    Commented Dec 29, 2017 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
    Commented Dec 29, 2017 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
    Commented Dec 29, 2017 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
    Commented Dec 30, 2017 at 15:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .