Add Windows Search Index plugin

[JSCU-CNI]

Implements #283. Depends on two bugfixes in fox-it/dissect.sql#37 and fox-it/dissect.esedb#48.

[PimSanders]

@JSCU-CNI thanks for this contribution! @DevJoost and I had been working on this plugin before and we have some code that might be useful.

DevJoost's original implementation: searchindex.py

My additions: searchindex.py

My (very WIP) attempt to merge part of your and mine implementation: search.py

These changes rely on some additions to dissect.sql: sqlite3.py

As of writing I have made a POC for the following:
- Reading the path to the Windows Search Index database file from the registry
- Parsing additional data from the SQLite WAL file

Things that DevJoost has made and could be added:
- Parsing Windows-gather.db
- Writing additional data to the record

While comparing our implementations I was wondering about two implementation differences: would it be useful to add more fields to the records, like the SDID or owner? What is the advantage of not reading the WAL? As I understand it, this could be used to read the latest changes to the index and potentially track changes over time. Could you elaborate on these decisions?

[JSCU-CNI]

@JSCU-CNI thanks for this contribution! @DevJoost and I had been working on this plugin before and we have some code that might be useful.

DevJoost's original implementation: searchindex.py

My additions: searchindex.py

My (very WIP) attempt to merge part of your and mine implementation: search.py

How do you propose we continue? Do you see any fundamental implementation changes purely related to the searchindex plugin? You could fork our fork and open a PR on this branch so we can properly compare your changes against this feature branch.

These changes rely on some additions to dissect.sql: sqlite3.py

This seems useful - along with parsing the write ahead log file, but seems somewhat unrelated to this PR. Perhaps we can modify SQLite3() to allow it to be initialized with a Path object, so it can automatically parse the WAL if one exists. Most (if not all) public dissect.target plugins currently ignore the WAL.

While comparing our implementations I was wondering about two implementation differences: would it be useful to add more fields to the records, like the SDID or owner? What is the advantage of not reading the WAL? As I understand it, this could be used to read the latest changes to the index and potentially track changes over time. Could you elaborate on these decisions?

Parsing SDID or owner certainly seems useful, but out of scope from our point of view for now due to time constrains. Not parsing the WAL is not a deliberate decision, as elaborated above.

[PimSanders]

I think I will continue working on dissect.sql to implement the WAL parsing as you mentioned. When the search index plugin is merged I will look into parsing the other data fields.

[codecov]

Codecov Report

❌ Patch coverage is 86.77686% with 16 lines in your changes missing coverage. Please review.
✅ Project coverage is 80.92%. Comparing base (0e1c75f) to head (4927e2e).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
dissect/target/plugins/os/windows/search.py	86.44%	16 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1254      +/-   ##
==========================================
+ Coverage   80.90%   80.92%   +0.02%     
==========================================
  Files         376      377       +1     
  Lines       33412    33531     +119     
==========================================
+ Hits        27031    27134     +103     
- Misses       6381     6397      +16     

Flag	Coverage Δ
unittests	80.92% <86.77%> (+0.02%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[codspeed-hq]

CodSpeed Performance Report

Merging #1254 will not alter performance

_{Comparing JSCU-CNI:feature/windows-search-index-plugin (4927e2e) with main (0e1c75f)}

Summary

✅ 9 untouched