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. :(
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...
Mac OS X 10.4.3 build 8F23 includes about 75 new bug fixes to the OS, fast bringing the total number of specific improvements the update will deliver to nearly 500.
Looks like 75 bugs and 500 improvements.Bradley Holt
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.
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."
The system changed so much between Developer Releases that Apps for DR1 would not run on DR2, etc.
Major updates underneath between releases.
HOWEVER - this was when they were fleshing out the base of the OS. New libraries, new coding practices, new releases of major components that were incompatible with prior versions.
You could still coax some NeXTSTEP and OPENSTEP apps to run, though. I imagine it's the same. Some Cocoa apps will run, some won't.
Is anything being done for straight ports of old X86 OPENSTEP code? It would be cool as rice to see a handful of the Unique apps (with source - no Lighthouse Suite, I know) running across the board (NS, OS, OSXPB, OSXPPC, OSX86).
I think it's more a matter of NeXT programming practice than anything. If the old version doesn't work, so be it - the old application doesn't need to go along for the ride anyway. Keeps people writing new software, keeps it fresh and in-tune with the theme of the system, & keeps the market alive.
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.
Certainly offtopic by the tone of the post.
Forced obsolescence of a DEVELOPER product that is under development? I mean, that'd much worse than, say, writing an operating system kernel and altering the ABI to break binary modules every so often I reckon*.
* probably the reason that the new x86 build of Mac OS X has the compatibility issues.
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.
It means that people that still have the older pirated version of OS X will not be able to run any programs that are created after yesterday.
or do you think those 20, 40, and 60 GB iPods out there are all full of iTunes bought at 99 cents each?
I doubt they're purposely breaking things, I bet the APIs were just being worked on and it caused enough changes that older compiled software crashes and burns. Remember, it's a rather early beta, it's not a commercial release-- they're allowed to change the interfaces around.
Comment of the year
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
No, it's off topic because this isn't a shipping product that we're talking about. It's basically a beta version only available to developers.
Furthermore, apple's not making money off of this. They allowing developers to download it for free.
And even more furthermore, the headline deals with software pirating, which doesn't earn anyone money.
One time I threw a brick at a duck.
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;
What is Apple thinking? They've got fans so dedicated that they're hacking OS-X to run on Intel boxes a full year before any mainstream applications are likely to arrive, and all Apple can think about is how to stop and discourage them.
You put too much faith in Slashdot's write-ups. This has nothing to do with piracy. All Apple can think about* is, in fact, how to make Mac OS X for Intel the best OS it can be, and since they don't have to worry about backwards compatibility yet, they're freely breaking things.
* OK, they think about iPods too.
$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
ADC Select membership gets us access to any & all pre-release software. No matter what that may be. There are no additional costs involved in downloading the latest pre-release iteration of any piece of software, and that includes OS X for intel.
All Apple beta software (with a few minor exceptions) is available only to ADC Select members. That's what ADC Select membership is. The fee doesn't pay for the software, it pays for technical support, and goes towards the salaries of Apple DTS, who have to work with all of us who use the beta software.
-Q
Jeez, guys, come on. This is a geek site. You'd expect more of a clue.
r Tools/Conceptual/cross_development/index.html for more info.
It has been the case for quite a while that a Mac OS X application built against a particular set of headers and stub libs will only run against those libs or newer. This means that if you build against the 10.3.9 headers (either by building against the system headers under 10.3.9 or against the 10.3.9 SDK), your code will not run in 10.3.8.
It has also been the case that the XCode install provided by Apple only provides SDK for the newest dot-releases of the OS (e.g. the current XCode installer has SDKs for 10.2.8 and 10.3.9 and no other of the 10.2.x and 10.3.x releases).
See Apple's Cross-Development Programming Guide at http://developer.apple.com/documentation/Develope
This is no intentional crippling. It's just how XCode works. No conspiracy here, move along.
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
An example of this (an old one albeit) was my first (cough) crack way back in time. I had bought ultima 5 but the disk (5 1/4) stopped working after a while. So I learnt assembly and did use debug to see why my game stopped working. After a short loading phase it went and XOR'd a small subset of instruction with number increasing by 3 (3,6,9 etc...) then if I recall correctly (it was waaaay long ago) it exchanged the interrupt 3 (the trace call interrupt) with a jump instruction and jumped right into the start of the code, which was only loading some waaaay off data into the disk interruption (13h) to read a bad sector on the disk. Depending on the result then it would say it is THE original disk or not. I simply exchanged the JMP with NOP, XOR'd by the correct number , wrote back the .COM programs. Et voila ! I could paly my game again.
The funny things is, this is only waaay later that somebody explained me that I had cracked my game. I just wanted to be able to play with something which had cost me 50$ and being 12 that was a lot of cash...
Nowaday the debugging is a bit more complicated and it all come down to the same : stop calling laserlok/safedisk/whatsoever checking that the CD is here.
C. Sagan : A demon haunted world:
http://www.amazon.com/gp/product/0345409469/
visit randi.org
Maybe if the hackers would have waited for a good stable build, Apple would have delayed their strategy. Imagine if the x86 OS X hack had not been made available until 10.4.4, or 10.4.8... what would Apple have done then? It would be too late to pull this strategy out of their hats. As long as the OS was stable, and binaries could be built with some version of XCode, I, for one, would at least be very interested in running this client version as a web/ftp/appletalk server/proxy... but only for the coolness factor, as part of a 'collection' of cool Apple stuff that should not be (like an ANS running Rhapsody or something). But 10.4.1 is just too unstable, as far as I can tell, for it to be worth dedicating such a new/good piece of hardware.
The Admin and the Engineer