Elso korben azt talaltam ki, hogy - jol ismerve az NTFS lelkivilagat - megkeresem az INDX rekordokat, es azokbol kinyerem a filenev, meret, datum infokat. Sot meg a parent mft id alapjan a konyvtarstuktura is valamennyire rekonstrualhato. Ez sikerult is, tehat mar volt egy eredeti filelistam datum+meret infokkal, ezt kell osszekotni valahogy a PhotoRec altal visszahozott random nevu 17k file-al.
Kovetkezo problema, hogy ehhez nem artana az omlesztett fileok modositasi datumat is megszerezni. Ez se remenytelen:
- OLE fileok (pl. DOC, XLS) eseten benne van a headerben valahol, az olefile lib ki tudja olvasni az esetek tobbsegeben
- OO-XML (DOCX, XLSX stb) eseten pedig az egyik xml-ben van egy mezo amiben van datum, ezt is ki lehet parsolni, bar nem szabvanyos formatumu a datum, kicsit trukkozni kellett ehhez is
- JPG eseten az EXIF-ben altalaban benne van a kep keszitesenek a datuma, ahogy PDF eseten is van ra esely megtalalni
Ezek alapjan a kovetkezo algoritmust talaltam ki: vegigmegyek az omlesztett fileokon, es megnezem a filelistat:
- van-e meretben egyezo file (a kis meretu OLE-t leszamitva altalaban eleg ritka az ugyanakkora meretu file)
- a kiterjesztes es a file formatuma egyezik-e (ne nevezzunk mar at JPG-t XLS-re csak mert a meret egyezik...)
- a datuma eleg kozeli-e (mondjuk elso korben 2 oran beluli az elteres max) a file datumahoz kepest?
igy a fileok kb harmada osszeparosithato volt, ha az idokorlatot elengedtem akkor masik harmad is.
Ezt meg kibovitettem az MFT rekordok keresesevel: mivel sok file volt, az eredeti MFT-t boviteni kellett, igy "csak" az elso 8k file MFT-je veszett oda, a tobbit megtalaltam a disk kozepen.
Igy a vegso modszer ez lett, meglepoen jo eredmennyel:
https://github.com/gereoffy/drutils/blob/main/lsindx.py
- MFT (FILE) rekordok keresese, ami infot lehet abbol kigyujt (file/konyvtar nevek/attribok, $DATA runlist-ek)
itt azt a nem dokumentalt featuret is ki kellett hasznalni, hogy az MFT rekordokban az MFT sajat id-je is benne van!
- INDX rekordok keresese (ebbol csak file/konyvtar stuktura jott, runlist nem, de a hianyzo MFT-k miatt ez is kell)
- ha mar ugyis megvolt sok konyvtar 2 forrasbol is, a disk pozicioik kulonbsegebol kiderult a particio kezdo offsetje!
- ezekbol a konyvtarstuktura rekonstrualasa (MFT parent id -> path)
- MFT-bol kinyert runlist-ek alapjan a file-ok egy reszenek visszaallitasa
- MFT runlistek alapjan az input image-bol a fileok TORLESE!!! tehat amit mar visszallitottam azt kinullaztam az inputban!
- PhotoRec futtatasa az input imagen, igy mar csak azt talalhatja meg, ami az MFT-bol hianyzik
- a megtalalt omlesztett fileok atnevezese az INDX infok alapjan (indxrename.py) es datum javitasa (indxfixdate.py)
- arpi_esp blogja
- A hozzászóláshoz be kell jelentkezni
- 1026 megtekintés
Hozzászólások
Szép munka! Mondjuk nem sokat értek belőle, nem ismerem az NTFS szerkezetét. Photorec-et viszont már használtam. Az ömlesztett, visszanyert fájlokban megtalálni a szükséges infót... Jó móka.
- A hozzászóláshoz be kell jelentkezni
koszi. az NTFS nem tul bonyi, persze tekintve hogy 30 eves, nem is kell csodat varni tole.
az erdekessege - es itt pont ezt hasznalom ki - hogy meglehetosen redundans, majdnem minden info megvan 2 helyen, az MFT tablaban (ami egy egybefuggo "file" az osszes metaadattal, nagyreszt a disk elejen) es a disken mindenfele szetszort INDX rekordokban (konyvtar leiro blokkok).
ha mind2 helyrol beolvasok mindent es osszefesulom (jo resze atfedesben lesz) akkor eleg sok elveszett(nek hitt) dolog elokerul, meg akkor is, ha se az INDX se az MFT nincs meg teljesen.
- A hozzászóláshoz be kell jelentkezni
Gratula! Kihívásképp mindig érdekesek az "innen szép nyerni" helyzetek :), pláne, ha valakinek komoly való életbeli segítséget tudsz az eredménnyel nyújtani; így persze jócskán túlmutat az önnön szórakoztatásra gyártott hobbi projekteken..
- A hozzászóláshoz be kell jelentkezni
Mennyi idődbe került és mennyi pénzt kértél el érte?
- A hozzászóláshoz be kell jelentkezni
az otlet regota megvolt a megvalositas kb 3 delutan/este volt, nem veszes. most volt ra idom. meg par 100 sor py kod, nem sok ido megirni, inkabb a sok futtatas/teszteles/kiertekeles vitte az idot.
ezt most nem a penzert csinaltam, hanem kivancsi voltam mit lehet ebbol kihozni, mert volt mar a multban par hasonlo ntfs mentes amit passzoltam, mft nelkul remenytelen volt hasznalhato eredmenyt produkalni, itt most az volt a kerdes ezzel az uj megkozelitessel mennyit lehet kihozni belole. es meglepett az eredmeny, hogy ha nem is mindent, de a cucc nagy reszet teljesen jol visszahozta.
ha csak leformaznak egy disket ugyanakkora kapacitasra, akkor az uj mft is ugyanakkora es ugyanott lesz mint elotte (hacsak nem allitgatja el a defaultrol a parametereket formazaskor, de ez nem jellemzo), es igy pont felulirja a regit. ilyenkor lehet jo ez a tool. mivel a gyorsformazas az indx-eket nem bantja (max a rootdirt) sem az adatok nagy reszet.
- A hozzászóláshoz be kell jelentkezni
Szép
- A hozzászóláshoz be kell jelentkezni
Szep!
Ilyenkor sokat tud segiteni, ha tudod mire losz. Foleg az elveszett file-ok formatuma erdekes. Sokkal trivialisabb eset, egyszer a noveremnek veszett el egy - talan - SD kartya tartalma, azonos felbontasu JPEG file-okkal. Talan a getdataback tudta olvasni, de a fileneveket nem. Az exif-bol kiszedtem a keszites idejet, es kaptak uj fileneveket.
A masik, ha tudod, hogy megis hogy hibasodott meg. Lehet veletlen formazas, de lehet rossz pendrive is, amiben a vezerlot mas meretre allitottak, mint ami a flash mennyisege. Ilyenkor ha elkezded hasznalni, mukodik, de ha sokat irsz ra, felulirja az elejet. Az f2write/f2read parossal szoktam tesztelni mindent, pont emiatt.
Ja, es a backup egyszerubb.
A strange game. The only winning move is not to play. How about a nice game of chess?
- A hozzászóláshoz be kell jelentkezni
igen fotok eseten nem olyan bonyi, es ott az se akkora drama, ha nem az lesz a file neve hogy IMG_9852.JPG hanem f16536732.jpg :) raadasul a file eredeti neve is sokszor benne van exif-ben, egyeb infok (datum, gps koordinata stb) mellett. na meg az ilyen fileok ritkan vannak fragmentalva, es jellemzoen idoben es disk pozicioban is egymas utan jonnek. igy a photorec-tipusu visszallitas is hasznalhato...
> A masik, ha tudod, hogy megis hogy hibasodott meg.
ezt kb sose lehet biztosan tudni. ha sejtjuk is, az user ugyis letagadja, hogy o volt a hulye :)
> Lehet veletlen formazas
az azert latszana, de olyan azert ritka elegge. mondjuk pont nemreg volt itt egy laptop vinyoja, leformazta a szervizes mentes nelkul, ujra is telepitettek, aztan szolt az user hogy he' haver hol a kocsim doksim? na azt en is passzoltam.
> a vezerlot mas meretre allitottak, mint ami a flash mennyisege
hat ez a wish-es pendriveokra jellemzo, azert amivel en talalkozom azok altalaban ceges cuccok, ott a hw valos szokott lenni.
amugy bennem is felmerult, hogy lehet valahol a flash chipen megvan meg az MFT, csak a vezerlo nem jot lapoz/mappel be olvasaskor es azert nem az latszik az elso 4MB-on hanem valami random szemet. de nem tudom hogy lehetne hozzaferni a raw flashhez, persze a kiforrasztast es a speci flash interfacet leszamitva... es amugy is valoszinubb hogy siman feluirodott, vagy csak meghibasodott egy blokk a flashben.
egyebkent a hozzam kerulo menteseknel a leggyakoribb hogy a disk (jo ez most pd volt de altalaban hdd-ket mentunk) elejenek felulirodasa, hol kicsit hol jobban. es a leggyakoribb ok meglepo modon a kontakthibas usb csatlakozo, iras kozben vszinu resetelodik a drive es/vagy az usb-sata chip, a pc meg tolja tovabb a datat DMA-val es ezert a disk elejere irodik vagy elcsuszik par szektort. vagy kihuzza az user iras kozben mert siet. nemreg pl. egy olyat mentettem ahol az MFT harmada el volt 1 szektorral csuszva...
> Ja, es a backup egyszerubb.
egyreszt ezzel nem is ertek egyet teljesen de az egy hosszu diskurzus lenne, masreszt ezt az usereknek kell mondani, nem nekem :) persze ha az userek leszoknanak a pendrive/usbhdd hurcolgatasrol es inkabb a fileszervert vagy valamilyen felhos tarhelyet hasznalnak akkor megszunne a problema forrasa is :)
- A hozzászóláshoz be kell jelentkezni
Nem jól emlékszek, hogy az MFT-ből létezik egy másolat is a diszk egy másik területén?
- A hozzászóláshoz be kell jelentkezni
$MftMirr a particio kb. közepén van, de az is csak az MFT első (pár?) rekordját duplikálja, nem az egészet.
Arpi: ez nem szokott segítség lenni?
- A hozzászóláshoz be kell jelentkezni
nem igazan, ez alapjan csak az elso 4-8 rekord van csak benne, nekem meg ennel a konkret esetnel az elso 8192 hianyzott...
de amugy rawba vegig olvasom a disket es az osszes MFT szektort parsolom, tehat ha mirrorba lenne akkor is meglenne, de meg sose talalkoztam duplikalt MFT-vel egy disknel se.
- A hozzászóláshoz be kell jelentkezni
elmeletileg igen, a gyakorlatban en meg sose lattam olyan ntfs particiot ahol 1-nel tobb peldanyban lett volna az mft :( gondolom opcionalis es senki se allitja be formazaskor.
FAT-nal viszont tenyleg van masolat, sokszor mentette mar meg az adatokat, mikor a disk eleje feluliorodtt, de a FAT copy meg megvolt.
- A hozzászóláshoz be kell jelentkezni
good job!
- A hozzászóláshoz be kell jelentkezni
Szép munka!
Gratula!
- A hozzászóláshoz be kell jelentkezni
ez az igazi hup karacsony!!! szakmai tartalom! :D:D
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
A szakmai tartalom jó dolog, de karácsony gyakrabban van.
- A hozzászóláshoz be kell jelentkezni
Szép munka!
Én nem vagyok ennyire profi, bár egyszer sikerült egy teljes lemez tartalmát megmentenem 3 porcelán tányérral és egy mélyhűtővel. (Abban a pillanatban qjó ötletnek tűnt.)
- A hozzászóláshoz be kell jelentkezni