Is a DEcompiled ACCDB still DEcompiled after signing?

[AHeyne]

Hello everyone,

Unfortunately I don't have Microsoft Access 365, so I can't test it myself.

But I am interested in whether a decompiled ACCDB is still decompiled after signing?

Is there anything official to read about this, or official statements from Microsoft?

Or is it possible to decompile/compact a signed ACCDB using the command line parameter “/decompile /compact” without losing its signature?
I assume not, but perhaps one of you would be kind enough to test this?

Or does signing itself possibly even lead to decompiling/compacting?

 

[jwcolby54]

The sequence is decompile / compile / compact (and / repair in the old days).

AFAIK the source is not compiled until you do a compile.

 

[AHeyne]

The sequence is decompile / compile / compact (and / repair in the old days).

My sequence is to execute “/decompile /compact” twice in a row. But that's not the point here.

AFAIK the source is not compiled until you do a compile.

I would like to know if it is still decompiled after signing.

 

[isladogs]

@AHeyne
That's an interesting question that I hadn't considered before and was easy to test!

First of all, signing a compiled project does not cause it to become decompiled.

I tested signing a decompiled project both from within Access and using the new command line signing option.
In both cases, the project was compiled automatically and the project was signed.

I then tried the opposite and decompiled then compacted a signed project from the command line. The project remained signed!

Command Line Project Signing

This article describes the new command line project signing feature available in Access 365. It is useful for quickly signing a batch of VBA projects in succession without needing to open each app first.

www.isladogs.co.uk

EDIT:
One further test with a result that surprised me!
I made a deliberate error in my code to prevent a project compiling - MssgBox deliberately mispelt

I was still able to sign the project both from within Access and the command line even though it couldn't be compiled

 

[jwcolby54]

Woof. Sounds like some issues for MS to look at!

 

[isladogs]

I'm intending to mention the point in the EDIT to the Access team

 

[AHeyne]

Yes, please don't mention "I then tried the opposite and decompiled then compacted a signed project from the command line. The project remained signed!".
Just kidding. I hope this is by intention. I could live with it to decompile/compact after signing.

Thanks for testing Colin, I expected it would trigger you somehow.

 

[The_Doc_Man]

From my days as a U.S. Navy contractor, I believe the rule was that anything you did to a file AFTER you sign it revoked the validity of the signature. The implications of your finding, Colin, are definitely not good. It would tend to indicate that the compiled pseudo-code is treated as data, probably one of those "binary large objects" that show up in the MSysxxx tables.

That further implies that if you COULD edit the code (text) but not compile it after a code change and then still execute it, you could have a false compilation - where the pseudo-code doesn't match the text code. Which in turn means that it's a really good thing that Access compiles any code that is newer than the corresponding pseudo-code.

FOLLOW-UP: If the .ACCDB file is NOT split, does that mean that only parts of the file are included in the signature's scope? If you have local data in the FE file or any data in the monolithic file, does using the DB void the signature? What is the scope of digitally signing the file? If EVER something needed clarity, that would be an example.

- Richard

 

[AHeyne]

@The_Doc_Man : For me it is crucial to deliver decompiled versions of the ACCDBs, as we have had problems in the past with older versions of Microsoft Access correctly executing a database that was compiled with a newer version. Decompiling has always prevented this problem.

Conversely, Microsoft Access should not use the precompiled pseudocode to check the certificate, as it may ‘look’ different on different computers.

 

[isladogs]

Thanks for testing Colin, I expected it would trigger you somehow.

LOL!
I've forwarded a link to this thread together with my entire reply to the A-team and sincerely hope it will trigger a response from them as well.
As I wrote in that email

I believe the final test indicates a serious bug as it means projects could be distributed both signed and containing code with errors
That shouldn’t be allowed to happen!

Although its still incorrect, I'm less bothered by the fact that a project without errors remained signed after it was decompiled. The reason I'm less bothered is that making any changes to the code (correct or otherwise) will automatically invalidate the signature.

@The_Doc_Man
Code signing only affects the VBA project. Making data changes is entirely unrelated to VBA project signing.

 

[The_Doc_Man]

Generically speaking, a particular pseudo-code (on ANY machine) should always look the same... but this code is emulated/interpreted, so the code interpreter might be very different on different machines. Having machine-tailored pseudo-code is essentially a step that makes pseudo-code pointless. Because if you have taken the pseudo-code far enough to machine-tailor it, you are far enough to truly compile it to machine binary. It is precisely because it is PSEUDO-code that the VBA library can be as small as it is. It also makes the compiler easier to write.

 

[isladogs]

I have discussed the questions raised in this thread at some length with several current and former MVPs, all of whom stated that the behaviour I described in post #4 is exactly what they would expect.

In summary, the consensus from those MVPs was that:
A signed project indicates one that has not been altered in any way after being distributed by the developer whose signature is attached
In other words that code signing is an indicator of authenticity rather than quality.

They further correctly pointed out that a project that compiles on the developer’s machine may not do so on the end user’s workstation
e.g. if a reference is missing or its an ACCDE on the wrong bitness.

I accept all of those as valid arguments but the fact remains that code signing will always compile a project first where it can do so.

For that reason, I would prefer that where a project cannot be compiled on the developer’s machine, then the code signing should fail with a suitable error message such as - this project cannot be signed as it contains compilation errors

However, I haven't had any support for this idea and accept that it is very unlikely there will be any change in this regard.

The onus remains on the developer to ensure that projects can be compiled before they are signed and distributed

I have now summarised both the questions raised by @AHeyne and the subsequent exchange of opinions in a new section of my article:

VBA Project Signing 2: Q+A

The second part of this article is used to follow up questions arising from my article and YouTube video about the new VBA project signing feature in Access.

www.isladogs.co.uk

 

[AHeyne]

Thanks Colin for discussing it.
Perhaps the Microsoft Access team will also comment on this?

Irrespective of this: Would you be so kind as to upload a signed ACCDB so that I can test with old Access versions whether the signature can withstand a “/decompile /compact”?

 

[isladogs]

The Access team haven't commented but suspect they would have responded if they disagreed with the consensus view.

My code signing certificate expired recently and I haven't yet renewed it.
You can download many signed files from my website e.g. from https://www.isladogs.co.uk/vba-project-signing/index.html#DL
Of course, although still signed, all of these signatures will also have expired.

Nevertheless, its probably pointless you doing so as the big weakness of code signing is that it is only valid in A365.
So even if you open a currently signed project in an older version, it will be marked as unsigned.

 

[AHeyne]

Thanks Colin, I will take a look on your site.

My code signing certificate expired recently and I haven't yet renewed it.
You can download many signed files from my website e.g. from https://www.isladogs.co.uk/vba-project-signing/index.html#DL
Of course, although still signed, all of these signatures will also have expired.

As long as a timestamp was used at the time of signing, this should not be a problem.
Do you know whether timestamps are set during the signing process using Microsoft Access?

Nevertheless, its probably pointless you doing so as the big weakness of code signing is that it is only valid in A365.
So even if you open a currently signed project in an older version, it will be marked as unsigned.

This is an important point that wasn't clear to me yet. I thought only the signing process required a 365 version.

 

[isladogs]

As long as a timestamp was used at the time of signing, this should not be a problem.
Do you know whether timestamps are set during the signing process using Microsoft Access?

You've just raised the second major flaw with project signing Access files.
Unlike adding a code signature to .exe files where I always add a timestamp, the code signing process within Access does not support timestamping and AFAIAA cannot be modified to do so when using certificates stored on secure tokens (required since June 2023).

If you examine the (once) signed ACCDB file on the page I linked, you will get this information:

Viewing the file in A365, the certificate appears to still be in place:

However, as soon as you try to check the Detail, Access will check & detect it has expired, then discard the signature.

Although CoPilot provides information on editing the registry to allow timestamping, this dates back to when certificates were stored on the user workstation as a .pfx file. I've asked for information about adapting this for certificates stored on a secure token but am unable to check the details with no current code certificate to test with

I'm tagging @sonic8 into this reply as he may be able to add further clarification on this point

This is an important point that wasn't clear to me yet. I thought only the signing process required a 365 version.

My mistake. It probably also works with A2024 though I don't have a copy to use for testing purposes

 

[AHeyne]

It probably also works with A2024 though I don't have a copy to use for testing purposes

For sure it doesn't work with Microsoft Access 2019 Pro Plus Version 2504 (Build 18730.20186), thats what I tested.

If you examine the (once) signed ACCDB file on the page I linked, you will get this information:

Also not shown with my Access 2019.

Regarding the time stamp:
Time stamping shouldn't belong to the source of the certificate (file or token). But during the signing process an URL of a time stamp server must be provided (e.g. "timestamp.digicert.com"). Best would be a "RFC 3161" time stamp server that can handle/provide "SHA256".

In the course of signing from Microsoft Access, the question would now be who specifies this server? The user in a dialog or via command line, or would Microsoft Access have implemented a hard-wired URL?

 

[sonic8]

Although CoPilot provides information on editing the registry to allow timestamping, this dates back to when certificates were stored on the user workstation as a .pfx file. I've asked for information about adapting this for certificates stored on a secure token but am unable to check the details with no current code certificate to test with

If the suggested solution for timestamping actually ever worked (I strongly doubt it), it should still work regardless of where the certificate is stored.
The new (2023) requirement for secure storage is not technically enforced. It is just an agreement by the certificate issuers industry (organized in the CA/Browser Forum) that they will no longer issue any code signing certificates where the private key is not stored on secure hardware.
The actual signing and validation/verification process remains unchanged.

 

[isladogs]

Attached is the suggested solution from CoPilot which does indeed mention RFC 3161.
I haven't tested the suggested solution with a self cert (in the absence of a current code cert,) but also have doubts about whether it will work

For signing EXE files, I have been using a Sectigo time stamp

 

[AHeyne]

Thanks for sharing, Colin.

The registry aspect could answer my question from #17:

In the course of signing from Microsoft Access, the question would now be who specifies this server? The user in a dialog or via command line, or would Microsoft Access have implemented a hard-wired URL?

However, as I only have a valid certificate but no Access 365, I cannot test it.