Comment by michaelt | Hacker News Reader

Comment by michaelt | Hacker News Reader

> You might ask: how do you know whether or not software has been fuzzed?

zbar has great barcode reading performance! I've seen far newer software that's nowhere near as good in terms of real-world performance.

But it seems the original developer hasn't updated it since 2009 [1] - and fuzz testing only rose to prominence in ~2012 with the rise of tools like afl-fuzz.

I would be absolutely astonished if it had ever been fuzzed.

> Cut out any unnecessary features to limit attack vectors. ZBar by default scans all code types, which means that an attacker can trigger a bug in any of the scanners. If you only need to scan QR codes for instance, then ZBar can be configured to do so in the code

Absolutely sensible, yes.

Not just for security, but also because packages sometimes have extra barcodes. If you're scanning an EAN-13 on a pack of pasta, decoding a QR code for a pasta recipe website is just going to confuse things :)

[1] https://sourceforge.net/projects/zbar/files/zbar/

I've seen the "overzealous barcode scanner" issue happen with some gas station POS systems, to the point where the seasoned cashiers know to cover the QR codes with their fingers before attempting to scan an item.

Absolutely. I helped with a physical inventory count project using smartphones as the "terminals". The barcode app we didn't allow us to selectively turn off symbologies. We ended up with a ton of links to recipes, websites, etc in the data.

Reminds me of the Jurassic Park novel where they ask the computer to find 10 velociraptors on the island and it finds 10. And they actually have 20.

Can you really blame the computer tho? That sounds more like a case a PEBCAC, if you ask me...

More like bad requirements. The system knew how many dinosaurs of each species had been released into the park, and the inventory system was only supposed to figure out if any were missing. No sense in looking further than that, after all where should the additional dinosaurs come from.

That was the main theme of the book. Everything was well designed with failsafes, but too many of the design assumptions turned out to be wrong. Expecting only the expected lead to many small mistakes that were harmless individually but together snowball into a disaster.

Crichton novels are excellent at that kind of technical dystopian/disaster.

(Well, not obviously dystopian, more ‘oh shit, that is how we’d be fucked isn’t it). Alien and Aliens also had a similar feel in their writing, except in real life there is rarely a Ripley there when you need one.

They can run the whole park with minimal staff for up to 3 days. You think that kind of automation is easy? Or cheap?

It is when you outsource to one Nedry and his coke habit!

The Jurassic Park novel had some of the best depictions of technical failures like that, IMO. The scene where they realize they've been running on backup power and everything goes down is another good one. I won't call them realistic per se, but they just felt right. Andromeda Strain, another Crichton work, was also pretty good at this.

The Andromeda Strain is the most underrated of Chrichton's books, to my mind. The movie adaptation is very good, too.

It's also a common annoyance in grocery store apps.

Kroger, for example, has an app that allows you to scan items to add them to a virtual cart as you shop and avoid scanning them at the register... however the same app is used to read QR codes on in-store coupons, which are "helpfully" placed very close to the price tags with UPC barcodes on them.

If I want to scan one of those coupon QR codes, I need to either start with the camera very close to the QR code or cover the barcode with my finger.

Sounds like the POS software isn't controlling the reader well, maybe because it wasn't adjusted for this model of reader. Or the reader's firmware could have been misconfigured, from what it's supposed to be for that POS setup.

The modern reader firmware tend to have multiple modes and many options. Some modes are as simple as "scan whatever you see out of the many formats you support, and spit out the decoded value of something as USB Serial". Or, worse, "...as USB Keyboard".

You can imagine how easy those modes are to integrate with POS software, without implementing the proprietary protocol for that device, and you can also imagine how poorly that can work out.

If you owned a store with a POS setup with flaky reader behavior like this, and were stuck with it, you could try reconfiguring the reader (to, say, disable QR support). This reprogramming can sometimes be done via documented protocol, via sketchy Windows software, or via... barcode... Careful you don't make it worse.

(Our startup used modern readers (multiple 1D formats, QR, NFC) for a factory station, and had to do a lot of experimenting with different brands and models, to get the behavior and speed we needed. We even managed to brick a reader, just with configuration changes, not flashing firmware.)

The shop may use QR codes for coupons or loyalty programs even if the merchandise doesn't use it. So being able to scan these items without switching mode is often an important feature.

I went to a meeting the other day in a building with a touch screen registration system. The woman in front of me was struggling with it. Every time she tapped the register button the system decided that some part of her was a badly formed barcode, printed an error message and exited back to the menu. She eventually got it working by moving to the side until it wanted to take her picture.

It appears to have been forked: https://github.com/mchehab/zbar

That's the repo Trail of Bits was working with; the PR they ended up submitting is at https://github.com/mchehab/zbar/pull/294.

Reply on news.ycombinator.com