For the best experience on desktop, install the Chrome extension to track your reading on news.ycombinator.com
Hacker Newsnew | past | comments | ask | show | jobs | submit | history | more prutschman's commentsregister

If I remember correctly, in the FTDI case that was very unlikely to happen. It wasn't a case of `if (looks_fake) do_brick()`. Rather, it accessed registers in a way that they knew their implementation supported but that was buggy in a widely counterfeited version.

(And I understand it they did this knowing the effect it would have. It wasn't some accident.)


The converse: they performed EEPROM writes in a way that was ignored by that particular chip from FTDI (only one - it would've bricked other FTDI products) but honored by the clones. They exploited a bug in their own product to make their bricking code only affect the (non-buggy) clones.

The code was blatantly deliberate; to pull this off they had to perform a preimage attack on the EEPROM checksum, etc.


I think ironically it was other way around - they issued write in such way that due to quirk in genuine chip it was no-op but actually worked on the clone.


This is correct.

More specifically: many of FTDI's devices, including the FT232RL, can store configuration data in an EEPROM. EEPROMs are conventionally organized as an array of bytes, but FTDI devices always access the EEPROM 16 bits at a time. The FTDI devices include some commands to read/write the EEPROM. For convenience, these commands use an address counting in bytes, but the official drivers and tools only ever use even addresses (so that the EEPROM addresses accessed never go "across" fields).

The FT232RL is one of FTDI's parts which has an internal EEPROM. An implementation quirk means that any attempt to perform a EEPROM write on this part with an odd address will be ignored. (This quirk is specific to this one part -- most of FTDI's other parts will perform this operation as expected.) This fact was apparently not known by the developers of the FT232RL clone; it will perform the write.

FTDI released a driver update which would, upon detecting a FT232RL, attempt to write zeroes to several odd addresses near the locations used for the device's VID/PID (vendor ID and product ID). These writes were ignored by the genuine devices, but were interpreted by clones as writing zeroes to these fields. This caused the devices to fail to be recognized when next connected to a host.

What's funny is that, as far as documented functionality is concerned, the clones work perfectly. In some regards, they actually work better than the originals!


That's not quite right. The addresses are in 16-bit word units; there are no unaligned accesses or byte offsets. You can write to any 16-bit word on other FTDI chips. However, the FT232RL has a quirk where it expects you to write adjacent pairs of 16-bit words sequentially, and only commits the write on the second one. If you only write the first half (at an even word address), nothing happens.

Usually, when programming the EEPROM in these devices (e.g. with FTDI's tools or open source ones), you write the whole thing at once, so those pairs are always written sequentially and it works anyway. However, if you try to write to some words at even addresses without following up with the next one, the FT232RL misbehaves and ignores the write.

Specifically, what happened seems to be that the FT232RL uses an internal 32-bit EEPROM. So when you write to even addresses, those writes are staged to a buffer in anticipation that you will subsequently write to the next odd address. At that point all 32 bits are written. The bricking code only ever wrote to even addresses, which involved a preimage trick to keep the existing checksum valid, since the checksum is at an odd address they couldn't write to. Instead they calculate what the value for the word before the checksum should be to make the existing checksum valid, and write that instead. Genuine chips would just stage all these writes in a holding register and never get to commit them.

Basically, FTDI decided to use an internal 32-bit EEPROM macro when developing this chip, and came up with this hack to shoehorn it into the 16-bit protocol (in what is arguably a buggy way). The clones just implemented 16-bit writes properly, which is the same thing all other FTDI chips (with external 16-bit EEPROMs) do.

(Source: I'm the guy who first figured all this stuff out back when this happened, including reverse engineering the FTDI bricking code and writing an unbricker).


Thank you very much!


Thank you for elaborating on the story! I didn't know the details.


You’re right - I think I was misremembering the details and it was something like a poisoned supply chain leading to people who thought they had bought the real thing shipping devices that ended up breaking or something.


Well, it was "a poisoned supply chain leading to people who thought they had bought the real thing shipping devices that ended up breaking"; it's just that FTDI was the company that poisoned the supply chain and broke the devices.


I was misremembering the specifics too, it turns out. It was much closer to do_brick(). Ugly.


I've never intentionally turned on google Photos backup since I use Dropbox instead, but I still notice it turning back on periodically.


> So... what exactly become the merit of taxing land over property? If you tax property, the value of the land is included in that tax.

If land--but specifically not improvements to that land--is taxed then there's relatively more incentive to make productive use of the land. $1 of investment to improve the productivity of land by building housing or whatever is tax advantaged over $1 of investment to try to hold onto appreciating land in hopes it goes up.


There's some available literature on the subject of required laser wavelength/energy for an in-flight thermal mosquito kill: https://www.nature.com/articles/s41598-020-71824-y.pdf

For a thermal kill you have to deliver some number of Joules of energy into the target. You can use a lower powered laser over a longer period of time, up to a point. You have roughly 25 milliseconds of thermal confinement time before the mosquito starts to cool off. Longer exposures can work, but the total energy dose needed goes up. Longer exposures also require keeping the laser aimed at the target for a longer time.

Power needed also depends on how closely you can track the target. If you make the spot small enough that the target catches all of it then you minimize power requirements, but that increases the complexity of the optics. If you use a spot size larger than the target then the optical and tracking complexity go down, but you're no longer sending all of your Joules into the target.


It's not literally false, but I got an inaccurate impression based on the headline. To me it implied a positive discovery of evidence rather than a ruling-out.

If they'd said "determined new constraints on a hypothetical 5th force" or something I would have gotten a correct impression.


Not a jq expert, but my understanding is:

`.[]` takes a list and turns it into a sequence consisting of each element of that list.

`| x` applies the filter `x` to that sequence, turning it into a new sequence.

The outermost `[ ]` builds a list from that new sequence.


If you happen to know: Is it the performing the test itself that's illegal, or is it "merely" that to perform a test for someone you'd have to take possession of the substance, however briefly? (Bad for both harm reduction and liberty either way, I'm just curious which it is.)


I think they're referring to the fact that there is one dimensionless base unit already standardized in SI: the mole. There aren't two length units, so there "shouldn't be" two dimensionless ones.

(Whether they were trying to be funny or not I couldn't tell you.)


It's a mol not a mole (sounds the same)

lol (or is that lole?)

"they" are not trying to amuse anyone.


The "mole" is the unit, "mol" is the symbol for the unit, like with "kilogram" and "kg".


How do you know that lalaithion was not trying to amuse anyone?


In some browsers you can get around this by selecting the text, keeping the mouse button down, hitting the keyboard shortcut for 'copy', then letting go. The selection will still be emptied, but the text is already in your clipboard.


My lay understanding of the current standard of care is very roughly speaking something like:

Patient exhibits symptom => perform a not-especially-invasive test Positive test result => invasive test like a biopsy Positive biopsy result => heavy-duty intervention (although I'm not focusing on this part of the chain in what follows)

Both testing and (certain) symptoms have predictive value, and don't completely overlap. So there's something like this going on:

P(actual problem|no additional information) = really really low, which is why they don't scoop out chunks of every organ to test "just in case" every time you go to the doctor

P(actual problem | [symptom AND positive test result]) = generally high enough in at least some cases to justify the risk of the biopsy, which is why it's the standard of care

P(actual problem | just symptom) = probably not super high, which is why the tests are developed

P(actual problem | just a positive test result) = substantially lower than P(actual problem | [symptom AND positive test result]), so in the general case the balance of risk no longer favors the biopsy

In the broadest of strokes, is there anything I've just said that you substantially disagree with?


No, there isn't, though it is probably important to point out that age, genetic disposition and gender are a big factor in selecting what kind of test and if positive what kind of treatment - if any - will be administered and that this is as you correctly identify on symptomatic patients only which raises the base rate in that population (the population of symptomatic patients) tremendously.

And that's exactly where the issue with indiscriminate asymptomatic testing lies, that requires much higher quality tests than the ones that can be used in a diagnostic setting once a patient is symptomatic.

To add one more unpopular bit of data to all this: there is some evidence that the indiscriminate testing for certain cancers has gone too far and that it no longer is a net positive. But in the presence of certain mutations those tests are extremely valuable.

https://www.statnews.com/2018/01/01/cancer-screening-misled-...

Biology is messy, and it is quite hard to state up front whether or not a test or a treatment - even if in an experimental setting it is working - will still be a gain if rolled out in a different setting or application. Hence all the trials and studies, that's the only way to really get a grip on this.

I'm quite curious what the outcome of the large scale test the article refers to will be.


Consider applying for YC's Summer 2026 batch! Applications are open till May 4

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

Search:

HN For You