Hacker News new | past | comments | ask | show | jobs | submit login
iMessage: Malformed Message Bricks iPhone (chromium.org)
652 points by appwiz 11 days ago | hide | past | web | favorite | 270 comments

This brings back old memories from hardening the sms/text parsers of feature phones of yesteryear.

There it wasn’t entirely uncommon that when you sent a malformed sms-deliver PDU (e.g. text message) to the phone and crashed parser that tried to decode it, it took also the phone down before it could ack the message back to SMSC. Which of course meant that as soon as phone was turned on and it registered to network, that same message was redelivered (crashing it again) for as far as the network was concerned, it was never received by the mobile. Until the time that message either expired in the SMSC in few days, or you switched you sim to a non-vulnerable mobile to receive the message. Good times.

Back in the day AOL parsed HTML for it's instant messages, a <font size=9999999999999999999999> would blue screen any client running windows. It was quite easy to empty chat room(s) using this.

Some AVs would monitor for certain IRC commands and kill the connection because it looked like your computer was talking to a c&c server.

But you could also write the same code into any IRC chat room and anyone running that AV would get booted.

DCC SEND startkeylogger 0 0 0

Hahaha on Yahoo we called it booting.

On AOL we called it "punting", and the apps that facilitated it were the first reason I ever wanted to code.

Strange nostalgic memories of "AOHell" and "LuciferX" come to mind... If I remember, a lot of them were visual basic apps that would use SendKeys() to control AOL via keyboard shortcuts. A little like the wild west back then...

Anyone recall the "SubZer0" proggie? (and who else recalls calling apps "proggies" in our kitchy chat rooms?)

I remember Sub-7 and its modules, including those that forced the user to play (and win) a game of tic-tac-toe, could melt the screen, flip the screen upside down and misc destructive things.

I recall a few, FaTe, AoLazy, and others being shared in island55. Also memories of Master AOL & Internal/Overhead accounts that allowed infinite scrolling in chat.

Man, I wish I knew what I was doing back then. Major service providers allowing unsanitized inputs like that? Sounds like a lot of low hanging fruit! And this was before blogging was popular so communicating advanced techniques wasn't as easy back then either.

Those must've been some scary code bases.

Ditto. I got into VB because of this "exploit," and that kicked off my inadvertent career choice. Punters were all the rage.

By the time AOL 3.0 rolled around, it wasn't bluescreening the machine, rather just ending the AOL process and disconnecting.

I downloaded VB4 from an AOL mail server when I was 11. I made the mistake of forwarding the email, which AOL considered making a pirated copy of the software. Came home from school the next day and our AOL account was terminated.

my little secret to not getting punted on aol was to remove the aolrich.dll which was responsible for parsing all the html the client received. those were great days!

Not to beat my own drum but I did not agree with the ethics of booting, and while I was too lazy to code back then, I rooted for defensive apps that armored you against getting booted :D. Yahelite on Yahoo was the best.

Same, this is how I got started with coding as a teenager.

Easier way to boot a group of people off of Yahoo Games back in the day when you wanted to clear up a room...

Just post in the general chat area.

“Hey, to speed up Yahoo Games, press alt-f4.”

Iirc the social engineering script was to “hold the alt key and repeatedly tap f4”. That has the two keys far enough from each other in prose to trick more people.

I always heard "hold down alt and press each f key one at a time", people forget about alt f4 if you don't specifically say f4

Even today Twitch chat is full of "Hold CTRL and type "WTF" for ℱ𝓪𝓷𝓬𝔂 𝓦𝓣ℱ" and people end up pressing ctrl+w, which closes the tab.

MSN Messenger did a similar thing.

I learned that you could evade their swear word filters in your screen name by using ASCII codes.

So I looked up a table. Beep didn’t work, but NULL would boot everyone on your contact list out.

Doesn't that date back to IRC?

irc has kicking / banning and kickbanning.. not necessarily booting (unless you used it as lingo) and certainly not HTML parsing.

/ping +++ATH0

There's supposed to be a delay in the Hayes protocol to prevent this kind of thing, but many "Hayes compatible" implementations didn't implement that part (through ignorance? working around a patent?), so this trick would work pretty well . . .

Patent issues. https://en.wikipedia.org/wiki/Time_Independent_Escape_Sequen...

Hayes themselves would even insert the sequence in press releases posted to Usenet. https://groups.google.com/forum/#!topic/comp.dcom.modems/Vr2...

IRC totally did have "booters" back in the old day, that would cause mass disconnects.

> [...] at the CCC congress

Your "congress" is redundant because CCC=Chaos Communication Congress.

ATM machine

CCC = chaos computer club. They might also use it for other meanings, but referring to the actual original name makes absolute sense.

This brings back old memories from hardening the sms/text parsers of feature phones of yesteryear.

They were indeed hardened? Do tell.

I've suggested that the iPhone be hardened against rendering crashes, here on HN. The immediate reaction is to downvote me, then reply, "undefined behavior must crash the process." That's pretty glib and shortsighted, however. It took me just a few seconds to think of a solution.

Have one process write the messages in a log file. This process also supervises the second process. The 2nd process renders the messages. If the 2nd process keeps crashing on the same message, the 1st process marks that message as a problem, and the user can be prompted to send the hex dump of the message for diagnostic purposes. (So if it's spicy, they can say no.)

The fact that such a basic function of the iPhone can be remotely vanished, requiring a reboot, is a pretty glaring hole. What's even worse, is that highly paid SV programmers would shrug their shoulders so easily.

Yes, Sony Ericsson A200 had a bug in SMS picture decoding (old, monochorme, pre-MMS one) which was easily craftable into an exploit if carriers were allowing multipart SMS.

Guess what cell carriers did back then? Yes, they disabled multipart SMS

What else could they do?

Filter. Spam detection wasn’t exactly a novel idea back then either.

With what? Especially back then, I wouldn’t assume there is anything with a programmable CPU in the data path that can inspect and filter things at line rate.

SMS are sent between devices via a message gateway server.

Fascinating problem. Since I have Faraday cages on the mind today (not that I know much more than ~10 minutes of reading)... simply isolating the phone from all signals would block both the message and any software update, so that doesn't work. But what if you attached it to wifi but not to the cell network? Either have the wifi router (itself having a wired connection) and the phone in the same shield; or, I guess, people say Faraday cages target certain wavelengths, so if wifi and cell tower are sufficiently different, maybe you could have a selectively blocking Faraday cage. Would that have been workable? (non-EE here)

To answer your question about selectively blocking, just put the wifi router inside the cage. To the point though, feature phones didn't have WiFi generally. I'm also not sure how doing so would fix the issue, unless you could block the number perhaps.

Feature phones also didn't have OTA updates. I remember taking my phones to service centers to get the latest software flashed. Later on you could flash it yourself with a cable to your PC, browsing esato.com for new versions.

> This brings back old memories from hardening the sms/text parsers of feature phones of yesteryear.

> There it wasn’t entirely uncommon that when you sent a malformed sms-deliver PDU (e.g. text message) to the phone and crashed parser that tried to decode it, it took also the phone down before it could ack the message back to SMSC.

By yesteryear do you mean the present and feature phones do you mean current android phones? Some models are still vulnerable to a text-of-death.

https://poetengineer.postach.io/post/deleting-the-text-of-de... not my blog, but the same problem happened with my mother in law's phone. The phone becomes unusable because of a stream of org.android.phone application has stopped messages and the only thing to do is use adb to delete all texts, until it comes in again. I was never able to pin down the exact problem.

Edit: Sorry, I didn't mean to come off as snarky, but I just wanted to 1) point out that there are still issues with decoding SMS and MMS messages, even in some modern phones and 2) provide a link to anyone who encounter the same issue as it was very frustrating for my MiL and very frustrating until I figured out I could just wipe all SMSes with adb.

This is fixed in iOS 12.3 [1] and macOS 10.14.5 [2], both released on May 13th. As Natalie noted on the ticket, turning off iMessage will also prevent the bug.

[1]: https://support.apple.com/en-us/HT210118

[2]: https://support.apple.com/en-us/HT210119

Turning off iMessage to prevent the bug is like turning off a car to prevent to consume petrol.. what a solution

It's more like turning off air conditioning system (because it's broken) to stop excessive consumption of petrol... Since you can still use the phone, just not one part of it (until you fix the air contidioner)

Turning off (and stop using) a car sounds like a great solution to prevent petrol consumption, IMHO.

Not if you have a diesel car.

Come on..

Where I live nobody uses iMessage so this sounds like a good workaround :P (Yes yes I know it’s been patched already...)

I never understood this, why would anyone want to deal with ANOTHER app to do messaging? iMessage is built in, integrated, and has end to end encryption. What more functionality are people clamoring for?

People want to use one app to do all their messaging. iMessage is not that app unless 100% of the people you message use iPhones. For a lot of people Whatsapp or Telegram can be that app.

Well seeing that iMessage integrates with SMS, it’s not just for iMessage users.

While there are a lot of reasons not to want to use iMessage but only being able to talk to other iOS users isn’t one.

When you send as SMS, it's not encrypted, some of the group chat features don't work, the reactions come through as confusing "so and so liked an image" on Android, etc. It's a big hit to the feature set.

And that's why I said While there are a lot of reasons not to want to use iMessage but only being able to talk to other iOS users isn’t one.

You're mixing up Messages with iMessage, then.

iMessage is a subset of features in the Messages app that are unavailable when communicating with someone on a non-Apple device or if one of the parties has iMessage turned off.

The original post was

iMessage is not that app unless 100% of the people you message use iPhones.

"XXX liked 'some dumb comment'"

Ugh, so sick of seeing that

> What more functionality are people clamoring for?

All those features in a market where lots of people you'd be chatting with are on Android, I'd suspect.

See samoa below, half of his friends using iphone disable imessage??? It's nonsensical. iMessage works wonderfully.

In the early days, iMessage had some availability issues - the only way you could get/send texts for a couple hours would be to switch it off so they'd send as SMS.

There was also a bug that allowed a malicious message to crash phones sometime last year where the recommended fix was turning off iMessage (similar to this one).

Some folks probably don't remember to turn it back on after these incidents.

Same here. Most iPhone users around me use Whatsapp. I don't live in the US.

second that. half of my friends using iphones dont enable imessage. thus penetration (in my circles) is way too low to make it useful.

Considering it's enabled by default, i'm really curious why you would want to do that.

It costs money to activate it (or so says the pop up that appears when you set up an iPhone).

Also if I switch to Android I don’t have to worry about disabling iMessage before. (Not that anybody in my country would ever send an iMessage or an SMS though...)

iMessage doesn't even warrant a dialog in OOBE on iPhone IIRC.

Not sure what pop-up you're talking about then.


This shows up when you insert a sim that’s not activated with iMessage. Maybe it depends on your region. In my country you really have to pay because the activation process sends an sms message.

I've seen this popup, too. It will send a silent SMS from your device on activation. Depending on your plan this could cost you money.

And depending on where you are, it may be an international SMS, which will either cost a lot or just fail silently.

iMessage uses your regular data plan. You would have to pay for data either way.

iMessage activation sends an international sms to the uk. Which is pretty costly.

... if you live in America.

Do you know why is the upstream bug in "New (Open)" state, if it's fixed in currently released versions of iOS/macOS?

Maybe it still has to be fixed in the betas?

For those with jailbroken iPhones, a community member has released the tweak BrickFix: https://www.reddit.com/r/jailbreak/comments/c9616j/release_b...

Speaking as an ex-Apple employee, I'll just point out that a really malicious actor could have used this to harm some significant percentage of the installed iOS infrastructure, and done critical damage to Apple as a company with it. In fact, I don't know the percentage of users still on <12.3, but maybe they still could. A band-aid fix for this one bug should not be where they stop here.

What they should also do is block the malformed message from being sent too. Not sure how to do that, since iMessages are encrypted in transit, but I'm sure there's some way.

Apple controls the CA; it's pretty straight forward for them to check contents.

iMessage really could have been something great (despite apple controlling CA) if they had just opened it up for more devices. Instead WhatsApp wiped the floor with them.

What? No Apple cannot decrypt messages so cannot check the content.

Messages are not encrypted to Apples keys they’re only encrypted to recipient device keys - there is no way for Apple to filter any content without removing the end to end encryption of iMessage, which Apple does not want to do - every bit of user content that Apple can decrypt increases the value in compromising Apple’s service infrastructure.

>Apple controls the CA; it's pretty straight forward for them to check contents.

and in the process eavesdrop on everybody's messages? no thanks.

That sounds like code for "Apple can push an update without user consent"


"Apple can turn off imessage to users with OS < 12.3 until users update"

They're (Apple) rather lucky that their user base vehemently upgrades whenever possible.

I've iPhone user I've ever met outside tech circles avoids installing OS updates. They end up updating soon anyway for a variety of reasons (some updated apps stop working, update occurs "on its own" overnight, to get rid of of the notification icon, and so on).

It does help that the process is pretty painless. And at least for me, a good excuse to do a reboot - which I really do as seldom as possible on my laptop and iphone.

> A band-aid fix for this one bug should not be where they stop here.

What do you suggest they do?

The easiest thing that occurs to me would be a on-phone "message virus scanner" that self-updates and checks incoming messages against a threat database after decryption, but before passing them to the rest of the system.

Architecture-wise some thought should be given to keeping iOS from being DoS'd by the crash/respawn of any service.

Also, looking at the "assuming it's a string" line from the problem description, Apple needs to make an investment look through the codebase for this same error in other guises.

That's what occurs to me off the top of my head anyway.

Would it not be possible to detect malformed messages, and prevent them from being sent to a phone in the first place?

No idea; it might be that Apple can't detect these because they're encrypted.

Yes, they're encrypted in transit.

they can force-push emergency fixes

This isn't easy on iOS, and that doesn't sound like a particularly good idea anyways.

What about older 32 bit iOS devices that can't be updated past iOS 10? Will they issue an update for them or do you just have to turn off iMessage? Still have a perfectly functional Series 4 iPad

Given that jailbreaks exist and can be exploited by malicious actors, deploying them as the user and applying the jailbreak community supplied fix may be the best approach:

> For those with jailbroken iPhones, a community member has released the tweak BrickFix: https://www.reddit.com/r/jailbreak/comments/c9616j/release_b...

(source: https://news.ycombinator.com/item?id=20379779)

Can anyone confirm that older iOS devices are affected as well or was this introduced at a later point?

Don't remote root exploits (jailbreaks) exists for those devices? Then it's basically game over if anyone want anything already.

Wow, you could actually lose the data with this bug. Glad it was fixed in 12.3. I remember the last time something like this happened (4-5 years ago?) it would only crash the phone.

The problem isn’t that the bug itself will cause data loss - it’s that you have no way of using the phone because of the boot loop unless you wipe.

I’m not entirely sure how you’d go about updating the phone without booting into it, but I think it is possible, and that would be one way to avoid losing all your data due to the bug.

One of the comments on the bug has the answer:

For testing purposes, there are three ways that I found to unbrick the device:

1) wipe the device with 'Find my iPhone'

2) put the device in recovery mode and update via iTunes (note that this will force an update to the latest version)

3) remove the SIM card and go out of Wifi range and wipe the device in the menu

Instead of wiping the phone, couldn’t you just disable iMessage once you habe removed the SIM card and are out of WiFi range?

Would that mean you could not use iMessage any more (without the patch)? An iPhone without iMessage is significantly redundant, at least in N.America.

You only lose data if you’re not backing up your phone - it’s not a corruption bug that breaks the ability to restore backups (like one of the iOS iOS 11 developer betas did).

That's like saying that with a faulty hard drive you can only lose data if you're not backing it up.

Well that’s not wrong.

Close, but imprecise. I’m saying two things:

You can lose data with a faulty hard drive if your backup is silently corrupted and you don’t realize it. That’s not a risk here, as long as before restoring from backup you upgrade the phone OS to patch the bug.

Also, you can lose data with a faulty hard drive if you have no backup.

Rooters especially will care about these points since they typically cannot restore from backups without upgrading the phone away from a rooted version, due to choices made by Apple in firmware.

Actually, if an iCloud erase works, it should be possible for Jailbreakers to recover their phones without updating.

Mind, they will still loose data, including some Jailbreak stuff that isn't included in iTunes backups.

You can still lose data because you can't really back up the whole phone with standard tools.

The degree of coupling in iOS has always puzzled me. In 2016 I was developing a WebGL program and I stumbled upon shaders which would cause iOS to reboot, on more than one occasion.

That's not really a coupling issue, but a matter of GPU drivers not generally being hardened against shader/usage bugs. Similar issues have existed on Windows, Linux, etc. browsers with WebGL support.

> That's not really a coupling issue, but a matter of GPU drivers not generally being hardened against shader/usage bugs.

You shouldn't be able to crash the whole operating system (not just the display server, display driver, etc.) with an ordinary shader, even if it crashes the shader compiler or causes the GPU not to halt. It's not as though I wrote these shaders in an attempt to crash iOS.

That's not unique to iOS, though. It seems a lot of display drivers on a lot of platforms were developed without ever considering hostile shaders coming in over the network, in an era where mostly only game developers would catch crashes during development? For example https://chromium.googlesource.com/chromium/src/gpu/+/master/...

Most of the software rendering list in Chromium is about more general bad behaviour, lack of features, or redundant behaviour (i.e. a GL driver is available, but it's a software renderer anyway, so might as well use Skia's software renderer), not security/full system DoS.

For example, the one at id: 3 is for renderers with the lowercase word "software" in their name; id: 1 is a GPU which does not have enough features on its mac driver to run ANGLE for GLES 2.0 (and in turn WebGL 1); id: 5 is for very old versions of mesa, where the libGL would crash (which in practice means the application would crash, but not the display/windowing servers or the display driver, nor other applications).

This behaviour on iOS is especially bad, it is not like other systems. The piece of code which would cause an issue like that is dramatically smaller on most Linux and Windows graphics stacks.

But that's unrelated to how tightly coupled the app is with the OS, but rather how ungracefully the driver fails. No matter how "far away" the app is from the gpu, at some point in the pipeline whatever data is being received will have to interact with it in some way, via the driver.

Sure, you could patch the app to avoid sending what's known as bad data to the next layer but I'd argue that that's the wrong place to do it.

It might very well just be the OS's recovery procedure when the display server crashes, rather than an uncontrolled crash. It's not the phone is of much use without it, so might as well have a single booting procedure rather than trying to reboot subcomponents individually.

On an iOS device crashing a critical component such as SpringBoard is often indistinguishable to the casual user from a reboot.

Genuinely curious: What’s the reasoning behind “unrestricting” this ahead of its 90 day window? (It’s tagged Deadline-90, Reported-2019-Apr-18 On Project Zero, so that’s July 18th?)

Because it's now fixed. The window is to allow the vendor to issue a fix.

Yeah but maybe it would be nice for users to keep that extra time in order to maximize the probability that they have actually updated software at disclosure time.

Disclosing in advance is a bad policy, it will just incentive good behaving vendors that update fast to delay full description of their changelog for security reasons because you put their users at unnecessary risks.

Security researchers have to assume that if they've found a vulnerability, it's only a matter of time before the evil people will find it as well - that is if they haven't found it already.

That's why all disclosures come with window - if they don't, the companies aren't under any pressure to update their systems, the exploit start being used in the wild, etc. The window is not ideal, but it is better than no window.

And there isn't much point arguing over 30 vs 90 vs 120 vs 365 days. 90 is reasonable, enough for even the largest mainstream software companies to issue a patch release.

Still make no sense, I agree the window is a good policy to force lazy vendors to act as they should.

But what’s the point of reducing the window for nice vendors who quickly delivered a patch?

This is totally counter productive. In order to incentivize vendors to deliver patches more and more quickly, good actors should profits from that extra time to secure their user base. In a ideal world that might even permit to reduce the windows in the futur when everyone behave well.

This is just jerking around and sending bad signal unless of course that anticipated disclosure date was decided together with the vendor.

I think patching is firmly in your hands now, and this data may help you choose to upgrade if you were holding off for some reason. Imagine your favorite iOS game was broken by the release that fixes this, so you've been ignoring the update. Now that you know your phone can be bricked by a malicious text message, you may decide "I guess I won't be playing that game for a while" and upgrade. The point is, pretty much everyone that applies every update (which is automatic) has the update now. The last few stragglers are probably waiting for information exactly like this. Now they have it.

The patch itself reveals the vulnerability. Attackers analyze these things to see what they’ve fixed. If you release a patch but don’t announce the vulnerability that was patched, then you’re just hiding it from good guys who don’t have time to dig through the patch.

I wouldn't be terribly surprised if the vendor asked for it to be disclosed late in the afternoon before a long holiday weekend (in the US) with the hope that mainstream press outlets would not notice.

> unless of course that anticipated disclosure date was decided together with the vendor

Does anybody know if it was? How does Project Zero make these decisions? Do they consider the install base already patched?

Your incentive line in no way matches reality. In the past every vendor that is given an unlimited open timeline on patching has not. This includes Microsoft, Apple, Oracle and most of the other large vendors. Most of them are better at patching, but this is mostly because of the risk at of someone zero daying the patch and destroying the userbase.

Security is not an ideal world, in fact I would say it is the opposite.

Microsoft (employees) has repeatedly argued that 90d can be unreasonable for Windows due to the development and testing cycle, which also has to align with “patch Tuesday”. I haven’t heard the complaints recently so maybe they’ve streamlined part of the process.

Windows 10 might be the largest enterprise codebase at over 50 million lines of code. It probably takes 30 days alone just to browse to the file that has the bug

The reasoning is that once a fix is out, by making it public then users can know about it and intentionally update their devices if they haven't yet.

The other side is that the moment a patch is released, people will diff it to the previous version making it much more likely this issue is found by a lot of independent people who might seek to exploit it.

The patch was released months ago

That sounds like a logic flaw because iPhones and most other devices like it will normally auto update after a short while. I think more people will rely on that feature than browse, uh, bugs.chromium.org...

This view of it will assist hackers in getting a head start before the auto update cycle gets to your device and you're notified. And if you're hit but something like this before that, your iPhone will no longer be able to update and apply the fix.

Of course, there's no way to find an objectively "correct" time frame since update cycles vary, but a month or two ought to give plenty of time for the updates to roll out and users to be made aware.

It was patched in march.

Before the initial report?

Sounds good in theory. In reality, the vast majority of iPhone users are not aware that this bug exists and never will be. The best action for user safety is to wait until the period has elapsed or the exploit has been seen in the wild already.

Alternatively, they could publish the gist of the exploit without providing enough detail to actually perform the exploit.

Publishing it like this will make them more likely to be aware of it. They may not read Hacker News but it spreads to Facebook user groups etc.

The bad guys (many enough of them) will anyway figure it out right away after the patches have been published, because with every patch, people will (and should) ask "why".

Publishing the gist of the exploit, combined with access to diffs of the patch should be enough for people to reverse engineer the exploit.

Where are they going to get access to the diffs of the patch? iOS is closed source.

Reading (dis)assembly is a skill many in our profession are required to learn. It’s common in OS & security fields. Heck, when developing Windows on ARM we were told Friday that we’d come to work Monday with a mandatory “no source” debugging session where we had up to an hour to describe a hanged program’s intended behavior and why it was hanged. One of my colleagues also refused my symbols when I asked for help debugging a program. He was more comfortable in ASM than the latest C++

The fix has been available for almost two months. Don't iOS updates hit the 50% adoption mark within two weeks?

http://gs.statcounter.com/ios-version-market-share/mobile-ta... shows 12.3 at around 50%, so the question for me would be what percentage of that long tail would upgrade within any reasonable extension period. Public news might actually accelerate that since it gives people a reason not to procrastinate hitting that button.

The numbers at the top are misleading. Are they the average over the graph's time interval? Average over June? Not clear, but I suspect the latter.

If you switch the graph to daily, you see that it passed 51% on June 10th, i.e. in four weeks, and it's at 66% now.


But yeah, the big question is how stubborn that long tail is, in the face of news reports about serious bugs or not.

I’m not sure of the stats honestly but there’s still going to be a huge long tail of people on earlier versions for months afterwards. I was surprised that I was still on iOS 12.2.

It says:

> Unrestricting, as this was fixed in the 12.3 update.

Because the fix shipped in May. I assume they held off on publishing for a month or so to provide a decent upgrade window, which was nice of them.

As an FYI:

> Unrestricting, as this was fixed in the 12.3 update.

Apparently patched in iOS 12.3, but that’s a pretty gnarly bug.

I see a free data hack: Load a version of iMessage that never acknowledges the message, but saves the data (and doesn't brick the phone). Send lots of data, acknowledge via other means (checksum sent over email etc). How much data could be sent this way? GBs?

This doesn't work with iMessage, because the carrier sees iMessage no differently from any other kind of data download. However, a friend of mine tried doing something similar using the <number>@txt.att.net (or equivalent for your carrier) email-to-SMS trick and wrote an Android app that parsed the messages. They promptly received a firmly worded email from AT&T and were forced to abandon the project.

I'd definitely like to know more about the project.

Why did your friend choose to send data over SMS? Why was AT&T upset at his project?

It doesn’t work that way. The person with a cell bill will still be charged the downloaded data.

It can be recovered so it's not actually a bricking, but this is very bad. If you aren't running 12.3 or later this will force you to turn iMessage off.

I found google sheets in safari will shutdown a Mac with certain special chars in it.

Which special chars?

He tried replying but his Mac crashed.

Cmd + q

Can this be avoided by disabling iMessage notifications?

> The calling method then calls -[IMBalloonPluginDataSource _replaceHandleWithContactNameInString:] which calls im_handleIdentifiers on the 'NSString' which is really an NSNumber, which throws an exception as the selector does not exist in that class.

Looks like they need to move more of their stuff to Swift to reduce snarfles like this.

Stories like these (this isn't the first time that iOS/macOS could be crashed by chat messages), and the empty root password debacle, or all the GateKeeper bypasses, make me wonder if their engineers take their own WWDC security-related talks seriously.

Still, it's not so bad as the Windows XP-7 epoch, when eldritch nightmares walked the land.

> Can this be avoided by disabling iMessage notifications?

Why do you think so?

From the code right after that quote, I would be confused if a the view fronting that IMBalloonPluginDataSource was rendered in SpringBoard if you had turned off notifications.

I'm assuming it crashes when it first tries to display a preview for the message?

Or does it happen even if you never use iMessage and have its notifications disabled?

> Still, it's not so bad as the Windows XP-7 epoch, when eldritch nightmares walked the land.

You are speaking like an Apple fanboy. Days of XP are in the past and even Windows 7/Windows 2008 fairs better than Apple OSX and iOS. This is especially bad as apple sells a false sense of security when they fail to build even the basics correctly.

Their walled garden is paved with expensive ibricks.

Edit: Those who think I am speaking rubbish can refer this link. https://www.cvedetails.com/top-50-products.php

> Edit: Those who think I am speaking rubbish can refer this link. https://www.cvedetails.com/top-50-products.php

That listing groups together all OS X bugs back to 2002 under one heading, but splits up each Windows version into its own entity. So the numbers aren't really comparable.

But the bottom of that page has a cumulative count by vendor which shows Apple having the second most security issues, only topped by Microsoft. Considering the fact that Microsoft has much bigger market share and therefore security research attention, that's quite an achievement.

I'm not going to comment on Apple's software security standards (and Microsoft deserves more kudos for their focus on security after the bad old days of XP), I'm just pointing out that summing up CVEs is not a valid way to compare.

> Considering the fact that Microsoft has much bigger market share and therefore security research attention

The OS X bug numbers also include a bunch of bugs for open source projects that are bundled with OS X (Perl, Ruby, Python, SQLite, PHP etc) which increases the security research attention.

You mean MS historically has 100% more security issues. Also IE alone competes with entire OSes in that top 10.

That proves the other comment right, but surely you can spin it other ways. Anyone who has switched from old windows to Mac doesn’t need numbers to tell how wild it was.

> You mean MS historically has 100% more security issues.

For an OS used 1000% as often[0], yes.

I have no skin in this game, BTW, as I use neither. But given the number of security issues Apple has, I really bothers me that they still sell those products as somehow more secure.

[0] = https://en.wikipedia.org/wiki/Usage_share_of_operating_syste...

Even now, I don't think any of macOS's recent failings are as bad as the Windows 10 update that deleted user documents [0], or all the official spyware and adware in the only operating system where you have to pay to even customize your wallpaper.

As for mobile, does anybody remember hearing of any iOS cross-app malware ("viruses") in the decade since it launched? I think that's pretty amazing.

[0] https://www.google.com/search?q=windows+update+deleted+docum...

Apple sells privacy and security so they should live up to the standards they have set for themselves[1].

They were actively misleading peoplebby running advertisements claiming MACs don't get virueses[2].

[1] https://www.forbes.com/sites/daveywinder/2019/06/21/new-crit...

[2] https://www.wired.com/2012/06/mac-viruses/

Your second link is an article from 2012 that says Apple stopped saying Macs can’t get viruses...

Not getting a virus is a theoretical impossibility so Apple claiming the contrary is dishonest.

Moreover Apple only stopped after misleading users for a long time and that also hapenned after high profile incidents as explained in the article.

Did iOS ever have a “virus”?

No, never iOS is deisgned by Gods themselves.


Not all malware is a "virus."

Has iOS ever had anything where one app could "corrupt" other apps?

> Not all malware is a "virus."

Haha, this is called moving the goal post. Fanboys do this all the time :)

Edit: Plenty of buffer overflow and momory corruptions are listed for iOS just in 2019.


This comment breaks more than one of the site guidelines. Could you please review them and follow them when posting here?


> Haha, this is called moving the goal post. Fanboys do this all the time :)

Ignoring the jab, which has no place here, malware is a general term which includes viruses. From the Wikipedia page on computer viruses (https://en.wikipedia.org/wiki/Computer_virus):

> The term "virus" is also misused by extension to refer to other types of malware. "Malware" encompasses computer viruses along with many other forms of malicious software, such as computer "worms", ransomware, spyware, adware, trojan horses, keyloggers, rootkits, bootkits, malicious Browser Helper Object (BHOs), and other malicious software. The majority of active malware threats are actually trojan horse programs or computer worms rather than computer viruses. The term computer virus, coined by Fred Cohen in 1985, is a misnomer.[16] Viruses often perform some type of harmful activity on infected host computers, such as acquisition of hard disk space or central processing unit (CPU) time, accessing private information (e.g., credit card numbers), corrupting data, displaying political or humorous messages on the user's screen, spamming their e-mail contacts, logging their keystrokes, or even rendering the computer useless. However, not all viruses carry a destructive "payload" and attempt to hide themselves—the defining characteristic of viruses is that they are self-replicating computer programs which modify other software without user consent.

> Edit: Plenty of buffer overflow and momory corruptions are listed for iOS just in 2019.

Again, these aren't viruses or even malware.

> The majority of active malware threats are actually trojan horse programs or computer worms rather than computer viruses.

What's your point here? Hidden malware secretly watching your phone is better than explicit virus? Ignorance is bliss I guess.

> defining characteristic of viruses is that they are self-replicating computer programs which modify other software without user consent.

and Malware doesn't replicate?

> Ignorance is bliss I guess.

Unless your goal is to get people to stop responding to you, don't do this.

> and Malware doesn't replicate?

It does when it's a virus. See the relationship between viruses and malware that I mentioned earlier.

I've been saying virus since the start. There's a clear technical distinction, and unprecedented for a general-purpose platform to be free of those, until iOS.

If you want to use the broad, general definition of malware, then Microsoft literally bundles malware with Windows 10 in the form of their "telemetry" and Candy Crush advertisements.

buffer overflow and memory corruption is not a virus. He asked a specific question, and people answered different questions while ignoring the question he actually asked.

His specific question is just a diversion tactics. Parent comment was about Apple intentionally misleading gullible people for many years by claiming that MACs don't get virus. They didn't change until high profile attacks hit and it was no longer viable to make the claim.

Instead of commenting on this, he just moved the goal post to iOS never getting a Virus. What does iOS never getting a Virus has anything to do with Apple being dishonest?

Another thing, in technical communities, "MAC" in capitals has the implicit distinction of https://en.wikipedia.org/wiki/MAC_address

P.S. Look what just showed up: https://news.ycombinator.com/item?id=20383432

Do Macs get viruses? In general, they don't. Certainly people have a variety of opinions on why that is, but the fact remains. I think someone finally may have made one, which was why Apple dropped that particular point out of their ad campaign.

His specific question has an answer, and you chose to obfuscate instead of answering.

You posted a link from 2012 [0] that you apparently didn't even read, saying that Apple claimed Macs didn't get viruses, whereas the link's headline is "Apple Drops 'We Don't Get Pc Viruses' Schtick."

You then went on to ignore that contradiction. Does that fall under "moving the goal post" too?

I also suspect you created a new account for the sole purpose of supporting yourself in this argument. [1]

[0] https://www.wired.com/2012/06/mac-viruses/

[1] https://news.ycombinator.com/user?id=rtrr_eter

Comment 5 by a...@gmail.com on Thu, Jul 4, 2019, 5:33 PM PDT (3 days ago) I really hope that no one big covers this, because if they do... oh boy

Comment 6 by p...@gmail.com on Fri, Jul 5, 2019, 3:27 AM PDT (3 days ago) Too late, already out in big news website...

Stupid question: How is the example python program actually sending an iMessage? Since Apple generally has the system locked down.

Apple doesn't lock down iMessage sending. A long time ago I've used AppleScript to automating sending messages (SMS/iMessage) successfully. These days you can probably use JavaScript as well.

It looks like it uses some AppleScript and Frida [1] to inject code into Messages.app on the Mac.

1: https://www.frida.re/

Could a UI input fuzzer have caught this?

Yet another wrong use of the word bricked. Bricked means bricked and you can’t ever come back from that.

This definition never holds up to scrutiny.

For example, if I pull out my EPROM writer, de-solder the chips, and update them almost no device is truly "bricked" by this definition. The only exceptions would be burned update fuses or similar physical damage. Making the definition itself extremely niche, to the point of being synonymous with "physically damaged/destroyed."

I myself stick to the broader "technologically as useful as a brick" definition. Which a boot-looping iPhone absolutely fits. The fact there are ways to recover it is neither here nor there.

I generally call what you're describing a "Hard Brick." But even those are sometimes recoverable via as I said chip re-programming.

I stand by words mean things. If you can recover in any way, it's not a brick. In this case it is a boot loop and there's no reason they should not have used boot loop to describe the condition.

>If you can recover in any way

Physically replacing every single component, one by one, will lead to a recovery.

>I stand by words mean things.

They are an abstraction of thought to enable communication and external storage. A very leaky abstraction.

A bricked device can be recovered - usually - by replacing hardware, that's the limit of the definition. The GP comment is right, bricked is bricked and there's no way to recover a bricked device with any software means. It means the hardware is fucked and it's usefulness is equivalent to a brick.

What if you can reprogram an eeprom to make it work, would you consider it bricked? You're not replacing any hardware and are fixing only software.

At the end of the day language is (for all pragmatic purposes) finite but possible states of the universe are not, so you can't have a perfect definition of that catches all possible states you want while excluding all others with perfect accuracy.

No, it's not as simple as that. People use brick to mean slightly different things - sometimes they say hard/soft bricked instead of bricked. And you'll even find some people who say what you say but admit that it was still the correct word to describe devices which can only be fixed by disassembling the hardware and using jtag, which "brick extremists" probably wouldn't allow.

This was a boot loop condition. The person reporting it clearly knows this and yet confused the issue by saying "bricked." Bricked is non-recoverable.

Can you provide your definition of non-recoverable? An extreme example: someone could tear down the phone down to every single last nanometer-scale transistor and polymer, fix the problem and reassemble it; that would make it recoverable from even most scenarios of destruction, hell, with enough energy available one could in theory fuse/fusion it down into iron and reconstruct the very elements themselves in order to eventually produce a working phone again.

There are some implicit limits to what "bricked" means and those limits vary by individual.

I'm curious, what component could you replace in this instance to recover the iPhone and not lose data?

One could argue that every single component on a device could be replaced to bring it back from the dead, but I would argue it isn't the same device at that point.

Bricked is a term that is, and always has been, defined as hardware that is rendered useless by bad software. Replacing hardware components to get a device working is not un-bricking it.

"One could argue that every single component on a device could be replaced to bring it back from the dead, but I would argue it isn't the same device at that point."

This is entering the realms of philosophy. If you get your screen replaced is it any longer your phone? If someone replaced every part of your phone one piece at a time, at teh pace of one piece a week did they suddenly steal it the moment the last piece was switched out? After all, they have "your" phone - if the concept of "your" phone ever made any sense in the first place.

Rendering useless by bad software - so if you take my linux device and install windows I now have something with objectively worse software than before, and where all my software no longer runs, and which is incapable of reading my ext4 formatting external hard drive. So...you've bricked it?

> Rendering useless by bad software - so if you take my linux device and install windows I now have something with objectively worse software than before, and where all my software no longer runs, and which is incapable of reading my ext4 formatting external hard drive. So...you've bricked it?

Obviously not because you can always put Linux back on it. A bricked device, you have no way of doing this. It's useless.

I can't believe all of this discussion simply because people want reuse a word that already means something. It's like the FE devs hijacking "real time". Good grief already.

I can't help but imagine what would happen if you take a phone stuck like this to the apple store. Would they save your phone or tell you to reinstall?

   bplist00ÔX$versionX$objectsY$archiverT$top † ¦U$nullÓ 
   €€¢€€€RanVldtext¢ËqÒZ$classnameX$classes\NSDictionary¢XNSObject_NSKeyedArchiverÑTroot€#-27>DKS^ehjloqsux„‰”ª­¶ÈËÐ                             Ò


It's the serialized object used in the PoC, in binary property list format. Here's what it looks like pretty-printed:

    "$archiver" => "NSKeyedArchiver"
    "$objects" => [
      0 => "$null"
      1 => {
        "$class" => <CFKeyedArchiverUID 0x7fd45ec02d50 [0x7fff97761b10]>{value = 5}
        "NS.keys" => [
          0 => <CFKeyedArchiverUID 0x7fd45ec02c20 [0x7fff97761b10]>{value = 2}
          1 => <CFKeyedArchiverUID 0x7fd45ec02c40 [0x7fff97761b10]>{value = 3}
        "NS.objects" => [
          0 => <CFKeyedArchiverUID 0x7fd45ec02cf0 [0x7fff97761b10]>{value = 4}
          1 => <CFKeyedArchiverUID 0x7fd45ec02cf0 [0x7fff97761b10]>{value = 4}
      2 => "an"
      3 => "ldtext"
      4 => 77777777
      5 => {
        "$classes" => [
          0 => "NSDictionary"
          1 => "NSObject"
        "$classname" => "NSDictionary"
    "$top" => {
      "root" => <CFKeyedArchiverUID 0x7fd45ec02ff0 [0x7fff97761b10]>{value = 1}
    "$version" => 100000

Since a restore works it cannot be called a brick though?

It's a sliding scale which depends on the user's competence and not just the hardware. To a completely non-technical person, a hard lock-up is "bricked" even if it could be fixed by pressing buttons. To a normal user, a borked ROM is "bricked" even if it could be fixed by plugging into a computer and re-flashing. To a power user, a busted bootloader is "bricked" if it stops them flashing a ROM, even if it could be fixed with a JTAG debugger. To a sufficiently good EE, it's not bricked until the whole thing is physically destroyed.

This is a good way to describe the reality of "bricked", and I think you could extend this to consider price, too.

Even to the EE, the cost of parts and time to repair may exceed the cost of replacement, much like a car in a relatively minor accident can still be considered "totaled" if the repair cost exceeds its value. "Bricked" may still not be the right term, but the difference is irrelevant at that point.

Another consideration is there's a big difference to a user if the fix requires erasing all data, as the work required (after fixing) is then the same as getting a replacement. At the least, this is the effort of applying updates, restoring backups, then dealing with all the fiddly things that didn't update/reinstall/restore properly. At worst, it's irreplaceable data loss (and a hard lesson in why backups are important).

> much like a car in a relatively minor accident can still be considered "totaled" if the repair cost exceeds its value

I've never heard of a minor incident referred to as being "totalled", but rather a "write-off", since it's the insurance companies that are ultimately making that decision, not the repair service. Is that a regional thing?

I don't know if it is a regional thing, but “totalled” is what I've always heard, and refers specifically to (and the term derives from) the insurance company declaring the vehicle a “total loss” and applying replacement rather than repair compensation.

I think data recovery is a big factor. From all of the discussion around it here, it seems like the key points are "data can't be recovered without physically modifying the hardware" and "hardware can't be made usable for less than the cost of replacement." For me, losing the ability to use my handset is a minor inconvenience but losing the data on it would be a real pain (speaking of which I should back up my contacts list right now...) I'd imagine I'm not alone in this.

Used to work on phones on the Android side. I remember blowing the Qfuse was widely known internally to brick devices, but there was a team that specifically could reverse the brick - except it was a secret because the company didn't want the fact that it could be reverted to be known.

A device that crashed isn't bricked. We already have a term for that.

This is more than a crash though since you have to wipe the phone.

Good luck fighting against the windmills.

The only purpose of the word’s existence is to define an entirely unrecoverable state.

Crash loop or hung on startup describes the state. It is by definition not bricked if it can be recovered.

And as my post illustrated, "unrecoverable" is entirely relative to the user's capabilities. There's no such thing as "entirely unrecoverable" to a suitably equipped and motivated person, although you get into a Ship-of-Theseus situation if enough hardware needs replacing.

There’s a fairly meaningful distinction between replace, repair, and recover.

In this case we can recover the phone without replacing any hardware at all, so bringing up repair or replacement is a bit of a red herring.

But as I recall, Theseus’ ship was repaired over so many battles, nothing of the original remained. That is distinctly different than botching a single repair so badly you would have been better off replacing from the onset.

There are plenty of ways to get plenty of hardware into an obviously FUBAR state. It’s simply false to say that there is no such thing as a definitively bricked state for any device whatsoever.

Simple rule of thumb; if the commonly accepted solution is “get a new device” then you’ve probably bricked it.

Absolutely no one will have to buy a new iPhone because of this bug.

The term has nothing to do with the users capabilities. A person with a broken phone will bring it to their nearest tech person or genius bar.

A bricked phone means it has as much use as a brick, therefore fully unrecoverable regardless of technical skill.

I think a fair in-between value on the "sliding scale" is calling a device bricked if it can't be recovered by a sufficiently advanced end-user without special hardware. If there is no way that an end-user could fix it without purchasing something or returning it to the manufacturer, it is bricked.

We can use it like when a car is "totalled". If it would cost the user more to fix the device (because they are nontechnical or need special parts) than the device is worth, then it is bricked.

I think the term is "soft bricked"

It's almost like the author of the above comment (zaroth) didn't read the parent comment. Put another way, bricking is in the eye of the beholder.

“Difficult [for someone] to recover” should not be a partially overlapping state as “bricked”.

I had a EdgeMax Lite router which has a propensity for the flash storage to get corrupted at which point it fails to boot. The fix is to buy a particular model of USB flash drive, and image it with a specific .img file. Open the case and replace the flash stick, then boot holding the reset button.

It was a somewhat difficult repair, but in the end just a matter of following step-by-step instructions with readily available tools. I would not consider the device to have been bricked. No more than your computer is bricked when your hard drive dies.

I did brick an Xbox once, trying to solder on an early gen mod chip that was well beyond my soldering abilities!

In this case it’s not even a question of hardware damage. The fix is to reset to factory, upgrade, and restore. This is the happy path recovery process which has done millions of times over on iPhones. I had to do it just a couple weeks ago when my son changed the PIN on an iPhone we use to play music on, and then promptly forgot the new PIN. (He’s 7)

With the proposed meaning, everything is a brick to the technologically illiterate. Better to admit the headline is simply sensationalizing / clickbait.

Not a brick if you have to replace a storage device. Is it a brick if you have to replace a motherboard? Would replacing a motherboard not have fixed your xbox? (Surely the commercial availability of a part isn't the deciding factor in whether something is a brick, right?)

Commercial availability of a part is absolutely a factor in deciding whether something is a brick! I.e. some large expensive machine is bricked because the manufacturer refuses to sell you a small proprietary part without which the machine is entirely non-functional.

It’s a fairly frequent pattern where an IoT device becomes a brick because an API shuts down. Similarly, if you can’t replace a crucial part because the manufacturer won’t sell it to you, that would brick a device. If the device is cheaper to replace than to repair, then it is bricked (the Xbox).

A brick must be entirely non-functional and simply not worth repairing. It’s supposed to be a less vulgar version of FUBAR.

There are rare stories of extraordinary lengths that a maker will go to (such as fabbing your own custom parts, or standing up a private version of an API and DNS hijacking requests from the device in order to make it function again) in order to “un-brick” a device. The defining trait of these stories is that something new is invented in order to make the device function again.

I guess we have fundamentally different definitions of "bricked", then. I'm always going to define brick by the type of damage. It's not like a car being totaled, where even cosmetic damage can total a car when its value is low enough.

Please don't comment on whether someone read a comment. That's informationless point-scoring, and the site guidelines explicitly ask you not to do that.


Technical terms have meaning defined by actual technical usage regardless of common misuse by the less informed.

Your entire tower isn't a cpu, a user recoverable device isn't bricked and if tomorrow most people start calling kidneys livers they will still be kidneys.

Reducing bricked to a subjective statement about the users ability to use their device robs the term of all utility in the same way as calling a computer a cpu.

The author didn't fail to read your words, you are in fact wrong and repeating yourself doesn't make you more correct.

Please edit acerbic swipes out of your comments here.


I don't think I CAN edit it at this point but I will revisit the guidelines. Do you feel that just the sentence that was problematic then?

Yes, I was responding to the one sentence.


They weren't my words, so I'm not repeating myself. Just agreeing with the point that the term "brick" is subjective. Requiring one to go to heroic measures to render their device useful would make me consider the device "bricked" for all intents and purposes. Folks more technically skilled than I might be able to recover my device, but if I can't get it back, it's all bricked to me. But this is a silly argument.

"Bricked" isn't a technical term; its basically just slang.

And from what I've seen, the common usage already includes cases "less bricked" than this bug.

I bet you also chime in anytime “Serverless” is brought up.

See prescriptivist vs descriptivist.

Damn right it can’t. This lack of distinction annoys me to no end.

I agree with you. The title is misleading. I thought this was about frying the device. When people say the raspberry pi is design not to be bricked, they are referring to not fucking the circuitry beyond use without physical repair, not some user process stuck in an infinite loop.

Maybe "clay" instead of "brick"?

No. Title should read, “malformed Message boot loops iPhone.”

There’s nothing bricked about this. There are no levels of brickedness.

I've encountered the terms soft brick and hard brick, maybe the first one would be somewhat clearer?

Is there a term for the current install being irreparably locked up?

Windows 95.


Safari on iOS threw a WebKit exception on my first try, but a reload worked…

Works fine for me, which version of Safari are you using?

Works in my FF 67.

Works on my FF 69 as well, but the text select behavior is weird at best.

The page did NOT work on my Edge 44, even after disabling uBlock.

Repeating repeatable results, works on 68 beta and 67.0.3 here

Same, it works for me on 67.0.3.

I didn't get a crash with 67.0.3 from f-droid, just to add a data point.

Another one :D

Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact