I'm trying to gather info on how certain things work now that we have this new forum and can start fresh, so I figured I'd start with a basic question. You may see more of these (as the wiki articles are cluttered and not very helpful sometimes).

Anyway, as the topic states, what is the difference between the different decryptors such as dsmos, AppleDecrypt and any others that surfaced? I heard about there being a decryption poem used or involved in the process, so any insight to this will be most helpful.

You should probably start off by reading this:

http://osxbook.com/book/bonus/chapter7/binaryprotection/

The poem is explained at the bottom of the page, but to understand it you should probably read the whole thing.

Amit Singh (the creator of that site) has an amazing book called OS X internals, which (imho) should be read by anyone with an interest in how OS X works.

dsmos.kext and AppleDecrypt.kext (and for historical purposes, r2d2.kext before them), are all used as decryptors to apply the poem to decrypt the binaries, specifically:

• The Dock binary within Dock.app
• The Finder binary within Finder.app
• The loginwindow binary within loginwindow.app
• The SystemUIServer binary within SystemUIServer.app
• The mds support binary within Metadata.framework
• The ATSServer support binary within ATS.framework
• The translate and translated Rosetta-related binaries in /usr/libexec/oah/

(list copy/pasted from the site)

AppleDecrypt claims not to use the poem, but that's technically a lie, since it does use the poem merely in an obfuscated (hidden/not easily seen) form.

Largely it's a choice between dsmos & Appledecrypt these days. The first one was r2d2, which was released amid much controversy in the scene.. r3d3 was a leopardised variant.

My information is very sketchy, but it seems dsmos & AppleDecrypt have diferent uses, apprently due to when they load in the startup, dsmos loading earlier. this has consequences for different kinds of preboot setup, if one fails you may want to try the other.

Ok, so I read that, and I understand the process behind the encryption and decryption process, what I am confused about is that I see the poem in the address space listed in the last part, but it doesn't explain it's purpose. Do you need the poem to decrypt the binaries or just some sort special code of sort to decrypt the AES encryption? I heard about the use of the poem in one of the decryptors and the big controversy about it, but never understood why that was such a big deal.

Well, Apple wrote the encryption to protect their binaries so people could not run OS X on non-Apple branded machines, where the decryption is handled by the Don't Steal Mac OS X.kext and the SMC/EFI.

On PC boxes it's a question of legality, especially in the homeland of Apple, he U.S. of A., where the DMCA "criminalizes production and dissemination of technology, devices, or services intended to circumvent measures (commonly known as Digital Rights Management or DRM)", ie: kexts (dsmos, r2d2, r3d3, appledecrypt) using the poem used to decrypt binaries protected by Apple.

Using the poem in cleartext essentially means "circumvention has taken place" and in some places that's illegal, so it's kind of a big deal.

The Decryption process, and interpretation/legality of the EULA are what keeps OSx86 a very gray area.

Ok, so this is probably a stupid question, if you can decrypt the binaries without directly making use of their poem, is that under the same category, if possible? Everything else I understand.

So far there has been no legal method of decryption without the key/poem, that's why AppleDecrypt was so revolutionary, it was supposed to be legal, and for a while was open source, but they merely used 'security through obscurity' which failed.

So in short, anything used to decrypt it is in effect illegal if you're in the US, whether legal or not in general.

Ah, I see. I wonder why Apple hasn't done anything against the community on that front aside from Psystar.

IM was shut down for a while, they actually did do stuff to the community at first, and some people think more prevention is coming in Snow, but that has yet to be seen.

I must have missed that incident. Hopefully Snow Leopard wont make it harder, but you never know. Supposedly it can boot on hacks (if I remember netkas got it to boot to GUI), but not sure if it works on non-vanilla at the moment.

Some people are using it as their primary OS, on hacks, in 64-bit mode hehe.

So it doesn't look like it'll be harder.

Oh, wow. That's great news then.

Sure you never know, but even when there is some "big surprise", there will be methods to merge the working part of the snow beta with the final release.

none the less. its still hackable. we can always go back to using bin patched kernels. they are still my prefered method tbh.