FSX Bypass Gauge Security

[eric_marciano]

Hello experts,

I think this question has already been asked but I couldn't find any answer in this forum.
I develop gauges in C++ for FSX. C/C++ developers know that each time you generate the gauge with the development environment, it must not be loaded in FSX, so each time you do a modification, you must select another aircraft, generate the new gauge, reselect the aircraft hat uses the gauge to see the change. But what I hate is that each time you do this, you have a security warning asking if you trust this new gauge, then it asks if it is a trusted gauge: 2 popup windows and 2 clicks.
Even if you set it as a trusted gauge, it will ask again because any change in the gauge will make it appear as a NEW gauge. This is a pain.

Is there a way to temporarily bypass this security warning for a given time and/or for a given gauge?
It would make each update easier and quicker...
When developing gauges, I do this dozens of times, so it would save time

Thanks for any help.
Eric

 

[WarpD]

Use Prepar3D.

 

[=rk=]

The dialog prompts a rewrite of the fsx.cfg so once accepted, a gauge or module is trusted from then on. You could add this entry to the fsx.cfg yourself.

 

[eric_marciano]

The dialog prompts a rewrite of the fsx.cfg so once accepted, a gauge or module is trusted from then on. You could add this entry to the fsx.cfg yourself.

I thought about this, but even if a gauge is part of the "trusted", the dialog appears again. This is because when I modify the gauge and regenerate it, FSX sees it as a new gauge even if the file name is still the same. This is because the hash is different. The hast is this strange code that is computed for each gauge and appears in the [Trusted] section after the file name. As soon as a new version of the gauge is created, the hash changes and the dialog appears again, asking me it is is trusted or not.

 

[ddawson]

If you don't have one, get a digital signature. You can then sign the gauge as part of the post-build events. You can indicate to FS to always trust that particular signature and then you should have no further issues.
Globalsign appears to be offering code signing certificates for free:
https://www.globalsign.com/en/code-signing-certificate/code-signing-tool/

 

[eric_marciano]

If you don't have one, get a digital signature. You can then sign the gauge as part of the post-build events. You can indicate to FS to always trust that particular signature and then you should have no further issues.
Globalsign appears to be offering code signing certificates for free:
https://www.globalsign.com/en/code-signing-certificate/code-signing-tool/

Yes, I thought about this solution, I used it some years ago when I released the Wilco Airbus Series. Wilco Publishing had bought a certificate I used it to sign the gauge for the first release of the Airbus Series.
But this solution has 2 problems:
- It requires to buy a certificate to sign the gauges, it is not free. I am surprised about Globalsign and I will watch this link carefully (it seems it doesn't apply for DLLs). Anyway, I guess it is not so expensive.
- Each time you regenerate the gauge, you need to resign it using the certificate. As explained before, the hash is different for each version so it needs to be signed at each generation. This may take more time than clicking on the FSX popup window... To avoid this, maybe I can add the signature as a post-link operation so that it is automated in the development environment (Visual Studio).
Nevertheless it is probably the best answer to my question, I will look at it carefully and will try to find an optimal solution.

 

[ddawson]

When the dialog box pops up asking for permission to load a signed gauge, there is an option on the left hand side of the dialog that allows you to expand the dialog. You then have the option of always trusting that particular certificate. If you select that option, you won't ever be asked for permission for any gauge signed with that certificate.

 

[=rk=]

The hast is this strange code that is computed for each gauge and appears in the [Trusted] section after the file name.

It is not so strange at all.

is just one example. Here's another, this one's virtual. I am guessing it is the MD5 hash.
Of course you would have had to edit this as well, or did you already confirm MSDN uses some obscure indecipherable algorithm?

 

[kalong]

many thanks to remain me. I have to delete content on [Trusted]. from 314Kb after delete the content of trusted it only left 7Kb. though it always generate new line in it, when new dll need to be test.

 

[eric_marciano]

It is not so strange at all.

is just one example. Here's another, this one's virtual. I am guessing it is the MD5 hash.
Of course you would have had to edit this as well, or did you already confirm MSDN uses some obscure indecipherable algorithm?

It is not strange for me, I know what it is but it may look strange for people who don't know what a hash is and what it is for. Flight Sim expertise does not require any knowledge abot hashing
I wrote this because I didn't know if you knew it or not, it appears that you know and I am happy about this, you can forget the "starnge" word

 

[CDGonzalezG]

The dialog prompts a rewrite of the fsx.cfg so once accepted, a gauge or module is trusted from then on. You could add this entry to the fsx.cfg yourself.

I see here that the hash FSX generates each time a new version of the DLL gauge is loaded, is not like a MD5 or SHA1 hash or maybe it is, but unfortunately, MD5 or SHA1 hashes are generated using Base16 characters (0-9, A-F) and this is not the case here because all hashes generated contain only alphabetic characters (from A to Z) and no numeric characters. So, it's a bit hard to determine how FSX generate that kind of hashes.

Mine is even generated in the same way:

[Trusted]
D:\Software\12bPilot\SODE\SimObjectDisplayEngine.exe.enoiowtozcziatnoahauztkhrnbzwhqziiolhaza=1
D:\Software\12bPilot\SODE\SimObjectAnimationModule.dll.zikohwuiahieurkzhicooncczutettcrziuichch=1
D:\Flightsims\FSX\Modules\MV_WXM.dll.iakhkeeuicwrianrqwheacitwhbchhlllhrhatqw=1
D:\Flightsims\FSX\GAUGES\KingAir.DLL.renlnnhkuoizukbbianietnbirtehuuqlzbzueah=2
D:\Flightsims\FSX\GAUGES\Cessna172.DLL.zqlnabornnanqenbqeeboqeckuwlurtulbiuiaoz=2
D:\Flightsims\FSX\GAUGES\KingAir_Radio.DLL.wqcokebwlwhotnquoiqhtncuzcaonlrikahurrlr=2
D:\Flightsims\FSX\GAUGES\Magnetic_Compass.DLL.zzhrqiwkqwhbtbiuwaorzzczoccbrzkaueawaaiz=2

 

[eric_marciano]

Yes, that's right. But would it help if you could understand how the hash is generated?
Would you update the fsx.cfg each time the gauge is generated?

 

[eric_marciano]

I looked here and there and I found out you can create your own "internal" certificate and sign the DLL with it, it will be recognized as trusted as soon as this certificate is stored in your Windows certificate store. So this looks like a good solution for developers who use this certificate only for themselves, during the development phase.
Unfortunately, I couldn't find the way to create this kind of certificate. The available tools I found run only on Linux or Windows Server

 

[CDGonzalezG]

I looked here and there and I found out you can create your own "internal" certificate and sign the DLL with it, it will be recognized as trusted as soon as this certificate is stored in your Windows certificate store. So this looks like a good solution for developers who use this certificate only for themselves, during the development phase.
Unfortunately, I couldn't find the way to create this kind of certificate. The available tools I found run only on Linux or Windows Server

The good news is that it'd be a great idea, especially if I want to debug it constantly.
The problem is that one you lastly mentioned Eric. For example, if you want to run any Linux application, you can do so on Windows, but you need Windows 10 because that version contains the Windows Subsystem for Linux component.
But I'll find out if I can find an alternative to that WSL component, but for Windows 7.

 

[DragonflightDesign]

Ed (WarpD) is absolutely right (as usual ). If you develop in P3D, simply switching Scenarios allows you to compile the gauge into P3D with closing the sim. Load your test Scenario and away you go. When it works in P3D, run the 32-bit compile instead and load up FSX for a final check.

 

[eric_marciano]

Ed (WarpD) is absolutely right (as usual ). If you develop in P3D, simply switching Scenarios allows you to compile the gauge into P3D with closing the sim. Load your test Scenario and away you go. When it works in P3D, run the 32-bit compile instead and load up FSX for a final check.

I know Ed is right, but I don't have P3D at this time. I will soon have the v4, but I need to test my addons on a 32 bit platform as well.

 

[WarpD]

They make a 32-bit version...

 

[eric_marciano]

They make a 32-bit version...

Yes, but I can't have FSX, P3Dv3 and P3Dv4 on my PC. I mean, maybe I can, but I don't want to...
And I will work for a company that will provide me P3Dv4, they will not give me P3Dv3 and I don't want to buy it. Buying a certificate would be cheaper