search

EricZimmerman / SQLECmd

MIT License
46 stars 20 forks source link

FileName is not Case-Insensitive #77

Open reece394 opened 2 months ago

reece394 commented 2 months ago

SQLECmd version # 1.0.0.0 .NET 6 Version

Describe the bug Using the KAPE SQLECmd: process SQLite databases SQLECmd.mkape rule I attempted to Parse Edge Browsing History. The Edge Browsing History I collected had lowercase file names based on the triage package tool I used to collect it such as history rather than the way the rules are written with a capital letter such as History. When I changed one of the rules Windows_ChromiumBrowser_Downloads.smap FileName field to lower case it immediately saw the file and processed it. Even more odd it also ran two other rules that had the capitalised name in FileName even though those files were not modified. Windows_ChromiumBrowser_HistoryVisits.smap and Windows_ChromiumBrowser_KeywordSearches.smap

To Reproduce Steps to reproduce the behavior:

  1. Collect Triage Package with Edge Browsing History that has downloads, web history and keyword searches
  2. Rename Triage Package with Edge Browsing History History file to lower case history and delete all other files for testing
  3. Run KAPE and run the SQLECmd: process SQLite databases - SQLECmd.mkape rule on the modified triage pack
  4. SQLECmd will run and will not output any results even though the history file is present.
  5. Rerun after opening Windows_ChromiumBrowser_Downloads.smap and modify the FileName: History field to FileName: history
  6. SQLECmd will run and will output three CSVs

Expected behavior SQLECmd should see the file regardless of case and process it.

EricZimmerman commented 2 months ago

is this net462 or net6.0? Please do a run with --debug and --trace enabled so i can see where things are falling down

EricZimmerman commented 2 months ago

i cant reproduce this. seems to work with H or h in both places

image

image

reece394 commented 1 month ago

Here is a series of logs with the --debug and --trace flags running. Seems like when the history file is not renamed or put in the rule it doesn't even bother looking for it. And yes I even deleted the SQLite.Interop.dll it was complaining about and did the same thing.

The SHA1 hash of the SQLECmd.exe I am using is bf80494b3603656a28778834c4e6ab2b10a63ece and the SHA1 hash of the SQLECmd.dll is 33b06358ec10d38d182b49b9483431b179e43f58 to help you get the specific version I am using. The runtime config indicates version net6.0 but putting this info here in case there is a mismatch but seems to line up with the latest .net6 version hosted on ericzimmerman.github.io

The logs should be fairly self explanatory but I will detail them anyway.

SQLECmdConsoleLogBeforeHistoryrename.txt is running them as is no modifications to any maps or filenames SQLECmdConsoleLogAfterHistoryrename.txt is running it with just the history file in the triage renamed from history to History SQLECmdConsoleLoghistoryoneRule.txt is running it with the history file in the triage back to lower case history plus modifying Windows_ChromiumBrowser_HistoryVisits.smap to lower case history SQLECmdConsoleLogDeletedSQLiteInterop.txt is reverting everything back to lower case history and Windows_ChromiumBrowser_HistoryVisits.smap to uppercase History but deleting SQLite.Interop.dll showing that that wasn't the issue. Thanks for looking into this for me. I can't seem to figure it out either when I had a skim of the code

SQLECmdConsoleLogAfterHistoryrename.txt SQLECmdConsoleLogBeforeHistoryrename.txt SQLECmdConsoleLogDeletedSQLiteInterop.txt SQLECmdConsoleLoghistoryoneRule.txt