search

dod-cyber-crime-center / sqlite-dissect

DC3 SQLite Dissect
Other
53 stars 8 forks source link

"No handlers could be found for logger "sqlite_dissect"" #37

Closed InfiniteBSOD closed 5 months ago

InfiniteBSOD commented 1 year ago

Hello,

Running the precompiled binary for Windows x64 for v.0.2.0 found here: https://github.com/dod-cyber-crime-center/sqlite-dissect/releases/tag/v0.2.0

I am trying to recover records in the "Cookies"-database for Chrome/Edge located either in: C:\Users\\AppData\Local\Google\Chrome\User Data\Default\Network [Chrome] C:\Users\\AppData\Local\Microsoft\Edge\User Data\Default\Network [Edge]

and issuing the following command: .\sqlite_dissect.exe "C:\Users\<my-user>\AppData\Local\Google\Chrome\User Data\Default\Network\Cookies" -d "C:\Users\<my-user>\Desktop\sqlite_dissect\" -e sqlite --carve and it returns:

Parsing: C:\Users\<my-user>\AppData\Local\Google\Chrome\User Data\Default\Network\Cookies...
No handlers could be found for logger "sqlite_dissect"

Exporting history as SQLite to C:\Users\<my-user>\Desktop\sqlite_dissect\\Cookies-sqlite-dissect.db3...
Finished in 0.08 seconds.

Now the end result is a "db3"-file but no deleted cookies recovered. Steps to reproduce: 1) Go into Edge / Chrome 2) Settings > Privacy & Security > Cookies > See all data and site permissions 3) Open up the "Cookies"-DB in SQLite DB Viewer 4) In the table "cookies" take note of exisiting cookies and using the opened Chrome/Edge Settings-page delete all cookies from a certain host 5) Refresh the table in SQLite DB Viewer to see that the cookies for host X are deleted 6) Run sqlite_dissect 7) Open the recovered DB / the output file

Just wondering if the error (?) "No handlers could be found for logger "sqlite_dissect"" can impact the carving result?

kchason commented 1 year ago

The error you were seeing appears to be due to the logging.basicConfig call that sets up the logging handler (output location, format, logging level, etc) and it doesn't get registered if the --log-level command line flag is set to "off" which is the default if not provided.

There's a linked pull request in to address this issue, but if you provide the --log-level flag in your command with the current version, it should properly register the handler and the error should no longer appear.