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:
- przez UPDATE,
- przez sekwencję INSERT, DELETE i VACUUM,
- przez sekwencję DELETE, INSERT i VACUUM,
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...
