Jump to content

Welcome to MSFN Forum
Register now to gain access to all of our features. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, post status updates, manage your profile and so much more. This message will be removed once you have signed in.
Login to Account Create an Account



Photo

USB stick no longer working - Lost partition with value data

- - - - -

  • Please log in to reply
15 replies to this topic

#1
davidoss

davidoss

    Newbie

  • Member
  • 10 posts
  • Joined 11-September 13
  • OS:Windows 7 x64
  • Country: Country Flag

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/...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!




How to remove advertisement from MSFN

#2
davidoss

davidoss

    Newbie

  • Member
  • 10 posts
  • Joined 11-September 13
  • OS:Windows 7 x64
  • Country: Country Flag

I have also tried running a deep analyse with TestDisk but it has not found any partitions.



#3
Kelsenellenelvian

Kelsenellenelvian

    WPI Guru

  • Developer
  • 8,688 posts
  • Joined 18-September 03
  • OS:Windows 7 x64
  • Country: Country Flag

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.



#4
davidoss

davidoss

    Newbie

  • Member
  • 10 posts
  • Joined 11-September 13
  • OS:Windows 7 x64
  • Country: Country Flag

I bought it from Australia, it's meant to be 60GB.



#5
davidoss

davidoss

    Newbie

  • Member
  • 10 posts
  • Joined 11-September 13
  • OS:Windows 7 x64
  • Country: Country Flag

It held around ~30GB before this happened.



#6
davidoss

davidoss

    Newbie

  • Member
  • 10 posts
  • Joined 11-September 13
  • OS:Windows 7 x64
  • Country: Country Flag
If someone would be kind enough to walk me through how I can go about recreating my partition table, that would be really, really appreciated!

#7
jaclaz

jaclaz

    The Finder

  • Developer
  • 15,176 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

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.datarescu...cue/v3/drdd.htm

http://members.ozema...eezip/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



#8
davidoss

davidoss

    Newbie

  • Member
  • 10 posts
  • Joined 11-September 13
  • OS:Windows 7 x64
  • Country: Country Flag

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.c...batim/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



#9
jaclaz

jaclaz

    The Finder

  • Developer
  • 15,176 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

 

 

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



#10
davidoss

davidoss

    Newbie

  • Member
  • 10 posts
  • Joined 11-September 13
  • OS:Windows 7 x64
  • Country: Country Flag

Thanks Jaclaz! I've now made an image of the disk.

 

How should I proceed from here?



#11
jaclaz

jaclaz

    The Finder

  • Developer
  • 15,176 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

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.cgsecurit...FAT_boot_sector

may work for your case, or this:

http://www.cgsecurit...ions_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



#12
davidoss

davidoss

    Newbie

  • Member
  • 10 posts
  • Joined 11-September 13
  • OS:Windows 7 x64
  • Country: Country Flag

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



#13
davidoss

davidoss

    Newbie

  • Member
  • 10 posts
  • Joined 11-September 13
  • OS:Windows 7 x64
  • Country: Country Flag

D:\dsfok>dsfo F:\usb\USB_full.img 0 512000 f:\usb\first100secs.img
OK, 512000 bytes, 0.047s, MD5 = 4975500c699fb72300856b1a19972edd

 

I've uploaded the first100secs here: http://davidoss.net//first100secs.img



#14
jaclaz

jaclaz

    The Finder

  • Developer
  • 15,176 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

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.cgsecurit...ec_Step_By_Step

 

jaclaz



#15
davidoss

davidoss

    Newbie

  • Member
  • 10 posts
  • Joined 11-September 13
  • OS:Windows 7 x64
  • Country: Country Flag

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.



#16
jaclaz

jaclaz

    The Finder

  • Developer
  • 15,176 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

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

Good :thumbup:, that is a sign that you have likely bought a "fake" USB stick (or anyway that a "wrap-around kind of issue happened because of some error of the controller/settings) and what you got is "just" the "wrap-around" issue.
The second image you posted is identical to first one, which confirms how the error you got initially with DSFO could be ignored, but also that filesystem oriented recovery is impossible on that stick.
Remember that Photorec cannot find the "original" filenames, and often it may mistake a file type for another (just as an example Office .xlsx and .docx files may be retrieved/recognized as .zip (mainly because they actually ARE ZIP files ;)).
It is recommended to "post-process" the results from PhotoRec:
http://www.cgsecurit..._Using_PhotoRec
http://builtbackward...hotorec-sorter/
to first group recovered files, then, if you have issues, you may want to use TriD on the files that have not been identified properly:
http://mark0.net/soft-trid-e.html


 

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

You are welcome, I am sure :).

Normally the last file(s) that you saved won't be recoverable, BUT if what happened is a "pure" wrap-around issue, you may want to try re-sequencing the image.
Translation/example:
Imagine that you have what the OS/filesystem thinks to be a (very, very small) 10 sector device:
0123456789
and you want to write on it the words hello and world, if the device actually has 10 sectors you would have something like:
0123456789
helloworld


BUT if it has, say, only seven sectors you would get something *like*:
0123456
rldlowo

 
By appending a second copy of the image, like:
01234560123456
rldloworldlowo


It is sometimes possible that also the "world" can be retrieved.
In your case, the "queer" fact is that the image is larger that the original device, so it is possible that this wrapping around happened at "controller" level and you are actually have already a re-sequenced image.

jaclaz




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users