Slashdot Mirror
Mac OS X Intel Build Addresses Pirating
aardwolf64 writes "ThinkSecret has an article up detailing information about the newest Mac OS X 10.4.3 builds (which is currently said to fix almost 500 bugs with 10.4.2.) What is more interesting is the release of 10.4.2 (Intel) to developers. Universal binaries built with the new version (and apparently all subsequent versions) will not work on systems running the older version of the OS."
Most cracks are extremely simple, crackers are simply looking for a conditional and unconditional jump instruction, that's it! Then it's all about stepping into the code step by step and having break points.
if ( !condition ) { error_message(); }
http://www.unixwiz.net/techtips/x86-jumps.html
So, one easy way is as simple as by passing the checks by renaming JZ into JNZ, JE into JNE, JO into JNO, or similar when the serial number is checked.
This way any invalid serial is now actually valid...
You might have to add a NOP to make the instruction the same length.
Other serials are simply generated by having the serial key code compare being blindly copied into another program to create a keygen.
if ( input_key != calculated_key ) { error(); }
Another way is to run it in debug mode and then see the content of the register having calculated_key.
The only product scheme which are more difficult to crack is those which they *seems* to be cracked, but fail unexpectively after a period of time which is very far apart the actual "test".
Days or weeks is a good delay.
And for products which prevent "debug mode" utilities, well, there exist other products to go around this issue by simply masquerading the WinIce/SoftIce application, so it doesn't get detected and prevented from running in "debug mode".
That's all I can tell.
Some of course are encrypted, but even then the code must be "decrypted" before being run so...
it's still possible to analyze it, just a bit harder.
In the end, the best way for a product is to be good, useful, have nice manuals and have a proper support at the right price, then the majority of people will buy it, especially if it's bundled with good hardware, since it wouldn't make sense otherwise.
Apple took a $795 user operating system ($1295 with the development system), moderized it, added new technologies (many of which were open sourced) and open sourced the core OS.
They now sell it commerically (with the development system) for ~$120.
Meanwhile, they are giving away:
-Darwin
-QuickTime streaming server
-Webkit
-Launchd
-Netinfo
-I/O Kit
Nobody in the open source community really asked for any of those things, Apple just opened them.
Then again, the things that people want from Apple has never been part of "a free operating system" that Apple benefitted from:
- QuickTime (particularly the commercial codecs)
- OpenStep / Cocoa / Carbon APIs
- Quartz compositor, Q. Extreme
- Core Image, Video, etc; Core Data
So mentioning the GPL isn't applicable at all. Apple has borrowed from and contributed things back using BSD style licenses.
Trying for force people to share isn't freedom.
Incorrect.
The dynamic linker in OS X makes the actual location of functions & other symbols in a linked library irrelevant, since the addresses are computed at run time by the dynamic loader -- the compiler inserts a 'stub' routine and a dummy address. The dummy address is first initialised to the address of a compiled-in function called _dyld_stub_binding_helper, which calls the relevant dyld library APIs to find the real function. The real address is then written over the dummy address, so future invocations will jump straight to the target routine.
I compile apps on OS X 10.4. Most things I compile using gcc 3.3 (because gcc 4.0 auto-links against a library that isn't present in 10.2.x), but I've never had the slightest problem running an app on an earlier version of the operating system. Unless I actually attempt to use a symbol that actually isn't there, nothing goes wrong.
Also, OS X has had weak-linking since 10.2. That means that the stub binding routine can happily return a symbol address of zero, meaning that I can link against somelib.dylib, including somefunc() which only exists in 10.4 & later, and -- at runtime -- I can simply do if (somefunc != 0) to see if the function is available. On 10.4, the function will be there. On earlier systems, the symbol value will just be zero.
Y'know, you should actually read the links you post, for instance, on the page you linked you'll find this useful nugget of information:
...you seem to imply that you're a programmer, so I'd recommend looking at <AvailabilityMacros.h> for further enlightenment.
So no, this isn't "just how Xcode works". Xcode (read: gcc & dyld) work in precisely the opposite way, and for a good reason. What's really happening is that some part of the binary file format has been changed, implemented, or created for the benefit of the Mach-O/dyld runtime.
Maybe it's something new for the Intel machines; maybe it's something that has been available for PPC, but just wasn't implemented in the Intel build of OS X 10.4.1; maybe the latest Intel build of dyld has some performance enhancements which are mirrored by a slight re-ordering of the data/text section format & flags. It doesn't really matter, since even now-- and this seems to be an important yet frequently ignored point so I'll make it very clear --
OS X for Intel is NOT FINISHED YET
Apple can and will make changes. That's part of the reason why folks like me have Developer Transition Kits. So we & they can find things that don't work so well, and would do better if they were changed slightly. This is just work in progress, and things can be changed, removed, added. It's Just Normal.
-Q