5

I'm developing a kernel driver for a client who is selling it to a client who is selling it to the final customer. The final customer is not only 3 times removed from me contractually, but also many thousands of miles and a dozen time zones away. Therefore I have no direct access to their test environment.

Everything is testing fine on the several machines and several different versions of OS X that I'm testing with, and I cannot duplicate a few issues they appear to be experiencing.

I have a tiny suspicion that they may be testing on a hackintosh, and while I'm working on their reported issues from angles assuming that their test setup is correct, I would like to put my suspicion to rest by adding code to the next build which will help me understand if they are running on real Apple hardware or not.

Right now I'm collecting the system profile, kernel.log, console.log, and USB profile. If the answer can be found in one of those, that would be even better, but I'm assuming that it won't be so simple.

  • What are my options for determining whether the computer my driver is running on consists of real Apple hardware or not?

Again, I have code both in user space and in the kernel, so I have complete access to the machine, though I'd prefer a user space solution. The user space code is running as root, and starts running at boot, before the apple logo shows. While it would be nice to support multiple versions of OS X, 10.6.8 is the specific version I need to target for this case.

Adam Davis
  • 91,931
  • 60
  • 264
  • 330
  • 1
    The similar question "[How can an app tell if it's running on a hackintosh?](http://stackoverflow.com/questions/1973375/how-can-an-app-tell-if-its-running-on-a-hackintosh)" turns out to be a question about how many hardware mouse buttons a laptop has. It has one interesting solution, but I'm hoping there are more options now - that question is 2 years old. – Adam Davis Aug 17 '11 at 13:19
  • why not just try to run your code on a hakintosh yourself and possible fix the issue? anyway the code should be robust enough to work with hakintosh as well. – Vlad Aug 17 '11 at 13:22
  • 1
    Not an expert on this, but just to add an idea: is it possible that they are running it inside a virtual machine? If so, it may get more complex. Although I work in a very different area, a test I would do is to perform some benchmarks and use that to narrow down the potential hardware possibilities (even within a VM). A VM won't easily fake better hardware than it has. – Iterator Aug 17 '11 at 13:22
  • 1
    @Vlad I have my hands full testing and debugging on 5 hardware platforms times 3 OS X versions. Even as stable as hackintosh's are today, unless I duplicate their exact test setup I might not be able to see the problem. – Adam Davis Aug 17 '11 at 13:28
  • @Iterator Interesting thought, I'll have to consider that. It would require some benchmarking on my end, but might be a viable solution. – Adam Davis Aug 17 '11 at 13:30
  • Unfortunately one other possibility arises: suppose that the end user is Apple (you may or may not know, but others with similar issues could find themselves in an analogous scenario). In that case, the target device need not be a hackintosh but a next-gen hardware. *If* the contract doesn't limit their devices (nb: this conditional is important), *then* knowing that it's not a commercially available system (be it hackintosh or next-gen), may not do a whole lot of good. In that case, the ramifications could make the original question "too-local". – Iterator Aug 17 '11 at 13:36
  • (Continuing) The issue of being "too local" is why I said it's unfortunate. I certainly find the question stimulating, but I'm at a loss to say what the impact of a hackintosh is. I am used the SW side and to working on commodity HW and multiple OSes, but I realize you're focusing on far deeper layers. I think that's the key to why this isn't a local problem. – Iterator Aug 17 '11 at 13:40
  • Good luck! I'm off to the cloud, where the hardware problems are solved or at least obscured. ;-) – Iterator Aug 17 '11 at 13:42
  • 1
    Can you get (download) a "System Profiler" output of the remote machine? It can output an XML, and non-apple hardware should be visible. – osgx Aug 17 '11 at 13:58
  • What exactly is the nature of the failure? Perhaps people can comment on theories for root cause and give you some more paths to try for a solution. – ccozad Aug 19 '11 at 04:09
  • It would also seem that if you found a reasonable method, Apple would like to talk to you because clearly if OSX is being installed in the first place, Apples own checks have been comprimised. – ccozad Aug 19 '11 at 04:17

1 Answers1

1

I'm collecting the system_profiler output from them with each bug report, and I can compare the hardware reported with the list at EveryMac.

It would be nice if there were a better answer to do this in software without compiling my own database of Mac hardware, but that may be the most comprehensive way to accomplish this task in software. Probably the easiest method would be to interrogate the IO Registry for a few key pieces of hardware (video card, processor, etc) then once the data comes back have software locally that checks it against a database of known Apple hardware configurations.

For now I'm checking the system profile output by hand.

Adam Davis
  • 91,931
  • 60
  • 264
  • 330