Go Kart Stores Louisiana

Filenames after formatting ... why? The mystery of

If you format a disk or a USB device, for example

NTFS, is formatted with the slow and fast, is recreated

MFT (Master File Table), right? files are not deleted, they disappear from view, just because there is no longer an index, a
MFT, which tells the file system where they are and what are their names, ergo we use

carving, (a technique that does not take account of the file system), to recover lost ... what a pity that the names and metadata (date and time, and cc .)... right?

There is no way to recover the file names, because there is more MFT that saves you, it has been overwritten by the new MFT and MFT all are allocated at the beginning of the disc. But how does

Recuva or R-Studio
to retrieve the file names, time and date?? I tried it on a memory stick formatted 2 times, a fast and a slow and even then formatted for Linux and anyway I can recover some files by name:

I tried R-Studio and he succeeds ... but I noticed that recovers some of the MFT metafile type
$ MFTMirr

,

$ MFTReconstructed
,

$ AttrDef ,

$ Bitmap, $ upcase

, $

MFT
,

$ Logfile, $ Boot who are not "0". So the explanation is that somehow these metafiles have not been overwritten with new ones when the new file system is formatted NTFS ... but it's weird! Then I tried to "dig " to better understand and here's what I got: strings-td-el-a / dev / sdb

(revenue strings contained in the device)
...

... Dl3.jpg
42281714 42282738 42282858 Dl4.jpg

15062008013.jpg
2.JPGjpg0

~ 42,283,762 190,820 42,283,882 42,284,786 190,820 19082008023.jpg ~ 3.JPGjpg0 19082008024.jpg
42284906 42285810 42285930 NANNI ~ 1.JPGa640
nanniricciola640. jpg 42286834 NANNIL ~ 1.JPGjpg0
42286954
nannileccia.jpg
...
etc.

I look with the hex editor the byte offset 42286954

corresponding to that referred to the string:
nannileccia.jpg






xxd-s 42286954-l 512 / dev / sdb
2853f6a : 6e00 6100 6e00 6e00 6900 6c00 6500 6300 nannilec 2853f7a: 6300 6900 6100 7000 6700 2e00 6a00 8000 .. cia .. jpg 2853f8a: 0000 4800 0000 0100 0000 0000 0400 0000 ............ .. H. 2853f9a: 9F01 0000 0000 0000 0000 0000 0000 4000 ..............@.

2853faa: 0000 0000 0000 0040 0300 0000 0000 8e3f .......@.......?
2853fba: 0300 0000 0000 0300 0000 0000 8e3f 22a0 .......?......". 2853fca: 0165 2800 0100 8279 4711 0000 ffff ffff .......... and (........ yG ... 2853fda: 0000 0000 0000 0000 0000 0000 0000 0000 .... ............
2853fea: 0000 0000 0000 0000 0000 0000 0000 0000 ................

2853ffa: 0b00 0000 0000 0000 0000 0000 0000 0000 ................
285400th: 0000 0000 0000 0000 0000 0000 0000 0000 ................
if I try to look for matches an i-node
(idiot proof I know! but since we
)



(42286954-0) / 512 = 82,591
(since the partition starts at sector 0 and the cluster size is 512 bytes)




ifind-f ntfs-o 0-s 82591 / dev / sdb Inode not found

Then there are the file names on the pendrive, but they are not allocated in a file (and rightly so I say), but programs like Recuva, Get Data Back or R-Studio can remap these file names thrown in the space of formatted disk with the files and then rebuild the file association - metadata. How do
... bho? With

Autopsy

clearly are not deleted files and search for data unit, inserting the value 82591, you get the raw view that cluster containing the string "nannileccia.jpg.

Well I hope it is interesting topic:) I look forward to your suggestions
Nanni Bassetti