Earlier quoted context omitted.
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
iMessage: Malformed Message Bricks iPhone
181–190 of 279 posts
Re: iMessage: Malformed Message Bricks iPhone
#182Earlier quoted context omitted.
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.
Re: iMessage: Malformed Message Bricks iPhone
#183Earlier quoted context omitted.
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.
Re: iMessage: Malformed Message Bricks iPhone
#184Earlier quoted context omitted.
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.
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.
Re: iMessage: Malformed Message Bricks iPhone
#185Earlier quoted context omitted.
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. https://www.cvedetails.com/vulnerability-list.php?vendor_id=...
[deleted]
Re: iMessage: Malformed Message Bricks iPhone
#186Stupid question: How is the example python program actually sending an iMessage? Since Apple generally has the system locked down.
Re: iMessage: Malformed Message Bricks iPhone
#187Earlier quoted context omitted.
Hahaha on Yahoo we called it booting.
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.
Re: iMessage: Malformed Message Bricks iPhone
#188Earlier quoted context omitted.
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.…
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.
Re: iMessage: Malformed Message Bricks iPhone
#189Earlier quoted context omitted.
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.…
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 t…
> 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?
Re: iMessage: Malformed Message Bricks iPhone
#190Earlier quoted context omitted.
You want to write explicit error handling for every possible case of runtime type errors in a dynamically typed language? The "unrecognized selector sent to instance" exception is not thrown in the hope that someone will catch it. It's intended to be a fatal error reporting a precondition violation.
That’s what secure coding guidelines say to do. It’s called “input validation”. For example here’s Apple’s: https://developer.apple.com/library/archive/documentation/Se... Especially important on methods called on launch, if a crash would cause a problem. (Swift or other strongly typed language would help here.)
The halting problem's existence means that there's no input validation that is guaranteed to work absolutely 100% of the time though, for sufficiently large inputs.