Self-Compiled SbieDrv.sys different than WHCP-signed version

[Ailbeenlynd]

I was able to use VS2019 community edition to compile Sandboxie Classic from source code using all default settings. I then disassembled my self-compiled SbieDrv.sys and the WHCP-signed SbieDrv.sys from the same release and compared the two. For earlier versions of Sandboxie (e.g., right after the Sophos hand over), the two SbieDrv.sys were usually roughly identical with only minor differences, however, for later versions, the WHCP-signed SbieDrv.sys always contains a few more unknown functions than the my self-compiled file. Why is that? I understand that different compiler/linker settings could contribute to that, if that's the case, can those settings be shared? Ideally, it'd be good to see both the self-compiled SbieDrv.sys and the downloaded/WHCP-signed version be identical, so we can safely use the WHCP-signed driver. I am not saying those extraneous functions are illegitimate, but would like to understand how they got into the driver that's supposedly built from the same code. thanks

[DavidXanatos]

The driver that gets signed is whats produced by the CI build mechanism run by github, you can pick the corresponding build artifacts from https://github.com/sandboxie-plus/Sandboxie/actions all binaries from the right action should be identical to the signed once, except ofcause for the attached signature.

[Ailbeenlynd]

When built with CI, the two matched. All's good, thanks for your hard work!

[Ailbeenlynd]

Sorry, all is not good yet... you added driver enforced signature verification. We don't have your privatekey, I can't just use your WHCP-signed SbieDrv.sys without also using your Start.exe, SbieCtrl.exe and SbieSvc.exe, is that right? I guess I can't disable signature verification in the driver either, since then I will lose the WHCP signature. This additional protection is a bit too restrictive for those wanting to self-compile but can't afford to WHCP sign their driver.

[Ailbeenlynd]

Thank you. Does SbieDrv.sys only enforce signature for SbieSvc.exe or all 3 .exe's with .sig? I am testing on an older version, it seems to work with the signed SbieSvc.exe with SbieSvc.exe.sig alone (without the signed Start.exe and SbieCtrl.exe).

[DavidXanatos]

all 3 exec, but its mostly critical only for SbieSvc.exe,
start.exe is mostly not affected
sandman.exe and sbiectrl.exe must be signed to be able to controll process excemptions, that is clicking allow on a allow network prompt or alike, and to set itself as session leader.

I could add an option to a specific certificate to disable this signature enforcement, making it a developer certificate, would that be of interest?

[Ailbeenlynd]

How would that work? Do you mean you would add exceptions to the standard release SbieDrv.sys to bypass signature enforcement if the .exe's are signed with a specific developer certificate? This would create a security loophole if the developer certificate is made publicly available? I must be missing something

[DavidXanatos]

No a user could install a special developer certificate instead of a regular supporter certificate which would for their PC disable the signature enforcement, and only their PC the certificate could be generated to be bound to their specific HwID, like business use certs are.

[Ailbeenlynd]

That makes sense. I don't think I need that level of exception for my usage scenario yet, maybe wait to see if others are interested? I will look into the custom kernel signer route you referenced, thanks for the offer and always being responsive!

[love-code-yeyixiao]

In a word,you may not use self-complier driver in a completely normal environment.

…

---Original--- From: ***@***.***> Date: Sun, Sep 8, 2024 02:28 AM To: ***@***.***>; Cc: ***@***.***>; Subject: Re: [sandboxie-plus/Sandboxie] Self-Compiled SbieDrv.sys differentthan WHCP-signed version (Discussion #4214) That makes sense. I don't think I need that level of exception for my usage scenario yet, maybe wait to see if others are interested? I will look into the custom kernel signer route you referenced, thanks for the offer and always being responsive! — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>