Reverse Engineering RET Homepage RET Members Reverse Engineering Projects Reverse Engineering Papers Reversing Challenges Reverser Tools RET Re-Search Engine Reverse Engineering Forum Reverse Engineering Links

Go Back   Reverse Engineering Team Board > Reverse Engineering Board > .NET Reverse Engineering
FAQ Members List Calendar Search Today's Posts Mark Forums Read

Reply
 
Thread Tools Display Modes
  #1  
Old 10-03-2010, 04:47 AM
G-Force1 G-Force1 is offline
Junior Member
 
Join Date: Oct 2010
Posts: 1
Default Strategies to identify reinstalls

This is my first post so please forgive me if this is the wrong forum for this topic, and tell me where it should be posted instead.

I'm looking for a bit of advice and good ideas. What are good strategies for determining whether my app has been installed on a specific machine before, to prevent the user from reinstalling to circumvent a 30-day trial?

One way would be to make trial installations require activation, where a machine ID is passed to the activation server. The activation server can check whether a trial has been issued to that machine before. I don't like this approach because it's just another step that gets in the way of legitimate users.

Another idea is to store the install date in an obvious place, as well as in numerous non-obvious areas of the registry. These keys will be based on a hash of the machine ID, so therefore unique to a machine. They are not written during install, or at first run - they are written at random times, such as on the 4th day of use, or after 2.3 hours of runtime, or etc. This is to circumvent people that have RegMon running during install and first run. Checks of these 'non-obvious' areas wouldn't happen at first run either - but at random times as well. Any resulting action would also be delayed - not at the time the registry is checked. If the 'obvious' place has been deleted but the non-obvious still exist then this means the user has tampered, therefore don't alert the user that he has been found out...rather throw a special error so that when the user contacts support we know it was due to tampering.

Obviously someone dedicated enough will always sniff out the strategy - I'm just looking for a way to make it more difficult to create a generic crack to allow reinstalls.

Any comments, other ideas?

Thanks,
G-Force1.
Reply With Quote
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump





Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.