The evil "jailbreak vendors who say you shouldn't upgrade" (term used by F-Secure) have stated that they will be releasing a fix for the exploit on the iPod Touch 1G and the iPhone 2G. Ironically, this means that all owners of such devices MUST now jailbreak unless they want to be vulnerable to this exploit forever.
McAfee? Symantec? You seriously expect them to do something useful instead of whining about how Apple doesn't let them write software to hog down your phones even more?
Older devices probably don't support it (the spec is quite recent after all). At least the iPhone 3G does, and quite likely newer devices too. I don't know about the 2G. Older iPods probably won't work.
As for the current, I measured mine at 500mA in this mode, which is consistent with the minimum requirement for a dedicated charger. I guess the iPhone makes no attempt to draw more unless it detects the specific resistors.
Now, of course, Apple hasn't publicly stated that their devices are compatible with USB spec chargers, so nothing's guaranteed. Personally, though, I'd just build in a switch for USB spec vs. dedicated resistor modes into a charger. That should make it pretty universal.
Keep in mind that I'm not advocating going with the spec, as it obviously won't work with older devices. All I'm saying is that there's a reason for the resistors, and this reason prompted an official spec which Apple do comply with in newer devices. i.e. this isn't a story about lock-in, it's about the evolution of USB charging standards. Unless Apple really did stop supporting the charging spec in newer iPhones (I only have my 3G, so I can't check).
That only works for the hexadecimal/octal/binary/2**n-ary representation of pi, though. To get the n-th decimal digit you still need to calculate the rest.
No verb, abuse of the term "hacker", marketroid terminology ("frontier"), and generally fails at providing any insight at all as to the article's contents.
This is one serious entry into the "worst Slashdot headline ever" competition.
I did RTFA and WTFV. SE1 (not SEI) isn't the charging signal, it's a USB data line state (an invalid one that goes against the USB spec). A short across the data lines (without connecting them to any explicit voltage) is what indicates a charger according to the USB Battery Charging spec. Now, SE1 could have well been the magic "charger" indication, but it isn't what was chosen for the USB spec.
Apple chargers use the data lines in non-standard ways (pulled to a voltage using resistors), but shorting them together is the standard way to make a USB charger and, as it turns out, Apple devices (at least recent ones) do understand this and properly charge from such a charger.
It's worth noting that it is impossible to place a USB bus into the SE1 state without resistors. SE1 means both data lines are at 3.3V (at least for full-speed and low-speed USB), which is not the 5V voltage that you have available on a charger, so if you in fact want to put a bus into SE1 state, you'd need resistors anyway. The charging spec is even simpler, it relies on the device detecting a short across the data lines and the charger doesn't have to provide any specific voltage.
Or you can get a $370 Rigol DS1052E, and software-hack it to enable 100MHz mode. Not quite as good as a Tek, but significantly cheaper and well worth the money, especially if you're on a smaller budget. I recently got one (it's about time I bought a scope) and I've been quite happy with it for my purposes.
As far as I know, the NDA is for devices that talk to their 30-pin accessory connector, including component cables, which do have crypto auth and you need to purchase auth chips from Apple (and yes, Apple deserves all kinds of bashing for that one).
I'm not aware of any NDAs required to make a USB compliant charger; all you need to do is visit the USB-IF website and download the USB charging standard spec, which Apple devices are compatible with. Before the charging spec, they didn't publish the resistor stuff, but it's not like it was a trade secret. Most likely they just didn't feel like documenting it. Sure, they could've tried to have it made into a standard, and that would've been a Nice Thing, but I don't think we can say they were deliberately preventing third parties from making compatible chargers just because they didn't publicly publish a few resistor values. "Reverse engineering" minor proprietary extensions like this is part of the day-to-day job of a third party accessory maker, and all USB chargers prior to the spec were outside the standard anyway; Apple just chose to do it a different (safer, saner) way from most other manufacturers.
I tested it and it appeared to draw 500mA (that's 2500mW, don't confuse mW and mA), so I guess the standard charger protocol triggers the current-limited charge mode (same as you'd get with a standard host PC). This makes sense given it's the minimum requirement of the spec.
They are. Short the data lines to an iPhone and it'll go into charging mode, no questions asked, no resistors required, just like the spec says. It seems people just haven't bothered to try it.
200 ohms is the maximum (you'll be out of spec if your resistor is 201 ohms). There is no minimum; what the spec means is that you should just short the data pins together.
I'm glad that someone else has bothered to test this; for a moment I thought I was the only one who knew that recent iStuff follows the official spec, since everyone seems to keep on using the same old resistor hacks.
We all love to call out Apple when they design deliberate incompatibility into their devices, but there is a perfectly valid technical reason for what Apple is doing here, and, in fact, they are following a USB specification (which LadyAda unfortunaterly didn't even test).
Without data communications or when suspended, devices may legally draw no more than 2.5mA from a host, which is useless for charging. In fact, even if you're generous and pretend they're connected, devices are not allowed to draw more than 100mA without negotiating for a higher current, which requires actually talking to the host, and 100mA is still too little to charge properly. 500mA is the maximum allowed by the USB spec, but devices must negotiate it (there may be too many devices on the bus for negotiation to succeed).
Before there was a spec for "dumb" USB chargers, Apple used the resistors as a sentinel to avoid drawing too much current from undersized chargers in order to avoid damaging the host. This is a hack, but it works, and honestly, we're smart enough to figure out a couple resistors on the data lines. It's not like they're using crypto auth on the charger. They have a perfectly valid reason to do this. Devices which charge from "dumb" chargers aren't following the spec, though this is a common industry practice.
As it turns out, the USB-IF came up with a USB Battery Charging spec. The spec is long and boring, but it boils down to: short together the data lines (no resistors required) and you indicate that you're a dumb charger that can supply anywhere from 0.5A to 1.5A.
(Yes, I'm not following the USB spec there by in turn using a USB cable to supply the 5V and not negotiating over its data lines. I didn't feel like grabbing a dedicated 5V PSU for the shot, so sue me.)
Presumably, you can request spurious permissions through the XML, but you can't use unrequested permissions in code. In other words, the OS makes no attempt to guess what permissions an app might need; it denies everything by default unless the XML lists the permission and the user accepts it.
As I said, it's highly unlikely for the kind of design defects that cause early failure to be correctable in software, and it also highly unlikely for software modifications to destroy the hardware. Therefore, you should be entitled to warranty coverage on your hardware whether you have modified the software or not. Your original post implies that there are no such cases and that all breakage after software modification happens due to that software modification, or that most of the time "original" firmware prevents such breakage and modified firmware does not, which is patently false.
I mentioned hardware that breaks due to a manufacturing defect or design defect. Manufacturing defects (e.g. poor soldering) and design defects (e.g. underspecced parts) can both cause devices to fail early. Software can only rarely correct for these kinds of defects.
But forcing a company to support (for free) hardware that broke due to a manufacturing or design defect whether you happened to install unofficial software on it or not would be a pretty good idea.
Slashdot filters out just about all useful Unicode for no good reason other than laziness. People were abusing control characters, but they were too lazy to make a proper blacklist and instead opted for an almost nonexistent whitelist.
I wouldn't trust the microcell signal. Femtocells (actual terminology) are a rather new technology and significantly cut down from a real cell tower (they are also based on new, cheap chipsets, not the good stuff). It's quite possible that an implementation bug in the cell (e.g. poor compensation for certain RF interference or signal degradation) is causing this.
What's so special about Irfanview? If you want to do batch conversion of images, use the ImageMagick console tools. If you just want to view images, use your desktop environment's image viewer. If you want to edit them, use whatever editing features are built in to your desktop environment's apps (e.g. KDE's gwenview can do some basic editing) or just use GIMP. Each of these tools will likely do its job better than Irfanview.
As for uTorrent, I find KTorrent is quite similar and a great substitute.
I've worked with security systems and I can definitely say that the guy who wrote that post doesn't know what he's talking about. I've hever heard of "resettable" eFUSEs. He keeps talking about eFUSEs as if they had some kind of power to control or supervise the boot procedure, which is bollocks - eFUSEs are storage elements, you need some kind of boot ROM to make use of the data and make decisions. And you don't "write programs in JTAG". Until someone writes something technically coherent about this issue, I'd take all of this with a huge grain of salt.
eFUSEs can indeed be used for this kind of self-destruct-on-tamper behavior, but honestly I would be very surprised if it were actually implemented this way on a retail handset. Deliberately designing brickage into a unit is just a bad idea overall (except for security devices, e.g. HSMs and smartcards).
A system like that got implemented in Spain a few years ago. All new Spanish national ID cards are smartcards which allow you to cryptographically sign documents with similar validity to a physical signature. It is expected that they will be increasingly used by banks and the like (and they are already being used in order to e.g. file tax documents on-line). The card is protected by a "PIN" (actually a password) and locks you out after a few incorrect attempts.
It's by no means perfect, but it will be interesting to see what comes out of it.
Nothing in that linked PDF is copied. The two sides are implementations of a function. The highlighted code is not copied verbatim, it just happens to perform the same task in slightly different ways. Of course some parts of the function are going to do the same thing - after all, the function has to work the same way. So both sides check the argument for NULL (as if that weren't an obvious sanity check) and then proceed to piggyback on the obvious standard (public) functions to do their job. That's like saying I'm infringing on some libc's copyright for implementing strcpy(char *dest, const char *src) as char *p = dest; while(*p++ = *src++); return dest;.
If you want an example of ripped off code, I suggest looking up libogc (the most popular Nintendo Wii homebrew lib). Lots of that has been reverse engineered and manually decompiled from Nintendo's SDK. There you can see how complicated functions follow the same exact code paths, and how the internal architecture of drivers is identical even down to structure layout at times. That is an example of copyright infringement. Not this, this is just writing compatible code in the obvious way.
Slashdot Mirror
The evil "jailbreak vendors who say you shouldn't upgrade" (term used by F-Secure) have stated that they will be releasing a fix for the exploit on the iPod Touch 1G and the iPhone 2G. Ironically, this means that all owners of such devices MUST now jailbreak unless they want to be vulnerable to this exploit forever.
McAfee? Symantec? You seriously expect them to do something useful instead of whining about how Apple doesn't let them write software to hog down your phones even more?
Older devices probably don't support it (the spec is quite recent after all). At least the iPhone 3G does, and quite likely newer devices too. I don't know about the 2G. Older iPods probably won't work.
As for the current, I measured mine at 500mA in this mode, which is consistent with the minimum requirement for a dedicated charger. I guess the iPhone makes no attempt to draw more unless it detects the specific resistors.
Now, of course, Apple hasn't publicly stated that their devices are compatible with USB spec chargers, so nothing's guaranteed. Personally, though, I'd just build in a switch for USB spec vs. dedicated resistor modes into a charger. That should make it pretty universal.
Keep in mind that I'm not advocating going with the spec, as it obviously won't work with older devices. All I'm saying is that there's a reason for the resistors, and this reason prompted an official spec which Apple do comply with in newer devices. i.e. this isn't a story about lock-in, it's about the evolution of USB charging standards. Unless Apple really did stop supporting the charging spec in newer iPhones (I only have my 3G, so I can't check).
That only works for the hexadecimal/octal/binary/2**n-ary representation of pi, though. To get the n-th decimal digit you still need to calculate the rest.
No verb, abuse of the term "hacker", marketroid terminology ("frontier"), and generally fails at providing any insight at all as to the article's contents.
This is one serious entry into the "worst Slashdot headline ever" competition.
I did RTFA and WTFV. SE1 (not SEI) isn't the charging signal, it's a USB data line state (an invalid one that goes against the USB spec). A short across the data lines (without connecting them to any explicit voltage) is what indicates a charger according to the USB Battery Charging spec. Now, SE1 could have well been the magic "charger" indication, but it isn't what was chosen for the USB spec.
Apple chargers use the data lines in non-standard ways (pulled to a voltage using resistors), but shorting them together is the standard way to make a USB charger and, as it turns out, Apple devices (at least recent ones) do understand this and properly charge from such a charger.
It's worth noting that it is impossible to place a USB bus into the SE1 state without resistors. SE1 means both data lines are at 3.3V (at least for full-speed and low-speed USB), which is not the 5V voltage that you have available on a charger, so if you in fact want to put a bus into SE1 state, you'd need resistors anyway. The charging spec is even simpler, it relies on the device detecting a short across the data lines and the charger doesn't have to provide any specific voltage.
And you can software-hack it into a 100MHz DS1102E, the hardware is the same.
Or you can get a $370 Rigol DS1052E, and software-hack it to enable 100MHz mode. Not quite as good as a Tek, but significantly cheaper and well worth the money, especially if you're on a smaller budget. I recently got one (it's about time I bought a scope) and I've been quite happy with it for my purposes.
Info on the hack here.
As far as I know, the NDA is for devices that talk to their 30-pin accessory connector, including component cables, which do have crypto auth and you need to purchase auth chips from Apple (and yes, Apple deserves all kinds of bashing for that one).
I'm not aware of any NDAs required to make a USB compliant charger; all you need to do is visit the USB-IF website and download the USB charging standard spec, which Apple devices are compatible with. Before the charging spec, they didn't publish the resistor stuff, but it's not like it was a trade secret. Most likely they just didn't feel like documenting it. Sure, they could've tried to have it made into a standard, and that would've been a Nice Thing, but I don't think we can say they were deliberately preventing third parties from making compatible chargers just because they didn't publicly publish a few resistor values. "Reverse engineering" minor proprietary extensions like this is part of the day-to-day job of a third party accessory maker, and all USB chargers prior to the spec were outside the standard anyway; Apple just chose to do it a different (safer, saner) way from most other manufacturers.
I tested it and it appeared to draw 500mA (that's 2500mW, don't confuse mW and mA), so I guess the standard charger protocol triggers the current-limited charge mode (same as you'd get with a standard host PC). This makes sense given it's the minimum requirement of the spec.
They are. Short the data lines to an iPhone and it'll go into charging mode, no questions asked, no resistors required, just like the spec says. It seems people just haven't bothered to try it.
200 ohms is the maximum (you'll be out of spec if your resistor is 201 ohms). There is no minimum; what the spec means is that you should just short the data pins together.
I'm glad that someone else has bothered to test this; for a moment I thought I was the only one who knew that recent iStuff follows the official spec, since everyone seems to keep on using the same old resistor hacks.
We all love to call out Apple when they design deliberate incompatibility into their devices, but there is a perfectly valid technical reason for what Apple is doing here, and, in fact, they are following a USB specification (which LadyAda unfortunaterly didn't even test).
Without data communications or when suspended, devices may legally draw no more than 2.5mA from a host, which is useless for charging. In fact, even if you're generous and pretend they're connected, devices are not allowed to draw more than 100mA without negotiating for a higher current, which requires actually talking to the host, and 100mA is still too little to charge properly. 500mA is the maximum allowed by the USB spec, but devices must negotiate it (there may be too many devices on the bus for negotiation to succeed).
Before there was a spec for "dumb" USB chargers, Apple used the resistors as a sentinel to avoid drawing too much current from undersized chargers in order to avoid damaging the host. This is a hack, but it works, and honestly, we're smart enough to figure out a couple resistors on the data lines. It's not like they're using crypto auth on the charger. They have a perfectly valid reason to do this. Devices which charge from "dumb" chargers aren't following the spec, though this is a common industry practice.
As it turns out, the USB-IF came up with a USB Battery Charging spec. The spec is long and boring, but it boils down to: short together the data lines (no resistors required) and you indicate that you're a dumb charger that can supply anywhere from 0.5A to 1.5A.
Guess what happens when you short the data lines of an iPhone 3G and supply 5V. Did Apple just follow a standard? Incredible!
(Yes, I'm not following the USB spec there by in turn using a USB cable to supply the 5V and not negotiating over its data lines. I didn't feel like grabbing a dedicated 5V PSU for the shot, so sue me.)
Presumably, you can request spurious permissions through the XML, but you can't use unrequested permissions in code. In other words, the OS makes no attempt to guess what permissions an app might need; it denies everything by default unless the XML lists the permission and the user accepts it.
As I said, it's highly unlikely for the kind of design defects that cause early failure to be correctable in software, and it also highly unlikely for software modifications to destroy the hardware. Therefore, you should be entitled to warranty coverage on your hardware whether you have modified the software or not. Your original post implies that there are no such cases and that all breakage after software modification happens due to that software modification, or that most of the time "original" firmware prevents such breakage and modified firmware does not, which is patently false.
I mentioned hardware that breaks due to a manufacturing defect or design defect. Manufacturing defects (e.g. poor soldering) and design defects (e.g. underspecced parts) can both cause devices to fail early. Software can only rarely correct for these kinds of defects.
But forcing a company to support (for free) hardware that broke due to a manufacturing or design defect whether you happened to install unofficial software on it or not would be a pretty good idea.
Slashdot filters out just about all useful Unicode for no good reason other than laziness. People were abusing control characters, but they were too lazy to make a proper blacklist and instead opted for an almost nonexistent whitelist.
I wouldn't trust the microcell signal. Femtocells (actual terminology) are a rather new technology and significantly cut down from a real cell tower (they are also based on new, cheap chipsets, not the good stuff). It's quite possible that an implementation bug in the cell (e.g. poor compensation for certain RF interference or signal degradation) is causing this.
What's so special about Irfanview? If you want to do batch conversion of images, use the ImageMagick console tools. If you just want to view images, use your desktop environment's image viewer. If you want to edit them, use whatever editing features are built in to your desktop environment's apps (e.g. KDE's gwenview can do some basic editing) or just use GIMP. Each of these tools will likely do its job better than Irfanview.
As for uTorrent, I find KTorrent is quite similar and a great substitute.
No chance, as UTF-8 isn't a character set but rather an encoding. However, a Unicode table would work pretty well.
I also use AltGr+E to type the Euro sign, though Compose E = also works (I bind Compose to Caps Lock).
Hacking the Linux source to change the CPU frequency registers is significantly easier than understanding a secure boot process.
I've worked with security systems and I can definitely say that the guy who wrote that post doesn't know what he's talking about. I've hever heard of "resettable" eFUSEs. He keeps talking about eFUSEs as if they had some kind of power to control or supervise the boot procedure, which is bollocks - eFUSEs are storage elements, you need some kind of boot ROM to make use of the data and make decisions. And you don't "write programs in JTAG". Until someone writes something technically coherent about this issue, I'd take all of this with a huge grain of salt.
eFUSEs can indeed be used for this kind of self-destruct-on-tamper behavior, but honestly I would be very surprised if it were actually implemented this way on a retail handset. Deliberately designing brickage into a unit is just a bad idea overall (except for security devices, e.g. HSMs and smartcards).
This was posted last month.
A system like that got implemented in Spain a few years ago. All new Spanish national ID cards are smartcards which allow you to cryptographically sign documents with similar validity to a physical signature. It is expected that they will be increasingly used by banks and the like (and they are already being used in order to e.g. file tax documents on-line). The card is protected by a "PIN" (actually a password) and locks you out after a few incorrect attempts.
It's by no means perfect, but it will be interesting to see what comes out of it.
Nothing in that linked PDF is copied. The two sides are implementations of a function. The highlighted code is not copied verbatim, it just happens to perform the same task in slightly different ways. Of course some parts of the function are going to do the same thing - after all, the function has to work the same way. So both sides check the argument for NULL (as if that weren't an obvious sanity check) and then proceed to piggyback on the obvious standard (public) functions to do their job. That's like saying I'm infringing on some libc's copyright for implementing strcpy(char *dest, const char *src) as char *p = dest; while(*p++ = *src++); return dest;.
If you want an example of ripped off code, I suggest looking up libogc (the most popular Nintendo Wii homebrew lib). Lots of that has been reverse engineered and manually decompiled from Nintendo's SDK. There you can see how complicated functions follow the same exact code paths, and how the internal architecture of drivers is identical even down to structure layout at times. That is an example of copyright infringement. Not this, this is just writing compatible code in the obvious way.