Hacker News Reader

Comment by qeternity | Hacker News Reader

It seems that 0d has since become a synonym by some for unpatched exploit.

The days can be reasonably counted since the release of a fix: 0-day would be an exploit for which there is no defense, and a n-day would be an (old) exploit patched since n-days.

The most valuable time of an exploit is not the time of discovery, but the time of resolution.

This isn’t a guessing game. Zero day has a very specific meaning. Just because something isn’t patched doesn’t mean it can’t be mitigated (i.e. disable the service) so no, patching is not the most important. Disclosure is.

By defense I meant patch or mitigation. When using the sysadmin hat, I don't care when the bug was discovered or disclosed, I only care about when was it fixed, or how can it be mitigated.

Sorry my reply came so late.

It feels l33t to appropriate the terminology of a professional -

like "We need to control the optics of the situation"

"I flashed my cellphone but it failed and now it's bricked."

but the unsophisticated public gets it wrong and now here we are, every recent unpatched exploit is now 0day

> I flashed my cellphone but it failed and now it's bricked.

It doesn't sound wrong to me, both "flash" and "brick" are correct in an appropriate context. It's not "updating the system" but "flashing" if the process uses some low-level recovery mode, and it would be "bricked" if can no longer be recovered by usual means.

Most of the time "flashing" a phone (presumably referring to androids) involves using the recovery, which is basically a stripped down version of android. In that sense it's not any lower level than booting off a USB drive to fix your computer.

According to your standard: to "flash" something, at least you need to use the bootloader itself, or possibly at a lower level? Well, calling the process of uploading a firmware image to an embedded device during early boot via U-Boot as "firmware flashing" is well established, so we can start from here... thus, uploading a new Android image in Android Recovery is not "flashing", but uploading a "recovery" image in Android bootloader is? Now, would you call firmware uploading via iOS's DFU mode "flashing" too? Or do you believe that the DFU mode is end-user accessible, thus not low-level enough? Then, would you accept that uploading the firmware to the baseband processor (which I believe uses its own EEPROM) via DFU "flashing"?

I guess the definition varies, it was what I meant by "an appropriate context".

>thus, uploading a new Android image in Android Recovery is not "flashing", but uploading a "recovery" image in Android bootloader is? Now, would you call firmware uploading via iOS's DFU mode "flashing" too? Or do you believe that the DFU mode is end-user accessible, thus not low-level enough? Then, would you accept that uploading the firmware to the baseband processor (which I believe uses its own EEPROM) via DFU "flashing"?

The difference is that the recovery is almost a full blown operating system. It can mount filesystems, has various shell utilities installed, and there's a user interface (through ADB and on-screen). This in contrast to fastboot which has noneof those things, and only allows you to flash/erase partitions with the help of a computer.

Fair enough.

What's wrong with the second example?

In my day, bricked meant recovery was impossible without dragging out a soldering iron. This gave way to needing to at least physically disassemble something to get to a jtag or similar port. If you can recover the device with user accessible buttons and and standard cables... it’s not bricked in my book.

To me it's not even a brick if a soldering iron is still useful.

And for a number of years I only thought a zero-day defect was something that had existed since that version of DOS or Windows was issued, regardless of when or whether it was discovered, patched, exploited or not.

Eventually I got the idea that people just don't want to count back that far.

Reply on news.ycombinator.com