OK, the DMS brain trust is my last ditch effort before calling it quits.
I have been trying to help a lady retrieve photos from her MicroSD card that stopped working all of a sudden. It contains a bunch of pictures that were never backed up, etc. (yes, we’ve had that discussion already).
When it comes to disk drives, I’ve succesful 80% of the time in retrieving data, but I’ve never dealt with solid state retrievals before this.
The card isn’t seen or recognized by either my android or PC (sees the adapter, but prompts to insert disk when you click on it.
It does not show up in disk management nor is seen by any of my software tools.
From my research, it appears that I’m out of luck, as it is likely the controller on this tiny little thing. There are companies out there that say they can expose the board and controller on the MicroSD cards and attach filament wire where necessary and rebuild data from NAND flash, but I already know this lady wouldn’t be able to afford those services.
Yeek. I’ve actually written software to talk to raw NAND flash devices, but there are all sorts of ways to store bad-flash-block remap tables, etc. I’d write it off unless it had irreplaceable information (legacy photos, dissertation, etc.) on it.
If it still shows up on a Linux box, you might try PhotoRec.
I would check to see what is the true capacity of the drive. I got a counterfeit SD card off ebay. Was supposed to be 32Gb and was an 8Gb card that was configured to look like 32Gb. This is what happened . . .
My camera (gopro) worked well for a few hours of video on a long event. Then it failed. It appeared as though it was a camera failure. I tried to recover from the chip using several recovery programs that never pointed to the actual problem. I could only recover about 1% of what I had shot. Pity, it was an important event. I was about to send it somewhere and waste some money on recovery when I got a clue one week later to check it for actual capacity. Turns out that the memory was remapped over itself 4x to make 8G look like 32G and it would never be noticed until you exceeded the 8G memory boundary. After that, data space and directory space got over written and . . . crash.
Many users would never discover the problem as they would never exceed the 8G. Others would just think it was a device or chip failure or would probably forget where they got the chip.
Here is the key thing - it took a specific program to detect this. Not one of half a dozen recovery programs were designed to detect this scam. It was a free program from the internet but I don’t recall what it was. When I ran it, it instantly diagnosed the problem. May be worth it to investigate. Note, it was a fake ‘branded’ card like Sandisk.
You’re probably way passed this point, but I had to update a driver on my computer for the MicroSD card from my GoPro to be seen. Are you able to see any data with the card in the camera through USB? Does the GoPro recognize the card, or does the GoPro also say the card is not recognized?
@paulstaf & @zmetzing - I don’t have access to a Linux machine to determine if it can be seen in something other than my Windows machines or Android phone
@rice81 - It’s branded Samsung, and knowing this lady, I doubt she bought online or anywhere other than the AT&T store or another big box brick & mortar. I’ll Google around and see if I can locate the software you’re referring to - I’m curious if/how it will recognize a card exists in the reader when nothing else does.
@Timbo - It’s actually a card from an Android phone, not a GoPro. And neither her nor my phone sees the card when put in the device(s).
I may be able to help you work on it. When are you going to be in the space next? I am usually there on Thurs. evenings. If we can meet up, I can make a dd image of the card so that we can work on the image and not the card, otherwise you may end up trashing it beyond recovery by working on the card itself.
@paulstaf - thank you very much for the offer! I’ll definitely take the help.
I have no planned time at the space right now - I don’t want to dictate your schedule when you’re the one helping me - so I’ll do my best to accomodate when you can be there.
If you are handy with a computer, you could download Ubuntu Linux from the Internet, then burn it onto a bootable CD/DVD, then you could boot your computer off of that, and then you would have instant access to Linux without having to install linux or make any permanent changes to your computer.
Download 14.04 and pick the 32-bit version since it is compatible with all desktops/laptops…could be your first step to learning linux!
They call them “live” cds. If you could get a computer booted to that point, then I could either talk you through creating an image which you could then upload to me, or I could remote into the Linux session and create the image and upload it to myself so that I could work with it.
We could work on it over the phone if you can get to the booted linux stage. If you get to that point, email me at: [email protected] and we can setup a time to work on it.
When you say “see” you are speaking from the perspective of a normal file system that mounts up. Unfortunately, Windoze has removed all their command line utilities that would help you to troubleshoot an issue like this. Deep down, the sdcard IS being “seen” by Windoze, albeit only as raw system device and not a mountable file system. Windoze’s dumbed down interface then asks you if you want to format it, and would do so given the chance thus eliminating any chances of recovering the data.
Connecting the sdcard to a Linux OS would allow you to see that it is connected as a raw device, then using fdisk, display some information about the device, then using dd, a Linux program, you can make a bit by bit copy of that raw device to the hard drive as an image file. In Linux, everything is a file, so Linux doesn’t care if it is a device or an image file. Once we have the dd image file, we can then attempt to recreate the MBR or run other programs against the IMAGE file and not have to worry about dinking up the original sdcard. We can make several copies of the image file and then hack on each copy until we are successful or have exhausted all attempts at which point you can then send the original sdcard out for data recovery if it is that important.
In my tenure as a ‘desktop guy’ I have seen a lot of instances where the MBR gets corrupted or deleted altogether. I have been successful a few times at rebuilding the MBR and then being able to recover the data.
I don’t think so because VMs usually share mounted drives and not raw hardware. A bootable CD is much quicker and easier than a VM. The liveCDs boot to the OS and from there you go to a terminal window and run dd and then save the image to your Windoze hard drive.
I think this site has nailed the fight against fake flash memory. There is a program in the link in the home page for it.
BTW, re concern for not being able to mount the drive in the first place, I think it runs at a lower level. Don’t think this is the program I used a few years ago, but maybe better.
He has a good idea . . . don’t use any flash (in a serious app, that is) until you have checked it with this program. He also has a database to report counterfeit cards and where they are coming from.
FWIW, one can get to a command line from Windows, and one can write a utility that is just as powerful from the Windows command line as from the Linux command line.
The following statements need the disclaimer that I can’t remember names, and I’m guessing which program did what.
I’ve only used data recovery tools in Windows/DOS. The best I’ve used is MiniTool’s Power Data Recovery. It has a free component, but I paid for a registered version.
I also paid for a registered version of Magic Cute Data Recovery. It did not work as well as MiniTool did.
sudo fdisk -l (l as in list) and see if the sdcard shows up there
It will look similar to this, but may be different like: /dev/sdXX and different size.
Disk /dev/sdb: 4092 MB, 4092592128 bytes
126 heads, 62 sectors/track, 1023 cylinders, total 7993344 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Disk /dev/sdb doesn’t contain a valid partition table
You can plug and unplug the sdcard and run the command between plugs and see if the device comes and goes then you know you have the correct one.
If there isn’t a change then the card isn’t even being recognized at the hardware level.