So I have this challenge : Our system has several windows applications each doing some work. One particular application's exe would load DLL of other applications and call a particular method from the DLL.
For security reasons, we want to make sure if the DLL is authentic before loading it. As suggested online, we currently use windows cryptographic APIs to check for the digital signatures but the problem is, in my company, the digital certificate which signs the binaries itself might change although not frequently. And since the upgrade of each of the application is independent of the other, there's a possibility that some of the DLLs could be signed by the old certificate and some by new certificate.
Is there an efficient way to solve this?
Related
I have developed an application and want to publish to the microsoft store. I have tried using advanced installer but unless I pay $500 I cannot publish it i think using the trial version? I have also tried using MSIX Package (Windows) but then I need to digitally sign it, and then I can't add logos and etc. I also do not know how to get a certificate and convert it to .pfx format for this to work.
Honestly, this process has just made me want to stop, which is unfortunate. So I am trying to find a service or someone that I can pay to package my .exe app to an MSIX, signed and everything so that I can just upload it to the store on my account..but I cannot find anything on google.
Does anyone know of a service, or even a better application that has better guides for MSIX packaging and signing? Advanced Installer is pretty extensive, but their guides are based on MSI, not MSIX. Not worth paying $500 for when they are not even current with Microsoft Stores required format.
FYI - to get a useful answer around here it helps if you place specific questions (i.e. split your question into multiple ones, like: Do I need to digitally sign an application for the MS Store?; how do I add logos...?)
Back to your problem. I work on the Advanced Installer and I will try to give you some advice to help clear a part of your problems.
First of all, to publish an application in the Microsoft Store you don't need a certificate. As explained in our guide, in your Store developer account you will find a package identity assigned to your application, here is an example:
The value that starts with CN=... must be copied and pasted into your Advanced Installer project, on the Package Information page, under the ID field. Make sure Digital Signing is disabled in your project. (You need to digitally sign the MSIX only when you deploy it outside the MS Store)
This identity will allow the MS team to certify you as the owner of the application. Once Microsoft approves your application submission, the MSIX package you upload will be signed with a Microsoft digital certificate. All MSIX packages uploaded in the store are signed by Microsoft.
I don't know how complex your application is, but most apps can be packaged with the free Advanced Installer Express edition. Have you tried that? The commercial editions include additional features, but you might not need them.
MSIX Hero is pretty great and is open source. Assuming your application is just a directory of files containing one or more EXEs just click "pack directory to MSIX"
Then select the folder containing your application files and the EXEs you want to create shortcuts for in the start menu. It will pull a lot of the package metadata from the metadata in the EXEs.
If you are publishing to the Windows store you don't need to sign the package.
If you do want to sign it for distribution outside the store the options for that are pretty easy to use as well. The only issue is you will need a code signing certificate, which is ~$300 a year.
I'm trying to create a custom CSP(cryptographic service provider) and I'm kinda stuck at signing the csp dll. In the cspdk(cspdk) it is said, that I should use cspsign.exe to produce the signature file that can be included into the dll as a resource. But there's no such a file in cspdk or anywhere in windows.
So I began to google and found some posts that before 2013 people were sending their dll's to microsoft and got it signed in return. And after 2013 you are supposed to use microsoft authenticode and purchase code signing cert for it.
I'm in a development stage so there will be many many builds, so may be there is some simple way to get thing working.
So the question is how this process looks like in 2019?
UPDATE:
I found out that cspsign was a test utility for Windows 2000, so the cspdk is a little bit out of date. The question remains actual ..
Those sdks are so old, with newer versions nowhere to be found, and documentation so sparse. The only reference I found on a somewhat recent process is hidden in here, halfway through the page: Authenticode signing of CSPs
Note Starting with Windows 8, it is no longer a requirement that CSPs must be signed.
So, CSPs no longer need to be signed.
I was tasked with developing a way to change how applications retrieve certificates.
To be more precise: provide alternative ways for browsers to retrieve certificates to be used as client certificates on SLL connections other than having them read from the certificate store.
I found the Crypto tools on the windows API and the tools it provide to allow applications to read the certificate store. My current guess is that would have to involve changing the system's DLLs and there is no streamlined way of achieving my goal.
I need to store some passwords inside an android app. I have no way around since this particular app cannot do authentication with a remote server.
I was looking at this decompiler:
http://www.javadecompilers.com/apk
yet, I have a simple question that I see different answers online. Is it possible for a hacker to root my client's device, get the application (I assume the apk is inside the device somewhere), run a decompiler and look up the passwords?
Note that this a production app and will be signed and installed through the google store. This is not just an unsigned apk floating around.
thanks.
Yes someone could take your passwords. Signing your apk won't make a difference.
You can secure your passwords by storing hashes in the APK. Then even if someone decompiles your code and takes the hashes there's nothing they can do with them since they still won't have the plain text to send to the app.
If all you need to do is control access to your signed app then that should be good enough. Though it doesn't prevent an attacker from decompiling your signed apk, modifying it, and recompiling it into an unsigned one. There's no reliable way to stop this, like there is no way to stop video game piracy. But techniques like obfuscation can help.
Executables and DLL's can be digitally signed. It suggests trust to the user.
However, my research upon this topic is slowly leading nowhere. I think I need a complete step-by-step idiot's guide on how to digitally sign binaries, directly upon compilation. What I mean is: Click on "Build" and retrieve a signed executable. I really don't want to manually sign everything myself.
Visual Studio has a "Signing" tab in project properties, so I guess I have to look there. It seems like I need a .pfx file for that. But where exactly do I get one that contains my name and how do I use it correctly?
Also, does this cost money? - Per binary / only once / not at all?
Example of a signed binary:
I have always signed my dlls and applications manually. To make your signature last even after code sign certificate expires you need to add a timestamp to the signature.
To sign a dll/exe you need to buy the codesign certificate but there are CAs (i.e. if you are open source developer) where you can get it for free. One of them is Cetrum CA (which I am currently using). Take a look here. The process of obtaining it is a torture, but the certificate itself is OK. (it doesn't work with all browsers - use FF, single signon needs to be done on every page and mails are in Polish language.)
Timestamp can be obtained for free (i.e. from the link in Hanselmans blog or you can find a list of free RFC 3161 compliant timestamp authorities here)