Limit dll lifetime

[Chris Walters]

Any thoughts, pointers, ideas relating to controlling dll's in such a way
that they have an expiry date.

eg, After, say, 1st September 2005 they no longer work.

I'd like to do this as we are installing our product (complex web
application + database) into a potential clients environment to allow them to
trial it. Problem is that we're setting up the full blown application. The
client is on the other side of the world so we're doing this remotely. All
they need to do is remove us from their firewall hole and we can't uninstall
the app.

The obvious (and presumably weakest?) way would be to check the machine
date/time during application startup. Changing the system clock or hacking
the dll would get round this, so this doesn't really appeal.

Is there some approach via signing the dll's I could investigate?

Should I get the application to "call home" via some sort of encrypted
messages to ensure it's allowed to run?

Is there some sort of method / approach / design that allows me to make this
reasonably secure (or at least enough effort / knowledge required to bypass
that makes it secure).

Gentlemen, your thoughts please!

[Cowboy (Gregory A. Beamer) - MVP]

No matter what you do, the client has the potential of screwing you. I would
consider the following:

1. Obfuscate all of your code. Make it as hard as possible to reverse
engineer. I would consider spending the couple of K for a really good
obfuscator.

2. Polling home is a decent option, but I would consider a COM DLL for the
phone home operation to make it even harder to remove. Set up multiple
methods that get back answers and liberal seed throughout the app.

3. I would consider a timebomb built into the COM app (deletes all registry
entries, configs, etc.) if triggered. If they shut down access to the
Internet or go past a date without a new build deployed (and paid for), they
will lose the app.


--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************
"Chris Walters" wrote:

Any thoughts, pointers, ideas relating to controlling dll's in such a way
that they have an expiry date.

eg, After, say, 1st September 2005 they no longer work.

I'd like to do this as we are installing our product (complex web
application + database) into a potential clients environment to allow them to
trial it. Problem is that we're setting up the full blown application. The
client is on the other side of the world so we're doing this remotely. All
they need to do is remove us from their firewall hole and we can't uninstall
the app.

The obvious (and presumably weakest?) way would be to check the machine
date/time during application startup. Changing the system clock or hacking
the dll would get round this, so this doesn't really appeal.

Is there some approach via signing the dll's I could investigate?

Should I get the application to "call home" via some sort of encrypted
messages to ensure it's allowed to run?

Is there some sort of method / approach / design that allows me to make this
reasonably secure (or at least enough effort / knowledge required to bypass
that makes it secure).

Gentlemen, your thoughts please!

[Chris Walters]

Thanks for the ideas.... more thoughts below.

1. Obfuscation
Understood. I'm currently thinking the pro version of Dotfuscator. However,
I've no experience of this tool - or infact any other .net obfuscator. Do you
have any real world experience of any tools, any preferences etc. $2k to
spend is not an issue. Preferably I'd want something I can plug into VS.NET,
set and then forget about - letting it do its thing.

2. Poll home - using COM DLL
Interesting, not thought of it like that. The downside for me is a very real
lack of COM experience. Any good sites / books you can think of to lead the
way?

3. Timebomb
Even more interesting! I'd only considered making the app refuse to work or
offer crippled functionality. I'll run this one past the legal suits as
loosing the app might involve loosing the database, which means they'd loose
their work etc.

In terms of polling home - to ensure that I don't have the application
"explode" at an inappropriate time I guess I need to store hours or days
"failed" somewhere safe before triggering the self destruct. The registery or
filesystem could potentially be updated to hide these values - not sure what
to do about that.

Maybe I could flood the machine memory or force a reboot every 10 mins
instead - I'm sure that would trigger a call from the client!

Finally.... is this a realistic option:
* Servers boot up
* Windows service (c#) kicks in, calls home, authenticates itself (and
potentially downloads application updates / fixes etc. from home - might. do
this anyway.)
* Once authenticated, allows IIS to run (ie, keeps trying to stop IIS when
not authenticated)
* ASP.NET app "talks" to the Windows server every x hours to ensure all is
ok. If it doesn't get the OK then web site returns a blank page.
* Service periodically "calls home" to ensure all is ok.
* Ideally the "call home" would return some sort of hash on a secret
passpharse+day+month+year - this could then be recreated to prove the hash?

or am I being paranoid!

BTW - to date not bothered even attempting to do anything clever with the
database (SQL Server 2000) or stored procedures. Is there anything crafty I
could do here to lock this down. The client obviously has full physical and
administrator access to the database boxes.