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 you
    > wish to use SSE3 features, you must detect them first
    Perhaps you mean SSE2:

    > 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:

    >
    > 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 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...>
previous month june 2006 next month
MTWTFSS
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30    
Go to today