Repository navigation
Fix CRX3 ZIP payload extraction - #951
Conversation
|
Hi @arunimshukla, |
Updates
|
Hi @babenek, thanks for preparing the fix and for testing it against different CRX files. I've merged your updates from arunimshukla#1 into this branch (2cf200c), so it's now in sync with the latest |
Enchancement & fix test
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #951 +/- ##
==========================================
+ Coverage 90.46% 90.49% +0.02%
==========================================
Files 166 166
Lines 7164 7172 +8
Branches 1205 1208 +3
==========================================
+ Hits 6481 6490 +9
Misses 456 456
+ Partials 227 226 -1 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Co-authored-by: Roman Babenko <[email protected]>
Co-authored-by: Roman Babenko <[email protected]>
Description
Before this change,
CrxScanner.matchaccepted CRX3 files, butzip_extractalways interpreted bytes 8–15 as the CRX2 public-key and signature lengths. For CRX3, bytes 8–11 are one protobuf-header length followed by the header, so the scanner could calculate the wrong ZIP offset and miss credentials inside modern Chrome extensions.Chromium format reference: https://chromium.googlesource.com/chromium/src/+/main/components/crx_file/crx3.proto
How has this been tested?
Benchmark was not run because this changes header parsing only and does not alter detection rules or model scoring.