Monday, March 3, 2014

Puffchat Fail. By @NinjaLikesCheez

The following content below was produced by @NinjaLikesCheez and mirrored for archiving purposes.
Original Source:
"It's a texting alternative to Snapchat, where you can send self-destruct texts to contacts, great for confidentiality/discreet messages that you want permanently erased." - Michael, CEO -developer of Puffchat. "Everything is secure guys, and phone numbers aren't required for registration like Snapchat." - Michael. Image © Puffchat. Puffchat popped up on my Facebook Timeline this week with the claim of being a 'secure' alternative to Snapchat. It has a nice user base for what it is with the dev claiming over 11,000 users... not bad, but is it secure?

Puffchat's registration asks for three pieces of information - Email, Password, & your Date of Birth. If these are acceptable it then asks for your desired username & access to your contacts. A lot of applications these days ask for access to your contacts, yet a lot handle your data incorrectly. One of the first things Puffchat does is upload your address book (via HTTP) to their 'secure' severs, along with some registration data and a unique device key to link the account to your phone. The application communicates with a REST API hosted on and has a couple of modules that do various operations; every request sent from the app has a key argument that holds a secret (not-so-secret) key. We all know you can't keep a secret key secret in a binary, you can try and hide it but not only is it pretty futile, in this case it wasn't done at all.So Secret. Much InfoSEC.
So Secret. Much key. Very hidden.

Turns out that searching for anyone gives you their registered username (not bad), birthday (wait what?), and registered email (which is shown in the app under their username). So by searching for a user you get three really nice pieces of information about them, and a lot of people still use their birthdays as their PINs, passwords, or security questions.
Not only that, but you can do almost any operation in the API on any account without access to the account or local access to the device . Proof? Well you can go ahead and send a friend request to yourself from any account you want - the CEO in this case.

key -> dl81Vh2uorfNdj2Rt2M4EylW91uUsQRZwhQ99g7K0MRXeMYePS
moduleName -> addFriendRequest
userName -> michael
userEmail -> michael***@***.*** 
friendName -> ***@***.***
friendEmail -> ***@***.***
Michael Puffs
Turns out you can send them on other's behalf too

Here comes the kicker;

Nothing is deleted automatically (even when the message is read). It's all their in the API responses.
{"success":true,"data":[{"id":"***","sender":"***","sender_email":"***@***", "receiver":"***","receiver_email":"***@***", "text":"hi babe send me back","filename":"***","time":"***", "duration":"10","status":"Read","is_taken_screenshot":"0"}
You can clearly see the server knows the message has been read and yet it remains; it's downloaded to your phone every time you make a request for your messages, the client just doesn't show it to you... and yes, that includes the nude dickpics you've been sending to that account. To top is all off, you can visit the pictures publicly and see via their site - nice! This is an incredible breach of privacy, and a blatant lie to their customers. It's 'secure' but no SSL, it's 'secure' but I can control your account remotely, it's 'secure' but I can see your junk on the web by visiting a public page. Proof?

Here you go:

Obviously censored to protect the poor guys pride.

In the interest of responsible disclosure I did try and contact the dev multiple ways, I was either ignored or not replied to and I feel users deserve to know what's happening with their data. It's only saving grace is that it appears to delete the message logs if you manually clear your feed, still a far way off being secure.

Sunday, January 5, 2014

p0sixspwn - Cydia not showing up/Not jailbreaking

Hi again,

If you're jailbreaking with p0sixspwn and notice that Cydia is not showing up,

Try p0sixspwn v1.0.7


Monday, December 30, 2013

p0sixspwn - Data connection/iMessage/iCloud issues


For those experiencing "No Data" or "No LTE", or similar symptoms... Do this...

1) Open Cydia.
2) Tap Changes on the bottom.
3) Tap Refresh in the top left corner.
4) Wait for Cydia to reload data (IMPORTANT!)
5) Search for 'p0sixspwn'.
6) Install it.
7) Reset Network Settings.

That should be it.

We'll also push an update for the Mac version of p0sixspwn shortly to address new jailbreakers.

~@iH8sn0w & @winocm

Monday, December 23, 2013

6.1.3 & 6.1.5 3GS/A4 untether Cydia package

Hello everyone,

With the unexpected release of the evasi0n7 jailbreak, we are finally able to release the 3GS/A4 6.1.3 + 6.1.5 untether Cydia package.

To grab it...

1) Have a tethered jailbreak (either via redsn0w [Point to 6.0 IPSW] or sn0wbreeze).
2) Open Cydia.
3) Click the "Changes" tab in the footer.
4) Press the "Refresh" button in the top left corner.
5) After "Reloading Data", perform a search for "p0sixspwn" (the O is a zero).
6) Tap Install.

That's it! You're untethered.

I'll be updating sn0wbreeze to incorporate the untether directly later (No eta :P).

Our next priority is getting an A5+ jailbreak for 6.1.3/6.1.4 out. As I stated on Twitter, we expect it should be out by Christmas day. So if you don't feel like upgrading to iOS 7 and prefer 6.1.3/6.1.4, sit tight for a bit. :)

A guaranteed drama-free untether (hopefully :]).

If you have intentions of submitting us donations, submit 'em to the EFF directly.

@p0sixninja (for the name ;P)
@saurik (for hosting :))

If you have an questions or issues, please direct them to the JailbreakQA forum where *awesome* people will help you! :)

Monday, October 7, 2013

Its Dumping Season!

Many of those who follow me attentively on Twitter noticed that I was asking for people jailbroken on 6.1.2 to email me to dump their kernels. Not many of you seemed to ask why, which is interesting :P

The 6.1.2 kernel dumps are crucial for locating specific functions within the kernel that are static between iOS 6.1.x kernel builds. This means functions such as "_START" within the kernel, are located at the same location in 6.1.2 kernels and 6.1.3 kernels.

So, why do we need these? Simple. We need some static offsets for functions within the 6.1.2 kernel to utilize them in the 6.1.3 kernel, and dump the actual 6.1.3 kernel.

The 6.1.3 kernel is more essential as some kexts such as the sandbox kext, signature check kexts [AMFI], etc, are not static and tend to shift its location on every recompile.

So what's next? Time to start dumping the 6.1.3 kernels for devices we do not have (list below).

6.1.3/6.1.4 Kernels Dumped:

Dumped? Product ID Device Name Board Config
iPhone2,1 iPhone 3GS n88ap
iPhone3,1 iPhone 4 (GSM) n90ap
iPhone3,2 iPhone 4 (GSM-RevA) n90bap
iPhone3,3 iPhone 4 (CDMA) n92ap
iPhone4,1 iPhone 4S n94ap
iPhone5,1 iPhone 5 (GSM) n41ap
iPhone5,2 iPhone 5 (Global) n42ap
iPad2,1 iPad 2 (WiFi) k93ap
iPad2,2 iPad 2 (GSM) k94ap
iPad2,3 iPad 2 (CDMA) k95ap
iPad2,4 iPad 2 (WiFi-RevA) k93aap
iPad2,5 iPad mini (WiFi) p105ap
iPad2,6 iPad mini (GSM) p106ap
iPad2,7 iPad mini (Global) p107ap
iPad3,1 iPad 3 (WiFi) j1ap
iPad3,2 iPad 3 (CDMA) j2ap
iPad3,3 iPad 3 (GSM) j2aap
iPad3,4 iPad 4 (WiFi) p101ap
iPad3,5 iPad 4 (GSM) p102ap
iPad3,6 iPad 4 (Global) p103ap
iPod4,1 iPod touch 4 n81ap
iPod5,1 iPod touch 5 n78ap
* The iPhone 5 6.1.3 & 6.1.4 kernels have been dumped.        

I have one of the devices listed above that is not () dumped yet. How can I help?
  • Have an Intel-based Mac running 10.6 or above.
  • Email a screenshot of f0recast for Mac with the device connected to 
Why does it have to be a Mac?!
The client I wrote to dump the kernel over USB only runs on Intel based Macs.

Does this mean a release after all the dumps are collected? :O
Not right after, but close. The kernel dumps will help us finish the untethers for these devices. Once that's done, we can finally begin writing the tool and finalizing everything.

I helped you dump a 6.1.2/6.1.3/6.1.4 kernel!
Thank you very very much!

Update #1 (Oct. 13): iPad2,1 - 6.1.3 kernel is dumped. More devices pending.
Update #2 (Oct. 14): iPod5,1 & iPad2,2iPad2,5 - 6.1.3 kernel is dumped. More devices pending.
Update #3 (Oct. 15): iPad2,4 & iPad2,7 - 6.1.3 kernel is dumped. More devices pending.
Update #4 (Oct. 16): iPad2,3 iPad2,6 & iPad3,1 & iPad3,3 & iPad3,4 - 6.1.3 kernel is dumped. More devices pending.
Update #5 (Oct. 17): iPad3,6 - 6.1.3 kernel dumped. 2 more devices pending.
Update #6 (Oct. 18): iPad3,5 - 6.1.3 kernel dumped. iPad3,2 pending.
Update #7 (Oct. 21): iPad3,2 - 6.1.3 kernel is finally dumped. What follows next is finalization of the untether bootstrap. There is no knowing how long this will take but we'll post an update when its done. Then the tool creation will follow after that. Again, ETA is still before 2014.
Update #8 (Oct. 28): I've mentioned this on Twitter, but seeing as A5+ devices are going to take awhile, we'll probably end up releasing the iPhone 3GS/A4 6.1.3 untether via a Cydia package after the bootstrap for it is completed. Still no ETA as to when it will be finished, but still aiming for before 2014.
Update #9 (Nov. 1): People are probably wondering why focus on A5+ devices is being lowered in priority. This is not because of difficulties, it is actually because it turns out a few of the vulns we were planning on using still work on iOS 7 (kind of exciting [yes and no]). We do not want to publish these vulns as they have the potential of being used in a future iOS 7.x A5+ jailbreak. With that being said, we are not removing our focus on an A5+ 6.1.3/6.1.4 jailbreak completely. We are looking for some vulns that exist in 6.1.3/6.1.4 but not iOS 7. The problem is... in terms of security iOS 7 looks likes an iOS 6.2 :P. This wouldn't be a problem if Apple did not silently kill the lockdown socket bug. We were initially planning on using that vuln to recycle the shebang attack used in evasi0n to remount the rootfs, but when I found out it was patched, I initially said it wouldn't halt the progress of the jb. This was before we found out the other vuln we had to get root and remount the rootfs as r/w still works in iOS 7. So as I said above, we are currently working on getting the A4 untether bootstrap finished. After that, we will resume looking into the A5+ possibility. If worse comes to worse, we'll release it alongside evad3r's iOS 7 jb to prevent disclosing any more vulns.
Update #10 (Dec. 21):
Update #11 (Dec. 23): Packaging the 3GS+A4 untether for 6.1.3+6.1.5 as i'm typing this. Should be up on saurik's repo. Will update this when that happens.

Monday, September 23, 2013

Some updates...

Just some brief updates to hopefully lower the number of mentions on my Twitter :P

6.1.3/6.1.4 A5+ Jailbreak status?!

As Apple closed the 6.1.3/6.1.4 signing window for devices capable of running iOS 7, many of you stayed behind on 6.1.3/6.1.4 (which is probably the best thing to do).

Everything for a 6.1.3/6.1.4 A5+ jailbreak is there. We're focusing on fixing bugs that occur internally. These range from Applications automatically deleting themselves from the uicache to iMessage/Facetime activations not working (even on legit sims). As far as a time frame goes for fixing these bugs, we have no idea. We're not lying. Its not like we got a progress bar going up every few minutes or something :P. I'll try to update this specific post as more things progress. 

Does this also apply to A4 devices?
Yes, A4 devices will get the 6.1.3 untether alongside this release.

Why don't you just release it now and release updates later to fix bugs?
Some bugs that are occurring internally sometimes require the user to restore their device in iTunes. This obviously is not good if its an A5+ device as it will kick them out of this window of using the 6.1.3/6.1.4 jb.

Why don't you give ETAs?!
As I tweeted the other day, "Funny thing about ETAs: When one is said but failed to achieve, people get more rowdy than if no ETA was announced at all.". So with that being said, no date/ETA is being given. When its ready it'll be pushed. Again, we have no idea of any time frame as to when it'll get pushed. If anything, before 2014 :P.

Update #1 (Sept. 26, 2013): Looks like even more internal stuff is breaking. Still a work in progress.
Update #2 (Sept. 27, 2013): Added three more entries to blog.
Update #3 (Oct. 5, 2013): In the midst of polishing the 6.1.3/6.1.4 untether. While doing so, I requested people running 6.1.2 jailbroken devices to email me to dump their kernels for reference. In conjunction with that, I also requested people running 6.1.3/6.1.4 to email me as well. However, many seemed to have emailed me expecting to beta test the jailbreak. Not true, this was also for dumping kernels. I'm not sure why many people would want to beta test a jailbreak for an iOS Apple is not actively signing anymore anyways(if something goes, you'd be forced to restore to 7.x). Release is definitely not this weekend, so don't get your hopes up. ETA for it is before 2014. When release is close, we'll tweet it. (Please don't bother tweeting asking for an ETA/progress).
Update #4 (Oct. 6, 2013): Got every iPad 6.1.2 kernel dumped for reference (thanks to everyone who emailed!). Will be putting something together shortly to easily dump 6.1.3 kernels. When I need specific iPads on 6.1.3, I'll be sure to make a tweet. iPhones 4/4S/5 and iPod touch 5 6.1.3 kernels are already dumped, so those devices are not needed.

Be sure to follow @winocm @iH8sn0w and @SquiffyPwn for the latest updates on this.

Why not keep these exploits for an iOS 7 jailbreak?!

They don't work on iOS 7.

iTunes 11.1 - WHAT IS THIS?! GO AWAY?!

Along with Apple pushing iOS 7, they updated iTunes to 11.1. This actually brought more headaches than convenience. 

When a user hits the restore button, they often see "iTunes will erase and restore your iDevice to iOS x.x.x and will verify the restore with Apple". What this does is submit a request to Apple for an apticket + SHSH blobs. Previous revisions of the iTunes Mobile Device Library would just use the BuildManifest included inside of an IPSW to supply the request to Apple with the essential "hashes" of each image within the IPSW. When tools like sn0wbreeze, PwnageTool, seas0npass, or redsn0w modified images such as iBSS, iBEC, ramdisk to avoid signature checks during the restore, iTunes didn't care or know. 

Now, prior to iTunes sending the TSS request to Apple, they ignore the values already in the BuildManifest and "re-hash" every image within the IPSW to create the TSS request. Meaning if 1 byte of any image is modified, when iTunes calculates the new "hash" and sends the TSS request, the TSS server will refuse to fulfill the request (Error 3194 is displayed). This essentially kills iOS 7 custom IPSW restores via iTunes.

Moving on to Error 11... This error seems to only be related to devices with basebands that require bbtickets (So basically the iPhone 4). Even though iFaith/sn0wbreeze removes the baseband requirement, iTunes 11.1 is expecting the iPhone 4 baseband firmware to be signed no matter what and notices that it isn't. This causes it to error out with code 11 (Error 11). It is worth noting that this issue was already present in the Mac OS MobileDevice framework on iTunes 11.0.x. When iTunes 11.1 was released for Windows, it looks like they finally merged code. Thus bringing the issue to Windows with iTunes 11.1. This does not affect the iPhone 3GS (bbfw is always pre-signed), 

A temporary workaround to fixing Error 11 on Windows is by downgrading to iTunes 11.0.x. You can find download links to old revisions of iTunes over here (thanks cj!).

One more thing worth mentioning is iREB for the iPhone 2G, iPhone 3G, and iPod touch 1G is broken with the iTunes 11.1 update. This is on my list of things to fix, but again... a workaround is typed up above.

sn0wbreeze/iFaith updates for iOS 7 please?!

As I have said above, iTunes 11.1 essentially kills iOS 7 custom IPSW restores via iTunes due to the "re-hashing" that is performed prior to the restore. I am working on a workaround for this, it will probably end up being something like the actual restore occurring within sn0wbreeze/iFaith itself (similar to redsn0w's "Restore" functionality).

As far as saving the iOS 7 apticket + SHSH blobs, iFaith can already fetch these blobs by selecting the "Show available caches on server" button and following on-screen prompts. This will work on all devices (including A5+ devices) except for the new iPhone 5C and iPhone 5S. 

Dumping functionality to dump iOS 7 blobs+apticket on the iPhone 4 will come when I get around the silly iTunes issue sorted.


Before you start wanting an iOS 7 jailbreak, you should know that lots of things are currently broken in iOS 7. To list a few: Cydia, MobileSubstrate, and WinterBoard. Not really worth pushing anything at the moment until these issues are sorted out (please don't bug saurik to fix it. He is aware of it already). 

With that being said, there is no use in pushing a user-friendly tethered iPhone 4 jailbreak at the moment.

As for updates on an A5+ iOS 7 jailbreak, follow the @evad3rs for updates on that.

Wednesday, September 18, 2013

Today is iOS 7, WHAT DO I DO?!?!?!?!!!!

Alright, so obviously everyone is freaking out about whether or not to stay on 6.1.3/6.1.4 or to upgrade to iOS 7 right away as there is currently no public jailbreak for 6.1.3/6.1.4. This post should explain everything. PLEASE READ EVERYTHING (no skimming please).

I'm an iPhone 4 user, what should I do?

If you have not already, make sure you save your iOS 6.1.3 SHSH blobs with iFaith, TinyUmbrella, or redsn0w (ipsw required). There is a lot of confusion about having to be running iOS 6.1.3 to obtain such blobs. No, that requirement only applies if you're dumping blobs right off the device. Which also makes me mention, if you have a firmware below 6.1.3 and do not have SHSH blobs for it, make sure to grab those blobs with iFaith. If you obtain these SHSH blobs, you are free to upgrade to iOS 7 and downgrade back down in case of anything getting released (DOES NOT APPLY TO A5 USERS).

I'm using a device with an A5 processor or higher, what should I do?

If you are currently on iOS 7, I would recommend downgrading to 6.1.3/6.1.4 (via DFU).

Why? There is currently a possibility of a potential 6.1.3/6.1.4 untethered A5+ jailbreak being pushed in the upcoming days/weeks.

If you wish to be included if such thing takes place, downgrade now. While you still can! Once iOS 7 goes live later today, the 6.1.3/6.1.4 signing window should close within the hour of the release (possibly even minutes).

If you're still running 6.1.3/6.1.4, today is your last chance to restore and get a "fresh" start.

If you're jailbroken on 6.0 --> 6.1.2 with evasi0n, you're better off staying where you are.

It is worth staying on 6.1.3/6.1.4 while iOS 7 is out if you want the chance to jump on board the potential A5+ 6.1.3/6.1.4 jailbreak. Once an iOS 7 jailbreak goes public, then you should have no concerns about the upgrade.

Also, although many people find it "useless" to save A5+ SHSH blobs, you're not going to lose anything by connecting your device and clicking a button. The saying is "Better safe, then sorry!". If some sort of low level boot loader exploit or apticket loophole goes public, such A5+ SHSH blobs will become useful again. (It is also worth noting that it is currently useless to look into 6.0 --> 6.1.2 A5+ downgrading due to Cydia caching incomplete aptickets. Read more). As usual, you can save A5+ shsh blobs for 6.1.3/6.1.4 by using either iFaith (click Show available caches on server and follow prompts), TinyUmbrella, or redsn0w (ipsw required).

Who should I follow for updates for the potential A5+ 6.1.3/6.1.4 jailbreak?


Please refrain from asking for any "ETAs", updates, etc. other than what is already posted.

Who should I donate to for an A5+ 6.1.3/6.1.4 jailbreak/BETA?!

No one. If you have donated to a non-credible/random dude who claims to be working on a jailbreak, demand a refund or issue a dispute on your credit card/PayPal. Any credible "jailbreak dev" will not ask for donations in advance to create a jailbreak.

Are you going to release an update to sn0wbreeze/iFaith so I can preserve my iPhone 4 baseband when upgrading to iOS 7?!

Yes. Probably sometime this weekend. (Should be able to work on it while in line for the iPhone 5S).
If you need any additional help for learning how to save your device's SHSH blobs, visit JailbreakQA.

Have an A1 day! ;)

Update #1 (September 20, 2013): Apple seems to finally closed 6.1.3/6.1.4 signing windows for devices capable of running iOS 7.