Brent Saner on 25 Aug 2007 18:23:06 -0000


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] FS recovery tools?

  • From: "Brent Saner" <brent.saner@gmail.com>
  • To: "Philadelphia Linux User's Group Discussion List" <plug@lists.phillylinux.org>
  • Subject: Re: [PLUG] FS recovery tools?
  • Date: Sat, 25 Aug 2007 14:22:58 -0400
  • Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=oWq3mGHrsPYWxVKeOmq9ojoVmAecFY3P4FeE8sg8DQsr6jItbfGPgB/ZPVb5N+vtBiZni5IB7XjqOZFzud+rFqo8b4sHEVjdkaigwtn6YA+GXV623jOYmRVstQU1qfsp73q0iF7tTm6sY5BSWF4qXPlgkhCYSVaFE7f1S83qu9A=
  • Reply-to: Philadelphia Linux User's Group Discussion List <plug@lists.phillylinux.org>
  • Sender: plug-bounces@lists.phillylinux.org

check out PhotoRec and Testdisk (both are on knoppix). make sure you dd_recovery the drive to an image first before doing recovery

On 8/25/07, Greg Lopp <lopp@pobox.com> wrote:
A friend had a U3 thumbdrive go "bad" on him.  This badness manifested in different ways on different flavors of Windows and thinking that it might just be some simple partition table or fat corruption, I offered to take a look.  Knowing that it could also be completely toes up, I made no promises.

When I plug it in, it enumerates as expected, presenting itself as two devices, one writable, one not (as a CD ROM)(where it would keep its U3 autorun and apps).  This is followed by a message about an unrecognized partition table type.

When I use dd to repeatedly to read the device, I get the same values each time.
Looking at the contents with hexdump, I find a strange, repeating bit pattern, all over the place :
df f2 05 a6 74 c7 55 71  76 b1 2d 3f 59 f0 e1 7f
This fills spaces that I would suspect are otherwise unwritten to.  Normally, I would expect FF or 00 in those spaces, but I don't know NAND flash like I should.  Additionally, I don't know partition table formats/offsets like I should.

I've used the end of that bit pattern as an indicator of "interesting locations" on the data image and tried to "mount -o loop,offset=${offset} backupImage /mnt" at each location.  The kernel looks for ext2, vfat and iso9660 at each offset, but it never finds a recognizable file system.

"strings backupImage" does not reveal anything that looks like files or filenames. 

It appears I can still write to the device and read it back. 


Can anybody recommend other things to try or recovery packages to play with? 

___________________________________________________________________________
Philadelphia Linux Users Group         --         http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug




--
Brent Saner
215.264.0112(cell)
215.362.7696(residence)

http://www.thenotebookarmy.org
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug