When Good Signatures Go Bad – Part 2
It has been a busy few weeks. Like Steve, I was in Florida but I didn’t get to meet any famous mice or Mounties. I was meeting with partners and helping spread the word about Windows Mobile and LOB solutions. One of the partner products showcased along the way was Checkpoint’s SecureClient Mobile which does a great job of maintaining a VPN when roaming across various networks and connection paths. Check it out…
Anyway, I wanted to finish off my post about certificates and signatures and move on to some other topics of interest. It’s hard not to dwell on security since so many questions on Windows Mobile root back this area… we’ll visit it again down the road.
Part 1 of this post talked about how to verify certificates on a device. The more practical questions come up with code signing itself and troubleshooting signed code…how do you know if code is properly signed?
If you can’t call privileged APIs...
Stay away unless you really need them, but if you can’t seem to call privileged APIs, then you may have signed code with the wrong cert (the standard M2M or Developer cert instead of the privileged one). You can use CeGetCallerTrust in your startup code as a good way to check for privileged access. If you it returns OEM_CERTIFY_TRUST then you should have privileged access. If not, then there may be a problem with the signature or your certs.
What if you still get “unsigned publisher” prompts or cannot call privileged APIs?
If we’re talking about a CAB that continues to prompt during install, the single most common culprit is that you may have failed to sign some of the CAB contents (executable components that were packaged inside the CAB). You have to sign the CAB *and* its executable contents in order to pass security checks at install time. I commonly see developers forget to sign a component or update the developer signature to the release signature. If you are using CabSignTool, it makes sure everything that needs to be signed, gets signed…but not everyone is using this yet.
To check the signature...
Start by examining the signatures on each component to make sure each is really signed. Check the CAB first and then decompress the CAB (WinZip should do this just fine) and look at all the contents. When you decompress a CAB, the files inside will have names that don’t make much sense (e.g. – abc.000, efg.001, etc.). The filenames will be abbreviated versions of the original name, followed by a numeric extension. These are the original files, but the CabWiz has renamed them. If you can’t make sense of them – just look at the _setup.xml file to make real names to the temp names if needed ( _setup.xml is your friend and will tell you all kinds of good stuff). Now just work through all of the files and check for the presence of a signature on each. If it’s a CAB, a DLL, an EXE, and an MUI it needs to have a valid signature.
To spot check each signature, right click on the file (or the CAB) and look at the Digital Signature tab (if it’s signed it will have a Digital Signature tab). Choose Details->View Certificate->Certification Path. In a perfect world, your certificate chain will look similar to the image below and chain all the way to the root (this is what a good VeriSign M2M Privileged cert chain looks like).
If you had signed with an unprivileged developer cert, it might look like this:
The final step would be to “View” the root certificate in the chain and compare the thumbprint. If I did this on the CAB signed with the VeriSign cert above, you would see that it matches the M2M privileged certificate thumbprint.
To verify the thumbprint you need the certificate chain to resolve all the way up to the root. This doesn’t always happen because Mobile2Market roots are not installed on your desktop and unless they are, the chain won’t show correctly when you examine it. This kind of makes it hard to tell if you are looking at a valid signature and/or verify where it came from in many cases. You need the M2M roots installed for the desktop UI to resolve this correctly. To do this, you have to extract the M2M certificates off a device using the CertificateStore CSP and then paste them into a .cer file and import them on your desktop (grab the attachment to this post to save yourself some time extracting these certs).
On a final note – people often ask if they need to get their code signed again for the newer platform releases. The answer is no. The M2M signatures didn’t change between WM2003, WM5, or WM6 so if you have signed code then it should continue to pass security checks on the newer devices. You might want to look at updated Logo and Certification criteria for newer platforms though.
Cheers,
Reed
Comments
Anonymous
June 20, 2007
The comment has been removedAnonymous
July 02, 2007
As long as the signatures are linked to valid certs, I don't think they have to match. I'll double check and verify... Thanks, ReedAnonymous
September 10, 2007
WindowsMobile开发人员可以使用设备安全管理器配置设备的安全设置。当应用程序在WindowsMobile设备或仿真器上安装和执行时，将会应用这些安全设置。这些设置将决定一个未签名的...Anonymous
September 10, 2007
Windows Mobile 开发人员可以使用设备安全管理器配置设备的安全策略。当应用程序在 Windows Mobile 设备或仿真器上安装和执行时，将会应用这些安全策略。本文介绍了 Visual Studio 2008 Beta2 自带的设备安全管理器的使用方法。Anonymous
September 10, 2007
Windows Mobile 开发人员可以使用设备安全管理器配置设备的安全策略。当应用程序在 Windows Mobile 设备或仿真器上安装和执行时，将会应用这些安全策略。本文介绍了 Visual Studio 2008 Beta2 自带的设备安全管理器的使用方法。Anonymous
June 17, 2008
  If you are anything like me, I walk away from events like Tech-Ed with an overflow of informationAnonymous
June 23, 2008
Over the years, I’ve delivered several “Top 10” sessions and called them different