Jump to content

USB stick no longer working - Lost partition with value data

davidoss
 Share

Recommended Posts

davidoss

davidoss

Posted
Posted

Hello everyone, this is my first post here but sadly this is also something I have become quite desperate with.

I'm using Windows 7 and was access a USB drive with a lot of important research documents (including my thesis which I have been working on all year), and the Windows Explorer decided to hang on me.

After closing the window, I am now unable to access my USB. Attempts at accessing my USB stick drive yield "You need to format the disk in drive J: before you can use it."

I did a lot of digging around and stumbled about Testdisk. I have come to the conclusion that this could potentially be the underlying issue preventing me from accessing the files I need ever so badly on my USB stick - "Partition sector doesn't have the endmark 0xAA55".

From further digging around here (http://www.msfn.org/board/topic/133933-usb-access-problem/), I'm guessing it basically means that there might be an error causing loss of the partition or an inability for Windows to boot the partition. I've tried multiple different Partition Recovery Programs (even loading via this Linux boot disc in order to use a linux based explorer to access my files) with no success.

Unfortunately, a lot of the links in that link I've listed above are also broken. I would be greatly indebted to anyone who'd be able to walk me through exactly what I need to do in order to get my USB working. It's at least an entire year's woth of hard work that is on it which I cannot afford to lose. :(

Please help!

Link to comment
Share on other sites

Kelsenellenelvian

Kelsenellenelvian

Posted
Posted

You most likely ended up with a USB drive that had a faked size marked in the partition table.

Did you buy a super cheap 32 or large-ish sized drive?

What happens is some people in asian countries remark drives with fake sized partitions (Say a 2 gig drive that now says it can hold 32 gigs) then when you put more that 2 gigs it wraps over and destroys the partition table info.

Link to comment
Share on other sites
jaclaz

jaclaz

Posted
Posted

Well, the first thing that you should do is to make a "dd-like" or "forensic sound" image of the physicaldrive.

You can use dd or ddrescue or dd_rescue in Linux or datarescue dd or dsfok under windows:

http://www.datarescue.com/photorescue/v3/drdd.htm

http://members.ozemail.com.au/~nulifetv/freezip/freeware/

to that effect.

Once you have an image, ideally you make a copy of this image and start working on this latter.

In any case, you can run again TESTDISK on the stick with the LOG option and post the log,

That should be enough to understand at least what might have happened (there are a number of issue that might have happened, including hardware failure :ph34r:).

No offence intended, but you seem like not very "exact" in your report, and a TESTDISK log may provide the information that you either missed or mis-represented, in addition I would like you to post some "descriptions", like what exact make/model the stick is, how exactly it was partitioned (IF partitioned) which filesystem(s) were used, which kind of files you had on it that you value (as an example even without managing to recover the actual volume structure it may be possible to recover some files through direct carving with PHOTOREC or similar), etc.

The more details you provide, the more likely it is that a suggestion would be appropriate.

jaclaz

Link to comment
Share on other sites
davidoss

davidoss

Posted
  • Author
Posted

Thank you for your reply. I have been trying to use dsfok to create an image but I've stumbeld into a roadblock early on. I understand I'm meant to use it by typing this "dsfo \\.\PHYSICALDRIVEn 0 0 C:\dsfok\USB_full.img"

Unfortunately, I do not know what physical drive number my dead USB is. Any thoughts on how I could find it out?

This is the exact stick that I was using: http://www.techbuy.com.au/p/213414/FLASH_USB_FLASH_32GB/Verbatim/49174.asp

I am reasonably sure that I had not partitioned it and that it came as a standard FAT32. The main files of value are Microsoft Office word documents.

I have attached a TESTDISK log below:

Mon Sep 16 19:15:09 2013
Command line: TestDisk

TestDisk 6.14, Data Recovery Utility, July 2013
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org
OS: Windows 7 (7601) SP1
Compiler: GCC 4.7, Cygwin 1007.17
Compilation date: 2013-07-30T14:08:52
ext2fs lib: 1.42.2, ntfs lib: 10:0:0, reiserfs lib: 0.3.1-rc8, ewf lib: 20120504
disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(/dev/sda)=500107862016
disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(/dev/sdb)=61918150656
disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(/dev/sdc)=3000590401536
disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(/dev/sdd)=1000204886016
disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(/dev/sde)=1500301910016
disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(/dev/sdf)=62898831360
disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(\\.\PhysicalDrive0)=500107862016
disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(\\.\PhysicalDrive1)=61918150656
disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(\\.\PhysicalDrive2)=3000590401536
disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(\\.\PhysicalDrive3)=1000204886016
disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(\\.\PhysicalDrive4)=1500301910016
disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(\\.\PhysicalDrive5)=62898831360
disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(\\.\C:)=125026959360
disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(\\.\D:)=359351189504
disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(\\.\E:)=1658486784
disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(\\.\F:)=3000589352960
filewin32_getfilesize(\\.\G:) GetFileSize err Incorrect function.

filewin32_setfilepointer(\\.\G:) SetFilePointer err Incorrect function.

Warning: can't get size for \\.\G:
disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(\\.\H:)=1500300861440
disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(\\.\I:)=1000202241024
disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(\\.\J:)=61918150656
disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(\\.\K:)=62894702592
Hard disk list
Disk /dev/sda - 500 GB / 465 GiB - CHS 60801 255 63, sector size=512 - ST950032 5AS, S/N:V56EQ0FQ, FW:0002
Disk /dev/sdb - 61 GB / 57 GiB - CHS 7527 255 63, sector size=512 - Verbatim STORE N GO, S/N:0C79077420C0, FW:PMAP
Disk /dev/sdc - 3000 GB / 2794 GiB - CHS 45600 255 63, sector size=4096 - WD Ext HDD 1021, S/N:WMC1T1299586, FW:2021
Disk /dev/sdd - 1000 GB / 931 GiB - CHS 121601 255 63, sector size=512 - WD 10EADS External, S/N:WD-WCAU48299686, FW:1.75
Disk /dev/sde - 1500 GB / 1397 GiB - CHS 182401 255 63, sector size=512 - WD 15EADS External, S/N:WD-WMAVU1693813, FW:1.75
Disk /dev/sdf - 62 GB / 58 GiB - CHS 7647 255 63, sector size=512 - Kingston DataTraveler 3.0, S/N:0B0D07F1E7A0, FW:PMAP
Disk \\.\PhysicalDrive2 - 3000 GB / 2794 GiB - CHS 45600 255 63, sector size=4096 - WD Ext HDD 1021, S/N:WMC1T1299586, FW:2021
Drive E: - 1658 MB / 1581 MiB - CHS 395 64 32, sector size=2048 - Optiarc DVD RW AD-7580S, S/N:TS49017460, FW:FX20
Drive F: - 3000 GB / 2794 GiB - CHS 45600 255 63, sector size=4096 - WD Ext HDD 1021, S/N:WMC1T1299586, FW:2021

Partition table type default to Intel
Disk /dev/sdb - 61 GB / 57 GiB - Verbatim STORE N GO
Partition table type: Intel

Analyse Disk /dev/sdb - 61 GB / 57 GiB - CHS 7527 255 63
Current partition structure:

Partition sector doesn't have the endmark 0xAA55

search_part()
Disk /dev/sdb - 61 GB / 57 GiB - CHS 7527 255 63
file_pread(5,2,buffer,120934400(7527/208/42)) lseek err Invalid argument
file_pread(5,1,buffer,120934400(7527/208/42)) lseek err Invalid argument
file_pread(5,1,buffer,120934399(7527/208/41)) lseek err Invalid argument
file_pread(5,14,buffer,120934401(7527/208/43)) lseek err Invalid argument
file_pread(5,3,buffer,120934415(7527/208/57)) lseek err Invalid argument
file_pread(5,3,buffer,120934462(7527/209/41)) lseek err Invalid argument
file_pread(5,8,buffer,120934478(7527/209/57)) lseek err Invalid argument
file_pread(5,11,buffer,120934525(7527/210/41)) lseek err Invalid argument
file_pread(5,2,buffer,120936447(7527/241/10)) lseek err Invalid argument

Results

interface_write()

No partition found or selected for recovery

search_part()
Disk /dev/sdb - 61 GB / 57 GiB - CHS 7527 255 63
file_pread(5,2,buffer,120934400(7527/208/42)) lseek err Invalid argument
file_pread(5,1,buffer,120934400(7527/208/42)) lseek err Invalid argument
file_pread(5,1,buffer,120934399(7527/208/41)) lseek err Invalid argument
file_pread(5,14,buffer,120934401(7527/208/43)) lseek err Invalid argument
file_pread(5,3,buffer,120934415(7527/208/57)) lseek err Invalid argument
file_pread(5,3,buffer,120934462(7527/209/41)) lseek err Invalid argument
file_pread(5,8,buffer,120934478(7527/209/57)) lseek err Invalid argument
file_pread(5,11,buffer,120934525(7527/210/41)) lseek err Invalid argument
file_pread(5,2,buffer,120936447(7527/241/10)) lseek err Invalid argument

Results

interface_write()

No partition found or selected for recovery

Link to comment
Share on other sites
jaclaz

jaclaz

Posted
Posted
disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(\\.\PhysicalDrive0)=500107862016

disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(\\.\PhysicalDrive1)=61918150656

disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(\\.\PhysicalDrive2)=3000590401536

disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(\\.\PhysicalDrive3)=1000204886016

disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(\\.\PhysicalDrive4)=1500301910016

disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(\\.\PhysicalDrive5)=62898831360

The only device with around 64 Gb size, are seemingly \\.\PhysicalDrive1)=61918150656 and \\.\PhysicalDrive5)=62898831360.

Idea :yes: :

  1. disconnect the stick.
  2. run TESTDISK again
  3. see which device is not anymore there in the log.

Or read the log:

Disk /dev/sdb - 61 GB / 57 GiB - CHS 7527 255 63, sector size=512 - Verbatim STORE N GO, S/N:0C79077420C0, FW:PMAP

...

Disk /dev/sdf - 62 GB / 58 GiB - CHS 7647 255 63, sector size=512 - Kingston DataTraveler 3.0, S/N:0B0D07F1E7A0, FW:PMAP

Since:

disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(/dev/sda)=500107862016

disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(/dev/sdb)=61918150656

disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(/dev/sdc)=3000590401536

disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(/dev/sdd)=1000204886016

disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(/dev/sde)=1500301910016

disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(/dev/sdf)=62898831360

disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(\\.\PhysicalDrive1)=61918150656=disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(/dev/sdb)=61918150656=Disk /dev/sdb - 61 GB / 57 GiB - CHS 7527 255 63, sector size=512 - Verbatim STORE N GO, S/N:0C79077420C0, FW:PMAP

jaclaz

Link to comment
Share on other sites
jaclaz

jaclaz

Posted
Posted

Since it is a non-partitioned image, i.e. what is commonly referred to as "superfloppy", most of TESTDISK capabilities may be ineffective (a large part of the TESTDISK scope is to re-build the MBR partition table).

But still some of the features may be of use.

Recover FAT32 boot sector from its backup
Rebuild FAT12/FAT16/FAT32 boot sector

Depending on how exactly (and under which OS) the original FAT32 formatting was performed, there may be a backup of the bootsector.

I.e. this:

http://www.cgsecurity.org/wiki/Data_Recovery_Examples#The_type_of_the_file_system_is_RAW_-_Recovery_of_a_damaged_FAT_boot_sector

may work for your case, or this:

http://www.cgsecurity.org/wiki/Data_Recovery_Examples#Two_FAT32_partitions_to_recover

Basically there are four sets of meaningful info in a "normal" FAT32 volume:

  1. the bootsector CODE (which has NO relevance whatsoever if not for booting)
  2. the bootsector DATA (including the BPB or Bios Parameter Block, a set of info about the volume and it's layout, of VITAL importance to find the FAT32 tables
  3. the FAT table(s) - normally in two copies, containing the address of each and every file saved in the filesystem
  4. the actual DATA (i.e. the files saved in the filesystem)

Of course you are interested in just #4, which IF the files were not fragmented can normally be recovered by "direct parsing" of the volume (please read as "using PHOTOREC").

Please understand that files recovered by PHOTOREC will "loose" their original filename.

The real problem comes if the files were fragmented, in this case a plain parser/carver cannot but get partial and often invalid data.

As said there is no interest in #1, but to get to #4 in the "normal" way, you need #3, and to get to #3 you need #2.

The good news are that if you find where exactly #3 is you can rebuild (using dome other info) #2, this is what TESTDISK may be able to do automatically (or that can be still done manually).

The idea is first thing to find out if there is enough useful information in the bootsector or if there is a backup copy of it, then to find out if the FAT tables are still valid (or at least one of the two copies is).

If you wish to have some "manual" help, make a small image with the first few sectors of the image you just made, something like:

dsfo C:\mynice.img 0 51200 C:\first100secs.img

(provided that the image you made is "C:\mynice.img" the above will produce a file "C:\first100secs.img" with the first 100 sectors, change paths/filenames according to your setup).

Then, compress the file in to a .zip and either attach it to your next post or upload it to any of the free file hosting site and post a link to it.

jaclaz

Link to comment
Share on other sites
davidoss

davidoss

Posted
  • Author
Posted

D:\dsfok>dsfo \\.\PHYSICALDRIVE1 0 0 f:\usb\USB_full.img
\\.\PHYSICALDRIVE1 - The request could not be performed because of an I/O device
error.
This error can probably be ignored.
OK, 99874111488 bytes, 8886.223s, MD5 = 1da3a922de229eaaf3b9df47b0965745

D:\dsfok>dsfo \\.\PHYSICALDRIVE1 0 0 f:\usb\USB_full.img

Link to comment
Share on other sites
jaclaz

jaclaz

Posted
Posted

BAD news. :(

The sectors you posted are just "hex gibberish".

This can usually depend on two things:

  1. actual hardware failure (a Pro may be able to do a chip-off, re-calculate ECC's and hopefully recover something)
  2. a size wrap-around (which is typical of the "fake sticks" Kelsenellenelvian hinted about)

It should be easy to understand which is which by running Photorec.

If it finds at least some files, it means that it is #2, if it doesn't find anything (or anything readable) it means it is #1.

There could also have been an issue in the making of the image, as DSFOK reported:

99,874,111,488 bytes

whilst the device "presents itself" as being 61,918,150,656

but that could be caused BOTH by a hardware error and by the wrap-around.

Try:

D:\dsfok>dsfo \\.\PHYSICALDRIVE1 0 512000 f:\usb\first100_2.img

If you get the same:

OK, 512000 bytes, 0.047s, MD5 = 4975500c699fb72300856b1a19972edd

the first100secs.img is an actual representation of the first 1000 sectors of the USB stick (thank you for the 900 more sectors you posted ;)).

However next step is trying Photorec:

http://www.cgsecurity.org/wiki/PhotoRec_Step_By_Step

jaclaz

Link to comment
Share on other sites
davidoss

davidoss

Posted
  • Author
Posted

Photorec is actually recovering quite a few files from the disk image!

D:\dsfok>dsfo \\.\PHYSICALDRIVE1 0 512000 f:\usb\first100_2.img
OK, 512000 bytes, 0.141s, MD5 = 4975500c699fb72300856b1a19972edd

I've uploaded the new file to: http://davidoss.net//first100_2.img

jaclaz, thank you so much for your help so far.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share
Go to topic listing

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...