Slashdot Mirror

Apple has already put capslock protection into their keyboards. It works really well in practice, I haven't accidentally engaged the capslock since I got this on a keyboard in 2008.

This is true, but don't even get me started on Objective-C. It has its good points, some of which I even miss when programming in other languages—but it's on the whole a mediocre language propped up by some amazing libraries.
I think this guy said it best.

<rant>
I mean, requiring the programmer to explicitly allocate and de-allocate each member of a class? Explicit allocation and destruction of your super class? It can FAIL and you have to check that in the constructor of every class you write?
</rant>

No thanks.

Just because it's written in Scala doesn't mean it's shitty and unmaintable! Just the latter.

(Talk slides, if you're interested.)

If you have a mac laptop and firewire AND are worried about people getting at your data, then maybe you should also figure out a way to disable full firewire access to your computer.

See: http://rentzsch.com/macosx/securingFirewire

"Firewire provides direct memory access. So I can plug in my PowerBook into an Xserve, and arbitrarily read and write to all of the Xserve's RAM, sans any logical protection."

"Paul claims enabling the Open Firmware password also automatically disables Firewire DMA, preventing tricks like Quinn's."

Go figure :).

As for your question. I'm not familiar with File Vault.

But with all such tech, it's very dependent on the details. A lot of cases the encryption is done with a "secret", and your passphrase is used to unlock that secret. If the secret is destroyed and there are no copies, even if you have your passphrase you won't be able to access the data.

With some tech, there is a way for you to create multiple keys with access to the data. So you use one key, and you store another key somewhere else safe, so if you screw up you can still go dig it out (if you can still get it ;) ). Naturally that also means someone else probably could get that...

Another issue: if you or someone else ever makes a copy of the encrypted partition or container file, and stores it somewhere, then an attacker might be able to compare the two versions.

Thus if the attacker can sneak in and make copies of your drives, you may have a problem. The attacker could do a "chosen plaintext attack" on you. For example the attacker could send you contrived spam emails, and compare the changes in the drive images.

Now the other problem is backups, what do you do with backups. If you don't encrypt the backups then you have an obvious problem.

If you make copies of the encrypted containers - see the above "chosen plaintext" thing.

So you need to use backup software that does things correctly, and which can actually restore stuff ;).

Crypto and security isn't easy to do right. You have to consider the costs and impact.

I realize that every operating system is vulnerable to this "feature" by default, but according to one of the links left by another poster this vulnerability doesn't affect Mac OS X if the OpenFirmware password is set because that will also disable Firewire DMA. That information is from 2004 and obviously only applies to PowerPC Macs, but I wonder if the same holds true for all the modern EFI/Intel Mac models. Anyone have more info on that?

Here's the link I'm referring to: http://rentzsch.com/macosx/securingFirewire

my only gripe with the new apple keyboard is that the caps lock key has a hard-wired delay, which makes it less suitable to being used as ctrl (my personal preference).
why oh why couldn't they make this a software-configurable option?

FireWire hardware can be set up to allow or disallow DMA requests depending on the device on the other end of the wire. Most OSes now only allow it if the device on the other end looks like a hard drive for security reasons. You can lock them down further if you want:

http://matt.ucc.asn.au/apple/
http://rentzsch.com/macosx/securingFirewire

Linux also has security features in recent versions of its kernel to protect against arbitrary DMA attacks. (Search for firewire-ohci.) Windows does the same thing. With the right tweaks, disabling FireWire DMA is completely within the realm of possibility if you're that paranoid.

Unfortunately. once you have FireWire DMA access, there is no way to actually fake the data in RAM, but you could theoretically require the user to take some action to enable FireWire devices, and upon detecting an unexpected DMA-capable device on the bus, use the power management hardware to power down the PHY for a few seconds, causing a bus reset and a stall for just long enough for you to page everything out to disk and replace the entire contents of RAM with naked pictures of Janet Reno, then reenable the PHY just before you overwrite the page that the wiper code occupies. :-D

Of course, this is very nearly undeniable proof that you are guilty of something. Nobody would do anything REMOTELY that insane if they didn't have something really MAJOR to hide.

Thanks for the info .. I was looking for something like this before without finding any info.. there is also a third party developer who suggests filing a bug report with Apple for there being no support under XCode .. I think it's at least worth a try if enough people file the bug -- at least they'll see it, and have to acknowledge it to some extent. Please mod parent up -- it would be great if more people knew about the petition. I don't actually have high hopes of it working, but at least it's nice to have our voice heard every once in a while.

Jon Rentzsch is suggesting that you fill a bug in the offial apple database if you're interested in this feature. I would like to ask everybody to fill one so that the list of "duplicates" show a clear sign of interest. Read more here.

Additionally, you might want to email steve, or spread the word in other means.

Here is someone who started a petition, by filing the lack of open-ness as as bug.

I think there are some users of Apple's Backup who would disagree...

I don't know if this what you are looking for, but: http://rentzsch.com/mach_inject/

Everyone seriously needs to calm down and carefully read what the article is saying.

The development release of OSX86 uses the features already present in the hardware to keep itself from being spread to other machines. Currently, all it does is prevent installs. It does not mean that the completed versions will use the DRM for anything (although it is certain they will expose it).

Further, it's not immediately obvious if Mac OS X can really be restrained by this kind of DRM because of tools exploiting certain aspects of Mach-O's binary structure.

It is disappointing, yes. But this is not a "Sky-Is-Falling" event. It's not even particularly surprising. We knew that Apple would use this to some extent. If all they use it for is their DVD player and their FairPlay DRM decoding module, then we know exactly who is calling the shots on the use of this kind of DRM (You have three guesses, and here's a hint, it's not Apple).

Alter OSX code at runtime. It only works on PPC at present, however.

Right here.

A sudden boom in OS-X86 (you heard it here, first)

No, you didn't.

I thought the article was more than relativly informative. Personally I love my mac and I think it's about time people stop fighting over which OS is better, use the right tool for the job, be that Linux, mac, windows, whatever. Anyways, figured I'd throw in a link to some other cool stuff about mach. http://rentzsch.com/papers/overridingMacOSX The page deals with code injection and function overriding within MAC OS X. I think something like it was on here not too long ago but it's also pretty interesting stuff, I'd suggest the read.

In his original paper there's a missing step:

1. Discover the original function's address.
2. Test the waters.
3. Make the original function writable.
4. Allocate the escape branch island.
5. Target the escape island and make it executable.
6. Build the branch instruction.
7. Optionally allocate and engage the reentry island.
8. Atomically:
a. Insert the original first instruction into the reentry island.
b. Target the reentry island and make it executable.
c. Swap the original function's first instruction with our custom-built branch instruction.

Missing step?

9. Make the original function non-writable.

...that the "hacking" in "Hacking Mac OS X" is referring to "hacking" in the traditional sense, not "cracking".

And for more on mach_inject, referred to in the summary, see Jonathan Rentzsch's website...and an interesting list of mach_inject and mach_override users.

As for the Finder, it may be true it was a "compromise" of sorts between the NeXT world and the Mac OS world. But it wasn't necessarily the social compromise between "personalities" within Apple it's pained to be; it was likely more of a technical one. It's not perfect, and it's woefully inadequate for some tasks that involve managing thousands (or hundreds of thousands) of files. But it's still more than sufficient, and there's no reason to completely junk it: it can continue to evolve and be improved upon.

...that the "hacking" in "Hacking Mac OS X" is referring to "hacking" in the traditional sense, not "cracking".

And for more on mach_inject, referred to in the summary, see Jonathan Rentzsch's website...and an interesting list of mach_inject and mach_override users.

As for the Finder, it may be true it was a "compromise" of sorts between the NeXT world and the Mac OS world. But it wasn't necessarily the social compromise between "personalities" within Apple it's pained to be; it was likely more of a technical one. It's not perfect, and it's woefully inadequate for some tasks that involve managing thousands (or hundreds of thousands) of files. But it's still more than sufficient, and there's no reason to completely junk it: it can continue to evolve and be improved upon.

Its a shame I can't mod the parent +1 astroturf...how about:

"Interestingly CodeTek uses this exact same bit of code for their latest VirtualDesktop program."

Seems pretty clear to me.

Perhaps you should read it again, in context this time:

"To allow DM to modify windows I had to use a little bit of code by Jon Rentzsch which allowed me to stick a bit of DM inside the Dock process (see later question). This bit of code communicates with the main app and performs much of the magic you see.

Interestingly CodeTek uses this exact same bit of code for their latest VirtualDesktop program."

The "exact same bit of code" referenced is obviously the Jon Rentzsch code, which you can find here. As you'll note from the site, it's released under a BSD license which can be incorporated into closed source projects. Since the article summary referenced "who steals GPL code" this doesn't even apply, now does it?

How's that astroturf feeling?

That's a pretty weak analogy - those plug-ins are plug-ins that the host application designed itself to be able to support. An app developer may not have anticipated exactly what QuickTime codecs the user was planning to install, but they're aware that the list is extensible and may change over time.

A haxie is injecting completely arbitrary code into the app, code that the app developer had no way of planning for. E.g., I call MoveWindow to move the window - and your code replaces my call with one to a FunkyMoveWindow that snaps it to some other position. Except that elsewhere in my code I assumed (quite reasonably) that MoveWindow(100,100) would do exactly what I expected it to - and wasn't anticipating it leaving the window at (30,100) instead...

Moving a window to the wrong place might not be a problem (then again, who can tell) but that level of redirection can easily get you into trouble - a haxie just doesn't know what assumptions the app code is making that it might be changing from under it. And that's not even touching on the fact that my app has no idea what your code is doing: if it scribbles over my address space and makes me crash, how am I supposed to debug something like that?

Your thought was right, you get billed for all the purchases made in a day. I've not yet bought tunes on consecutive days to know if they'd lump two days together or not.

They tend to bundle charges made in 48 hour periods together.

There is a very nice article by Jonathan Rentzsch with more details on the way credit card payments work and how Apple could (in theory) reduce the costs more than they do now: Credit Card Micropayments

The page you linked to with the credit card micropayments theory is interesting, but from what I can tell I don't think the iTunes Music Store works that way. I bought one track on the 29th and another on the 30th, and both are already showing up on my credit card statement as separate 99 transactions. So it would seem that Apple does in fact charge each micropayment seperately.

Is it possible Apple is getting a discount from credit card companies on transaction and capture costs? I imagine it wouldn't have been too hard to cut a deal, given the volume of transactions a service like this could expect to see. Of course, I'm no expert on the way the credit card system works, so I could be mistaken.

yours

At $1/song, if you consider the average CD to contain around 15 songs, that still $15.

The price of most albums is $9.99, unless there are fewer than 10 tracks. In that case, the total for the album is adjusted down. The remaining case is for "double CDs" which typically cost 2*$9.99

Now, please quit with the "N_songs * $1 > cost_of_album" foolishness.

There is room for improvement with the selection. That having been said, the experience is very pleasant and purchases are smooth and easy.

The REAL accomplishment is that Apple has apparently figured out how to do Credit Card Micropayments.

DeanT