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."
That's a lot of bugs. And I haven't even noticed any of them. :(
The hackers will be making it sing like Sinatra.
Is that really so surprising? That a company will act to protect its products from people who are blatantly pirating it and enacting workarounds to bypass whatever security might have been present to ensure it only worked on developer workstations?
Oh no, your pirated pre-release software can't be upgraded! Teh horror!
I'm sure when Rhapsody (the Pre-OSX betas just after the NeXT takeover) was being developed, that some of the same types of incompatibilities were there.
;)
Think about it though, most apps from 10.3 don't work properly in 10.2, but that doesn't mean it's apple's way of keeping pirates away. Since all these X86 versions are beta quality anyway, they're probably working on a much faster development mode, and things break easier.
Then again, they could be doing it on purpose, in which case they have the right, since it's their OS.
You remember buying crack illegally from the streets... and now your posting on Slashdot. Drugs are a slippery slope :p
Since this is still not a publicly released Operating System available to buy, I'm not all that surprised they're taking care of this sort of thing now. There's no reason for them to care about the old versions of the Operating System if it is not available to the general public. Once the Operating System is actually available to buy this sort of thing will stop, but they want their developers to be using the most recent version available to give them the newest target. I don't really see a problem with this.
cheese logs keep my wang warm at night.
In case you were wondering whether Apple wanted everyone to pirate OS X onto their Dell and HP systems (for mindshare!), now you have your answer.
I was reading some publicly available Apple documentation on the transition to intel style chips, and they included a note that as of June they hadn't finalized their application-binary-interface (ABI) specification for MacOS X on intel. So, maybe it just means they changed the spec and now there's an incompatibility. It would be something most developers would never see, totally taken care of by the compiler, and a make clean and a recompile necessarily fixes everything.
Start Running Better Polls
Will binaries built using the currently available builds of OSX and Xcode work on future versions of x86 OSX? I can understand newer builds not working on older versions of the operating system, but is the same true of the reverse?
everyday is another shooter.
I flipped on this issue so fast that my head is still spinning. Aside from having the iPod and a huge cash reserve to keep them afloat I am honestly worried that piracy will crush the mac platform on intel.
And in all honesty I want my platform to continue living - I need Apple to stay proftiable in the computer business because I want to continue to buy their computers. Sadly this means that I now support any kind of gestapo like tactic that they use to keep the OS locked to their hardware.
Hopefully they can find a middle ground but the past few years have taught me that technology cannot build a wall that technology cannot also knock down - it will be a long uphill battle - I hope the FSB on the new powerbooks is worth it.
---- The real Slashdot is still here. You just have to browse at -1 to read the comments.
Well, the poster has one take on this, but perhaps the current release is incompatible because Apple has changed the compiler and some of the dynamic libraries? Perhaps this was not to specifically address pirating, but to fix bugs and to otherwise optimize the system. The OS X 86 project page has a slightly more informed discussion.
This gives a clear indication that apple is (as expected) not going to let it's new intel OS run on non apple hardware. Does apple have the means to stop (legal use anyways) typical beige box users from using a virtual server to run OS X though?
Perhaps with proprietary hardware that the OS relies on in some way which would have to be emmulated in a typical intel pc?
Who among us in their right mind didn't expect this possibility? The whole idea of these utterly generic Intel PowerMacs were for them to be cheap development preview systems. ADC members who wanted to test and develop ahead of time could either build Universal Binaries on PPC (and cross their fingers), or actually buy one of these and test while the OS is being ported and finalized.
The point here being, these are not production Intel Macs! Why would you expect to have everything Just Work (which, of course, is the whole reason many folks buy Macs in the first place) - heck, you can only get one of these systems if you're an ADC member! Remember, Apple said that OS X would not work on a generic Intel PC, only on Apple's gear. So now it's starting to come true? Wah!
As for the breakage between 10.4.1 Intel and 10.4.2 Intel - Get used to it - this may well happen a few more times before live product ships next year. I don't think any legit developers are worried about it. Only the pirates. Right now is the "build, test, and learn" phase, anyhow.
-- Josh Turiel
"2. Do not eat iPod Shuffle."
They're kinda handy because all us PowerPC Mac owners aren't going to wake up in mid 2006 and find their processor has been replaced by the processor fairy with an Intel processor. Until 2008 or 2009 I expect that PowerPC will remain the dominant processor in the Mac user community.
Currently Apple requires NO serial number, registration, or any other verification to load OS X. People trade Jaguar, Panther & Tiger disk images on filesharing networks and they burn great. The same disks or legit copies can be used to load onto multiple machines on the same network. "Upgrades" bought from Apple require no previous version's SN to install, and cost the same as a brand new copy.
The big question is, does this new policy signal a change?I hope not, I appreciate Apple's laid back policy. Right now I'm trying to determine which flavor works best on my near-obsolete G3/333 "Lombard" Powerbook. It's convenient to be able to try out different options before I license a copy.
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.
or do you think those 20, 40, and 60 GB iPods out there are all full of iTunes bought at 99 cents each?
I think you'd be discouraging them too if there was a chance all your profits would die because you could go out anywhere and get an illegal copy of their OS and run it on generic hardware.
Sure some people would actually buy legitament copies of OS X for the MacTels, but a lot more people would just pirate it to save money and not buy an Apple Machine.
If you have a choice between buying an Apple Machine at $2000, but you can build an even more powerful machine for that price or lower and stick a cracked copy of OS X on it, where will you spend your money?
Believe me, I'd love to have an Athlon 64 FX-57 PowerMac over some Pentium Mac any day, but Apple has to keep itself afloat. They can't live off the iPod sales forever.
That's an interesting counterpoint to what I was thinking actually. While I fully support the whole "It's their OS, they don't have a monopoly, it's still beta, they can do what they like" idea, I was under the impression that Intel piracy could actually be good for them (something I want, since I, like you, want to continue using Apple's products). For now I'll ignore the debate of whether they could maintain their quality of software over a wider range of hardware or not.
It's true that Apple could benefit from some piracy on the generic vanilla PC side, but this would do little for the long run. There are many people who would love to run OSX and could care less what the PC it's running on looked like or the build quality. If Apple lets the situation get out of control it will put it's hardware business (which is Apple's real business, despite what people keep trying to claim about the iTMS and OSX upgrades) in jeopardy.
Also, Apple has an image as a serious company to maintain for their shareholders. They may want a little piracy to get word-of-mouth, first-hit-free publicity in the Wintel world. But if they stand idley by and become complacent about the piracy/hacking of OSX86 their shareholders are going to wonder how much Apple is working to protect it's core hardware business and their stock investments. Apple may be making a mint off iPod sales, but Macintosh sales are still the company's bread and butter. Apple has to show it's commited to a business plan in it's switch to Intel and not being blaise with the company I.P.
I remember old PC games being sold (illegally) in the streets. The CD included a directory called "crack" which contained some patches. I wonder how long before someone hacks into the OS/X code and does this...
Maybe never. The consumer hardware that ultimately ships may only partly resemble PC compatible hardware. Using Intel CPUs and PCI chipsets does not mean you have a PC compatible motherboard. The current hack only works because Apple is using an off-the-shelf Intel PC motherboard. Apple has quite a bit of experience designing their own motherboards, they could easily redo their current custom design, or redo an Intel reference design, and ship something that does not use PC compatible parts and Mac OS X can be coded to only support those parts. Think interrupt controllers, DMA controllers, etc. The real cost savings comes from using Intel CPUs and PCI chipsets, not from having Intel design your motherboard.
Remember, Apple only said they would do nothing to stop Windows from running on their hardware. That does not mean the version of Windows you have today will run, they may merely mean they would not prevent MS from doing a version of Windows for Apple hardware.
Wonder how much innovation will be sacrificed by pulling developers and stuff off creating great new features, and putting them to work creating copy proof/crack proof install media.
Give it 5 years, and they could have 95% people trying blindly, Microsoft style to stop piracy, and have given up making the OS better in the first place.
Get your own free personal location tracker
Firstly, the latest version of 10.3 is 10.3.9, and it'll run anything built with gcc 4.0, including things which use the C++ dynamic library. [/pedant]
Secondly, compiling with gcc 4 doesn't completely prevent apps working on earlier OS versions, except in a couple of cases:
Thirdly, it's entirely possible to build two applications (using two targets within Xcode, one building ppc, one building intel) & throw the binaries at the lipo command-line tool to generate a fat binary (read: universal binary) from the two of them.
Lastly, it looks like Xcode 2.2 includes options to set compiler, linker, deployment target, etc. seperately for each compiled architecture. So in the next version of Xcode you won't even need to bother with the second step, you just let it use gcc 4.0, and you set something like 'GCC_VERSION_ppc=3.3' and 'GCC_VERSION_i386=4.0' in the build settings. Voila.
I mean, did you really, honestly think this wouldn't ever be possible? Universal binaries are just two binary files concatenated at 4096-byte (fs block size) offsets, with a header at the beginning saying what's in the file & where it is. Only a portion of the file gets mapped into memory, and that's the bit specified by the entry in the Fat header. Look at <mach-o/fat.h> and <mach-o/loader.h>; that's really all there is to it.
-Q
I know that updating for bugfixes is the right things to do... But there's not much incentive to upgrade if your 'universal' binaries won't work on the previous developer system.
You're insane.
These are developer systems that cost $1000 each, you can't buy one without signing an NDA, and next year you'll have to give them back to Apple. If your shiny new universal binary doesn't run on a developer system that hasn't been upgraded to the latest OS from Apple... who the hell cares? The binary you compile when Apple is ready to sell x86-based Macs will run just fine on the x86-based Macs that your customers can actually buy. If some developer hasn't bothered to upgrade to Apple's latest version yet, who cares if your app won't work for him?
Does anyone else think that the whole universal binaries idea is a waste of time?
No, I'm pretty sure it's just you. Do you even know what a universal binary is?
Sure its handy where writing two versions is next to impossible, but realistically, thats not very often.
Yeah, I didn't think so. Go learn something about what's going on here before babbling incoherently about it.
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
Erm-- This is a developer system. It's not finished. This isn't The Thing That'll Be Released Next Year, it's something cobbled together so that folks like me can make sure my software will work on the processor/hardware. It's not a live system that's being 'bugfixed', it's a development system that's actively being developed. That means it'll change. Binary file formats, linker specifics, etc. etc. We're not so much 'upgrading', we're keeping our aim focusssed on a moving target.
...also, having re-read your comment: where do you get the idea that anyone wants to maintain any sort of compatibility with the original 10.4.1 DTK? I mean, it's not like it's been released to the public or anything. Compatibility with the intel build of OS X 10.4.1 is not required; compatibility with the intel build of OS X 10.2 will also have been broken, but you don't seem concerned about that...? Or do you think we should all maintain compatibility with the pirated copies of OS Xi 10.4.1?
(For the record, intel apps built under 10.4.1 still work using 10.4.2; I'd guess that new capabilities/functions were added to the intel dynamic linker, which gcc 4.0.1 uses)
Again, you seem to be labouring under a misapprehension here. Universal Binaries are what are technically known as 'fat' binaries. In other words, they are a file which contains more than one executable file concatenated together. In this case, it's a file which has the i386 binary and the ppc binary within it, padded to fit the encapsulated 'files' on filesystem block boundaries (4096 bytes) and with a header up front that says where they are.
I can't believe I'm having to say this on Slashdot of all places, but universal binaries are not some weird magical thing which runs the same binary code on two different processors. They're not like the bytecode generated for the Java Virtual Machine. They're just a way of storing the binary code & data for different architectures within a single file. That's all.
Oh, and want to see a shipping application compiled as a universal binary? Try BBEdit 8.2.3 (here are the release notes).
like "mplayer mms://machine.network.org/stream.wmv" ??
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
Yes, but this isn't 'planned obsolescence'. This is an Unfinished Product. If I write a program, and at the start I put in Feature X, then later on remove Feature X to make way for Feature Y, before I've even released it as a product, then nothing becomes obsolete. There's no-one using Feature X, because the product hasn't been released. Now, I may have sent copies to some people to test, but that's all they'd be doing with it. Testing. Just like we are with the Apple DTKs, and the Intel builds of OS X.
Now, if OS X 10.4.1 for Intel were actually shipping, I'd agree. But it isn't. It's an unfinished product that is only available to paid-up developers -- the reason for which is very likely to filter out hobbyists and people who would sign up & 'buy' an Intel-based Mac for general use. The Developer Transition Kits are not ready for the prime time. They aren't finished. They are a work-in-progress.
OS X for Intel isn't finished. Its entire user base is made up of people who know that, and who have no trouble whatsoever updating to the latest version of the pre-release software. There are no legitimate users of OS X 10.4.1 for Intel processors who do not have access to the 10.4.2 install DVD, and there are none who have any reason not to install it.
-Q
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