# ntfs mount [mounted]

## idella4

Years ago I accidentally wiped an ntfs boot sector with a grub boot loader on a win XP.  I just tried hexedit to fix it.  Having a healthy XP, I tired copying the sector from the healthy to the broken. Thus fixed one thing and broke another.

Windows itself can't read the partition in this form.  Its PM reports the fs as raw.

parted in linux succeeds where windows' own PM fails, reporting the fs as ntfs.However, mounting it doesn't come off.  The linux ntfs profs at least output a clue as to the cause.  Widows' own chkdisk utility can't work on on it since it can't recognize an ntfs.  For that reason I suspect but haven't tried the windows recover console won't find a windows system to write a new sector to.

```

idella@genny ~/bin $ sudo fsck.ntfs /dev/sdd1

file record corrupted at offset 3221225472 (0xc0000000).

Loading $MFT runlist failed. Trying $MFTMirr.

file record corrupted at offset 5960892416 (0x[code]1634c0000[/code]).

Loading $MFTMirr runlist failed too. Aborting.

$MFT has invalid magic.

ntfs_mft_load(): Failed.

Failed to load $MFT: Input/output error.

Failed to startup volume: Input/output error.

```

Now the file offset marks above are the original partition's own file markers. 

```

C0000000   34 38 30 35  20 2E 65 76  65 6E 20 7B  77 69 64 74  4805 .even {widt

C0000010   68 3A 34 39  25 7D 0D 0A  23 63 61 74  5F 68 6C 5F  h:49%}..#cat_hl_

C0000020   34 38 31 30  20 68 31 7B  62 6F 72 64  65 72 2D 62  4810 h1{border-b

C0000030   6F 74 74 6F  6D 3A 6E 6F  6E 65 7D 0D  0A 23 63 61  ottom:none}..#ca

C0000040   74 5F 68 6C  5F 34 38 31  33 20 7B 62  61 63 6B 67  t_hl_4813 {backg

C0000050   72 6F 75 6E  64 2D 63 6F  6C 6F 72 3A  23 45 38 45  round-color:#E8E

```

The mark 1634c0000 reports empty of content.

Loading $MFT looks interesting.

 *Quote:*   

> 
> 
> 057D2E70   AC A2 F9 55  CB 9D 4B 59  18 26 DC 2B  11 BF FF FF  ...U..KY.&.+....
> 
> 057D2E80   F4 6B 80 0C  40 22 22 10  BD F2 A7 D4  54 10 60 29  .k..@"".....T.`)
> ...

 

 *Quote:*   

> 
> 
> 05EC4D00   74 00 00 00  24 42 69 74  6D 61 70 00  24 41 74 74  t...$Bitmap.$Att
> 
> 05EC4D10   72 44 65 66  00 00 00 00  24 56 6F 6C  75 6D 65 00  rDef....$Volume.
> ...

 

??  Is this metadata?

The sector drive data copied was the first 564 or so bytes, just enough to capture what appeared to be the end of the boot sector info.  

Perhaps I didn't  copy enough, more likely that original sector contained some file markers citing the above points.

I took an image of it, re-formatted the partition in ntfs, then wrote it back to the partition, but ofcourse it carried the file info fault with it.

Any  chance of re-connecting these?

Hmmm, the win XP cd is not working which is what happened when this occurred.   On boot, the cd puts to the screen windows is examining your hard drive, then

the screen blanks to dark and the cpu is flatout.   No wonder linux outperforms windows.  In unplugged three drives leaving it only 2 ides and it did that.

The win XP recovery console can scan for windows systems and offer to rewrite a boot sector with FIXBOOT.

What it can't do is boot up.  sheeeesh

----------

## ShadowCat8

Well, 

I tend to "go to the source" when having an architectural issue like this one.  And, in your case, where the source is all but completely useless, then follow their paradigm.  They can't fix the drive, so go to a 3rd-party app in that architecture that can, like PartitionMagic.  PartitionMagic *should* be able to recover and fix the drive's boot sector without toasting the data.  Or, of course if you aren't concerned about the data on the drive, go to their most basic paradigm, "If it's got a problem, reinstall!"   :Razz: 

And if you are really trying to save the data, copy it off while it's mounted inside of the linux architecture and then start working on the drive with PartitionMagic.  Like my first computer teacher told us on the first day of class, "The three most important words in computing are... backup, Backup and BACKUP!!!"

HTH.

----------

## ShadowCat8

Another thought occurred to me:

Have you tried seeing how Hiren's Mini-XP from the Boot CD sees the drive?  If you use Hiren's CD, you will likely find a number of utilities that should be able to help you with your drive.

HTH.  Let us know.

----------

## idella4

ok,

I have made a copy in gentoo using dd.  I have already re-fromatted the partition and written the content back to it, but it carries the flaw.

This can be fixed with just a few keystroks in hexedit.  Need to know what you are doing.

Unfortunately this is an exercise in windows setup.  Just that I can execute it in gentoo or any linux with hexedit.

In the root of the windows root are the two files MTP & MTPMirr.  I have found they are the key to its setup.

I'm back in windows and I happen to have a few freeware utilities from years back that still work.  However they mostly have the essential save capacity cut off in the demo version.  However, the reading ofthe partition content is done via these files $MTP $MTPMirr.  Having copied the sector it is likely looking for the files that are located in the other windows.

MTP are to do with tables and I think are a direct map to the ntfs metadata file structure.

I need to correct the bootsector info to point to the correct MTP files in its own root directory, easy in hexedit, if you know what to edit, but am suspecting more & more it's too deep.

----------

## NeddySeagoon

idella4,

Are we talking the Master Boot Record at sector 0 or the Volume Boot Record, which is near the start of the partition ?

----------

## idella4

Neddy, 

welcome again. 

 *NeddySeagoon wrote:*   

> idella4,
> 
> Are we talking the Master Boot Record at sector 0 or the Volume Boot Record, which is near the start of the partition ?

 

 The Volume Boot Record, which is near the start of the partition is the one.

We have

```

idella@genny ~/bin $ sudo mount -t ntfs /dev/sdc1 /mnt/windata

mount: wrong fs type, bad option, bad superblock on /dev/sdc1,

       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try

       dmesg | tail  or so

idella@genny ~/bin $ sudo tail -20 /var/log/messages

Nov 16 21:05:59 genny sudo:   idella : TTY=pts/2 ; PWD=/home/idella/bin ; USER=root ; COMMAND=/bin/tail /var/log/dmesg

Nov 16 21:05:59 genny sudo: pam_unix(sudo:session): session opened for user root by idella(uid=0)

Nov 16 21:06:00 genny init: Id "h0" respawning too fast: disabled for 5 minutes

Nov 16 21:06:00 genny init: Id "s1" respawning too fast: disabled for 5 minutes

Nov 16 21:06:18 genny sudo:   idella : TTY=pts/2 ; PWD=/home/idella/bin ; USER=root ; COMMAND=/bin/tail /var/log/messages

Nov 16 21:06:18 genny sudo: pam_unix(sudo:session): session opened for user root by idella(uid=0)

Nov 16 21:06:42 genny sudo:   idella : TTY=pts/2 ; PWD=/home/idella/bin ; USER=root ; COMMAND=/bin/tail -20 /var/log/messages

Nov 16 21:06:42 genny sudo: pam_unix(sudo:session): session opened for user root by idella(uid=0)

Nov 16 21:07:30 genny sudo:   idella : TTY=pts/2 ; PWD=/home/idella/bin ; USER=root ; COMMAND=/sbin/fsck /dev/sdc1

Nov 16 21:07:30 genny sudo: pam_unix(sudo:session): session opened for user root by idella(uid=0)

Nov 16 21:07:39 genny sudo:   idella : TTY=pts/2 ; PWD=/home/idella/bin ; USER=root ; COMMAND=/sbin/fsck.ntfs /dev/sdc1

Nov 16 21:07:39 genny sudo: pam_unix(sudo:session): session opened for user root by idella(uid=0)

Nov 16 21:09:21 genny sudo:   idella : TTY=pts/2 ; PWD=/home/idella/bin ; USER=root ; COMMAND=/bin/mount -t ntfs /dev/sdc1 /mnt/windata

Nov 16 21:09:21 genny sudo: pam_unix(sudo:session): session opened for user root by idella(uid=0)

Nov 16 21:09:21 genny kernel: [  724.658243] NTFS-fs error (device sdc1): ntfs_attr_find(): Inode is corrupt.  Run chkdsk.

Nov 16 21:09:21 genny kernel: [  724.658249] NTFS-fs error (device sdc1): ntfs_read_inode_mount(): Failed to lookup attribute list attribute. You should run chkdsk.

Nov 16 21:09:21 genny kernel: [  724.658253] NTFS-fs error (device sdc1): ntfs_read_inode_mount(): Failed. Marking inode as bad.

Nov 16 21:09:21 genny kernel: [  724.658258] NTFS-fs error (device sdc1): ntfs_fill_super(): Failed to load essential metadata.

Nov 16 21:09:29 genny sudo:   idella : TTY=pts/2 ; PWD=/home/idella/bin ; USER=root ; COMMAND=/bin/tail -20 /var/log/messages

Nov 16 21:09:29 genny sudo: pam_unix(sudo:session): session opened for user root by idella(uid=0)

idella@genny ~/bin $ sudo fsck.ntfs /dev/sdc1

file record corrupted at offset 3221225472 (0xc0000000).

Loading $MFT runlist failed. Trying $MFTMirr.

file record corrupted at offset 5960892416 (0x1634c0000).

Loading $MFTMirr runlist failed too. Aborting.

$MFT has invalid magic.

ntfs_mft_load(): Failed.

Failed to load $MFT: Input/output error.

Failed to startup volume: Input/output error.

```

ntfs_fill_super(): Failed to load essential metadata

Now unlike the linux metadata, this ntfs is out in the open.  It is a matter of giving the correct metadata files to read, via giving it the correct drive location data.

At this point I suspect it may be reading the metadata files in /dev/sde3 because the data in the sector contains location data of sde3.

The instructions are in the relevant pdf , edition 14, page 1368.  This is a matter of getting onto how to use hexedit to enter new settings, a new task but easy.

ok, I have deciphered that a hex location point is one thing, the data it contains is another.  What I was doing was looking for the cited hex code entry by search.

So, lesson 1, in hexedit, in the hex column, press return and enter a hex location to go to, it takes you to a byte.  On arriving at that location, hexedit displays the data entered at that point.  So example 1.  Location 3E marks the signature bytes.  

 *Quote:*   

> 
> 
> 000001F0   00 00 00 00  00 00 00 00  83 A0 B3 C9  00 00 55 AA  ..............U.
> 
> 

 

The entries are highlighted.  

The pdf cites a disk parameter block and the volume boot code.  All the above appears to capture the latter, but it appears it's the former I need, and my perusing can't find it outlined like the VBR.

ok, at this point, the content of the cited table appears ok, which is a kinD of setback. 

The above error code cites the MPT as being involved.  What is dictating the flaw is that when selecting the entry in grub that selects this old Win, it reads the boot program on the partition and takes you to the screen listing the two systems, so the boot program is working, but it seems to load the boot.ini in /dev/sde3, so it seems to be loading a boot program that thinks it lives in /dev/sde3,  so selecting the 2nd entry of win XP, it fails to load, just as gentoo can;t mount it.  A matter of tying this to the partition content pointing to and loading the $MPT files in the old XP.

I might be relying on you to point me in the relevant area of the pdf.  Need to find how these metadata files are pointed to in the volume booting sector, or thereabouts.  Got to recognize at this point it's only worth so much effort, need to evaluate that, then maybe abandon.

 *NeddySeagoon wrote:*   

> 
> 
> Yes, hexedit can follow files but as you say it needs to use the filesystem driver to do so. 
> 
> 

 

Can we try this in hexedit?  The ntfs drivers are there.

----------

## s4e8

NTFS has a backup boot sector at the end of partition.

----------

## idella4

s4e8l 

 aha.  Your help came unexpectedly.

Just to complicate things, I've lost the correct partition boundary, well maybe.

I took a backup of the mbr and partition table before adjusting it, then on writing it back, I got a scrambled reading of the thing by parted and fdisk.

Very puzzling, don't want the added task of fixing an mbr record.  

I've got one more backup of it mind you.  Currently I have remade the partition with the correct starting point but an end point slightly beyond its real end point.

As Neddy asked about, is it an mbr boot record a the volume boot record?

Can I find it with a search in hexedit?

----------

## s4e8

You can search it using "A disk read error occurred", "NTLDR is missing", "NTLDR is compressed".....

----------

## idella4

thanks, I just got my partition table back. 

```

966D7A00   EB 52 90 4E  54 46 53 20  20 20 20 00  02 08 00 00  .R.NTFS    .....

966D7A10   00 00 00 00  00 F8 00 00  3F 00 FF 00  3F 00 00 00  ........?...?...

966D7A20   00 00 00 00  80 00 80 00  BD 36 CB 00  00 00 00 00  .........6......

966D7A30   04 00 00 00  00 00 00 00  6B B3 0C 00  00 00 00 00  ........k.......

966D7A40   F6 00 00 00  01 00 00 00  B6 00 6E 38  17 6E 38 CC  ..........n8.n8.

966D7A50   00 00 00 00  FA 33 C0 8E  D0 BC 00 7C  FB B8 C0 07  .....3.....|....

966D7A60   8E D8 E8 16  00 B8 00 0D  8E C0 33 DB  C6 06 0E 00  ..........3.....

966D7A70   10 E8 53 00  68 00 0D 68  6A 02 CB 8A  16 24 00 B4  ..S.h..hj....$..

966D7A80   08 CD 13 73  05 B9 FF FF  8A F1 66 0F  B6 C6 40 66  ...s......f...@f

966D7A90   0F B6 D1 80  E2 3F F7 E2  86 CD C0 ED  06 41 66 0F  .....?.......Af.

966D7AA0   B7 C9 66 F7  E1 66 A3 20  00 C3 B4 41  BB AA 55 8A  ..f..f. ...A..U.

966D7AB0   16 24 00 CD  13 72 0F 81  FB 55 AA 75  09 F6 C1 01  .$...r...U.u....

966D7AC0   74 04 FE 06  14 00 C3 66  60 1E 06 66  A1 10 00 66  t......f`..f...f

966D7AD0   03 06 1C 00  66 3B 06 20  00 0F 82 3A  00 1E 66 6A  ....f;. ...:..fj

966D7AE0   00 66 50 06  53 66 68 10  00 01 00 80  3E 14 00 00  .fP.Sfh.....>...

966D7AF0   0F 85 0C 00  E8 B3 FF 80  3E 14 00 00  0F 84 61 00  ........>.....a.

966D7B00   B4 42 8A 16  24 00 16 1F  8B F4 CD 13  66 58 5B 07  .B..$.......fX[.

966D7B10   66 58 66 58  1F EB 2D 66  33 D2 66 0F  B7 0E 18 00  fXfX..-f3.f.....

966D7B20   66 F7 F1 FE  C2 8A CA 66  8B D0 66 C1  EA 10 F7 36  f......f..f....6

966D7B30   1A 00 86 D6  8A 16 24 00  8A E8 C0 E4  06 0A CC B8  ......$.........

966D7B40   01 02 CD 13  0F 82 19 00  8C C0 05 20  00 8E C0 66  ........... ...f

966D7B50   FF 06 10 00  FF 0E 0E 00  0F 85 6F FF  07 1F 66 61  ..........o...fa

966D7B60   C3 A0 F8 01  E8 09 00 A0  FB 01 E8 03  00 FB EB FE  ................

966D7B70   B4 01 8B F0  AC 3C 00 74  09 B4 0E BB  07 00 CD 10  .....<.t........

966D7B80   EB F2 C3 0D  0A 41 20 64  69 73 6B 20  72 65 61 64  .....A disk read

966D7B90   20 65 72 72  6F 72 20 6F  63 63 75 72  72 65 64 00   error occurred.

966D7BA0   0D 0A 4E 54  4C 44 52 20  69 73 20 6D  69 73 73 69  ..NTLDR is missi

966D7BB0   6E 67 00 0D  0A 4E 54 4C  44 52 20 69  73 20 63 6F  ng...NTLDR is co

966D7BC0   6D 70 72 65  73 73 65 64  00 0D 0A 50  72 65 73 73  mpressed...Press

966D7BD0   20 43 74 72  6C 2B 41 6C  74 2B 44 65  6C 20 74 6F   Ctrl+Alt+Del to

966D7BE0   20 72 65 73  74 61 72 74  0D 0A 00 00  00 00 00 00   restart........

966D7BF0   00 00 00 00  00 00 00 00  83 A0 B3 C9  00 00 55 AA  ..............U.

966D7C00

---  sdc1       --0x1966D7C00/0x1966D7C00--------------------------------------

```

Oh my,

```

idella@genny ~ $ sudo mount /dev/sdc1 /mnt/tmp

idella@genny ~ $ sudo ls /mnt/tmp/  

AUTOEXEC.BAT            LogiSetup.log              arcldr.exe     compressedvideo.txt

AUTOEXEC.CMI            MSDOS.SYS                  arcsetup.PIF   cygwin

AUTORUN.INF             NTDETECT.COM               arcsetup.exe   ezsetuplog.txt

BOOTWIZ                 NVIDIA                     boot.ini       fdconfig.old

BcBtRmv.log             PCIAUD                     boot.ini2.txt  logit.log

CONFIG.SYS              Program Files              boot.txt       logo.miff

Config.Msi              Programs                   boot_1.ini     ntldr

CtDrvIns.log            RECYCLER                   boot_2.ini     pagefile.sys

CtDrvStp.log            SahAgent.log               boot_3.ini     setupSNK.exe

Documents and Settings  System Volume Information  boottt.ini     tkcon.hst

FAVORITE.HTM            TEMP                       cmdcons        vetsetuplog.txt

IO.SYS                  WINDOWS                    cmldr          ~QTWTMP.TMP

Inetpub                 WIN_NT                     common

```

Neddy you've been bypassed!!!!!!!  Now to see if it will boot.  The booting was going to the new XP in both entries.  Just found the copied entry I made carried with it the partition id of the new XP. so it hasn't been pointed to the old one yet.     Anyway. this is a win.

s4e8, well done, right on the mark.

EDIT:  I did adjust the boot.ini to point to the right place in windows code.  It started to boot via safe mode and pulled up after about 2 dozen files.

In gentoo you can analyse & fix it.  In XP, you are defeated.  Never mind.  The mini goal was achieved in rectifying the boot sector.

----------

## NeddySeagoon

idella4,

 *Quote:*   

> Neddy you've been bypassed!!!!!!! 

  hehe ... I have to sleep sometime.

Even if it won't boot, you can recover you data now it mounts.

----------

## funkoolow

hi, i got the exact problem with my usb drive.

i dd'ed an image in tmp/usb2.img, then with losetuped at /dev/loop2 but that same error comes out. how did you solved that precisely?

 *Quote:*   

> 
> 
> # dd if=/dev/sda of=/tmp/usb2.img bs=512
> 
> # losetup /dev/loop2 /tmp/usb2.img
> ...

 

note that while fscking the cpu jumps to 99% activity and it's still there since a couple of days (i suppose it's not working that well..)

the image is about 8gb and i'm just interested in recovering files.

thanks everyone in advance

----------

## NeddySeagoon

funkoolow,

Exactly how did your problem occur?

You have similar symptoms to idella4 but you may have a different cause.

Your error suggests that your Master File Table is corrupt.  Thats a very bad thing.

Small files are stored in the MFT. For larger files the file location is stored there.

----------

## funkoolow

i have no precise idea about what caused that, probably an uncorrect unmounting or usb plug failure but cannot assure since it's a pendrive of a friend who need to recover files

----------

## NeddySeagoon

funkoolow,

NTFS on a pen drive is very unusual.  Are you sure its really NTFS ?

----------

## funkoolow

hm, maybe not, how to verify that? here's the fdisk output

```
# fdisk -l /dev/loop2

Disk /dev/loop2: 7903 MB, 7903117312 bytes, 15435776 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

Identificativo disco: 0x420a0d00

Questa non sembra una tabella delle partizioni.

Probabilmente è stato scelto il dispositivo sbagliato.

 Dispositivo Boot      Start         End      Blocks   Id  System

/dev/loop2p1   ?  1936028272  2154160610   109066169+  20  Sconosciuto

/dev/loop2p2   ?  1094921044  2976083617   940581287   4c  Sconosciuto

/dev/loop2p3   ?  1701994857  2238868341   268436742+  69  Sconosciuto

/dev/loop2p4   ?  2794192906  2794245570       26332+  61   SpeedStor

Le voci nella tabella delle partizioni non sono nello stesso ordine del disco
```

Swapped quote tags for code tags to make for easy reading - NeddySeagoon

----------

## NeddySeagoon

funkoolow,

Thats scary ...  from http://www.win.tue.nl/~aeb/partitions/partition_types-1.html

```
20 Unused

    Rumoured to be used by Willowsoft Overture File System (OFS1), if there is such a thing

4c Oberon partition

    See http://www-old.oberon.ethz.ch/betadocu.html and http://www.ocp.inf.ethz.ch/wiki/Documentation/Front. This partition type (decimal 76) is used for the Aos (now A2) filesystem. Type 4f is used for the Nat filesystem. One may have several partitions of this type.

69 Novell Netware 5+, Novell Netware NSS Partition

    According to disk.c in the Netware source. NSS = Novell Storage Services.

61 SpeedStor

    Storage Dimensions SpeedStor Volume. This is a Non-Standard DOS Volume. (Disk Manager type utility software)
```

Looking at your Start and End block numbers, your first three partitions appear to have a lot of block in common.

I would go with fdisk when it says  *fdisk wrote:*   

> Questa non sembra una tabella delle partizioni.
> 
> Probabilmente è stato scelto il dispositivo sbagliato. 

 

It may not be the wrong device but it may be the wrong place on the right device. 

Its very rare for USB sticks to contain more that one partition if they are used with Windows.  They may not contain any partitions at all. Instead they behave like a huge floppy drive.

What happens id you try to mount /dev/loop2 ... read only, so nothing nasty happens.

----------

## funkoolow

```
# mount -o ro /dev/loop2 /mnt/usb2

ntfs_mst_post_read_fixup_warn: magic: 0xd918c029  size: 1024   usa_ofs: 32833  usa_count: 25425: Argomento non valido

Record 0 has no FILE magic (0xd918c029)

Failed to load $MFT: Errore di input/output

Failed to mount '/dev/loop2': Errore di input/output

NTFS is either inconsistent, or there is a hardware fault, or it's a

SoftRAID/FakeRAID hardware. In the first case run chkdsk /f on Windows

then reboot into Windows twice. The usage of the /f parameter is very

important! If the device is a SoftRAID/FakeRAID then first activate

it and mount a different device under the /dev/mapper/ directory, (e.g.

/dev/mapper/nvidia_eahaabcc1). Please see the 'dmraid' documentation

for more details.
```

maybe this image is quite messed up for my initial ntfsck. Since I originally kept the initial dd file (in /tmp/usb.img) then created a copy for my first tryouts, maybe you know a better way to proceed to solve the matter restarting from there? thanks in any case for your precious time.

----------

## NeddySeagoon

funkoolow,

Make a dd image of the first 8Mb of your file and email me the 8Mb as an attachment.

By poking about with hexedit, I may learn a bit more about what you have there, but I need the start of the binary.

A link to a binary file on the web also works.

----------

## funkoolow

dear NeddySeagoon,

here it is, made with dd if=/tmp/usb.img | split -b 8m - /tmp/ , being /tmp/usb.img the original dump

https://dl.dropbox.com/u/4137342/aa.img

thanks for any further possible help

----------

## NeddySeagoon

funkoolow,

The first 4MB are filled with 00, thats a bad sign.  All file systems that I know if keep their metadata there. The data that is present, in the 4Mb fragment I have, appears to be PDF files.

Even the MSDOS partition table and boot sector is filled with zeros.  Thats very rare, even for a non bootable volume, which should contain an error message there.

There is nothing that looks like a directory.

Looking at the raw file system, I cannot tell what was really free space and what was useful data.

I did not see any indication of a particular file system type but that does not mean its not there.

I'm sure that there are scanning programs that attempt to detect file boundaries by a sequence of zero bytes at the end of a disk block, this is the wasted space at the end of the last block of a file.  They are only useful for data recovery if the file is stored as a single fragment and you can't tell that until you do the recovery.

You need some file fragments to search on.  It helps to know what the data was that you are trying to recover.

If you have a time to spare, you might want to try sleuthkit (on your complete .img) as its a disc forensics tool.

----------

## funkoolow

thank you very much for your precious suggestion, i'm already emerging that tool to give it a look  :Smile: 

Since I really never operated so deep on this kind of stuff, can you please tell me what other tools you used to read that 8mb file? (just) hexdump?

thanks again for you time

----------

## NeddySeagoon

funkoolow,

If its FAT32, a search for .. followed by six spaces should find the second entry in any directories you have. Thats 

```
'..    '
```

if you want to copy and paste between the quotes.

The directory entries will give file names and start cluster numbers.

You may not have any subdirectories, so no hits tells nothing.

Doing the arithmetic for an 8G filesystem shows that both copies of the FAT occupy less than 1Mb combined, so they are both gone, along with the root directory ... if it is a FAT32 volume.

----------

## funkoolow

hi again,

i've solved my issue using the great photorec tool (part of the testdisk ebuild) directly on the dd'ed image, recovering about 5,6gb of files.

thanks anyway for all your extremely precious and kind support  :Smile: 

----------

## NeddySeagoon

funkoolow,

Well done - you got the data back.

Now it needs to be checked as photorec has to make the same guesses as I explained above.

----------

## funkoolow

I tried to give a look at the 8mb file:

```
 # hexdump -C aa.img | grep "..      "

0048a060  6f 62 6a 0d 20 20 20 20  20 20 20 20 20 20 20 20  |obj.            |

0048a2a0  30 0d 0a 25 25 45 4f 46  0d 0a 20 20 20 20 20 20  |0..%%EOF..      |

0050c060  65 6e 64 6f 62 6a 0d 20  20 20 20 20 20 20 20 20  |endobj.         |

0050c440  20 20 20 20 20 20 0d 0a  35 30 34 20 30 20 6f 62  |      ..504 0 ob|

007e5e60  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |                |

007e5eb0  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 0a  |               .|

007e5ec0  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |                |

007e5f20  20 20 20 20 0a 20 20 20  20 20 20 20 20 20 20 20  |    .           |

007e5f30  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |                |

007e5f80  20 20 20 20 20 20 20 20  20 0a 20 20 20 20 20 20  |         .      |

007e5f90  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |                |

007e5fe0  20 20 20 20 20 20 20 20  20 20 20 20 20 20 0a 20  |              . |

007e5ff0  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |                |

007e6050  20 20 20 0a 20 20 20 20  20 20 20 20 20 20 20 20  |   .            |

007e6060  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |                |

007e60b0  20 20 20 20 20 20 20 20  0a 20 20 20 20 20 20 20  |        .       |

007e60c0  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |                |

007e6110  20 20 20 20 20 20 20 20  20 20 20 20 20 0a 20 20  |             .  |

007e6120  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |                |

007e6180  20 20 0a 20 20 20 20 20  20 20 20 20 20 20 20 20  |  .             |

007e6190  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |                |

007e61e0  20 20 20 20 20 20 20 0a  20 20 20 20 20 20 20 20  |       .        |

007e61f0  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |                |

007e6240  20 20 20 20 20 20 20 20  20 20 20 20 0a 20 20 20  |            .   |

007e6250  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |                |

007e62b0  20 0a 20 20 20 20 20 20  20 20 20 20 20 20 20 20  | .              |

007e62c0  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |                |

007e6310  20 20 20 20 20 20 0a 20  20 20 20 20 20 20 20 20  |      .         |

007e6320  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |                |

007e6370  20 20 20 20 20 20 20 20  20 20 20 0a 20 20 20 20  |           .    |

007e6380  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |                |

007e63e0  0a 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |.               |

007e63f0  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |                |

007e6440  20 20 20 20 20 0a 20 20  20 20 20 20 20 20 20 20  |     .          |

007e6450  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |                |

007e64a0  20 20 20 20 20 20 20 20  20 20 0a 20 20 20 20 20  |          .     |

007e64b0  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |                |

007e6500  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 0a  |               .|

007e6510  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |                |

007e6570  20 20 20 20 0a 20 20 20  20 20 20 20 20 20 20 20  |    .           |

007e6580  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |                |

007e65d0  20 20 20 20 20 20 20 20  20 0a 20 20 20 20 20 20  |         .      |

007e65e0  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |                |

007e6630  20 20 20 20 20 20 20 20  20 20 20 20 20 20 0a 20  |              . |

007e6640  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |                |

007e6650  20 20 20 20 20 20 20 20  20 20 0a 3c 3f 78 70 61  |          .<?xpa|

007e9070  3e 20 0d 65 6e 64 6f 62  6a 0d 20 20 20 20 20 20  |> .endobj.      |

007e9080  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |                |

007e90a0  20 20 20 20 20 20 20 20  20 20 20 20 20 78 72 65  |             xre|

```

if i'm right in interpreting your request, it seems the image WAS a FAT32 partition (as in the second line we have the "EOF..      " string), but since I'm a total noob in stuff like this I can't tell more... Reason for which i also tried the simpler photorec  :Embarassed: 

Is my way of proceeding correct?

----------

## NeddySeagoon

funkoolow,

grep has not done what you think it has.

Run 

```
hexedit <yourfile>.img
```

Press the tab key to switch to ASCII mode in hexedit.

Press Ctrl-S and hexedit should ask for a ASCII search string.

Enter "..      " without the quotes and hexedit will find the first pattern like that.

If its in the middle of a lot of unreadable stuff, its a false positive.

Press Ctrl-S followed by return to find the next occurance.

You should eventually see something that looks like a block of filenames.

FAT32 directory entries are a mess due to growing like topsy over the years.

Each entry is in two parts. The old original DOS 8.3 names and long file names.

Lets stick with the old names for now - its easier.

A Directory entry holds the 8 character name and the 3 character extension.  The dot separator is not stored, so names are 11 sequential characters.

You would get less false positives in you added 3 more spaces to your search string.  

There is some good reading but it will make your head hurt. Thats for FAT16, which is easier to understand. There are links on that page for FAT32 too.

----------

