Trusted Certificate and limiting access to a DLL

  • Thread starter Thread starter Tim Johnson
  • Start date Start date
T

Tim Johnson

I'm not too familiar with the trusted certificate mechanism, I thought it
was mostly about installing things or accessing certain types of web
services. But is it possible to also use that feature to ensure that only
my exes can access my dlls, and outside (nonsigned?) exes cannot?

--

Tim Johnson
High Point Software, Inc.
www.high-point.com
(503) 312-8625
 
The only possible approach would be to use the InternalsVisibleTo attribute
to reduce the scope of APIs that are publicly accessbile, however this
would not stop another application from accessing your code through
reflection. Code Access Security (CAS) on the desktop framework can
restrict access to public APIs based on strong name, but this doesn't offer
much more protection than InternalsVisibleTo.

In general this is a difficult problem to solve once you've distributed
your assembly since any application with access to the file system can read
through it.

Ryan Chapman
..NET Compact Framework

This posting is provided "AS IS" with no warranties, and confers no rights.
 
I should have explained I'm talking about an unmanaged legacy C++ dll (so
maybe this is the wrong forum for it). Sorry for the confusion.

--

Tim Johnson
High Point Software, Inc.
www.high-point.com
(503) 312-8625
 
The more I'm looking into I'm now thinking the message is more about the
fact the my app is not trusted, since I never signed it with a certificate.
Not so much my attempting to access this other dll. Although building a
simple unmanaged C++ app in evc4.0 and downloading it by hand has no
problems and I don't get this message, so I don't get why WM5 bothers to
check trustedness on one app and not the other.

Could you point me to a place that describes what's required to sign my app
with a test certificate, just to see if that clears things up? I have some
info for the desktop but didn't know if there's something different for
doing it on WM5, or if it matters if it's not a .Net assembly. For example,
the various cert cmdline utilities are for the desktop only it appears.

--

Tim Johnson
High Point Software, Inc.
www.high-point.com
(503) 312-8625
 
Hi Tim,

Here are a few resources, but I'm not sure they'll give you all the info
you need...in particular, it isn't sufficient just to sign with a test cert
if that certificate doesn't map to one in the device's certificate store:

http://blogs.msdn.com/ryanms/archive/2004/10/26/248292.aspx
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnppcgen/ht
ml/wmsecurity.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnppcgen/ht
ml/smartphone_security.asp

VS 2005 gives you the option of signing applications with various
certificates. The code signing utility should work for mobile applications
as well as desktop ones as long as you sign with a mobile certificate.

The NetCF loader runs through the same security checks as the native OS
loader, so it makes no difference whether you are running managed or native
code when it comes to signing.

What is the message you are getting? It does seem strange that a random
unsigned app built with eVC would not invoke a security dialog, but another
app would--in theory, if security is enabled on your device, any unsigned
app should bring up a security dialog when it launches.

Ryan Chapman
NET Compact Framework

This posting is provided "AS IS" with no warranties, and confers no rights.
 
Thanks, I've darkened the doors of several newsgroups on this one lately
with only slightly better understanding. To be clear on this thread, I'll
tell the whole story again for future generations.

There's a hidden/system/inROM dll on my new HP WM5 device. I have an
existing unmanaged C++ evc4.0 app that has always been able to use it on
earlier versions, though before it wasn't hidden/system. I wrote a very
simple 1-line unmanaged C++ app and small dll in evc4.0 to reproduce the
problem.

If my test.exe makes an instance of a class from my test dll I have that
exports a class (using CTest x = new CTest( ); ), it all runs fine on the
PDA, no warning messages. If instead I make it use the class I really want
from the now-hidden dll (CTarget x = new CTarget( ); ), I get this message:

"Test.exe cannot be opened. Either it is not signed with a trusted
certificate, or one of its components cannot be found."

It turns out there's a lot of postings about this exact message, but mostly
having to do with using Exchange Server on the PDA or more likely on
SmartPhone, or using PocketIE and SSL websites. In my case it's about
running a 1-line C++ app!

This tells me it's one of those 2 things (footnote to MS - why not just tell
me which it is!). To test the "not found" part, I made my test dll be
hidden/system (though I can't make it reside in ROM of course), but my test
app still works. So my feeling was, it's not the "not found" part of the
message. Else how could my little app load my hidden/system dll ok, but not
load a hidden/system/INROM dll? It's right there, it has a non-zero size,
etc as seen in Resco's file explorer.

Then I turned to the "not trusted" part, which is how this thread started.
It started dawning on me that if this was the culprit, it wasn't so much
that my app wasn't signed with the same cert as the target dll (and now I
think I've learned that's just not how certs work anyway, there's no
"matching" certs to let an exe be allowed to use a particular dll); it was
more that my app wasn't trusted at all, ie not signed with ANY trusted cert.
When I use signtool verify on the target dll, it in fact says it isn't
signed/trusted either, fwiw. So why would the OS suddenly require my app to
be trusted when loading the ROM dll, but not when loading my dll, and only
now on WM5 and not on earlier PocketPC versions?

Nonetheless, I tried to make my simple test app signed to run my test. What
I discovered was that you not only have to use makecert and signtool to sign
your app with a test cert (on the desktop), you also have to install both
your cert and the "Root Agency" cert which "issues" the test cert. That's
on the desktop, and I finally managed to get it to work such that afterward
a "signtool verify" operation says, yes my test app really is finally
authenticoded (there's 2 days I'll never get back). So far so good.

But that didn't ultimately help on the PDA - if I just copy the "signed"
test.exe app and run it, same error. I understand now that's because I need
to sign it with a cert issued by some issuer the PDA already knows about
(like Verisign or GTE); or, I have to do the equivalent of an install cert
of my test-issuer (Root Agency) which is not normally an issuer the PDA
knows about. I still don't know how to do that part at the moment. And I'm
really not interested in spending any money for a real cert that works (is
recognized) by the PDA. There's also talk on the newsgropus of a
"de-certifier app" for the PDA to basically turn off certification checks -
but there's not one for WM5, only for PPC2003. Or maybe the OEM is
controlling this and they won't let their users change this feature. So I'm
blocked at every turn for about a week now...

BUT - it could very well be that even if I have a legitimate signed test app
I might still get the message. Right now I'm looking around for a free cert
from an issuer recognized by WM5 on a PDA. But basically, I don't
understand which of the 2 options in the error message is the real cause,
and I've been trying to track it down systematically. And nobody can tell
me what could be causing it.

Note, I don't WANT to have to sign my actual production app. But it appears
I might have to just to access this ROM dll. Which I don't get.

Unlesss of course it's really the "not found" part after all.

Which I also don't get. :)

--

Tim Johnson
High Point Software, Inc.
www.high-point.com
(503) 312-8625
 
Hi Tim,

This is a good one, I feel like I get a chance to put my real sleuthing hat
on...

From your description, it really doesn't sound like the signing is the
problem. If your app wasn't signed properly, it wouldn't be able to run at
all. Since you're running on a PPC, the security model should be running
in 1-tier mode which means that as long as you are running, you're allowed
to do whatever you want.

So my guess is that something about the file is making it hard for the
system to find. Can you try a simple LoadLibrary on the DLL and see what
happens? Try it a few different ways: with a path and without, and if it
returns NULL, check out the error from GetLastError. This should mimic the
same loader code path that is used by the OS when you run your program, so
we should be able to get more info about why it didn't load.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcecoreos5/
html/wce50lrfloadlibrary.asp

Ryan Chapman
..NET Compact Framework

This posting is provided "AS IS" with no warranties, and confers no rights.
 
I've already tried LoadLibrary on the "offending" dll. It works. So does a
subsequent FreeLibrary. But since it's a legacy C++ dll that exports a
class, I don't know how to then actually use it - ie it's not like doing
LoadLibrary then doing GetProcAddress because a class factory is involved.
I don't know enough about vtables etc to fake up an equivalent to "CTarget x
= new CTarget( );" when using LoadLibrary.

However, the LoadLibrary call itself acts fine. Likewise, if I link to this
dll's lib file but don't actually use it in code, my app runs fine. Somehow
the act of using it gives me the trouble.

If it really is "component not found", is it possible to get the name of the
specific component it didn't find?

--

Tim Johnson
High Point Software, Inc.
www.high-point.com
(503) 312-8625
 
When you call LoadLibrary, do you specify the full path to the DLL or just
the DLL name? I'd be interested if it also works if you just specify the
DLL name and not the full path since that's all the OS loader would have to
go on. If that works too, then we'll have to look for the problem
elsewhere.

One thing to try is to run this in a debugger and see if the ROM module is
loaded when the application fails. I can't think of any way to find out
what component it can't find without having a debuggable OS image, but if
the library in ROM has no dependencies then it shouldn't be causing any
problems down the line.

Ryan

This posting is provided "AS IS" with no warranties, and confers no rights.
 
Just the dll name, with no path, succeeds.

I'm just using evc4.0 for these simple tests and it can't connect over
ActiveSync 4.0 to my WM5 ipaq PDA. So I can't do the debugging type of run.
I wasn't sure if I can build unmanaged C++ targeted for WM5 with VS2005 or
not.

I'd be glad to send you my 1 line app and .lib file to see yourself, if you
happen to have a WM5 device with bluetooth!
--

Tim Johnson
High Point Software, Inc.
www.high-point.com
(503) 312-8625
 
Mortifying followup:

It was my fault. I'd been creating the .lib file by hand (from a .def file
using the LIB utility). For reasons I can't even remember I temporarily
named the file "phone.def", and created "phone.lib" with LIB. Then I
renamed it to the actual lib name I needed, like "x.lib". Unbeknownst to
me, the LIB utility creates the lib with numerous references to the expected
dll. In my case, "phone.dll". So after the rabbit trails, it was really
the "phone.dll" file which was "component not found".

Why they couldn't just a) say it was component not found, and b) name the
missing component, and c) not confuse things by saying what else it *might*
be (and why would those 2 possible errors have anything to do with each
other?!) - is a mystery to me.

Thanks for all the interest, and sorry for the stupid gene expressing itself
once again.

--

Tim Johnson
High Point Software, Inc.
www.high-point.com
(503) 312-8625
 
Back
Top