Detecting Illegitimate OS X Installations?
-
Hey,
I want to write code to explicitly keep my application from running
on non-Apple branded Intel hardware. I've seen this done in several
other applications, and I was wondering what indicators other
developers usually look for to tell if an application is running on
some other vendor's hardware. Until Apple officially condones OS X on
non-Apple hardware I don't want to support users running pirated
copies of OS X, on hardware that Apple doesn't support. Along with
the ethical stuff, I also don't want to bother supporting systems
running a hacked kernel and oddball graphics drivers.
-Colin -
On 17 Jun 06, at 12:55, Colin Cornaby wrote:
> I want to write code to explicitly keep my application from running
> on non-Apple branded Intel hardware. I've seen this done in several
> other applications, and I was wondering what indicators other
> developers usually look for to tell if an application is running on
> some other vendor's hardware. Until Apple officially condones OS X
> on non-Apple hardware I don't want to support users running pirated
> copies of OS X, on hardware that Apple doesn't support. Along with
> the ethical stuff, I also don't want to bother supporting systems
> running a hacked kernel and oddball graphics drivers.
Before I go any further, NOTE WELL that this technique will probably
break as Apple releases new hardware! Do not make use it unless you
fully believe you can keep your software available and up to date for
at least the next few years.
That being said...
One good technique for detecting illegitimate OS X installs could be
to check what kind of CPU is being used. Apple has not yet released
any Intel Macs which use anything except a Core Solo or Core Duo
chip, so any OS X install that's running on a Pentium 4 or an AMD
chip is definitely a hacked version. The easiest way to check the CPU
type, in turn, would be to use the CPUID instruction. -
On Jun 17, 2006, at 3:12 PM, Andrew Farmer wrote:
> On 17 Jun 06, at 12:55, Colin Cornaby wrote:
>
> Before I go any further, NOTE WELL that this technique will
> probably break as Apple releases new hardware! Do not make use it
> unless you fully believe you can keep your software available and
> up to date for at least the next few years.
>
> That being said...
>
> One good technique for detecting illegitimate OS X installs could
> be to check what kind of CPU is being used. Apple has not yet
> released any Intel Macs which use anything except a Core Solo or
> Core Duo chip, so any OS X install that's running on a Pentium 4 or
> an AMD chip is definitely a hacked version. The easiest way to
> check the CPU type, in turn, would be to use the CPUID instruction.
>
> This email sent to <colin.cornaby...>
Sure, this is one big fat concern. Including such scans isn't really
worth it if I'm blocking legitimate OS X machines. I've thought about
several options, including checking for the EFI partition. Another
idea might be checking for the presence of "Dont Steal Mac OS
X.kext", but from the Googling I just did, it looks like this kext is
left in place on non-Apple machines. I'll leave the link out for the
sake of keeping the mods happy.
-Colin -
On 17 Jun 06, at 16:55, Colin Cornaby wrote:
> Sure, this is one big fat concern. Including such scans isn't
> really worth it if I'm blocking legitimate OS X machines.
Exactly. And remember that it isn't your job to be policing for
piracy, anyway... that's Apple's job.
> I've thought about several options, including checking for the EFI
> partition. Another idea might be checking for the presence of "Dont
> Steal Mac OS X.kext", but from the Googling I just did, it looks
> like this kext is left in place on non-Apple machines. I'll leave
> the link out for the sake of keeping the mods happy.
The EFI partitioning scheme is present in illegitimate copies of OS X
as well. In general, the software is going to be very similar - your
best bet is checking for hardware tip-offs, since that's the real
distinction.
(Another option, incidentally, might be to run a few SSE3
instructions. They're guaranteed to be present on all genuine Apple
x86 machines, and may be absent on some lower-end illegitimate
installs.) -
On Jun 17, 2006, at 10:31 PM, Andrew Farmer wrote:
> (Another option, incidentally, might be to run a few SSE3
> instructions. They're guaranteed to be present on all genuine Apple
> x86 machines, and may be absent on some lower-end illegitimate
> installs.)
That's certainly not what <http://developer.apple.com/documentation/
Performance/Conceptual/Accelerate_sse_migration/migration_sse_C/
chapter_3_section_3.html> says:
> SSE3 is an optional hardware feature on MacOS X for Intel. If youPerhaps you mean SSE2:
> wish to use SSE3 features, you must detect them first
> Similar selectors exist for MMX, SSE and SSE2, but since those are
> required features for MacOS X for Intel, it is not required that
> you test them before using those vector extensions, in software
> intended solely for MacOS X for Intel
Glenn Andreas <gandreas...>
<http://www.gandreas.com/> wicked fun!
quadrium2 | build, mutate, evolve, animate | images, textures,
fractals, art -
On Jun 17, 2006, at 8:35 PM, glenn andreas wrote:
>> Performance/Conceptual/Accelerate_sse_migration/migration_sse_C/
> On Jun 17, 2006, at 10:31 PM, Andrew Farmer wrote:
>
>> (Another option, incidentally, might be to run a few SSE3
>> instructions. They're guaranteed to be present on all genuine
>> Apple x86 machines, and may be absent on some lower-end
>> illegitimate installs.)
>
> That's certainly not what <http://developer.apple.com/documentation/
> chapter_3_section_3.html> says:
>
>> SSE3 is an optional hardware feature on MacOS X for Intel. If you
>> wish to use SSE3 features, you must detect them first
> Perhaps you mean SSE2:
Yeah but all Apple Intel based hardware has SSE3 and will likely only
go up from their with Core 2.
-Shawn -
> One good technique for detecting illegitimate OS X installs could
> be to check what kind of CPU is being used. Apple has not yet
> released any Intel Macs which use anything except a Core Solo or
> Core Duo chip, so any OS X install that's running on a Pentium 4 or
> an AMD chip is definitely a hacked version. The easiest way to
> check the CPU type, in turn, would be to use the CPUID instruction.
Just a note on CPUID, there was a thread a while back on the darwin-
x86 list (http://lists.apple.com/archives/darwin-x86/2006/Jan/
msg00002.html). One of the caveats of using CPUID is, as noted by
Eric Albert:
"Calling CPUID is challenging, since it trashes %ebx. gcc uses %ebx
as the PIC base and doesn't handle the case where you tell it in your
asm constraints that you're trashing %ebx. So the only way to use
CPUID is to save %ebx, call CPUID, and restore %ebx."
The recommendation from that thread (and others like it) is that you
shouldn't really ever be calling CPUID yourself. For example, you
can get most of the same info using sysctl, which has the advantage
also of being platform agnostic.
Wade Tregaskis
ICQ: 40056898
AIM, Yahoo & Skype: wadetregaskis
MSN: <wjtregaskis...>
iChat & email: <wadetregaskis...>
Jabber: <wadetregaskis...>
Google Talk: <wadetregaskis...>
http://homepage.mac.com/wadetregaskis/
-- Sed quis custodiet ipsos custodes? -
Am 17.06.2006 um 21:55 schrieb Colin Cornaby:
> I want to write code to explicitly keep my application from running
> on non-Apple branded Intel hardware. I've seen this done in several
> other applications, and I was wondering what indicators other
> developers usually look for to tell if an application is running on
> some other vendor's hardware. Until Apple officially condones OS X
> on non-Apple hardware I don't want to support users running pirated
> copies of OS X, on hardware that Apple doesn't support. Along with
> the ethical stuff, I also don't want to bother supporting systems
> running a hacked kernel and oddball graphics drivers.
Have you checked what ASP returns for unknown computers running OS
X? I'd guess that it'd be much easier to just ask people for an ASP
report (which helps with most bug reports anyway) and if it's an odd
CPU/hardware combo you'd know they're running either a third-party-
upgraded Mac (I think there's some hacks like a bigger Core Duo for
Mac minis) or a PC.
Cheers,
-- M. Uli Kusterer
http://www.zathras.de -
Isn't a little too ambitious to assume that you will succeeded were
Apple fails (if it will fail)? If Apple fails to prevent Mac OS X
from running on "un-authorized" hardware, what chances yours (or
anyone else) application has to achieve the same goal? If your
application will be wildly successful and huge number of people will
run Mac OS X on none-Apple hardware, you should have no doubts that
some one will break through what ever protection you will care to
devise (and it will be even easier if they will search through Cocoa-
Dev archives and look into this discussion ). Otherwise (your
application is mildly successful and just a few people running Mac OS
X on "wrong" hardware) why bother? Disclaimer stating that you are
not supporting "un-authorized" hardware will do just fine.
Andrei
On Jun 19, 2006, at 8:21 AM, Uli Kusterer wrote:
> Am 17.06.2006 um 21:55 schrieb Colin Cornaby:
>> I want to write code to explicitly keep my application from
>> running on non-Apple branded Intel hardware. I've seen this done
>> in several other applications, and I was wondering what indicators
>> other developers usually look for to tell if an application is
>> running on some other vendor's hardware. Until Apple officially
>> condones OS X on non-Apple hardware I don't want to support users
>> running pirated copies of OS X, on hardware that Apple doesn't
>> support. Along with the ethical stuff, I also don't want to bother
>> supporting systems running a hacked kernel and oddball graphics
>> drivers.
>
> Have you checked what ASP returns for unknown computers running OS
> X? I'd guess that it'd be much easier to just ask people for an ASP
> report (which helps with most bug reports anyway) and if it's an
> odd CPU/hardware combo you'd know they're running either a third-
> party-upgraded Mac (I think there's some hacks like a bigger Core
> Duo for Mac minis) or a PC.
>
> Cheers,
> -- M. Uli Kusterer
> http://www.zathras.de
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Cocoa-dev mailing list (<Cocoa-dev...>)
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/<andrei...>
>
> This email sent to <andrei...>
-
However high-minded the intention, attempting to detect pirated OS X
installations is simply misguided. Because only those empowered to define a
legitimate installation, can test for one. Or to put it another way, by
performing a test for a legitimate install, the app is defining (on Apple's
behalf) what a legit installation must be.
Moreover this feature is a disaster in the making: because at some time in
the near future, some number of customers would buy a new model Macintosh,
take it home, excitedly launch this application for the first time on this
new machine - only to have the program immediately - and falsely - accuse
them of having committed a federal offence. In other words, this is not the
right approach toward building brand loyalty and customer satisfaction.
Even if that accusation is toned down - simply not having the software work
when it has no reason not to - unjustly denies the user the services of the
program. And in reality the only people most likely to be affected by this
behavior are not pirates - but first-time Mac buyers and the early adopter
types - exactly the kind of individuals for whom a positive initial
impression matters a great deal.
If still not persuaded, then answer this question: Would it be appropriate
for the same program to scour the user's hard drive looking for Adobe
products that appeared to be pirated? Of course not. Only Adobe and its
designated agents can decide licensing terms for its own products. And that
observation is just as true for Adobe as it is for Apple - or for any other
third party.
Greg
On 6/19/06 5:54 AM, "Andrei Tchijov" <andrei...> wrote:
> Isn't a little too ambitious to assume that you will succeeded were
> Apple fails (if it will fail)? If Apple fails to prevent Mac OS X
> from running on "un-authorized" hardware, what chances yours (or
> anyone else) application has to achieve the same goal? If your
> application will be wildly successful and huge number of people will
> run Mac OS X on none-Apple hardware, you should have no doubts that
> some one will break through what ever protection you will care to
> devise (and it will be even easier if they will search through Cocoa-
> Dev archives and look into this discussion ). Otherwise (your
> application is mildly successful and just a few people running Mac OS
> X on "wrong" hardware) why bother? Disclaimer stating that you are
> not supporting "un-authorized" hardware will do just fine.
>
> Andrei
>
> On Jun 19, 2006, at 8:21 AM, Uli Kusterer wrote:
>
>> Am 17.06.2006 um 21:55 schrieb Colin Cornaby:
>>> I want to write code to explicitly keep my application from
>>> running on non-Apple branded Intel hardware. I've seen this done
>>> in several other applications, and I was wondering what indicators
>>> other developers usually look for to tell if an application is
>>> running on some other vendor's hardware. Until Apple officially
>>> condones OS X on non-Apple hardware I don't want to support users
>>> running pirated copies of OS X, on hardware that Apple doesn't
>>> support. Along with the ethical stuff, I also don't want to bother
>>> supporting systems running a hacked kernel and oddball graphics
>>> drivers.
>>
>> Have you checked what ASP returns for unknown computers running OS
>> X? I'd guess that it'd be much easier to just ask people for an ASP
>> report (which helps with most bug reports anyway) and if it's an
>> odd CPU/hardware combo you'd know they're running either a third-
>> party-upgraded Mac (I think there's some hacks like a bigger Core
>> Duo for Mac minis) or a PC.
>>
>> Cheers,
>> -- M. Uli Kusterer
>> http://www.zathras.de
>>
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Cocoa-dev mailing list (<Cocoa-dev...>)
>> Help/Unsubscribe/Update your Subscription:
>> http://lists.apple.com/mailman/options/cocoa-dev/<andrei...>
>>
>> This email sent to <andrei...>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Cocoa-dev mailing list (<Cocoa-dev...>)
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/<greghe...>
>
> This email sent to <greghe...>
