Minggu, 27 November 2011

Weapons of Mass Exploitation

Greetings, friends & jailbreakers!

It has now been several months since OPK and I (posixninja) took the stage at JailbreakCon (fka MyGreatFest) in London. Since then, I & other members of the Chronic Dev team have been keeping quietly busy on many fronts, so I thought it was about time to give you all a brief update.

Update on iOS5 Jailbreak

First & foremost: during my JailbreakCon talk in September, I was excited to announce that the Chronic Dev team had already discovered 5 different exploits for use in our upcoming jailbreak. Unfortunately, that announcement was a bit premature, because in the subsequent weeks, Apple found & patched a (critical) few of those exploits, between the beta versions we used for testing and the final release of iOS5 on October 12.

Sadly (and trust us, we are much more sad about this than any of you could possibly be), this has prevented us from being able to release a new jailbreak as quickly as we wanted to. As I hinted at earlier this week on Twitter, I was initially disheartened to think that so many of the countless hours we’ve worked on this jailbreak seemingly went right down the drain.

Not to mention, these are by no means the first exploits that have been “lost” by Chronic Dev (or any other iOS hacking teams) in this manner. In fact, these are just a few in a long-running series of exploits that were patched by Apple before we hackers could make use of them in a free jailbreak for you, our loyal fans.

Well, to be frank… this is bullshit!!! And now, Chronic Dev is ready to turn this little information battle into an all-out, no-holds-barred information WAR. So we want to use this experience as an opportunity to explain the method Apple uses to find potential vulnerabilities, as well as to unveil our new master plan, which should not only prevent this from happening to us again in the future, but also allow us to use all of you to find more exploits, so we can ultimately get an untethered jailbreak into your hands as quickly as possible.

How Apple Finds Exploits

One of the primary challenges in working with userland exploits is that, every time any program crashes on your iPhone, a “crash report” is generated and instantly sent back to Apple. As you can imagine, while we’re working out all the kinks in the exploitation of a vulnerability, we may need to crash any particular program thousands & thousands of times.

It’s possible to change your iTunes settings to stop sending this diagnostic information back to Apple, and of course everyone in Chronic Dev has made this change on all our development machines. However, even this is not always 100% effective at preventing Apple from obtaining our data. For instance, if one of us is at a friend’s house and plugs our iPhone up to his or her computer (even just to charge it), it’s very likely that computer is set up to send all our valuable data & crash reports right back to Apple.

As a side note, this is also the primary reason we’re unable to perform or allow any public beta testing of our software before it’s released. Any potential beta tester could be unknowingly sending crash reports back to Apple, which would prematurely alert the company to our exploits & the discovery of their vulnerabilities before we even have the chance to release.

Help Us Help You: Send Us Your Crash Reports

Instead of allowing this vicious cycle to continue, we decided to write a new program to turn Apple’s own beast against its master, per se. All this program requires from you is to attach your iOS device to your computer and click a single button!

At this point, the program copies all the crash reports off your device (which, under normal circumstances, would be sent right back to Apple), and instead sends this data to a secure, private server hosted by your friendly Chronic Dev team. Next, our program proceeds to neuter your copy of iTunes, simply by changing your settings to prevent your computer from sending any further diagnostic information from your device to Apple.

Using this agglomeration of your crash reports and our ninja skills, Chronic Dev will be able to quickly pinpoint vulnerabilities in various programs by using the same techniques Apple currently employs. At the very least, your data will help point us in the direction of which applications are the most vulnerable, so we can focus our time & energy on these with laser-like intensity. And, of course, this will also prevent Apple from accessing all your valuable data, just so they can then turn around and use it against you.

Thank You!

Many thanks in advance for your prompt response & help in this effort, your continued support of GreenPois0n & the Chronic Dev team, and your patience while we continue our never-ending, diligent work on your (free!! coming soon!) untethered jailbreak for iOS5 and/or iPhone 4S.

One final THANKS! While I have spent many of my own hours on the development, design & programming of this tool, especially the back-end, I also owe a great debt of gratitude to:

C-Dev hacker Nikias & his lovely wife Hanene – for the many tedious hours they spent programming the front-end & user-friendly interface;
C-Dev member OPK – for his graphic design work & the brilliant logo for this app; and
Chronic-Dev, LLC – for graciously hosting the servers where we will store the (fingers crossed) millions of crash reports and other data that you all are going to send us momentarily, via this link…

[CDevReporter_mac.zip]

[CDevReporter_win.zip]

[PLEASE NOTE: This link is to the Mac beta version of our software. An updated/final Mac version as well as a Windows version will be available in the next 24 hours.]

Jumat, 18 November 2011

How to Unlock Your GSM iPhone 4S, No Jailbreak Required

Early GSM-flavored iPhone 4S adopters may be happy to hear

that Twitter user xoicos has found a way to unlock the new handset using a bug in iOS 5. Of course we know that Apple sells unlocked phones outright, but they are considerably more expensive.

Unlocking a device means that you are be able to activate it on other wireless carriers outside of the one you purchased the phone from. Initially, unlocking the iPhone required complexed baseband tweaking, but now it could be as easy as following these steps…

OSXDaily claims that several users have reported success with this unlock method, but it does warn readers to follow the guide at their own risk. We haven’t been able to confirm its safety or success either, so we are going to issue the same warning.

This tutorial describes how to unlock an AT&T iPhone 4S to work on T-Mobile’s network, so results with other carriers may vary. Obviously you’ll need a GSM iPhone 4S, and both an AT&T and T-Mobile SIM card (or one from a compatible GSM carrier).

“Step 1. Insert your AT&T SIM card. Dial 611 for customer service, and once it starts ringing, hang up.
Step 2. Turn on your iPhone’s Airplane mode, take out the AT&T SIM card, and replace it with a T-Mobile SIM.
Step 3. Make sure Wi-Fi is off, and clear any remembered networks to ensure it doesn’t auto-connect later.
Step 4. Turn off Airplane mode. The handset will search for a network, and the Activation Required screen will popup.
Step 5. Once you notice the device has found an EDGE network (E symbol), wait about 30 seconds and turn off the phone.
Step 6. Power the handset back on, and you should see the same Activation Required screen.
Step 7. Once you notice you have 1 bar of signal, tap on the Use Cellular Connection option. Then eject the SIM card.
Step 8. The Activation Required screen should pop up again. Re-insert the T-Mobile SIM card, and you should be unlocked.”

It’s worth noting that some users had to repeat this process multiple times for it to work. We’ll keep you updated on our findings once we can test this out for ourselves.

Did this guide work for you?

Rabu, 16 November 2011

How to Enable Native FaceTime Over 3G Feature in iOS 5

In the onslaught of rumors that we saw leading up to Apple’s Fall iPhone announcement,

there was talk that iOS 5 would finally allow users to make FaceTime calls over 3G. As most of you know, FaceTime has been limited to Wi-Fi since its introduction.

As it turns out, the option actually exists in iOS 5, it’s just hidden. Apple obviously isn’t ready to release it to the public. But as usual, hackers have figured out how to enable the secret feature…

Sure, jailbreakers have been using utilities to make FaceTime calls over 3G for quite a while now. But unlike those apps, enabling the native iOS 5 feature won’t cost you anything. And you won’t need to open third party software to make calls.

But you will, however, still need to be jailbroken, as you will be editing a .plist file inside your device. That means this tip is for iPhone 4 users only at this time.

Step 1. Using iFile or any other file browser, navigate to/System/Library/CoreServices/SpringBoard.app/

Step 2. Locate the N90AP.plist and open it.

Step 3. Below the line, under capabilities, add in 3Gvenice

Step 4. Make sure to save your changes, and then exit the file browser.

That’s all there is to it. Remember to watch your usage if you aren’t on an unlimited dataplan. Video calls can really rack up the MBs.

Senin, 14 November 2011

Cracking Siri

On October 14, 2011, Apple introduced the new iPhone 4S.

One of its major new features was Siri, a personal assistant application. Siri uses a natural language processing technology to interact with the user.

Interestingly, Apple explained that Siri works by sending data to a remote server (that’s probably why Siri only works over 3G or WiFi). As soon as we could put our hands on the new iPhone 4S, we decided to have a sneak peek at how it really works.

Today, we managed to crack open Siri’s protocol. As a result, we are able to use Siri’s recognition engine from any device. Yes, that means anyone could now write an Android app that uses the real Siri! Or use Siri on an iPad! And we’re goign to share this know-how with you.

Demo

The best demo probably is Siri’s speech-to-text feature. We made a simple recording of us saying “autonomous demo of Siri”, and got a perfect result !

Sample_Siri_speech_to_text.zip

70.78 KoDownload

This sound sample never went through any iPhone, but nonetheless we got Siri to analyze it for us.

Understanding the protocol – A brief technical history

We’re used to building mobile applications. The best way to chat with a remote server is HTTP, as it’s the protocol that is the more likely to work in any case.

The easiest way to sniff HTTP traffic is to setup a proxy server, configure your iPhone to use it, and look at what goes through the proxy. Surprisingly, when we did, we wouldn’t gather any traffic when using Siri. So we ressorted to using tcpdump on a network gateway, and we realised Siri’s traffic wasTCP, on port 443, to a server at 17.174.4.4.

Going to https://17.174.4.4/ on a desktop machine we noticed that this server was presenting a certificate for guzzoni.apple.com. So it seemed like Siri was communicating with a server named guzzoni.apple.com over HTTPS.

As you know, the “S” in HTTPS stands for “secure” : all traffic between a client and an https server is ciphered. So we couldn’t read it using a sniffer. In that case, the simplest solution is to fake an HTTPSserver, use a fake DNS server, and see what the incoming requests are. Unfortunately, the people behind Siri did things right : they check that guzzoni’s certificate is valid, so you cannot fake it. Well… they did check that it was valid, but thing is, you can add your own “root certificate”, which lets you mark any certificate you want as valid.

So basically all we had to do was to setup a custom SSL certification authority, add it to our iPhone 4S, and use it to sign our very own certificate for a fake “guzzoni.apple.com”. And it worked : Siri was sending commands to your own HTTPS sever! Seems like someone at Apple missed something!

That’s when we realised how Siri’s protocol is opaque. Let’s have a look at a Siri HTTP request. The request’s body is binary (we’ll get into that later), and here are the headers :

ACE /ace HTTP/1.0
            Host: guzzoni.apple.com
            User-Agent: Assistant(iPhone/iPhone4,1; iPhone OS/5.0/9A334) Ace/1.0
            Content-Length: 2000000000
            X-Ace-Host: 4620a9aa-88f4-4ac1-a49d-e2012910921

A few interesting things :

The request is using a custom “ACE” method, instead of a more usual GET.
The url requested is “/ace”
The Content-Length is nearly 2GB. Which is obviously not conforming to the HTTP standard.
X-Ace-host is some form of GUID. After trying with several iPhone 4Ses, it seems to be tied to the actual device (pretty much like an UDID).

Now let’s move on to the body. The body is some raw binary content. When we first looked at it with an hex editor, we noticed it started with 0xAACCEE. Oh, seems like header ! Unfortunately, we couldn’t understand anything of what was after that.

That’s when we took some time to think. As people who are used to designing mobile application, we know there’s one thing which is very important when talking over a network : compression. The bandwidth is often limited, so it’s usually a very good idea to compress your data. And what is the most ubiquitous compression library around ? zlib:“http://zlib.net/”. It’s a very solid library, really efficient and powerful (makes sense, it’s half french!). So we tried to pipe that binary data through zlib. But nothing came out, we were missing a zlib header. That’s when we thought “hmm, so there’s already thisAACCEE header in the request body. Maybe there’s some more ?”. We developpers like to keep things packed. 3 bytes is not a good length for a header. 4 would be. So we tried un-zipping after the 4th byte. And it worked!

Now when we unziped the content, we got onto some new binary data. Not very understandable either, but some parts were text. Among them, one caugh our attention : bplist00. Hurray, it seems like the data is some binary plist. After fiddling a little bit with that binary stream, we figured out it was made out of chunks :

Chunks starting with 0x020000xxxx are “plist” packets, xxxx being the size of the binary plist data that follows the header.
Chunks starting with 0x030000xxxx are “ping” packets, sent by the iPhone to Siri’s servers to keep the connection alive. Here xx is the ping sequence number.
Chunks starting with 0x040000xxxx are “pong” packets, sent by Siri’s server as a reply to ping packets. Without surprise, xx is the pong sequence number.

And deciphering the content of binary plists is very easy, you can do it on Mac OS X with the “plutil” command-line tool. Or in ruby with the CFPropertyList gem on any platform.

What we learned

We did really learn a few interesting things about how the iPhone 4S talks to Apple’s servers :

The audio data

The iPhone 4S really sends raw audio data. It’s compressed using the Speex audio codec, which makes sense as it’s a codec specifically tailored for VoIP.

Signature

The iPhone 4S sends identifiers everywhere. So if you want to use Siri on another device, you still need the identfier of at least one iPhone 4S. Of course we’re not publishing ours, but it’s very easy to retrieve one using the tools we’ve written. Of course Apple could blacklist an identifier, but as long as you’re keeping it for personal use, that should be allright!

The actual content

The protocol is actually very, very chatty. Your iPhone sends a tons of things to Apple’s servers. And those servers reply an incredible amount of informations. For example, when you’re using text-to-speech, Apple’s server even reply a confidence score and the timestamp of each word.

What’s next ?

Here’s a collection of tools we wrote to help us understand the protocol. They’re written mostly in Ruby (because that’s a wonderfully simple language), some parts are in C and some in Objective-C. Those aren’t really finished, but should be very sufficient for anyone technically inclined to write a Siri-enabled application.

Let’s see what fun application you guys get to build with it! And let’s see how long it’ll take Apple to change their security scheme! Follow me on twitter @lovetenderhh for updates on that subject

Minggu, 13 November 2011

Download Siri FULL INSTALL via Cydia! [TUTORIAL]

I know many of you have been skittish about SSHing files and such,

so here is a Cydia repo where the files are downloadable.

Please note that this is not compatible with Semitether, you will need to uninstall that to avoid a respring loop.

click here -> CydiaRepo

Just install, it does everything for you. Thanks, @ChristopoulosZ

I´m very close to release the Serverconnection if u wana help me just donate to egohot.dev@googlemail.com -- Paypal
Video tutorial on how to install:

Download iTunes 10.5.1 Beta 3 With iTunes Match

Screen-Shot-2011-11-01-at-11.29.15-AM-560x352

iTunes 10.5.1 Beta 3 has been released by Apple to developers

with more important stability and performance improvements for iTunes Match. This beta version , which is now available on the iOS Developer Center allows you for continued testing of iTunes Match.

iTunes 10.5.1 beta 3 includes a number of important stability and performance improvements for iTunes Match, and is a required update for all subscribers to iTunes Match beta.

Backup regularly and do not delete the music you add to iCloud from your computer. Apple may periodically delete all iCloud libraries during the beta period. This will require you to scan, match, and upload songs again