Ontrack EasyRecovery 6.x

[Kowa1]

Mam starego ontrack-a FileRecovery ( 6 z groszami ) który ma opcje RAW recowery a w niej standardowe "file sygnatgures" tj. zbiór sygnatur plików których poszukuje.

Nieastety nie ma w tym zbiorze plików z rozszerzeniem *.wma - a takich chcę szukać.

Jest opcja dodawania sygnatur u żytkownika ale w nie trzeba poza rozszerzeniem ( wma ) podać również offset i signature - w helpie opisane to jest tak:

RawRecovery - File Types

During a RawRecovery scan the tool is searching for specific file signatures.  The tool has over 200 file signatures, which can be selected for the scan.  The File Types dialog will list all file signatures in the tool’s database.  The RawRecovery tool default is to scan using all file signatures.  If you wish to customize your recovery and do not wish to scan using all file signatures, you can select file signatures individually for the scan.

You may add custom signatures by selecting the Add button.  The Add File Signature dialog has fields for signature, offset, description, and extension.  The signature and offset fields require you to enter data in hexadecimal format.

Custom signatures can be adjusted or changed by highlighting the signature in the list and selecting the edit button.  You cannot edit or remove non-customized signatures in the file list.  At least one file signature must be selected to exit the File Types dialog.

© 2002 - 2003 Ontrack Data Recovery, Inc.

 

I, urwał nać, zadnych wyjaśnień. Poszukałem w necie i trafiłem, między innymi, na:

http://www.garykessler.net/library/file_sigs.html
i

https://www.filesignatures.net/index.php?page=search&search=WMA&mode=EXT

 

Jak "signature" w miarę, wydaje mi się, kminie tak "offset" już kompletnie nie!

Pomóżcie

W standardowym zestawie sygnatur w posiadanym przeze mnie programie ontrack easy recovery 6...? brak sygnatury dla rozszerzenia *.wma. Chciałbym dodać ale jak!?

[Groszexxx]

Zastosuj program Photorec, który jest w pakiecie testidsk i to rozwiąże Twój problem. Darmowy i opensourcowy, o wszechstronniejszych zastosowaniach, bardziej elastyczny, praktycznie w kazdym aspekcie lepszy. Co do sygnatur *.wmv to są opisane w necie dokładnie. Choćby właśnie na stronie photoreca - https://git.cgsecurity.org/cgit/testdisk/tree/src/file_asf.c

 

Offset to po prostu przesunięcie, w którym owa sygnatura się znajduje. Dosyć często znajduje się ona na początku pliku. Utwórz plik wmv albo po prostu przejrzyj obecne - i zobacz cechy wspólne, na pewno wspomniana sygnatura będzie taka sama - chodzi mi o to, żebyś dane pliki porównał w hex editorze. Tam masz zawsze lokalizacje danego bajtu. 

[Kowa1]

Co prawda nie jest napisane do czego mam zastosować Photorec ale domyślam się że miałbym go użyć w miejsce EasyRecovery do odzyskania plików. Generalnie nazwa sugeruje że program jest dedykowany do odzyskiwania grafiki ale może wszelkich, tyle że testowałem wiele programów i żaden nie posiadał funkcji RawRecovery, a Photorec posiada taką funkcje z plikami wma na liście wyszukiwania?

Co to jest offset wiem doskonale bo borykałem się z tym wielokrotnie w różnych sytuacjach i stąd problem.

Jedne programy używają jako ofset numer bajtu licząc od zera inne liczą od 1 Przykładowo: dla trzeciego bajtu w pliku jedne podają offset 2 ( pierwszy bajt to ofset 0 ) inne offset 3 ( pierwszy bajt to ofset 1 ) ?
Nie wiem jak to interpretuje EasyRecovery, ma co prawda liste sygnatur do której można dopisać własne i edytować ale edytować tych już "fabrycznie" wpisanych nie można czyli nie można podejrzeć jak to interpretuje program.
W helpie/manualu do programu brak słowa na ten temat. Wiem że ostatecznie można to sprawdzić bojem wykonując sprawdzenia hexedytorem miejsce sygnatury w pliku wma a potem nowy dysk, zapisanie na nim wma, usunięcie, wpisanie wzorca na liste EasyRecovery przy danej interpretacji ofsetu, sprawdzenie czy znajdzie, jak nie znalazł to ........ Ale jstem już zmęczony sytuacją w której za niezła kase sprzedawane są programy za których działanie wydawcy nie poniszą żadnej odpowiedzialności i do których nie dają koniecznych do poprawnego użytkowania informacji.

Faktycznie w pierwszym poście nie doprecyzowałem ale teraz powinno być wszystko jasne.
Jeśli kotoś posiada dedykowane, dokładnie informacje na temat przedstawionego problemu i pytania będę wdzięczny.

[Groszexxx]

Firma OnTrack to bardzo negatywna firma jeśli idzie o PR. Na rynku zyskała popularność głównie dzięki kłamstwom, zagrywkom marketingowym, efektownym (choć niemających nic z prawdą) filmikach. Testy zostawiam Tobie. Większość programów do odzyskiwania danych jest wlasnie w oparciu o sygnatury. Recuva, Photorec, Wynika to z prostego faktu, że są dziecinnie proste do napisania. Widzę, że szanowny kolega jest z tych, którzy wszystko wiedzą, a mimo to zadają wiele pytań. Nie spotkałem się, żeby offset nie był liczony od zera, mimo iż używałem wiele hex editorów.

 

Twoje pytanie dotyczy programu komercyjnego, jeżeli zapłaciłeś za ten program to skorzystaj z supportu. Kolego, sygnaturę pliku możesz sobie wpisać w każdy hexeditor. Problem polega na tym, że taką metodą możesz znaleźć tylko pliki niepofragmentowane.  Na dokładkę oczekujesz odpowiedzi na pytanie, na które zarzekasz się, że w sumie sam mógłbyś sobie odpowiedzieć, ale nie chce Ci się zrobić krótkiego, 5 minutowego testu. Skoro masz możliwość dodania sygnatury ręcznie - to to zrób. Utwórz folder, w którym jeden plik będzie plikiem wmv i ustaw szukanie tylko na ten folder. Brak wynikow oznacza, ze zle wpisales. Proste jak drut. 

http://www.cgsecurity.org/wiki/File_Formats_Recovered_By_PhotoRec

Czy to są dla Ciebie rozszerzenia tylko plików graficznych? Tak naprawdę wyszukiwanie pliku w oparciu o sygnatury można zrobić w każdym hexeditorze, a do odzyskania przydałby się jeszcze windowsowy programik fsutil. To wszystko.  

[Kowa1]

Może ontrack to "negatywna firma" ale korzystałem z wielu progrmów odzyskujących dane ( np: Acronis, Active@, O&O .. ) i żadn nie miał funkcji RawRecovery, a przuynajmniej na tak dobrym poziomie.

Przy okazji ta funkcja nie działa na katalogach tylko na całych dyskach logicznych - zakłada nieznany format zapisu i testuje dysk ( od pierwszego do ostatniego sektora ) i odzyskuje pliki przy pomocy specjalnego algorytmu używającego wielu formatów zapisu. Czasmi jeden odzyskany plik podaje w kilkunastu wersjach o różnych lub identycznych rozmiarach i tylko jeden z nich okazuje się być poprawnym całokwicie odzyskanym lub przynajmniej w zadawalającej części odzyskanym: filmy, fotografie, nagrania, teksty, zawsze jednak coś można z tego wyciągnąć. No z wykonywalnych już nie.
Co ciekawe kompletnie nie radzi sobie z undelete.

Nie wiem wszystkiego ale wiele a pytania zadaje tylko wtedy kiedy nigdzie nie znajduje na nie odpowiedzi licząc na to że ktoś już to przećwiczył bojem.
Może piszę nazbyt skomplikowanie ale zapewniam że nigdzie nie napisałem o tym że chciałbym pliku wma szukać na dysku po sygnaturze za pomocą hexedytora - polecam ponowną lekturę mojego drugego postu i zastanowienie się dłuższe niż dotychczasowe a zpewnością pojawi się konkluzja że 5 minut na testy niewystarczy i będzie konieczny dodatkowy pusty dysk logiczny.
Skoro nie spotkałeś się z tym "żeby offset nie był liczony od zera" może spotkałeś się ze zbyt małą ilo ścią programów zarządzających dyskami. Ja spotkałem się z kilkunastoma od PCtools ( gdy nie było jeszcze żadnego GUI a tylko DOS ) przez Power Quest, paragon, ....., Acronis, Avanquest do Minitool i zapawniam   że różne rzeczy liczą one w różny sposób i podają odmienne wyniki. Ze trzy z nich lub ich wersji różnie liczą ofsety - najnowsza ciekawostka MBR nie 62 a 2048 sektorów!

 

I proszę nie pisz takich dowcipów żeby skorzystać z supportu ( pomocy technicznej producenta ) bo jeszcze ktoś uwierzy i wyrzuci piweniądze na licencje z pełną pomocą. Wielokrotnie miałem okazje próby skorzystania z takiej pomocy ( właściciele firm popełniali takie błedy - Microsoft, Corel, Lotus, Acrobat ... ) i  od tamtej pory stałem się zwolennikiem teorii spiskowej że cała zaawansowana technologia pochodzi ze strefy 51 a jednostki które ją sprzedają mają o niej mgliste pojęcie.

Najbardziej spektakularny przypadek z suportem Gigabyte gdy to na bardzo rozbudowanej płycie głównej GA-8IRXP jest hardware czytników kart pamięci MMC SD CF na stronie były sterowniki w manualu opis umiejscowienia pinów na płycie do podłączenia gniazd - tylko nigdzie nie było informacji który pin z którym stykiem gniazda połączyć. Suport przez pół roku nie dał sobie rady z tym problemem i trzeba było kupić czytnik na USB a w tamtych czasach nie był to mały wydatek.

To wszystko.

[Groszexxx]

W kwestii sprostowania, bo odnoszę wrażenie, że nie bardzo zdajesz sobie sprawę o czym piszesz. 

 

 

 

Przy okazji ta funkcja nie działa na katalogach tylko na całych dyskach logicznych - zakłada nieznany format zapisu i testuje dysk ( od pierwszego do ostatniego sektora ) i odzyskuje pliki przy pomocy specjalnego algorytmu używającego wielu formatów zapisu. Czasmi jeden odzyskany plik podaje w kilkunastu wersjach o różnych lub identycznych rozmiarach i tylko jeden z nich okazuje się być poprawnym całokwicie odzyskanym lub przynajmniej w zadawalającej części odzyskanym: filmy, fotografie, nagrania, teksty, zawsze jednak coś można z tego wyciągnąć. No z wykonywalnych już nie.
Co ciekawe kompletnie nie radzi sobie z undelete.

 

 

 

Nieznany format zapisu? Nie chciałbym być nieuprzejmy, ale kolega dawał mi link, w którym wszystko było wyjaśnione. "Magic number", signature. Specjalny algorytm zapisu?  Wiele formatów zapisu? 

 

Niech Szanowny Kolega pozwoli, że rzucę na to nieco światła: 

Tutaj otwarty plik wma w hexeditorze. 

Tutaj problem w samodzielnym odzyskiwaniu polega na tym, że mamy początek, a nie mamy końca. Można przyjąć dwie główne metody - pierwsza to próba oparcia się o dane z nagłówku pliku (z angielskiego header). Np. w niektorych plikach graficznych (na przykladzie jpg) nagłówek zawiera szereg informacji o pliku m.in gdzie sie zaczynaja poszczegolne sekcje pliku: np. miniatury, gdzie zaczynaja sie skompresowane dane i gdzie sie koncza. Gorzej, gdy nie mamy dostępu do dokumentacji danego rozszerzenia.

Wówczas sprawa sie komplikuje. Można próbować przeglądać klaster aż do momentu, gdy na końcu klastra będą zera. Klaster to struktura grupująca sektory w systemie pliku. W windowsach domyślny klaster ma 8 sektorów. 

Widać, że to 3 sektor danego klastra, dalej są już same zera. NIestety, klastry rzecz jasna widzimy w oparciu o system plików, gdy system plików jest uszkodzony - to wtedy trzeba improwizować, można na podstawie szczątkowych informacji pewne rzeczy wywnioskować. Gorzej, gdy dane pliku wypełniają dany klaster do końca. Wtedy jest problem. Wymienialem PhotoRec, Recuve, teraz najnowsze wersje DMDE mają również wyszukiwanie RAW. Powiedziałem Ci również, że można to zrobić zupełnie samemu. 

 

Co się tyczy zaś samego testu - możesz albo stworzyć sobie jakąś partycję - choćby na kilka megabajtów. Jeśli obecne partycjonowanie na to nie pozwala - wtedy pozostaje posłużyć się pendrive albo stworzyć wirtualną partycję. Szybko łatwo i przyjemnie. Żadnych problemów. 

 

Uczepiłeś się jak rzep psiego ogona jakiegoś oprogramowania, na dokładkę drogiego i kiepskiego, żeby nie napisać wręcz - oszukańczego, przedstawiłem Ci lepsze alternatywy jako osoba doświadczona, a Ty dalej swoje. Co jest z Tobą nie tak? Jak widać fakt, że niektórym da się wędkę nie wystarcza, koniecznie chcą dostać rybę czyjąś pracą. Nie tędy droga. 

[Kowa1]

Na początek erratum MBR = PBR i 62 = 32

Bardzo proszę o informacje jaki hexedytor został użyty.

Doradzam nie używać programów które pisane są w kompilatorach a nie w języku najniższego poziomu = kodzie procesora = deburgerze i które używają bibliotek i zawartych w nich driverów a nie przerwań = bezpośredniego dostępu do dysku.
 
Nie wiem jak jabłko ale windows, linux, unix i parę innych systemów pracują pod DOS-em ( Disk Operaton System ).
Dostęp do dysku lub jego partycji ( w sęsie określonego zakresu zsektorów na dysku fizycznym ) nie rozróżnia klastrów i wygląda tak:
pod porządnym hexedytorem

pod porządnym dysk managerem

Jak widać Partition Table DOS-owa standartowa ze standardowym oznaczeniem rodzaju partycji, jej aktywności i formatowania. I dopiero wynalazki takie jak nietrzymające standardów Boot managery lub emulatory windows pod linuksem rozpierniczają wszystko. Co porządne programy trzymające standart pokazują lub się na tym wysypują.

Funkcja RAW we wskazywanych programach to nie prawdziwe RAW tylko popierdółka. Prawdziwe RAW ( Ontrackowe ) nie interesuje system plików ( formatowanie, wielkość klastra etcetera ) szuka po sektorach od do ( a dokładniej po pojedyńczych bajtach ) specjalnym algorytmem na podstawie danych: roszerzenie, sygnatura, ofset - którego interpretacji w tym programie nie znam, to problem którego rozwiązania szukam.

Czasmi odzyskiwanie trwa kilkanaście dni a wielkość odzyskanych wersji wszelkich plików przekracza pojemność dysku a dodatkowo nie wiadomo która z wersji jest dobra lub najlepsza ale w krytycznych sytuacjach pozwala odzyskać sporą część danych kiedy inne programy nie dają takiej szansy.

Do tej pory szukałem plików znajdujących się na liśćie niestety wma brak.

[Groszexxx]

Dla Ciebie MBR to PBR? Master boot record to partion boot record? 

 

 

Doradzam nie używać programów które pisane są w kompilatorach a nie w języku najniższego poziomu = kodzie procesora = deburgerze i które używają bibliotek i zawartych w nich driverów a nie przerwań = bezpośredniego dostępu do dysku.
 
Nie wiem jak jabłko ale windows, linux, unix i parę innych systemów pracują pod DOS-em ( Disk Operaton System ).

 

Windows , linux pracują pod Dosem? System operacyjny pracuje pod poziomem innego systemu operacyjnego? Skąd Ty się urwałeś? Ja zupełnie szczerzę zapytam czy Ty pisałeś to na trzeźwo? 

 

Skoro kolega wspomina o przerwaniach to chyba faktycznie zatrzymał się w erze dos. Już nie wspomnę o takich kwiatkach jak wyraz "sęsie". Nie chcę używać argumentów ad personam, ale to nie pierwszy przypadek, gdy ktoś pod pozorem chęci otrzymania pomocy zaczyna kogoś innego uczyć. Temat dotyczył sygnatury plików wma, a teraz Ty mi coś o tablicy partycji zaczynasz pisać. 

 

 

 

 

 I dopiero wynalazki takie jak nietrzymające standardów Boot managery lub emulatory windows pod linuksem rozpierniczają wszystko. Co porządne programy trzymające standart pokazują lub się na tym wysypują.

 

???? 

Jakiś dowód, źródło? 

 

 

 

Funkcja RAW we wskazywanych programach to nie prawdziwe RAW tylko popierdółka. Prawdziwe RAW ( Ontrackowe ) nie interesuje system plików ( formatowanie, wielkość klastra etcetera ) szuka po sektorach od do ( a dokładniej po pojedyńczych bajtach ) specjalnym algorytmem na podstawie danych: roszerzenie, sygnatura, ofset - którego interpretacji w tym programie nie znam, to problem którego rozwiązania szukam.

 

Weź się nawet nie ośmieszaj. Pokazałeś już wyraźnie, że Ty nawet nie masz pojęcia o czym piszesz. Pierwszy cytat to już w ogóle mistrzostwo świata. Specjalne algorytmy, pokazałem Ci specjalne algorytmy. 

 

Z racji tego, że kolega dalej nie ma pojęcia  - to czas na praktykę. Może to moja wina, że nie wyjaśniłem wszystkiego należycie jasno, jest mi z tego tytułu bardzo smutno i przykro. Postanowiłem poświęcić zatem swój cenny czas na tę małą lekcję. Na dysku miałem niewiele plików wma. Zaledwie 12. 

 

Tutaj mój malutki pendrive 256 MB. Na screenie 12 plików wma + program Refind.

Następnie dysk został sformatowany. Czas na zastosowanie SPECJALNEGO ALGORYTMU : 

Niewiele hexeditorów pozwala na przeglądanie całej partycji. Obejściem jest zrobienie obrazu partycji do pliku. Ja używam hexeditora w DMDE. Od lat na nim pracuję i przyzwyczaiłem się do jego interfejsu. 

Pierwszym etapem będzie zatem wpisanie naszej sygnatury WMA 

30 26 B2 75 8E 66 CF 11 A6 D9 00 AA 00 62 CE 6C

I tak natrafiamy na pierwszą sygnaturę! 

Wiemy, że to początek naszego pierwszego pliku! 

Gdzie jest jego koniec? Tak jak mówiłem, mamy kilka metod postępowania. Zastosujemy każdą z nich. 

1) Pójdziemy po najniższej lini oporu. W ciemno założymy, że plik ma 100 MiB (dla uproszczenia będziemy operować w mebibajtach (w angielskim często pojawia się "binary MB"), wszak co nam szkodzi? Zaczynamy! 

100 MB (104857600)  104857600/512 (tyle ma sektor na dysku) - wychodzi nam 204800 sektorów. Stwórzmy więc pusty plik o takiej wielkości, abyśmy mogli wypełnić go naszym znaleziskiem. W tym celu odpalamy CMD jako admin, a w nim: 

fsutil file createnew c:\odzysk\Plik1Metoda1.wma 104857600

fsutil file setvaliddata c:\odzysk\Plik1Metoda1.wma 104857600  (ta czynność jest niezbędna, tak naprawdę utworzony plik jest "sztuczny", system wskazuje, że ma wagę taką jak wyżej, ale jest pusty, jest traktowany jako "sparse file", składający się z samych zer, system plików ntfs automatycznie potrafi taki plik upakować, że mieści się w rekordzie mtf. Odsyłam do słowa-hasła "sparse file". W każdym razie dopiero wtedy zostaje wypełniony losowymi danymi i ma "realny" rozmiar".

 

Wracamy do hexeditora. Hexeditor w dmde pozwala na łatwe zapisanie fragmentu pliku, partycji, dysku do pliku. Zaznaczmy więc interesujący nas fragment. Jak widać na screenie nasza sygnatura pojawiła się w sektorze 44580. Dodajmy do tej liczby wspomniane wyżej 204800 sektorów. Wychodzi więc, że kopiujemy dane od sektora 44580 do 249380. 

(Tutaj wazne info, edytor w dmde pozwala na wrzucanie zawartości tylko do plików .bin, .img, .ima, dlatego zmieniłem nazwę naszego, dodając mu rozszerzenie .bin. Wynik: 

Nasz pliczek działa i pięknie gra. Przypominam, że zastosowaliśmy SPECJALNY ALGORYTM. Kto wie, może warto go opatentować? Panie Kowa, mogę się tego patentu dla Pana zrzec. 

Metoda 2

Czas na SPECJALNY ALGORYTM 2. 

Tutaj zakładamy, że nasz plik kończy się tuż przed zaczęciem kolejnej sygnatury. Proste jak drut. 

Widzimy, że w lba 46616 zaczyna się nowy plik wma, tak więc nasz poprzedni pliczek kończy się w 46615. 

Po raz kolejny przygotowujemy nasz pusty pliczek za pomocą narzędzia fsutil. Łatwo policzyć, że 46615-44580+1 = 2036 sektorow, a to wynosi 1042432 B. O takim rozmiarze stworzymy nasz pusty plik. Dalej procedura wygląda tak samo. Plik działa i gra tak samo jak poprzednio. 

 

Wady pierwszego SPECJALNEGO ALGORYTMU są intuicyjne: duży rozmiar pliku, a i brak pewności czy plik nie będzie większy. Przy drugim odwrotnie - otrzymany plik może być za duży (jeżeli nie następują bezpośrednio po sobie). 

To dlatego profesjonalne programy uwzględniają to o czym też już wspominałem, a więc dokładne informacje zawarte w nagłówku (header) takiego pliku. Dekodują je i na tej podstawie szacują wielkość pliku. Oczywiście taka opcja dotyczy tylko niektórych standardów plików (np. graficznych czy własnie dźwiękowych).

 

Zmarnowałem na Ciebie już wystarczająco dużo czasu. Ty nie zrobiłeś do tej pory nic poza bzdurnymi postami, w którym prawdy jest tyle ile kot napłakał. Jak widać - system plików nie ma żadnego znaczenia, nic nie trzeba analizować tak jak to pisałeś tutaj: 

 

 

Nieznany bo EasyRecovery w opcji RAW nie zna sytemu zapisu plików dopiero na podstawie tego na co trafi i zanalizuje ustawia domniemane dopuszczalne systemy ( sam linux ma ich : Minix, xia, Ext, Ext2, Ext3, Ext4, umsdos, msdos, ReiserFS, vfat, XFS, proc, JFS, smb, NFS, ncp, Swap, iso9660, Sysv, hpfs, Affs, ufs ) zapisu i w oparciu o nie odzyskuje dane.

Masz sporo braków, jak widać - słyszysz,  że dzwonią tylko nie wiesz, w którym kościele. Na sam koniec wynik z photorec: 

Jak widać 1 plik ma identyczny jak ten odzyskany przez hexeditora. No, ale przecież to wszystko dzięki SPECJALNEMU ALGORYTMOWI. 

 

Pozdrawiam. 

[Kowa1]

Nie chcę używać argumentów ad personam, ale to nie pierwszy przypadek, gdy ktoś pod pozorem dyskusji dotyczącej informatyki chce kogś uczyć ortografi o imputowaniu nietrzeźwości nie wspomnę.

Wiadomo kiedy tak się dzieje - przy braku innych argumentów.

 

 

Windows , linux pracują pod Dosem? System operacyjny pracuje pod poziomem innego systemu operacyjnego? Skąd Ty się urwałeś? Ja zupełnie szczerzę zapytam czy Ty pisałeś to na trzeźwo?

 

A jakiż to system tak organizuje zapis na dusku? Drugi raz dołączę obrazek który zignorowałeś.

Jednego dysku fizycznego zawierającego trzy rodzaje partycji, dwa rodzaje formatowania i dwa systemy. Drugi raz załączę dugi obrazek który zignorowałeś.

Wydaje się że dla Ciebie to niemożliwe bo przecież linuks pracuje pod linuksem a windows pod windowsem, nie?

To poczytaj o windows 3.1 to pierwsza nakładka na dos z rodzaju windows.

 

 

Nie zamierzam Cie niczego uczyć sam to powinieneś zrobić. Polecam strony Starmana.

 

Przypominnasz mi doradcę technikcznego jednego z operatorów telefonicznych który mie mógł zrozumieć że z internetu można się wylogować bez wyłączania komputera.

 

PS

 

 

Nieznany format zapisu? Nie chciałbym być nieuprzejmy, ale kolega dawał mi link, w którym wszystko było wyjaśnione. "Magic number", signature. Specjalny algorytm zapisu?  Wiele formatów zapisu?

 

Nieznany bo EasyRecovery w opcji RAW nie zna sytemu zapisu plików dopiero na podstawie tego na co trafi i zanalizuje ustawia domniemane dopuszczalne systemy ( sam linux ma ich : Minix, xia, Ext, Ext2, Ext3, Ext4, umsdos, msdos, ReiserFS, vfat, XFS, proc, JFS, smb, NFS, ncp, Swap, iso9660, Sysv, hpfs, Affs, ufs ) zapisu i w oparciu o nie odzyskuje dane.
Nigdzie nie pisałem o spcjalnym algorytmie zapisu tylko o algorytmie analizy i odczytu danych z dysku - prosiłem żebyś czytał uważnie.

[Groszexxx]

Edytowałem powyższy post - dokładniej: dodałem nowe informacje. Zachęcam do przeczytania. 

[Kowa1]

Szanowny Panie szanujmy się nawzajem. Jestem Kowa1 a nie Kowa tak jak Pan jest Groszexxx  a nie Grosze, Groszek czy Groszeks.

Dziękuję za wkład pracy ale dotknięty jest on ( jak cała obecna świetlana rzeczywistość ) stygmatem powierzchowności.

Parafrazując wstęp do Rodziny Poszepszyńskich

Otwórzmy się na wiedzę, zajrzyjmy jej do wnętrza, tam tyle różnych spraw nawarstwia się i spiętrza.

Przywrócenie Pliku wma tej wielkości ( czas trwania nagrania 127 sekund przy 72 kbps daje to wielkość pliku nie większą niż 1,2 MB ) po, nieokreślonym przez Pana dokładnie, formatowaniu 256 megowego pendriva to faktycznie dziecinada. Adekwatna do poziomu rozumowania.

Teraz wyjdźmy z przedszkola i udajmy się na uniwerek.

Dysk 9 giga  zapisany w dwóch trzecich albo nieco więcej systemem, oprogramowaniem, danymi ok 6 giga pofragmentowanych plików.
Przy tym stanie instalacja kolejnej aplikacji do ściągania plików wma z dyktafonu. Scięgnięcie czterechech plików ( największy około 146 MB - pełna pamięć dyktafonu czyli wielkość wszstkich plików - 256 MB ) na ten dysk logiczny. Praca nad plikami: kopiowanie dzielenie, łączenie z i bez przekodowywania ( wyniki tych operacji zapisywane w innych plikach bez naruszania plikó źródłowych) ....
Format ( pełny ) dysku xFAT32 ( szczęście bo NTFS lub inne to już kaplica - dlaczego? okazja do popisu ).

Tak się składa niestety że format, pełny format spod windowsa, nie tylko czyści tablice ale fizycznie na dysku co jakąś wielkość sektorów kilka sektorów wypełni a bajtami #FF.

Po formacie zapisanie na dysku systemu z backupu. System zapisywany od początku dysku bez defragmentacji plików gdzieś do pojemności 2,4 GB.
Tak było i poprzednio przed pracą na dysku która zapełniła go do pojemności 6 GB - i tylko dlatego jest nadzieja że pomimo defragmentacji plików na dysku zapisy na nim będącym użytym w objętośći ok 6 GB nie sięgneły poniżej 2,4 GB od początku dysku więć zapisanie na nim plików systemu do 2,4 GB nie miało wpływu ( nie nadpisało ) poszukiwanych plików a jedyny problem to problem formatowania które w nieodpowiednim miejscu mogło wsadzić te bajty #FF.

Ale muszę napisać że kiedyś udało mi się odzyskać po pełnym formatowaniu plik archiwum rar o wielkości ponad 700 MB i był idealny. Widocznie przy zapisie na dysk został tak zdefrragmentowany że akurat wpisy sektorów z bajtami #FF przy pełnym formatowaniu mijały dane. Cud, sam nie mogłem uwierzyć ale sprawdiłem sumiennie zero błędów.

No to teraz spróbuj odzyskać te cztery pliki wma, choćby w części Twoimi programami z pseudo RAW ( już nie kopie leżącego i o metodzie z hexedytorem nie wspominam ) bez algorytmu i rzeczywistej metody RAW oferowanych przez ontracka przynajmniej do wersji 6.x EasyRecovery.

Bo niestety zauważam że programy zamiast być coraz lepsze i dawać coraz bardziej skomplikowane narzędzia są coraz gorsze ze zwykłą obrazkową klikanką dla inteligentnych bez matury z matematyki. Przykładowo MP Clasic który do wersji 1.4.2543 ( do dzisiaj używam tej wersji i nie mam najmniejszych problemów z odtwarzaniem najnowszych formatów plików, kodowań audio, video w różnych kontenerach ) się rozwijał a potem zwijał np. zniknął z niego demuxer.


Panie Groszexxx proszę dalej nie brnąć, szkoda Pańskiego cennego czasu ale gdyby kiedyś wpadła Panu w ręce poszukiwana przeze mnie informacja polecam się pamięci Pana jak też innych uczestników tego forum.

 

PS
Mały oftop może tutaj będzie wiedza.
Od jakiegoś czasu usiłuję w sposób pewny rozstrzygnąć problem obsługi FATa pod win7. Jest kila obozów: obsługuje ale nie działa, nie obsługuje. Jest też pare informacji że nawet działa. A tu właśnie przed sekundą wpadł mi w ręce
https://support.microsoft.com/pl-pl/help/140365/default-cluster-size-for-ntfs,-fat,-and-exfat
z którego tabel niby wynika że czytać i zapisywać powinien bo postawić system raczej nie bo FAT nie ma usługi Junction/SymbolicLink.

[Groszexxx]

Daję koledze 72 godziny na przedstawienie własnych wyników prac. Cokolwiek co zrobiłeś samodzielnie. Liczę na dobrą argumentację. W przeciwnym wypadku temat zostanie poddany głębokiej moderacji, a większość Twoich postów usunięta. Czas upływa od godziny 14:00, 03.07.2017. Jak łatwo policzyć - masz czas do 14:00 dnia 06.07.2017. 

 

Pozdrawiam. 

[Kowa1]

Daję koledze 72 godziny na przedstawienie własnych wyników prac. Cokolwiek co zrobiłeś samodzielnie. Liczę na dobrą argumentację. W przeciwnym wypadku temat zostanie poddany głębokiej moderacji, a większość Twoich postów usunięta. Czas upływa od godziny 14:00, 03.07.2017. Jak łatwo policzyć - masz czas do 14:00 dnia 06.07.2017. 

 

Pozdrawiam. 

 

Napewno nie jesteśmy kolegami.

 

Na początek dla wypełnienia szantażu "Cokolwiek co zrobiłeś samodzielnie." zgodnie z nim cokolwiek:

 

 

 

Do tego ponieważ robione były rzeczy dziwne w dziwny sposób na dziwnych nośnikach

 

 

Zrbiłem samodzielnie modyfikacje sterownika Hitachi i podmieniłem nim sterowniki windowsowskie żeby pokazać  czym różni się pendrive z deskryptorem rodzaju nośnika jako nośnik wymienny od normalnego dysku.

 

Do komputera podłączone dwa pendrive jeden pożyczony Kingston formatowany na jakmś nieznanym mi badziewiu drugi mój PQI formatowany programem "HP USB Disk Storage Format Tool" na dwie partycje.

 

Tak są widziane bez podmiany driverów

 

 

 

Tak są widziane z podmienionym sterownikiem windows dla PQI

 

 

 

Tak są widziane z podmienionymi sterownikami windows dla PQI i Kingstona

 

 

 

 

To na początek dla zachowania terminu - cdn

[Groszexxx]

Terminu może i dotrzymałeś, z tym, że kompletnie nie na temat.

Przypominam, że temat dotyczy w najlepszym wypadku szeroko rozumianego zagadnienia "data recovery", odzyskiwania danych, a Ty wyleciałeś z podmianą sterownika, która nie ma nic wspólnego ww. kwestią. 

Mogę zapytać jaką to ma korzyść? W jakim celu to robiłeś? Strzelam, że chciałeś, aby system wyświetlał Ci więcej niż jedną partycję? 

 

Szczere uznanie za gifa. Chociaż w tym się odnajdujesz . I to wcale nie jest złośliwość. 

 

Co dla Ciebie jest dziwne w moim screenie? 

[Kowa1]

 

Pierwsza partycja pendrive PQI sformatowana pod windowsem obraz z hexedytora pier.. ( no i tu problem interpretacyjny ofsetu o którym już pisałem a który jest podstawą tego tematu ) pierwszego lub inaczej zerowego sektora partycji.

 

CDN

Edytowane 9 Lipca 2017 przez Kowa1
Proszę pisać na temat, to nie jest forum polityczne, na których tak kolega lubi się udzielać. Zostawiłem to co miało związek z tematem.

[Kowa1]

Gościu usunął cytaty swoich własnych wpisów w temacie twierdząc że nie były na temat. Sprawdźmy dlaczego.

 

 

Windows , linux pracują pod Dosem? System operacyjny pracuje pod poziomem innego systemu operacyjnego? Skąd Ty się urwałeś? Ja zupełnie szczerzę zapytam czy Ty pisałeś to na trzeźwo?

Pierwsza partycja pendrive PQI sformatowana pod windowsem obraz z hexedytora pier.. ( no i tu problem interpretacyjny ofsetu o którym już pisałem a który jest podstawą tego tematu ) pierwszego lub inaczej zerowego sektora partycji.

No to już go nie cytuje bo i tak usunie dla ukrycja blamażu sami znajdźcie gdzie pisał bzdury które tu prostuje - wyjaśniam.
Nie istnieje "domyślna wielkość klastra w windowsach". Domyślna wielkość klastra używana przez wszelkie oprogramowanie formatujące jest zależna od wieklości formatkowanego obszaru i jest przyjmowana różnie przez różne narzędzia formatujące np. Norton Partition Magic lub inne używane przez dany system narzędzia np. Format.com.

CompanyName       : Microsoft Corporation
FileDescription   : Disk Format Utility
FileVersion       : 5.1.2600.5512 (xpsp.080413-2111)
InternalName      : format
LegalCopyright    : © Microsoft Corporation. All rights reserved.
OriginalFilename  : format.com

Kolejny raz robi prywatne wycieczki, bezpodstawne insynuacje i atakuje moje dobre imie a jak ja na to zareaguje i zdementuje z udokumentowaniem - to usunie bo nie na temat.

 

A przecież pisałem

 

Odpowiadam i komentuje ( ad vocem ) posty. Do recovery i spraw związanych wracam momentalnie gdy tylko ustaną wszelkie prywatne wycieczki, wymuszenia czy inne niemerytoryczne ataki.

Ale to usunął!

Herbaciany chłopcze gdzieś Ty się Ulung.

To co poniżej przeczy wszelkim Twoim przedszkolnym wynurzeniom Groszexxx-a na temat realnego odzyskiwania danych hexedytorem.
Wyjaśnij to, ale nie atakami na moją osobę czy przedszkolnymi blubrami tylko rzetelną wiedzą.

























Jakie dane są zapisywane na nośnikach których systemy ( te nowe to zupełnie ) i programy, również hexedytory, ( poza specjalistycznym oprogramowaniem ) nie widzą?
Jak to się dzieje że duży plik ( np. Recal.wma ) który jest na nośniku pofragmentowany na wiele kawałków edytowany w hexedytorze jest w jednym kawału. I ten to jeden kawałek różni się od danych na dysku jeśli zaczniemy dysk edytować w hexedytorze od początku zapisu na dysku pliku Recal.wma?
Co to jest suma kontrolna sektora, co to jest badsektor i dlaczego pomimo wielu bad sektorów ( sektorów usuniętych z użytkowania na dysku ) dysk ma nadal taką samą pojemność?

Jak będąc moderatorem można robić userom wode z mózgu - trochę odpowiedzialności i przyzwoitości.

[Groszexxx]

Nie wiem gdzie miałeś ustawiony focus, w którym miejscu miałeś znak zachęty, ale ponów test z zaznaczoną opcją: wszędzie zamiast w dół. Jestem przekonany, że Twoja zguba się odnajdzie. 

 

 

 

 

Jakie dane są zapisywane na nośnikach których systemy ( te nowe to zupełnie ) i programy, również hexedytory, ( poza specjalistycznym oprogramowaniem ) nie widzą?

Poza jednym przypadkiem to wydaję mi się, że wszystkie dane w user area na dysku przy odpowiednich uprawnieniach mogą być widoczne w hexedytorach. Jest takie ustawienie na dysku jak HPA. Host Protected Area. Patrząc z punktu widzenia dysku to przy nałożonym HPA faktycznie translator będzie zezwalał na adresowanie tylko części adresów z user area i wtedy nie ma mozliwosci dostania sie do obszaru, ktory wychodzi poza hpa. 

 

 

Jakie dane są zapisywane na nośnikach których systemy ( te nowe to zupełnie ) i programy, również hexedytory, ( poza specjalistycznym oprogramowaniem ) nie widzą?

Wynika to z faktu, że Ty oglądasz plik już poskładany, słowa kluczowe to lcn (logical claster number) i vcn (virtual cluster number). Z racji tego, że lcn są właśnie pofragmentowane - to Ty tak naprawdę oglądasz VCN, a więc te wirtualne, poskładane. 

 

 

I ten to jeden kawałek różni się od danych na dysku jeśli zaczniemy dysk edytować w hexedytorze od początku zapisu na dysku pliku Recal.wma?

Tak jak wyżej. Edytujesz złe miejsce na dysku. 

 

Co to jest suma kontrolna sektora, co to jest badsektor i dlaczego pomimo wielu bad sektorów ( sektorów usuniętych z użytkowania na dysku ) dysk ma nadal taką samą pojemność?

Budowa scieżki na dysku w mocnym przybliżeniu i uproszczeniu wygląda tak: 

źródło: 

http://hddscan.com/doc/HDD_Tracks_and_Zones.html

 

DIF to sekcja, w której zapisana jest właśnie suma kontrolna CRC. Pisałeś wyżej, że system potrafi operować na bajtach, to nieprawda. Najmniejszą jednostką na dysku to sektor. Każda operacja zmiany jednego bajtu w sektorze musi owocować wczytaniem całego sektora. Po edycji sektora, w pamięci jest liczona suma kontrolna, która zapisywana jest własnie w strefie oznaczonej na rysunku jako DIF. Po skonczeniu operacji zapisu na dysku, sektor jest ponownie wczytywany, ponownie obliczana suma kontrolna i porównywana z sumą kontrolną zapisaną w DIF. Różnica owocuje popularnym błędem CRC, najpopularniejszym rodzajem bad sektora. Oczywiście rodzajów bad sektorów jest więcej. 

Każdy dysk zawiera pulę sektorów zapasowych, a operacja ich zamiany nosi nazwę mapowania czy remapowania, uszkodzone zostają dodane do G-list (w przypadku Seagate'ów, Samsungi zdaje sie mialy na ta inna nazwe, ale to taki detal). Takie remapowanie jest całkowicie transparentne dla systemu operacyjnego. Zamieniony sektor będzie miał ten sam adres LBA.

 

Cieszy mnie fakt, że w końcu szanowny autor zrobił coś sam. Zachęcam jednak do większego przyłożenia się, ponieważ został popełniony istotny błąd, który miał niby podważyć to co pisałem wcześniej. Nie można robić badań z jakąś intencją. Badania są po to, aby coś wyjaśnić.  

 

 

 

Co do klastrów - przecież masz napisane, że od systemów XP w górę rozmiar klastra wynosi domyślnie 4KB, wyjątki są tylko dla bardzo dużych woluminów opartych o macierze. Największy pojedyńczy dysk hdd to zdaję się 10 TB. Domyślny oznacza taki, który zostanie nadany przez system automatycznie w danej sytuacji. Ty używasz archaicznego FAT12, który jest tylko dla dyskietek ;-). Jako, że wcześniej nie rozróżniałeś czym się różni PBR od MBR, dodam,że być może z racji tego, że na dyskietce widziałeś PBR jako pierwszy sektor dysku, wyciągnąłeś wnioski, że to to samo co MBR. Otóż nie. Dyskietka nie zawiera w ogóle MBR ;-). Tak czy siak rozmiar klastra można samemu odczytać. Budowa BIOS Parameter Block (BPB) jest opisana na elektrodzie przez Okzo: 

http://www.elektroda.pl/rtvforum/topic891920.html

Łatwo zobaczyć, gdzie jest zapisana liczba o tym ile sektorów jest w klastrze, to trzynasty bajt.  U Ciebie na fat12 masz 1 sektor na klaster. 

 

Co się zaś tyczy bajtów 3-A - to tylko nazwa, którą możesz edytować .

 

 

Amerykanie numerują od zera własnie. My w Europie przyzwyczajeni jesteśmy od numeracji od 1. Nie wiem co w tym trudnego. Ty pokazujesz różne offsety - raz offset partycji, raz pliku. I jeszcze twierdzisz, że nie zawsze numeruje się go od zera ;-)

[Groszexxx]

W dniu 3.07.2017 o 12:34, Kowa1 napisał:

 

Przywrócenie Pliku wma tej wielkości ( czas trwania nagrania 127 sekund przy 72 kbps daje to wielkość pliku nie większą niż 1,2 MB ) po, nieokreślonym przez Pana dokładnie, formatowaniu 256 megowego pendriva to faktycznie dziecinada. Adekwatna do poziomu rozumowania.

Dalej brak  zrozumienia, że system plików nie ma żadnego znaczenia. Czy to będzie ext2,ext3, fat, ntfs, hpfs, reiserfs - to wszystko bez znaczenia. Nie trzeba byc geniuszem ani Sherlock Holmesem, żeby zauważyć, że stąd się wzięła nazwa "raw recovery". Ponadto w systemach windows, gdy jest uszkodzony lub nieznany system plików to wolumin wyświetlany jest własnie jako RAW.

 

W dniu 3.07.2017 o 12:34, Kowa1 napisał:

Dysk 9 giga zapisany w dwóch trzecich albo nieco więcej systemem, oprogramowaniem, danymi ok 6 giga pofragmentowanych plików.

Przy tym stanie instalacja kolejnej aplikacji do ściągania plików wma z dyktafonu. Scięgnięcie czterechech plików ( największy około 146 MB - pełna pamięć dyktafonu czyli wielkość wszstkich plików - 256 MB ) na ten dysk logiczny. Praca nad plikami: kopiowanie dzielenie, łączenie z i bez przekodowywania ( wyniki tych operacji zapisywane w innych plikach bez naruszania plikó źródłowych) ....

Odzyskiwanie sygnaturowe jest możliwe tylko dla plików niepofragmentowanych. O tym też już było bardzo wyraźne wspominane. Oczywiście nigdy nie wiemy czy poszukiwane przez nas pliki są pofragmentowane czy nie. Odzyskiwanie po sygnaturach to prosta rzecz. Jeżeli znajdziemy sygnaturę i zastosujemy metodę nr 2 tak jak opisywałem to w poście nr 8 - to jeśli plik będzie w jednym fragmencie oraz sygnatura będzie faktycznie należeć do niego (nie tak rzadko zdarzają się "false positive", czyli sygnature owszem, zostanie znaleziona, ale będzie należeć do czegoś zupełnie innego, czasami antywirusy mają w swoich zasobach takie kwiatki, gdzie hurtem są różne sygnatury listowane.

 

 

W dniu 3.07.2017 o 12:34, Kowa1 napisał:

 

Format ( pełny ) dysku xFAT32 ( szczęście bo NTFS lub inne to już kaplica - dlaczego? okazja do popisu ).

Było już powtarzane wielokrotnie, że system pliku nie ma znaczenia. No, ale to nie pierwszy przypadek na forum, gdy ktoś jest hermetyczny na wiedzę .

 

 

W dniu 3.07.2017 o 12:34, Kowa1 napisał:

 

Tak się składa niestety że format, pełny format spod windowsa, nie tylko czyści tablice ale fizycznie na dysku co jakąś wielkość sektorów kilka sektorów wypełni a bajtami #FF.

Po formacie zapisanie na dysku systemu z backupu. System zapisywany od początku dysku bez defragmentacji plików gdzieś do pojemności 2,4 GB.

Tak było i poprzednio przed pracą na dysku która zapełniła go do pojemności 6 GB - i tylko dlatego jest nadzieja że pomimo defragmentacji plików na dysku zapisy na nim będącym użytym w objętośći ok 6 GB nie sięgneły poniżej 2,4 GB od początku dysku więć zapisanie na nim plików systemu do 2,4 GB nie miało wpływu ( nie nadpisało ) poszukiwanych plików a jedyny problem to problem formatowania które w nieodpowiednim miejscu mogło wsadzić te bajty #FF.

 

W takim razie czas na kolejny, prosty test. Pendrive 8 GB.

Poszukajmy na nim w naszym hexedytorze wspomnianych sektorów wypełnionych samymi wartościami FFFFFFFFFFFFFFFFF.

Do dzieła!

Są pierwsze trafienia. Nie będę wrzucał podobnych screenów, jest jeszcze kilka podobnych miejsc. Stwórzmy więc plik, który całkowicie wypełni wolne miejsce na naszym woluminie. Wykorzystamy tą samą metodę co poprzednio:

Ktoś mógłby powiedzieć: - Ale momencik! Nasze sektory wypełnione FFFFF dalej istnieją, nic się nie zmieniło!

Proszę nie być zbyt naiwnym, jest oczywistą rzeczą, że żaden plik, który realnie waży 3,5 GB zostanie stworzony w ułamku sekundy. Tak naprawdę fsutil ww. komendach operuje tylko na rekordzie w mft, zaś realna wartość atrybutu $Data zostaje bez zmian. Mamy jeszcze możliwość wyzerować cały nasz plik zanim to jednak zrobimy - screen z mapy klastrów, która zawiera dane alokacji plików:

Obszar zaznaczony na niebiesko należy do jednego pliku. Nie ma żadnej wątpliwości, że sektory, które wcześniej były wypełnione FFFF należą do klastrów objętych tym plikiem, co zresztą zaraz będziemy weryfikowac. Wyzerujmy wszystkie sektory tego pliku. Żeby to zrobić najpierw musimy się dowiedzieć, które sektory zajmuje. Do tego służy atrybut Data we wpisie mft. Zajmę się tylko analizą samego atrybutu data i to powierzchowną, tylko po to, aby odczytać położenie fragmentów plików:

Pierwsze zaznaczenie oznacza początek atrybutu $data, drugie to położenie ekstentów data runs (pierwszy bajt atrybutu traktujemy jako 0), trzeci to oczywiście początek spisu ekstentów data runs.

 

Pozwolę sobie zacytować samego siebie z innego forum, gdy miałem nieco inny przykładem, to tak w gwoli wyjaśnienia.

Źródło: http://www.elektroda.pl/rtvforum/topic1054920-240.html#13608601

Najpierw oryginał:

Być może miało to jakiś cel i było zamierzone, ale wyszedłem z założenia, że Okzo temat zna doskonale, a intencją było podzielenie się wiedzą i próba nauczenia innych. Jako, że jestem początkującym - spory szmat czasu poświęciłem, żeby coś z tej lekcji wyciągnąć i za przysłowiową "cholerę" nie mogłem tego ogarnąć.

Sprawa okazała się dużo prostsza. Gdy użyje się odpowiednich kolorków to jest banalna.

Zaczynamy:

A używając tych samych kolorów co Okzo, będzie to wyglądać tak:

 

Opisy rzecz jasna się zgadzają (dziwne, żeby było inaczej ).

 

Takie przedstawienie jest dużo czytelniejsze. Przynajmniej dla mnie. Jeśli się zgodzicie - to wymyślcie jak tą sytuację poprawić.

 

Troszkę rozszerzę jeszcze opis:

12 23 04 04 22 32 07 46 09 22 13 11 86 17 00

 

Run 1

Header=0x12

Lenght=0x423

Offset=0x4

(0x423+0x4=0x427) co daje przedział 4-1063 klaster. (0x4-0x427)

 

Run 2

Header=0x22

Lenght=0x732

Offset 0x94A (0x946+0x4) co daje przedział 2374-4216 klaster (0x946-1078{0x946+0x732})

 

Run 3

Header=0x22

Lenght=0x1113

Offset=0x20D0 (0x1786+0x94A) co daje przedział 6022-10393 klaster (0x1786+0x2899{0x1786+0x1113})

 

Od siebie jeszcze dodam, że dwa zamieszczone tam przykłady o ile są życiowe, to wartość edukacyjną mają ograniczoną.

 

Dorzucę od siebie jeszcze dwa przykłady:

 

run1

lenght 38

offset 342573

 

run2

lenght 114

offset 363758 (211E5+342573)

 

run3

lenght 42

offset 393802 (300aa+363758)

 

Czas na nasz przykład:

13 75 E5 0B 2D 33 82 A7 00 48 2F 1D 32 6D 03 E0 CC EE 23 A0 C2 00 EB 03

0x0be575 > 779637

0x2d > 45

od 779637 do 779682

 

0xa782 > 42882

0x1d2f48 > 1912648+45=1912693

 

0x036d > 877

0xeecce0 > * -1127200+1912693 =785493

 

* - tutaj mała sztuczka, o której powinienem był wspomnieć na początku, słowa kluczowe to: system uzupełnień do 2. U2. Gdy zamienimy tę liczbę na binarną: 111011101100110011100000, ogólnie kodowanie liczb jest jako signed, a więc pierwszy bit jest zarezerwowany na znak. 1 oznacza liczbę ujemną, 0 dodatnią. Weźmy poprzedni offset, który był dodatni, a więc 1d2f48, zamieńmy go na l. binarną: 11101001011110100100000, ktoś powie, że z przodu jest jedynka - proszę pogrupować cyfry od prawej: 0001 1101 0010 1111 0100 1000 na kalkulatorze widać to od razu:

Teraz nasz przykład:

0xEECCE0 > 111011101100110011100000 > -1127200

kalkulator: http://www.free-test-online.com/binary/signed_converter.html

0xc2a0 > 49824

0x3eb > 1003+785493=786496

 

Potwierdzenie wyliczeń:

Początkowe numery klastrów zaczynające ekstenty danych pliku. Z lenistwa nie wyliczyłem dokładnych zakresów.

 

Czas na wyzerowanie w dmde wszystkich klastrów należących do pliku, tutaj na przykładzie tylko pierwszego fragmentu:

O, prawie sam z rutyny zapomniałem, że w DMDE operujemy w tej opcji na sektorach, a nie na klastrach .

 

Jak przeliczyć klastry na sektory?

Na początek trzeba wiedzieć, że klaster zerowy, a więc pierwszy klaster woluminu to boot sektor partycji (pbr), jego lokalizacja jest zapisana w MBR (opisy mbr, pbr, mft znajdziecie tutaj: http://www.elektroda.pl/rtvforum/topic891920.html , ktore zostały wyjasnione przez mój autorytet w tej branży legendarnego Litwina o nicku Okzo.

Na pierwszym screenie mamy info o tym, że bootsektor znajduje się w lba 2048 (to domyslna wartosc, gdy tworzymy partycję w windowsie od visty wzwyż. Na xp był to sektor 63)

tak więc do liczby 2048 dodajemy liczbę klastrów pomnożone przez 8, a więc:

sektor początku klastra (45)

2048+8*45 =2408

sektor końca klastra (779682)

2048+8*779682-1=6239503

Sprawdźmy nasze wyliczenia, posłużymy się innym, popularnym hexedytorem - HxD, potrzebny tutaj tylko w kontekście opcji wypełnienia

pliku. Zaznaczamy cały plik ctrl+a, następnie edit > fill selection - wpisujemy wzór i zatwierdzamy. Ja musiałem robić na trzy raty, przy próbie wypełnienia całego pliku miałem komunikat o braku pamięci, ale to detal.

Zobaczmy jak wygląda teraz sektor skrajny sektor pierwszego kawałka pliku, tj 6239503 i następny tj 6239504:

Jak widać:

Nasze wyliczenia okazały się całkowicie poprawne.

 

Następnym miejscem, gdzie pojawiły się tajemnicze FFFF był obszar pliku metadanych $LogFile, który jest rodzajem dziennika, w którym zapisywane są wszystkie operacje oczekujące na zapis. Chodzi o zachowanie integralności plików, dobrym przykładem jest np. operacja dokonywana w pliku rejestru, którego gałęzie są atomowe. Atomowość gałęzi oznacza, że rejestr zapewnia atomowość poszczególnych operacji. Każda jego modyfikacja wykona się poprawnie lub nie. Nie może być sytuacji, gdy jakaś wartość będzie zawierała część starej wartośc i nowej. Także nawet awaria zasilania, sprzętu czy oprogramowania nie jest w stanie sprawić, aby powstała wspomniana hybryda starych i nowych wartości. Rejestr albo zostanie przywrócony do poprzedniego stanu albo zachowa nową wartość. Nie jest istotne czy te wartości należały do niego czy są pozostałością po poprzednich systemach plików na tym pendrivie.

 

Czas na format, użyjemy standardowego formatowania w windows za pomocą gui. Zobaczmy co się stanie z naszymi danymi.

Na początek wyszukiwanie pliku o wartości FF

 

Ten sam plik, $LogFile. Jest jednak pewna ważna różnica. Już po samej mapie alokacji widać, że ten plik jest większy niż poprzedni. Gdy przyjrzymy się poprzednim granicznym wartością lba między poprzednim $LogFile, a naszym plikiem test.bin (test.txt) zobaczymy, że niektóre nasze dane zostały nadpisane:

 

Dlaczego tak się stało i czy użytkownik Kowa1 ma rację, że windows wypełnia co jakiś czas FFFF ?

 

Jak to możliwe? Czy Kowa1 naprawdę ma rację, że "ale fizycznie na dysku co jakąś wielkość sektorów kilka sektorów wypełni a bajtami #FF." ?

Odpowiedź poniżej.

Jeszcze tylko na screenie zaznaczony jeden fragment, gdzie sektory sa wypełnione FFFF

 

Porównajmy nasze metadane sprzed i po formatowaniu:

W drugim przypadku plik $LogFile jest ponad 3x większy!

Na tym screenie metadane po formatowaniu w AOMEI Partition Assistant i Minitool Partiton Wizard Home Edition

 

W spoilerze moje stare zdjęcia odnośnie położenia $MFT i $MFTMirr w zależności od użytego programu do formatowania:

 

 

 

 

 

 

Przeprowadzimy jeszcze raz ten sam test, z tym, że tym razem użyjemy tego samego programu do formatowania od microsoftu (wbudowanego w win7), plik z filmem kopiuję na pena, tworzę kolejny nowy plik, który wypełni wolne miejsce, zmieniam jego atrybut dane na ciąg znaków hex: 66 69 78 69 74 70 63 2E 70 6C co w ASCII daje: fixitpc.pl

Formatujemy i sprawdzamy różnicę. 

Co zmienia się podczas formatowania opisane jest tutaj: 

 

 

Teraz popatrzymy co dzieje sie przy formatowaniu dysku NTFS

NTFS formatowanie dysku :

Buduje się boot-sektor w formacie ntfs

Generuje się nowy seryjny numer dysku i zapisuje się w boot sektor, offset 48h

Oblicza się nowa suma kontrolna boot-sektor i zapisuje się offset 50h,

Buduje się nowy plik MFT, zawierający informacje o wszystkich plikach na dysku i zazwyczaj zapisuje się nadpisując stary plik MFT (wyjątków tu nie ma). We wszystkich przypadkach pierwsze ~24 zapisy (File Record) będą zniszczone bezpowrotnie.

W tych zapisach znajduje sie sam $MFT, $MFTMirr, folder root, /$LogFile - plik transakcji,/$BITMAP - mapa wolnej przestrzeni,/$Secure- deskryptory bezpieczeństwa i inne służbowe pliki

Inicializuje się $MFT:$DATA - ustala się nowa długość ($MFT:$30.AllocatedSize, $MFT:$30.RealSize, $MFT:$80.AllocatedSize, $MFT:$80.RealSize, $MFT:$80.CompressionSize, $MFT:$80.InitializedSize, $MFT:$80.LastVCN), data/czas zbudowania/ostatniej modyfikacji ($MFT:$10.FileCreationTime, $MFT:$10.FileAlertedTime, $MFT:$10.FileReadTime, $MFT:$30.FileCreationTime, $MFT:$30.FileAlertedTime, $MFT:$30.MFTChangeTime, $MFT:$30.FileReadTime) i najważniejsze, buduje się nowy spis odcinków (data-runs), bezpośrednio nadpisując stary, a to oznacza ze zbierać fragmentowany $MFT trzeba będzie po kawałkach

Buduje się nowy /$BITMAP-plik odpowiedzialny za podzielenie przestrzeni dyskowej (wolne i zajęte klastry) znowu nowa zawartość nadpisuje stara, ale to tez można odzyskać z chkdsk.

Buduje się nowy plik dziennika transakcji - /$LogFile,

Do nagłówka zapisu $MFT wprowadza się nowy LogFile Sequence Number w skrócie LSN;

$MFT naznaczany jest nowy numer kolejności aktualizacji (Update Sequence Number);

Buduje się lustro $MFTMirr, bezpowrotnie zacierająca stare (znajduje się po środku partycji NTFS ),

Budują się nowe /$Volume, /$AttrDef i inne pliki służbowe.

Przeprowadza się sprawdzenie powierzchni i wszystkie odnalezione uszkodzone klastry zapisywane do pliku /$BadClus;

Formuje się nowy folder root

Jeżeli do formatowania partycji istniał /System Volume Information-plik, to on po prostu odnawia się, w przeciwnym razie /System Volume Information buduje się tylko po restarcie komputera;

Jak widać po formacie zostają wszystkie dane, które były na dysku, tylko z wyjątkiem niektorych szczegółów samych metadanych zmiana których utrudnia odzyskiwanie , ale nie na tyle, żeby to było niemożliwe.

Przy tym klasyczna metoda zerowania za pomocą MHDD niszczy dane całkiem, nadpisując bezwzględnie każdy sektor zerami, softowe kasowanie można liczyć na dzień dzisiejszy za jeden z najbardziej dostępnych i najskuteczniejszych. Mozę nie jest najszybszy , ale używając odpowiednich metod można to przyspieszyć, przy tej samej skuteczności niszczenia danych.

Źródło: http://yura.puslapiai.lt/prob/odzyskiwanie_plikow.html

 

 

 

 

 

Postanowiłem zerknąć na poprzednie posty autora, widzę, że powtarzają się pewne schematy, stare nawyki. Lata mijają, a brednie zostają, dalej szanowny autor powtarza głupoty. Dla mnie to jasno dowód na to, że nigdy tak naprawdę nie zależało Ci na tym, aby pewne rzeczy wyjaśnić. To nie jest forum związane z polityką, na których tak lubisz się udzielać. Albo coś wiesz i podajesz źródła do swoich sytuacji albo nie wiesz i wtedy słuchasz. Ty ani nie wiesz ani nie chcesz słuchać. W tym problem:

 

 

 

W dniu 19.04.2012 o 00:30, Kowa1 napisał:

Mam pod WinXP zainstalowanym na FAT32, dodatkowe partycje też FAT, zamknięte kosze tak że dane są likwidowane permanentnie. Takie zlikwidowane permanentnie dane można jednak odzyskać. Służy do tego wiele różnych programów: Ontrack EasyRecovery, Active@, R-Studio, PC INSPECTOR czy najprostszy Undelete. Mam testowałem, potrzebowałem. W zasadzie wszystkie działały identycznie z wyjątkiem PC Inspektora bodajże, czy jakiegoś innego, który miał możliwość wybierania rodzaju pliku do odzyskania oraz przywracania pokawłkowanych przez nadpisanie chociaż fragmentów plików np Worda czy Excela. Programy te mają opcje odzyskiwania nawet po sformatowaniu. I faktycznie po sformatowaniu dysku pod win98 ( formatowanie w tym systemie co ileś klastrów czy sektorów w pisuje ścieżkę FF# czyli nadpisuje dane ) odzyskałem większość, ok 80%, plików bez uszkodzeń - aż byłem zdziwiony !

Pod Win98se też miałem zamknięte kosze a dodatkowo dla pewności usuwałem DEl-em z Shft-em co pod Total commaderem powoduje permanentne usuwanie bez przenoszenia do kosza. I po takim usunięciu dawało rade pliki odzyskać.

 

Z konieczności musiałem się przesiąść na XP ( ustawienia kosza opisane na początku ) choć bardzo niechętnie i moja niechęć została boleśnie potwierdzona. Nieopatrznie skasowałem kilka katalogów których skasować nie powinienem. Momentalnie wyłączyłem zasilanie i spod systemu uruchomionego na innym dysku usiłowałem odzyskać dane.

 

Żaden z wyżej wymienionych, i jeszcze parę innych, programów nie potrafił tego dokonać. Dane zniknęły jakbym je wymazał kilerem/wiperem ustawionym na siedmioprzebiegowe czyszczenie RussianGhostem.

 

Na innym dysku z FAT32 i innej partycji z NTFS jeszcze raz przetestowałem zjawisko. dokładnie to samo dane znikają jak w czarnej dziurze.

 

Urwał nać co jest grane ?

 

Szukam jakiejś informacji co się właściwie odbywa, czy WinXP sp3 ma natywnie istniejącego jakiegoś erasera który permanentnie czyści dane przy usuwaniu poza kosz. Permanentnie to znaczy że Dip advanced super scaning, co olewa fata i wcale z niego nie korzysta, nie znajduje nawet kawałka pliku.

 

Usuwał ktoś pod WinXP pliki od razu zupełnie ( tj bez przenoszenia do kosza i późniejszego usuwania z kosza ) i później je odzyskiwał ? Czy to się komuś udało ?

 

To nie tylko przeczy temu co wcześniej wypisywałeś o OT ER, już wcześniej miałeś w rękach całkowicie darmowy pc inspektor, który działa na tej samej zasadzie. R-studio również ma opcję odzyskiwania plików RAW, active@ nie znam. Nie chcę przyczepiać się do języka, pisanie, że coś się usuwa permanentnie, a potem coś się z tego jednak daje odzyskać - jest śmieszne. 

 

W dniu 19.04.2012 o 00:30, Kowa1 napisał:

Mam pod WinXP zainstalowanym na FAT32, dodatkowe partycje też FAT, zamknięte kosze tak że dane są likwidowane permanentnie. Takie zlikwidowane permanentnie dane można jednak odzyskać. Służy do tego wiele różnych programów: Ontrack EasyRecovery, Active@, R-Studio, PC INSPECTOR czy najprostszy Undelete. Mam testowałem, potrzebowałem. W zasadzie wszystkie działały identycznie z wyjątkiem PC Inspektora bodajże, czy jakiegoś innego, który miał możliwość wybierania rodzaju pliku do odzyskania oraz przywracania pokawłkowanych przez nadpisanie chociaż fragmentów plików np Worda czy Excela. Programy te mają opcje odzyskiwania nawet po sformatowaniu. I faktycznie po sformatowaniu dysku pod win98 ( formatowanie w tym systemie co ileś klastrów czy sektorów w pisuje ścieżkę FF# czyli nadpisuje dane ) odzyskałem większość, ok 80%, plików bez uszkodzeń - aż byłem zdziwiony !

Pod Win98se też miałem zamknięte kosze a dodatkowo dla pewności usuwałem DEl-em z Shft-em co pod Total commaderem powoduje permanentne usuwanie bez przenoszenia do kosza. I po takim usunięciu dawało rade pliki odzyskać.

 

Z konieczności musiałem się przesiąść na XP ( ustawienia kosza opisane na początku ) choć bardzo niechętnie i moja niechęć została boleśnie potwierdzona. Nieopatrznie skasowałem kilka katalogów których skasować nie powinienem. Momentalnie wyłączyłem zasilanie i spod systemu uruchomionego na innym dysku usiłowałem odzyskać dane.

 

Żaden z wyżej wymienionych, i jeszcze parę innych, programów nie potrafił tego dokonać. Dane zniknęły jakbym je wymazał kilerem/wiperem ustawionym na siedmioprzebiegowe czyszczenie RussianGhostem.

 

Na innym dysku z FAT32 i innej partycji z NTFS jeszcze raz przetestowałem zjawisko. dokładnie to samo dane znikają jak w czarnej dziurze.

 

Urwał nać co jest grane ?

 

Szukam jakiejś informacji co się właściwie odbywa, czy WinXP sp3 ma natywnie istniejącego jakiegoś erasera który permanentnie czyści dane przy usuwaniu poza kosz. Permanentnie to znaczy że Dip advanced super scaning, co olewa fata i wcale z niego nie korzysta, nie znajduje nawet kawałka pliku.

 

Usuwał ktoś pod WinXP pliki od razu zupełnie ( tj bez przenoszenia do kosza i późniejszego usuwania z kosza ) i później je odzyskiwał ? Czy to się komuś udało ?

Sam odzysk plików też nie stanowi żadnego problemu po usunięciu, jak i dokładnej struktury wszystkich folderów, chociaż jest tutaj parę wyjątków.

Pisałem o tym tutaj: 

https://www.fixitpc.pl/topic/26497-misja-forensic-wwwhackthissiteorgmissionsforensic/