Pozostałości po rekordzie w sqlite

Krótki(?) wpis w nawiązaniu do historii o uwierzytelnieniu w aplikacjach mobilnych i danych, które mogą wyciec z uwagi na wykorzystanie baz sqlite. Postanowiłem przeprowadzić prosty eksperyment – zapisać w bazie pewien rekord, a następnie zmodyfikować go na kilka sposobów:

W każdym z przypadków spróbuję znaleźć w systemie plików pozostałości tego rekordu. Tajna wartość brzmi tak:

MAGICPMQ00

Dodatkowe założenie – testy wykonywane na FAT32.

Po przygotowaniu bazowego pliku, trzykrotnym jego skopiowaniu, podmontowaniu (ImDisk) i wykonaniu w każdym innej sekwencji operacji pozostaje poszukać markerów. Rezultat tego wyszukania jest poniekąd zgodny z oczekiwaniami:

C:\spool\sqlite>strings -o * | grep MAGICPMQ C:\spool\sqlite\1-update.img: 8205816:#MAGICPMQ000 C:\spool\sqlite\2-insert-delete-vacuum.img: 8206849:MAGICPMQ000'

Jak widać zarówno w przypadku UPDATE, jak i sekwencji INSERT, DELETE, VACUUM marker jest ciągle do odnalezienia na dysku, konkretnie w miejscu, gdzie był plik -journal.

Co w przypadku sekwencji DELETE, INSERT, VACUUM? Gdyby nie została wykonana operacja VACUUM, wartość nadal byłaby do odzyskania z pliku -journal. Kolejna operacja (VACUUM) jednak tworzy kolejny dziennik w tym samym miejscu na dysku (ale nie ma gwarancji, że zawsze tak będzie), więc siłą rzeczy dane zostają nadpisane i marker ginie.

Tematowi można się przyjrzeć nieco dokładniej. Ciekawym tematem jest też to, jak system operacyjny wybiera miejsce w systemie plików, gdzie należy zapisać dane. Jeśli do tego jeszcze dodać wear leveling, sprawa robi się jeszcze bardziej skomplikowana...

Oryginał tego wpisu dostępny jest pod adresem Pozostałości po rekordzie w sqlite

Autor: Paweł Goleń