Crash when running SharpChrome logins

[technion]

I'll start by saying - I'm fully aware this can be hard to assess given you won't have the same compiled file I do.

I'm working on a git clone from today, and I've set it to compile with .Net 4.7.2. I'm on a Windows 11 machine with January 2026 updates, and I'm wondering if this is a similar issue to #43 involving the size of a structure changing.

SharpChrome.exe logins

  __                 _
 (_  |_   _. ._ ._  /  |_  ._ _  ._ _   _
 __) | | (_| |  |_) \_ | | | (_) | | | (/_
                |
  v1.12.0


[*] Action: Chrome Saved Logins Triage


[*] Triaging Chrome Logins for current user


[*] AES state key file : C:\Users\User\AppData\Local\Google\Chrome\User Data\Local State
[*] AES state key      : 4767800FC297384BAB8EC061C017D9885C6D8412113468A99A8BE66599E9333E

    size             : 41
    type             : chrome
    offset             : 40

[!] Unhandled SharpChrome exception:

System.ArgumentException: Destination array is not long enough to copy all the items in the collection. Check array index and length.
   at System.ThrowHelper.ThrowArgumentException(ExceptionResource resource)
   at System.BitConverter.ToUInt32(Byte[] value, Int32 startIndex)
   at SharpDPAPI.Dpapi.DescribeDPAPIBlob(Byte[] blobBytes, Dictionary`2 MasterKeys, String blobType, Boolean unprotect, Byte[] entropy)
   at SharpChrome.Chrome.ParseChromeLogins(Dictionary`2 MasterKeys, String loginDataFilePath, String displayFormat, Boolean showAll, Boolean unprotect, Byte[] aesStateKey, Boolean quiet)
   at SharpChrome.Chrome.TriageChromeLogins(Dictionary`2 MasterKeys, String computerName, String userFolder, String displayFormat, Boolean showAll, Boolean unprotect, String stateKey, String browser, Boolean quiet)
   at SharpChrome.Commands.Logins.Execute(Dictionary`2 arguments)
   at SharpChrome.Domain.CommandCollection.ExecuteCommand(String commandName, Dictionary`2 arguments)
   at SharpChrome.Program.MainExecute(String commandName, Dictionary`2 parsedArgs)

What's those extra print statements you ask? It's this debugging I added to DPapi.cs:

var guidMasterKey = new Guid(guidMasterKeyBytes);
var guidString = $"{{{guidMasterKey}}}";
// Adds
Console.WriteLine("    size             : {0}", blobBytes.Length);
Console.WriteLine("    type             : {0}", blobType);
// End adds

if (!blobType.Equals("rdg") && !blobType.Equals("chrome"))
{
    Console.WriteLine("    guidMasterKey    : {0}", guidString);
}
offset += 16;

if (!blobType.Equals("rdg") && !blobType.Equals("chrome"))
{
    Console.WriteLine("    size             : {0}", blobBytes.Length);
}
Console.WriteLine("    offset             : {0}", offset); // Adds

So if I'm reading this right, we have a 41 byte buffer, a 40 bye offset, and an attempt to read four bytes. I have tried the fix that @leechristensen proposed in in #43 but that doesn't change this issue.

Edit: A suggestion as to what's going on, I see code for a newer V10 header, but here we have an app that handles two newer headers:

https://github.com/fantasywastaken/Chrome-App-Bound-Decryption

[leechristensen]

I believe this has to do more with how Chrome has changed out how it stores the state key. We have an upcoming post that has some solutions (implemented into Nemesis already) but we haven't ported the fixes here yet.