Stop reporting cache locations for files that do not exist - #320
Merged
Merged
Conversation
The Timeline's "Data / Value / Path" column named a file that has never existed for most Chromium cache rows. ccl's _get_location does not check Addr.is_initialized, and a null data address reports is_initialized False while still giving file_type EXTERNAL and file number 0, so it comes back as external file f_000000 at offset 0. Chromium never allocates external file 0. On the Edge profile in cellebrite.ctf_2021 that was 9066 of 21748 locations across 10874 entries; the Chrome profile beside it had 4. A path in the output is an invitation to go and look at the file, and a phantom one cannot be told apart from a real one, so each location is now checked against what the cache directory actually holds and dropped if it does not resolve. Checking presence rather than special-casing f_000000 also covers a cache directory that was only partially collected. Entries whose locations all fail leave the column empty, which matches their '<no data>' summary. The count is logged per cache directory. The column was also being built by calling str() on a dict of ccl location objects, and CacheFileLocation.__repr__ is missing its closing '>', so the text ran together as "...offset: 0, 'metadata': ...". It is now formatted here, as "metadata: data_3 @ 8192; data: f_000001". Firefox rows carried a bare 40-character cache2 entry filename, which is the SHA-1 of the cache key and so reads as a hash rather than as the location it is. Labelled "entry: <name>", matching the Cache API rows in the same parser. Also drops CacheItem.locations_str, which was assigned None in __init__ and never set or read anywhere.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Cache rows named a file that has never existed. ccl's
_get_locationdoesn't checkAddr.is_initialized, so a null data address comes back as external filef_000000at offset 0, and Chromium never allocates external file 0. On the Edge profile in cellebrite.ctf_2021 that was 9066 of 21748 locations.Each location is now checked against what the cache directory actually holds and dropped if it doesn't resolve, which also covers a partially collected cache. Rows where nothing resolves leave the column empty, matching their
<no data>summary. The column was also built by str()-ing a dict of ccl location objects, and their__repr__is missing its closing>, so the text ran together. It's formatted here now, asmetadata: data_3 @ 8192; data: f_000001.Firefox rows carried a bare cache2 entry filename, which is the SHA-1 of the cache key and reads as a hash rather than a location. Labelled
entry: <name>to match the Cache API rows in the same parser.Also drops
CacheItem.locations_str, assigned None in__init__and never read.Both ccl bugs are logged in future_work with repros. Suite green, no baselines moved.