fix: windows decrypt patch#1227
Conversation
Greptile SummaryThis patch replaces the Chromium-provided
Confidence Score: 3/5The include swap may re-introduce BoringSSL macro conflicts that the shim was designed to prevent; the decryption path should be validated against the exact Chromium target before merging. The sole code change — swapping The single changed patch file Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[DecryptChromeValue called] --> B{Has v10 prefix?}
B -- No --> C[Return ciphertext as-is + LOG INFO]
B -- Yes --> D[Strip v10 prefix]
D --> E[DecryptAesGcm]
E --> F{Key valid 32 bytes?}
F -- No --> G[Return false]
F -- Yes --> H{Ciphertext long enough?}
H -- No --> I[Return false]
H -- Yes --> J[Extract nonce first 12 bytes]
J --> K[crypto::Aead AES_256_GCM Open]
K --> L{Decrypt OK?}
L -- No --> M[Return false]
L -- Yes --> N[Return plaintext]
subgraph ExtractChromeKey
P[GetLocalStatePath] --> Q{Local State exists?}
Q -- No --> R[kLocalStateNotFound]
Q -- Yes --> S[Parse JSON / FindDict os_crypt]
S --> T{Key found?}
T -- No --> U[kLocalStateParseError]
T -- Yes --> V[Base64 decode]
V --> W[DecryptWithDpapi]
W --> X{CryptUnprotectData OK?}
X -- No --> Y[kDpapiDecryptFailed]
X -- Yes --> Z{cbData > 0?}
Z -- No --> AA[Memory leak — LocalFree skipped]
Z -- Yes --> AB[LocalFree + return key]
end
%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
flowchart TD
A[DecryptChromeValue called] --> B{Has v10 prefix?}
B -- No --> C[Return ciphertext as-is + LOG INFO]
B -- Yes --> D[Strip v10 prefix]
D --> E[DecryptAesGcm]
E --> F{Key valid 32 bytes?}
F -- No --> G[Return false]
F -- Yes --> H{Ciphertext long enough?}
H -- No --> I[Return false]
H -- Yes --> J[Extract nonce first 12 bytes]
J --> K[crypto::Aead AES_256_GCM Open]
K --> L{Decrypt OK?}
L -- No --> M[Return false]
L -- Yes --> N[Return plaintext]
subgraph ExtractChromeKey
P[GetLocalStatePath] --> Q{Local State exists?}
Q -- No --> R[kLocalStateNotFound]
Q -- Yes --> S[Parse JSON / FindDict os_crypt]
S --> T{Key found?}
T -- No --> U[kLocalStateParseError]
T -- Yes --> V[Base64 decode]
V --> W[DecryptWithDpapi]
W --> X{CryptUnprotectData OK?}
X -- No --> Y[kDpapiDecryptFailed]
X -- Yes --> Z{cbData > 0?}
Z -- No --> AA[Memory leak — LocalFree skipped]
Z -- Yes --> AB[LocalFree + return key]
end
|
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| +#include <windows.h> | ||
| + | ||
| +#include <wincrypt.h> |
There was a problem hiding this comment.
wincrypt.h can conflict with BoringSSL macros
base/win/wincrypt_shim.h exists in Chromium precisely because <wincrypt.h> defines macros (X509_NAME, X509_CERT_PAIR, X509_EXTENSIONS, PKCS7_SIGNER_INFO, etc.) that collide with BoringSSL definitions. The shim #undefs those symbols after including <wincrypt.h>. This file then includes crypto/aead.h (line 24), which pulls in BoringSSL transitively — with the shim removed, those macro conflicts can surface as compilation errors. If the shim path was the actual problem, the safer fix is to restore the shim and add a #pragma comment(lib, "crypt32.lib") in the build file rather than bypassing the shim altogether.
Prompt To Fix With AI
This is a comment left during a code review.
Path: packages/browseros/chromium_patches/chrome/utility/importer/browseros/chrome_decryptor_win.cc
Line: 13-15
Comment:
**Direct `wincrypt.h` can conflict with BoringSSL macros**
`base/win/wincrypt_shim.h` exists in Chromium precisely because `<wincrypt.h>` defines macros (`X509_NAME`, `X509_CERT_PAIR`, `X509_EXTENSIONS`, `PKCS7_SIGNER_INFO`, etc.) that collide with BoringSSL definitions. The shim `#undef`s those symbols after including `<wincrypt.h>`. This file then includes `crypto/aead.h` (line 24), which pulls in BoringSSL transitively — with the shim removed, those macro conflicts can surface as compilation errors. If the shim path was the actual problem, the safer fix is to restore the shim and add a `#pragma comment(lib, "crypt32.lib")` in the build file rather than bypassing the shim altogether.
How can I resolve this? If you propose a fix, please make it concise.Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
1 participant
No description provided.