Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How a single line of code could brick your iPhone

rambo.codes

Post reply on HN
Print view View original

121–126 of 126 posts

Re: How a single line of code could brick your iPhone

#121

Post by genewitch »

genewitch wrote: post #81
bslanej wrote: post #27

Earlier quoted context omitted.

I’m too lazy to look it up but there was some string you could send over IRC that would make some routers drop the connection immediately - if you pasted that string in a big channel you would see dozens of people immediately disconnect.

On AOL in chatrooms you could play sounds, so if you sent S{/con/con As the sound, you could crash anyone on windows that hadn't shut off user sounds. My memory is a bit hazy and I don't want to look up the exact sequence, but that's close enough.

https://mazur-archives.s3.amazonaws.com/aol-files/breaches/c...

it was `{S /con/con`; my memory transposed two characters. the {S was the "system message" that AOL chatrooms used to send sounds, so that sequence of characters after a newline made your computer look for that sound. It was cool if everyone was trusted to not do the /con/con, people would have email chains with the audio files on them, like a proto-napster.

Re: How a single line of code could brick your iPhone

#122

Post by nativeit »

croisillon wrote: post #11
nativeit wrote: post #7

Earlier quoted context omitted.

I read a comment under the story about the recent YouTube vulnerability where one could unmask the related Google account and its owner using the standard YouTube API (something similar to that anyway), and they explained a lot of lesser-known nuances in establishing values for bounties like these, and it helped explain a lot (not all) of the reasons for what might seem like low-ball/high-ball valuations on the surfa…

is this the one: https://news.ycombinator.com/item?id=43025038

That's it! Really informative, IMHO. Thanks for adding the other cheek to my half ass job there.

Re: How a single line of code could brick your iPhone

#123

Post by nativeit »

sdeframond wrote: post #10
nativeit wrote: post #7

Earlier quoted context omitted.

I read a comment under the story about the recent YouTube vulnerability where one could unmask the related Google account and its owner using the standard YouTube API (something similar to that anyway), and they explained a lot of lesser-known nuances in establishing values for bounties like these, and it helped explain a lot (not all) of the reasons for what might seem like low-ball/high-ball valuations on the surfa…

Probably one of those https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

100% Thanks for the assist.

Re: How a single line of code could brick your iPhone

#124

Post by timschumi »

jchw wrote: post #111
miki123211 wrote: post #77

Earlier quoted context omitted.

There's physically no way to permanently "brick" an iPhone. DFU mode boots entirely from read-only ROM, and from there, you can just restore everything via USB cable. Same applies to Apple Silicon Macs. You can damage the system, recovery and emergency recovery volumes, but even then, you can still boot into DFU from ROM and re-initialize everything via another Mac. This is in contrast to some PCs, where if you damag…

I'm gonna walk through this because I have a bit of experience here on the computer side of things, but I'm not really making an excuse for the fact that the PC version of this is less user-friendly; from my perspective, I fully respect that Apple has done a good job with user experience where PC manufacturers have lagged. However, my main concern is devices turning to e-waste, so the important thing for that isn't U…

> Screwing up EFI vars doesn't make most systems unbootable. I have corrupted my EFI vars quite a few times trying to do funny things. UEFI implementations do tend to be buggy, but not all of them are that catastrophically bad.

For what it's worth, I have a laptop here that can be irrevocably (short of having a flash memory dump on-hand that can be flashed back) bricked just by messing around with EFI variables through fully intentional operations (i.e. operations that would be available to any program with Administrator privileges on Windows, or the root user on Linux).

Re: How a single line of code could brick your iPhone

#125

Post by jchw »

timschumi wrote: post #124
jchw wrote: post #111

Earlier quoted context omitted.

I'm gonna walk through this because I have a bit of experience here on the computer side of things, but I'm not really making an excuse for the fact that the PC version of this is less user-friendly; from my perspective, I fully respect that Apple has done a good job with user experience where PC manufacturers have lagged. However, my main concern is devices turning to e-waste, so the important thing for that isn't U…

> Screwing up EFI vars doesn't make most systems unbootable. I have corrupted my EFI vars quite a few times trying to do funny things. UEFI implementations do tend to be buggy, but not all of them are that catastrophically bad. For what it's worth, I have a laptop here that can be irrevocably (short of having a flash memory dump on-hand that can be flashed back) bricked just by messing around with EFI variables throu…

As far as I know virtually all of the EFI vars will be stored on battery-backed NVRAM, so the usual solution is to just clear that, by removing the CMOS battery. I am pretty sure the only solution are things you definitely can not read or write from the host OS (e.g. BIOS passwords.) Does require partially disassembling the laptop though, and I know there's at least a couple random models of laptop that actually stop working if you clear the NVRAM (lol)

Re: How a single line of code could brick your iPhone

#126

Post by jchw »

jchw wrote: post #125
timschumi wrote: post #124

Earlier quoted context omitted.

> Screwing up EFI vars doesn't make most systems unbootable. I have corrupted my EFI vars quite a few times trying to do funny things. UEFI implementations do tend to be buggy, but not all of them are that catastrophically bad. For what it's worth, I have a laptop here that can be irrevocably (short of having a flash memory dump on-hand that can be flashed back) bricked just by messing around with EFI variables throu…

As far as I know virtually all of the EFI vars will be stored on battery-backed NVRAM, so the usual solution is to just clear that, by removing the CMOS battery. I am pretty sure the only solution are things you definitely can not read or write from the host OS (e.g. BIOS passwords.) Does require partially disassembling the laptop though, and I know there's at least a couple random models of laptop that actually stop…

*only solution = only exceptions

Not sure how that happened.

Post reply on HN