Build application (exe) self-check if it is digitally signed - is it possible?

[approximately_whatever]

Hi,

Is it possible for a build application (exe) to check if it is digitally signed with my certificate (that was used in the build specification)?

The reason in need this is because I suspect my client is running an unauthorized exe in production that was build from modified source code. My clients always receive source code for projects, but with a caveat that any modification will void waranty. I suspect this one client is doing a bait-and-switch with the exe's in order to have a legitimate reason for invoking the warranty calls.

I was thinking of implementing a self-check in the app init phase (maybe include this piece of code as a lblibp so it can't be modified) and hide the result somewhere in the logs (for proof).

Or are there any better ideas for dealing with such situations?

[wiebe@CARYA]

---

@approximately_whatever wrote:

Is it possible for a build application (exe) to check if it is digitally signed with my certificate (that was used in the build specification)?

---

It seems SignTool - Win32 apps | Microsoft Docs does that.

EDIT: It verifies if the exe ("signtool verify myfile.exe") is signed with a certificate issues by a trusted authority. I'm not sure if that's enough. I assume there's a way to actually get the info on the certificate to see who issued the certificate. I do not know if this would work for self signed (unauthorized) certificates.

EDIT 2: Using SignTool to Verify a File Signature - Win32 apps | Microsoft Docs

For any SignTool verification, you can retrieve the signer of the certificate. The following command verifies a system file and displays the signer certificate: "SignTool verify /v MyControl.exe"

---

@approximately_whatever wrote:

Or are there any better ideas for dealing with such situations?

---

Fire the customer 😋.

How do you interact with the customer? If all you have is the info they provide, nothing is going to help.

If trust isn't the basis of doing business, there's very little left. 

[wiebe@CARYA · Accepted solution]

Or use .NET:

Gives:

There's more to explore there...

[JÞB]

Give them all the source code you want.

But the ICON is proprietary 😉 the one encluded in the source distribution should be a big red X at about 75% transparency.  Your company's image/Logo is TM protected. 

I'm mean when customers violate my hard work. 

[johntrich1971]

You could use a CRC. Any changes to the exe will change the CRC for the executable. You create a CRC certificate when you create the release version of the executable.

[approximately_whatever]

Thanks for the ideas. I've decided on the .NET implementation because it's the simplest.

I will put this in the logging lvlibp component, so the code cannot be seen or changed, but the signature always gets logged. They can still change all the log entries, but it takes some work.

Also, I will put a "dirty pixel" somewhere on the GUI as a backup.

[wiebe@CARYA]

To some extend, source code control helps. If there source is changed, it will show in SCC...

Checking the signature seems like a pretty solid solution though.

My only concern is that even if you put the check in a ppl, it would be possible to replicate it's results (a dialog?). These things tend to be a battle of who's the smartest. It will never be 100% secure.

I'd consider being open about this. Careful, but open. Tell them you don't understand the problems they have, that you can only explain it if the exe isn't original. By them or any other way (don't accuse them without proof). That even if they did modify the exe, you're OK with that, but that it isn't a sustainable situation for you to provide support on that. That was the deal.

The first thing I would do is to put the original exe back (I hope you kept a record of shipped versions). If that fixes things, they either have to admit the version was modified, or admit that the cause was unknown but is now solved... Combine with an open dialog.

[approximately_whatever]

Yeah, dialog doesn't work.

This is a large company and the problem is only with one department. Some persons just can't be reasoned with ...

[wiebe@CARYA]

---

@johntrich1971 wrote:

You could use a CRC. Any changes to the exe will change the CRC for the executable. You create a CRC certificate when you create the release version of the executable.

---

certutil -hashfile "myfile.exe"

returns the MD5 hash of the file.

Iff you have the original exe (or it's hash) you can check this without even programming anything.

[wiebe@CARYA]

---

@approximately_whatever wrote:

Yeah, dialog doesn't work.

This is a large company and the problem is only with one department. Some persons just can't be reasoned with ...

---

Sounds like at least you have some leverage...

You'd have to be very subtle, but if you'd let the other departments know that you have less time for them because this departments is wasting your time, that could open some gates.

Bleh. politics...