MAGICPMQ000 &mdash; Paweł Goleń, blog https://wampir.mroczna-zaloga.org/tag:MAGICPMQ000 Fri, 15 May 2026 13:53:57 +0000 Pozostałości po rekordzie w sqlite https://wampir.mroczna-zaloga.org/pozostalosci-po-rekordzie-w-sqlite <![CDATA[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. !--more-- 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_ smallAutor: Paweł Goleń/small]]> 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...

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

Autor: Paweł Goleń

]]> https://wampir.mroczna-zaloga.org/pozostalosci-po-rekordzie-w-sqlite Sat, 20 Oct 2012 17:12:00 +0000