Securely limit the running an application by serial number
-
I want my application to run on specific computers that are licensed to use
the software. This is for limited use, and isn't a product for the masses.
I've realized that you can limit the software to run on specific computers
by limiting using the serial number of the machine. how secure is it? can
someone crack the software by avoiding the "if statement" that does the
check? How can I secure my checks.
Thanks,
Ammar -
I meant "Securely limit the running *of* an application by serial number"
On Fri, Jul 3, 2009 at 10:49 PM, Ammar Ibrahim <ammar.ibrahim...>wrote:> I want my application to run on specific computers that are licensed to use
> the software. This is for limited use, and isn't a product for the masses.
> I've realized that you can limit the software to run on specific computers
> by limiting using the serial number of the machine. how secure is it? can
> someone crack the software by avoiding the "if statement" that does the
> check? How can I secure my checks.
>
> Thanks,
> Ammar
> -
On Jul 3, 2009, at 1:49 PM, Ammar Ibrahim wrote:> can
> someone crack the software by avoiding the "if statement" that does
> the
> check?
Yes.> How can I secure my checks.
Obfuscate them and hope nobody finds out. It's the only way. 32-bit
apps can be easily hacked through input managers, CM plugins, and APE.
64-bit apps can't be hacked by any of the above - yet.
Nick Zitzmann
<http://www.chronosnet.com/> -
On Fri, Jul 3, 2009 at 11:09 PM, Nick Zitzmann <nick...> wrote:>
> On Jul 3, 2009, at 1:49 PM, Ammar Ibrahim wrote:
>
> can
>> someone crack the software by avoiding the "if statement" that does the
>> check?
>>
>
> Yes.
>
> How can I secure my checks.
>>
>
>
> Obfuscate them and hope nobody finds out. It's the only way. 32-bit apps
> can be easily hacked through input managers, CM plugins, and APE. 64-bit
> apps can't be hacked by any of the above - yet.
I'm writing a 64-bit only app. Any pointers on where I can find info on
obfuscation? -
On Jul 3, 2009, at 2:11 PM, Ammar Ibrahim wrote:> I'm writing a 64-bit only app. Any pointers on where I can find info
> on obfuscation?
<http://unsanity.org/archives/000101.php>
Nick Zitzmann
<http://www.chronosnet.com/> -
On Jul 3, 2009, at 12:49, Ammar Ibrahim wrote:> I want my application to run on specific computers that are licensed
> to use
> the software. This is for limited use, and isn't a product for the
> masses.
> I've realized that you can limit the software to run on specific
> computers
> by limiting using the serial number of the machine. how secure is
> it? can
> someone crack the software by avoiding the "if statement" that does
> the
> check? How can I secure my checks.
Also see this tech note:
http://developer.apple.com/technotes/tn/tn1103.html
about trying to rely on the serial number. It talks a bit about some
of the other issues, too. -
>> I'm writing a 64-bit only app. Any pointers on where I can find info on
>> obfuscation?
>
>
> <http://unsanity.org/archives/000101.php>
In addition to that, don't even think about doing your checks in
objective-C. It's just too easy to hack around, and if somebody's
dedicated to cracking you, it's an easy entry point.
So do it all in C. It's much tougher to crack into.
Once you've written it all in C, then convert it all to a C macro
instead. That makes it excruciatingly difficult to find it. And, at
that point, there is no if statement to crack - the macro duplicates
the code all over the app, so even if somebody hacked into the
assembly and switched it in one place, you've still got unaltered
checks all over the rest of the place.
Raw C executes pretty fast, so you can pepper your app with it. In
completely unrelated methods, even, just to spread out the checks
everywhere.
Wanna get really hardcore? Write 3 different versions of your
validation macro and vary which one you use. That's now 3 different
blocks of assembly that the black hat is going to have to decipher,
disassemble, and hack to get inside.
Sound like too much trouble to you? Well, then security really isn't
that important anyway. :-)
Just remember - it's always an arms race, and the more time you spend
writing security functionality for your application, the less time
you're spending actually developing the stuff that the user cares
about. No end user is going to be impressed at all with your app that
so securely locks them down to a single machine and if that gives your
competition time to catch up with a better feature set, you're in big
trouble.
Oh, I also wrote up an article with my experience in doing some of
this stuff a few years ago. Doesn't specifically address tying to the
hardware, but may be useful for general pointers, too:
http://www.jimandkoka.com/m.cgi/Journal.mchn?state=display_entry&journa
l_entry_id=283
-Jim.... -
> This is for limited use, and isn't a product for the masses.
There has already been some pretty good stuff posted, but just keep in
mind that once you've released your code, if someone is really
interested in modifying your code, they probably will. I doubt there
will ever be a 100% guaranteed solution.
The military has been investigating elements of this for a few years
with respect to unmanned combat vehicles (they know they are going to
be captured by their enemy, so for a variety of reasons they want to
protect the code), so you may want to look around at DARPA and DARPA
contractors to see what unclassified papers have been published.
Todd -
On Fri, Jul 3, 2009 at 1:33 PM, Michael Ash<michael.ash...> wrote:> In addition to what the others have said, you should think seriously
> about how useful obfuscation will be.
There might be an argument here about protecting trade secrets. If
you don't defend them, they lose their protected status.
The biggest threat to Ammar's product seems to be an insider attack.
"What You Know" security is not going to be useful here, since
everyone will have shared access to roughly equivalent knowledge.
"Who You Are" level security is going to be tough to implement in this
situation. That leaves us with "What You Have."
The best solution might be to have a server process running on a box
outside of the user's control, and have the client machines depend on
certain functionality provided by the server. You can generate a key
for each client, stick it on the client's keychain, and use that to
authenticate any messages transferred between the client and server.
This gives you the opportunity to revoke a rogue client's key, which
will cripple the client since it depends on the server for
functionality.
I only recommend this approach if you are providing this software on a
licensed, contractual basis. From my ethical perspective, customers
of buyout software should not be subject to such treatment.
--Kyle Sluder -
Hello Ammar,
Friday, July 3, 2009, 8:49:32 PM, you wrote:> I want my application to run on specific computers that are licensed to use
> the software. This is for limited use, and isn't a product for the masses.
> I've realized that you can limit the software to run on specific computers
> by limiting using the serial number of the machine. how secure is it? can
> someone crack the software by avoiding the "if statement" that does the
> check? How can I secure my checks.
First thing - Apple and their devout followers will tell you "don't do that" when it comes to ANY protection. Ironic since as they have DSMOS and PT_DENY_ATTACH on iTunes etc.
Second, to make it really effective, you have to get hardcore. I've just written a system for the company I work for that actually encrypts the whole executable, and only decrypts it at run time with the right licence file (keyed to the user's system serial) in place. This meant writing a "stub" program and a tool to parse a Mach-O and encrypt it suitably. Expect to have to get friendly with BSD API's, syscalls, and assembly language.
You have a lot of ground to cover to make any checks etc hidden. IOKit is the only way to get the system serial, and it's easy to spot in the Mach-o load commands and symbol table - as soon as a cracker spots it, they can say "aha", and at best, forge the answer to a known good system serial. Opening it dynamically with dlopen() and looking up symbols helps - especially if you rot13 or xor the symbol name strings.
If you go my route, you've also got to think about other things, such as process dumping. Once the code's decrypted you can easily do something like enable coredumps, then send a SIGABRT and grab the decrypted app (Mach-O header and all) out of the core dump. You then two routes 1) thwart the dumping 2) make it so that the app can detect if it was dumped, and break.
Of course, I have ways and means, but I won't give away my secrets ;) I'm also under no illusions - it'll be cracked, but you have to try and protect your stuff. Simply saying "why bother they will crack it anyway" gets your stuff spread on day 0, instead of a few weeks or a month later
--
Best regards,
Peter mailto:<darkmatter...> -
On Jul 3, 2009, at 6:48 PM, Peter Mulholland wrote:> First thing - Apple and their devout followers will tell you "don't
> do that" when it comes to ANY protection. Ironic since as they have
> DSMOS and PT_DENY_ATTACH on iTunes etc.
I call trollshit.
There's a whole thread-worth of responses before yours that more or
less make your very same points:> Second, to make it really effective, you have to get hardcore....> I'm also under no illusions - it'll be cracked ...
In essence: it takes a lot of effort to make your scheme reasonably
difficult to crack but it will never be crack-proof. Sounds like 90%
of the responses on this list across all similar threads to me.> Simply saying "why bother they will crack it anyway" gets your stuff
> spread on day 0, instead of a few weeks or a month later
Your quote is not the same as "don't do it". It only highlights
that some people don't view it as "worth it" at all. Many on this list
are business owners or represent a business and are interested in
protecting their work - present company included. The majority merely
warn that:
1 - Increasing investments of effort to protect your code has
diminishing returns.
2 - Nothing is 100% crack-proof.
3 - It's unlikely (though not impossible*) you're smarter than the
smartest, so it's pretty likely that your best efforts will still be
cracked.
4 - Any Objective-C-based protection mechanism is trivial to crack
because it's practically self-documenting and easily modified by (the
language's) design.
5 - There are a number of resources outlining the weaknesses of an
Objective-C application in this regard as well as many approaches for
increasing security (ie, making it very difficult for casual crackers
to crack).> Of course, I have ways and means, but I won't give away my secrets ;)
The funny thing about point #5 above is that, in this thread alone,
there were some direct links to specific and relevant information.
--
I.S.
* ... then again, if you were smarter than the smartest, you wouldn't
need to ask how to do this, so we can safely assume you're probably
somewhere near the mean. If you *are* among the smartest and asking
this question, you're just weird. -
the discussion of software protection is off-limits for this list.
take to to the mac small business list.
[moderator]
On 2009-07-03, at 6:48 PM, Peter Mulholland wrote:>> I want my application to run on specific computers that are
>> licensed to use
>> the software. This is for limited use, and isn't a product for the
>> masses.
>> I've realized that you can limit the software to run on specific
>> computers
>> by limiting using the serial number of the machine. how secure is
>> it? can
>> someone crack the software by avoiding the "if statement" that does
>> the
>> check? How can I secure my checks.
>
> First thing - Apple and their devout followers will tell you "don't
> do that" when it comes to ANY protection. Ironic since as they have
> DSMOS and PT_DENY_ATTACH on iTunes etc. -
I don't see how this is a "business" question, it's very technical.
On Sat, Jul 4, 2009 at 7:23 AM, Scott Anguish <scott...> wrote:> the discussion of software protection is off-limits for this list. take to
> to the mac small business list.
>
> [moderator]
>
>
> On 2009-07-03, at 6:48 PM, Peter Mulholland wrote:
>
> I want my application to run on specific computers that are licensed to
>>> use
>>> the software. This is for limited use, and isn't a product for the
>>> masses.
>>> I've realized that you can limit the software to run on specific
>>> computers
>>> by limiting using the serial number of the machine. how secure is it? can
>>> someone crack the software by avoiding the "if statement" that does the
>>> check? How can I secure my checks.
>>>
>>
>> First thing - Apple and their devout followers will tell you "don't do
>> that" when it comes to ANY protection. Ironic since as they have DSMOS and
>> PT_DENY_ATTACH on iTunes etc.
>>
>
> -
It's something that has been over and over on this list in the past.
The discussion of software protection and licensing schemes simply
belongs there.
There is a Yahoo Group for discussion of business-related issues at:
<http://groups.yahoo.com/group/macsb/>
[moderator]
On 2009-07-04, at 2:13 PM, Ammar Ibrahim wrote:> I don't see how this is a "business" question, it's very technical.
>
> On Sat, Jul 4, 2009 at 7:23 AM, Scott Anguish <scott...>
> wrote:
> the discussion of software protection is off-limits for this list.
> take to to the mac small business list.
>
> [moderator]
>
>
> On 2009-07-03, at 6:48 PM, Peter Mulholland wrote:
>
> I want my application to run on specific computers that are licensed
> to use
> the software. This is for limited use, and isn't a product for the
> masses.
> I've realized that you can limit the software to run on specific
> computers
> by limiting using the serial number of the machine. how secure is
> it? can
> someone crack the software by avoiding the "if statement" that does
> the
> check? How can I secure my checks.
>
> First thing - Apple and their devout followers will tell you "don't
> do that" when it comes to ANY protection. Ironic since as they have
> DSMOS and PT_DENY_ATTACH on iTunes etc.
>
>
