Mobile Apps - Is there a way to install more root certificates on a phone
Asked By Anthony Wieser
09-Nov-09 05:03 AM
I have just started developing for WM 6.5 on an HTC Touch2, and every time I
deploy for debugging, I get a warning about an unknown publisher.
My program is signed with a Comodo Code Signing certificate issued to my
company.
Is there a way to add to the trusted root authorities on a device, so the
device can recognize my signed code? Pointers to documentation on this
greatly appreciated, as I have not had any luck on google.
--
Anthony Wieser
Wieser Software Ltd
DLLs
(1)
Mobile2Market
(1)
Comodo
(1)
Windowsmobile
(1)
Authenticode
(1)
Authorities
(1)
Remembers
(1)
Windows
(1)
Christopher Fairbairn [MVP] replied to Anthony Wieser
Hi,
It is possible to add new root certificates to the certificate store,
however if your devices are prompting you when you install "unsigned" or
unpriviledged code it is possible you may also not have enough permissions
on the device to install certificates to the appropriate store. You also
have the chicken and egg scenario of how to install the certificate without
prompting the user.
See http://support.microsoft.com/default.aspx/kb/915840 or
http://www.jacco2.dds.nl/networking/windowsmobile-certinstall.html for
details on how to install custom certificates.
If you want your application/cab files to install without prompts on
customer devices to my knowledge the only practical way is to purchase a
Mobile2Market code signature
(http://www.verisign.com/code-signing/content-signing-accounts/microsoft-windows-mobile/index.html).
Or release your software via the new Windows Mobile marketplace...
If this is just your development device, you may like to use the Device
Security Manager utility (found in VS2008's Tools menu) to alter your
device's security policy to one which does not prompt for unsigned code.
Documentation is at http://msdn.microsoft.com/en-us/library/bb384149.aspx
Hope this helps,
Christopher Fairbairn
Anthony Wieser replied to Christopher Fairbairn [MVP]
Thanks for your suggestions. I did eventually figure this out and it went
something like this, as my phone was not locked.
1. Export the root certificate from certificate manager on your PC that
corresponds to your authenticode signature
2. Copy the certificate to your device, which should be installed
automatically.
The problem was that I was seeing a message that "this program depends on a
component from an unknown publisher". Eventually I figured out that that
means that the debug MFC DLLs are not signed. A release build just works.
It also implies that I need to sign my DLL's as well as exes.
When I do sign my code, I timestamp it and countersign.
Does anyone know how loader works when the original certificate expires?
On a PC there istill is no warning, but on this device, I am not so sure.
Also, it seems that the device somehow remembers that I allowed the code
once, and then does not complain again. Any idea how that is achieved?
Anthony Wieser
Wieser Software Ltd
XIP dlls Mobile Apps I develop a device that runs an application that uses multiple dlls. These dlls are big (around 4 MB and 6 dlls for at total of around 24 MB). This leaves us only a little space in we somtimes go out of memory. I read that it is possible to have XIP dlls that would load in slot 1 intead for slot 0. This would allow us to free memory. Does XIP dlls are slower at execution? Would it be possible for me to change theses dlls without having to recompile and reinstall the OS on the device? Of course we develop located into slot 0 when ROMIMAGE. Ok but would it be possible to have these dlls on a flash and have the ddls loaded after the driver? This would allow us
Default DLLs or SYSGENs found in WM5 Mobile Apps 3 Questions: 1: Does anyone know of the default DLLs (or SYSGENs) that *must* be in *all* Windows Mobile 5.0 devices, versus optional DLLs which *may* be present, versus DLLs that will *not* be present? 2: Relating to this question: If Windows Mobile 5 does not* come with a SYSGEN, and therefore related DLLs, is it possible for a Windows Mobile 5 software vendor to use PB 5 to generate the missing SYSGEN, and related DLLs, and then include some, if not all of the DLLs, for redistribution with the WM5 application? 3: If this is not generally acceptable, how can could.) WindowsCE Embedded Discussions Windows Mobile 5.0 (1) OpenNETCF (1) SYSGENs (1) LIBs (1) DLLs (1) Tacke (1) Redist (1) Whan (1) This would be covered under the WM NDA
XIP Dlls Mobile Apps Hi, Can some one please tell me more about XIP (eXecution In Place) Dlls. I heard that this mode determines how the dlls will be loaded into memory. Whether it is on demand basis or it will be not in used. Am I correct to state this? Sincerely Jimmy WindowsCE Platform Builder Discussions Dlls (1) AC5104510FD7 (1) XIP (1) Since you didn't say, I guess I'll assume CE5. XIP DLLs are executed in their default location, with no decompression or movement to RAM. That is your nk.bin image is written into linear flash and executed directly from flash, XIP DLLs will also be executed directly from flash. Non-XIP DLLs will be loaded from their image in flash, decompressed, and placed in RAM for execution So, no, you're not correct. XIP DLLs are never 'loaded'. They just sit where they are in the OS image and are
limitations we have experienced are the following: - 25 Mb per process - 12 Mb for the DLLs (independently from the number of processes) - DLLs can only be loaded in the "first" 12 Mb of each process For example: 1. If a process loads 4 Mb of DLLs, then 8 Mb of data, he can no longer load DLLs, but can still load data. A second process launched in parallel will be able to load a maximum 8 Mb of new DLLs, then data. 2. If a process loads 12 Mb of data, it can no longer C. Clearly, process 3 is close to trouble if it attempted to load any more DLLs that had not been loaded already by other processes. This is a somewhat contrived example to be incredibly large, or Process 2 would have to load a large number of DLLs for this problem to occur naturally." We do have a large number of DLLs, some of which are quite large and the previous example is no longer contrived in