__ __ __ ___ / // /__ _____/ /__ ___ _ / _ \___ ___ __ / _ / _ `/ __/ '_/ / _ `/ / // / _ `/ // / /_//_/\_,_/\__/_/\_\ \_,_/ /____/\_,_/\_, / retro edition /___/Now optimized for embedded devices!
|About||Successes||Retrocomputing guide||Email Hackaday|
As promised in their yellowsnow demo, [pytey], [MuscleNerd], and [planetbeing] from the iphone-dev team presented at 25C3 on their work Hacking the iPhone. The team originally formed in 2007 and this is the most comprehensive presentation on how the iPhone was compromised to date. You can find the full talk embedded above.
They opened with a few stats about how popular their software is. Our favorite by far is that at least 180 people with Apple corporate IPs update their phones using the dev-team’s software on a regular basis. From there the talk was split into two sections: jailbreaking the S5L application processor and unlocking the S-Gold baseband processor.
The phone relies on a chain of trust to guarantee that only Apple’s code is being run on it. All of userland is signature checked by the kernel. The kernel is checked when loaded by iboot. The iboot image is checked when loaded by LLB. LLB is loaded from the NOR by the lowest piece of code, the bootrom. That’s where things fall apart; the bootrom does not check the signature of the LLB. To take advantage of this, the team found what they describe as a classic stack buffer overflow in DFU mode. DFU is Device Firmware Upgrade mode, a state that the phone can be forced into after the bootrom loads. Their exploit forces the certificate check to return ‘true’. They are then able to patch all of the subsequent signature checks out of the phone’s system.
The baseband processor proved to be much more difficult simply because it doesn’t have any sort of recovery mode; bricking a phone was always a possibility. The S-Gold is a complete system-on-chip and has a unique ID on each phone. The NOR also has a unique ID on each phone. These two IDs are used to sign the secpack, which in turn enforces the SIM carrier lock. These unique IDs are why you can’t just take an officially unlocked phone and copy the secpack off of it to unlock another phone. Everything else is identical: the firmware, the baseband, the bootroom are all the same. On the second generation iPhone, the bootrom checks the bootloader. The bootloader then verifies the bootrom before checking and then loading the firmware. The firmware enforces the carrier lock. The team decided that it wasn’t worth attempting to break the chain of trust. The SIM unlock code they developed is divided into two sections. The first part is the actual software unlock. They patch the firmware while it’s running in RAM. Their patch modifies the firmware’s decision tree about whether to enforce the carrier lock. The second half is the exploit that allows them to inject the code. The team knows that Apple can and probably will patch the exploit hole, but their RAM patching code will always work, so it’s just a matter of finding another hole to apply it through. In order to do a permanent unlock solution (like on the first generation iPhone), they’d need to analyze the actual bootrom code.
The team mentioned several things Apple did that actually helped them in their efforts. Security was gradually rolled out, so they were able to look at things that would eventually be hidden. The firmware was initially unencrypted. Earlier versions trusted iTunes, something they could easily modify. All userland apps originally ran as root meaning any application exploit gave root level access.
The iphone-dev team has truly put in a tremendous amount of effort and we look forward to the yellowsn0w release on New Year’s Eve.
[Windell] was stoked enough to send us [Jay]‘s sweet hack on [Windell]‘s Evil Mad Scientist Laboratories Peggy 2.0 kit. [Jay] added serial input and hacked quartz composer on his mac to light up all 625 LEDs with live motion video. If you were jealous of the Metalab’s giant LED display, now you can have your own – smaller and cheaper.
EMSL has recently supplemented this awesome device with their Arduino Library for Peggy 2.0. It is a program library that contains various animations and demonstrations of how to draw on a Peggy. Download and enjoy them as they are or tweak them to test out some of Peggy 2.0′s capabilities.
Paul, as he describes himself, is “a student without a big budget,” which might have been part of the inspiration for this hack . Paul wanted to see how much time he was spending under the shower each day, so came up with this monitoring device using the ever-awesome Arduino processor and a RFID tag that many of you are certainly familiar with. One simply waves the tag in front of the reader to start the timer, and waves it again to stop it.
One may not, however, be familiar with “thingspeak” and “weatherspark“, two other important elements of this hack. Thingspeak is “an open application platform designed to enable meaningful connection between things and people,” and was used to interface the weather data on weatherspark with the shower monitor. This was to help figure out if there was a connection between outside temperature and the length of showers taken.
The results of this experiment should be interesting, so hopefully some will be published soon!
[Mike Field] took what he had learned with a few past projects and combined them to make this FPGA-based SPDIF audio pass-through. In order to get the SPDIF signal ready for the FPGA he needed a few components to use for level conversion. Once everything was connected he used a first in first out (FIFO) buffer to ensure that the outgoing bitrate is the same as the input, while still allowing enough time for the FPGA to do some digital manipulation.
This reminds us of the NeTV, which is an HDMI pass-through device. That one allows you to overlay your own video information to any TV that has an HDMI port. This would allow you patch into any audio system that’s using SPDIF, letting you inject your own audio, such as a paging system in a public lobby, or the ringing of a phone when you get a call, or to create your own sounds.
We like his overhand knot cable management system to keep those jumper wires from becoming too much of a mess on the breadboard.
Today we continue on with part 2 of our series where [Jack] shows how to program for the ATmega328p processor using the Pololu 3pi robot. In this video, he starts to dig deeper than last week’s video by showing you how to program in C so that you are directly reading inputs and directly sending data to outputs. Specifically, this video shows how to set up your I/O pins and then how to interface with LEDs, buttons, and a beeper.
There were a few comments on last week’s video about not wanting to buy a 3pi robot to learn on. That’s fine. For this series there really is no reason that you need to use the 3pi robot. We picked it because it is a great device to learn about the ATmega processors since it has so many things that you can play around with to get your feet wet but there really is no reason that you couldn’t wire up a DIP version on a perfboard and still follow along with these videos. In fact, if you have a good writeup about the cheapest possible way to get started with the ATmega series of processors, we’d love to hear about it.
Looking for part 1 of this series? [Click Here]
Video is after the break.