maratoolHow to open a .crx file and read what an extension actually does
Drop a Chrome extension into the browser and read its manifest, its permissions and all of its source, without installing anything.
You download an extension to check what it does before trusting it. You get a .crx file. Double click it and nothing happens. Rename it to .zip and some archive tools open it while others refuse. The CRX viewer reads it directly and shows you what is inside.
How it works
- Load the extension. Drop in a
.crx,.zipor.xpi, or paste a Web Store URL or the 32 character extension ID. - Read the permission summary. Each permission the extension asks for is translated into one sentence about what it can reach.
- Read the code. Click any file in the tree, or search across every file in the archive at once.
Why the double click does nothing
A CRX file is an ordinary ZIP archive with a signature header stuck on the front. The first four bytes spell Cr24, then a version number, then either a public key and a signature (version 2) or a small protobuf structure holding the same things (version 3). Only after that does the ZIP begin, with its own PK magic number.
That prefix is the whole problem. Your archive tool looks at byte zero, finds something that is not a ZIP, and gives up. Some tools scan forward for the ZIP signature and succeed by accident, which is why the advice to rename the file works on one machine and not another.
It also means converting a CRX to a ZIP is not really a conversion. The ZIP is already in there, intact and valid. Removing the header is a matter of skipping the first few hundred bytes, so the download button here writes out the original compressed data untouched rather than repacking it.
Reading the permission list
The Web Store shows a permission summary written for a general audience. The manifest is more precise, and the interesting entries are the ones that describe reach rather than features.
storage and alarms are furniture. Almost everything uses them. What deserves a second look is <all_urls> in the host permissions, because it means page content on every site you visit is readable and editable. So does a content script whose matches pattern covers the whole web, since that code runs without you clicking anything. nativeMessaging means the extension talks to a program installed outside the browser, where the sandbox does not reach. debugger grants complete control of any page, including reading what you type into it.
None of these is proof of bad behaviour. A content blocker genuinely needs to see every request, and a password manager genuinely needs to touch every login form. The point is to know what you are agreeing to, then read the code that uses it. That is why the tool states each capability and names the manifest key it came from instead of printing a risk score.
One more thing worth checking: a content security policy that allows unsafe-eval or names a remote origin in its script-src. Either one means code can arrive after the extension was reviewed, so the source you are reading is not necessarily the source that runs.
Whether it is the extension it claims to be
Chrome does not store an extension's identity as a name. The 32 character ID in a chrome-extension:// URL is the SHA-256 of the publisher's public key, with each hex digit shifted into the letters a through p. Hash the key in the file, apply the same mapping, and you get the ID that key is entitled to.
This is how you catch a repack. Someone downloads a popular extension, adds a few lines, signs it with their own key and hands it out. The signature verifies perfectly, because it is a real signature. It just belongs to a different key, so the ID it produces is not the ID of the extension being impersonated.
Reading that correctly takes some care. A packed extension from the Web Store carries several signing keys, not one: the publisher's own key plus proofs added by Google. uBlock Origin Lite ships with three. Only one of them is the identity key, and it is the one whose hash appears in the signed header, so picking whichever key comes first in the file accuses honest extensions of being repacks. The viewer reports the signature, the derived ID and the ID you asked for as three separate facts, because the repack case is exactly the one where they disagree.