Once I scanned barcodes from a competing store rewards program into a PointOfSale terminal of a grocery store. The machine promptly shutdown. Sometimes I wonder if that was a failure mode to prevent attacks or a lack of sanitizing inputs.
In the early days of our local rfid-powered public transport payment system, i tried scanning a random misc rfid card from my wallet instead of the correct payment card.
The gate locked up and started screeching its "i scanned a card" chime on loop.
It was hilarious... and i guess a matter of poorly sanitized inputs.
[1] Is what (I believe) they were talking about. Rather than configuring these in a sane way you just scan configuration barcodes. I didn't see anything on the list that was too dangerous but you could change the maximum input length or allow full ASCII encoding which could be dangerous if the programmers assumed that the barcode reader returns a fixed length string of numbers.
Bingo. The better ones will only accept scantags if you scan the "enter config mode" within 30 seconds after power-on, for instance. Or yes, a hidden button on the underside of the checklane.
That's rare though, and sometimes the installer disables it for convenience while they're debugging the system and never re-enables it. So the vast majority of scanners in the wild will happily accept an enter-config-mode at any time.
A lot of them are configured by literally scanning settings. These "settings" barcodes are often left out in the open, or east to recreate. I used to have a "cheat sheet" when i managed scanners in a warehouse
Keyboard-wedge is only one of a dozen ways a barcode scanner can send data. Most also have legacy serial interfaces for use with old POS systems, so you have scantags that enable and disable those, and configure the baud rate, start bits, stop bits, parity bits, flow control (like a dozen different types), minimum idle time between subsequent codes, etc. And some of the old stuff isn't exactly ASCII, like there are systems that operate in MSI/Plessey mode which is all sorts of martian. It has its own whole config tree. I don't even remember how Nixdorf mode works, I never had to deal with it.
And even within USB, sometimes you emulate a HID keyboard and send scancodes, sometimes you enumerate as an actual USB HID barcode scanner (that's a dedicated device class), sometimes you emulate a USB CDC serial device and inherit all the serial config from above minus the baud rate. Oh, and sometimes you can configure the USB polling interval for performance.
Do you start with a special key/character to signal that a barcode is coming, or just begin vomiting digits into wherever the cursor happens to be? Pad shorter codes with leading zeroes? Do you send CR or LF at the end, perhaps both? Or some other key/character like tab?
Oh and keep in mind that some barcodes can do alpha characters too. Which keyboard layout are you emulating, because the whole world isn't US-English? Convert to upper or lower case? Filter characters? Send a different start-character to indicate that an alpha code is coming?
And then you've got the symbology selection. There are hundreds of different types of barcodes, and they're used for different things. Have you ever scanned a box and the scanner picked up a barcode from the shipping label rather than the UPC? That's because whoever set up the POS didn't disable the other symbologies. They should have. So there are config variables for all that. Even just the UPC/EAN/JAN family has a dozen subvariants, and some POS systems want a prefix to indicate which variant is coming down the wire.
Then there's scan tuning. How many times does the laser/imager need to read the code before it considers it good? Crank this up to increase confidence, crank it down to favor speed. How much "dead time" should the reader take after scanning one code before it can scan another code? How much should it have before it can scan the SAME code again? Picture the way a clerk whips products across the scan window and try to tune it so you can easily scan multiples of an identical product, without scanning the very same item twice if it remains within the window too long.
Newer scanners also have tunables for recognizing barcodes displayed on LCDs since customers now sometimes present coupons on their phone screens. That's its own whole can of worms and largely newer than my time in the industry so I don't know the specifics, but again it's a performance tradeoff depending on the situation.
There's also minimum and maximum distance and apparent line width, which can help in certain handheld situations (think of the handheld style used at convenience store counters) where it otherwise might pick up distant products on the counter by mistake. But sometimes you might want to be able to scan things from a few feet away, so that's configurable.
Then you've got UX variables. Beep after a good read? Configure pitch, duration, and volume. Different beep/tone for error? All of the above again. Turn the feedback LED(s) green/red for those statuses? Or does green mean "ready for scan", like at self-checkouts? Scanner always active, or only when activated by button push (handheld) or proximity sensor (pedestal) or scale (checklane)? Or active only when DTR line high (serial)? Timeout after activation if no valid read? There's so much more, this only scratches the surface.
Finally, all these config variables can be stored, recalled, defaulted, protected, and unprotected.
I have a credit card that bluescreens (some) PoS terminals. I theorize the upstream server is returning a rare error code when it's used in contactless mode, because that account's never been approved for contactless. In that case I'm going with lack of sanitizing inputs.
Terminals that only supported the first version of tap to pay in the USA often have this bug when activated by a card from this first version of tap to pay.
Similar to airplane phone in the late 90's using a calling card. While the asked for a calling card number, the system didn't actually confirm that there was any money on the card itself and just connected to the person you were calling.
That actually makes sense, the logic there would be that the on-plane system just captured the card number and an on-the-ground system was responsible for checking and billing.
Given that 747s (IIRC) are still using floppy disks (https://google.com/search?q=747+floppy+disks) the chances are the billing was probably done by some equally byzantine process.
Yes, I'm saying that, despite the fact that
"capture calling card number for later using on-plane PBX, establish satellite call directly to dialed number"
and
"establish satellite call directly to on-ground PBX, which asks for calling card number and forwards call"
both ultimately return TRUE for "but users can trigger our satellite uplink to initiate connections just by picking up the phone!!1"... but the latter approach actually blocks illegitimate use and is thus measurably better, and skips the need for an on-plane PBX too.
I can't help but wonder if there was some sort of "capture the number first before initiating the call" initiative early on (which totally makes sense), only for the calling-card billing integration to fall through at some point rendering the whole approach moot.
Naturally I'm making a lot of assumptions here, the biggest being that the plane isn't just making a direct-to-ground connection the moment you pick up the phone, with an on-ground system accepting then forgetting the calling card number. That would be even more stupefying but I do doubt that's what was happening.
Most of the stores where I live allow you to scan other stores rewards cards. You don't get points on your account but you still get whatever sale prices that are reserved for reward card holders. Wonder if in your case the store supported this function but there was a null or something similar in the record for that card type.
Most retailers use the same ranges for their rewards cards, UPC-A barcodes starting with 4. So even if not intentional, if their system is configured to allow an unregistered card to receive discounts, doesn't validate registration at all, or the number collides with a legitimate rewards card, you'll receive the sale pricing. Similarly, if you simply use a common phone number like xxx-867-5309, 800-555-1212, the store's phone number, etc., you'll probably get discounts too.
At the store I worked at 15 years ago, any 4xxxxxxxxxx code would give you the loyalty program. No reason to authenticate, they'll give you the "discount" (hint its not really a discount) even if you just ask.
Sounds like a pretty easy way to do a denial-of-service attack against a grocery store if you can just shut down a bunch of terminals with a barcode. I guess you'll stand out a fair bit if you move from PoS to PoS, scanning a barcode.
and this video https://www.youtube.com/watch?v=cIcbAMO6sxo where all the gates at a parking garage are rendered inoperable because someone scanned a QR code that encoded EICAR
The barcode register attack was explored in a episode of The X-Files titled Duane Barry (2x05; 14 Oct 1994), when Special Agent Dana Scully scans a chip (that had been found implanted in her neck and subsequently removed) at a grocery store checkout scanner, and iirc all the registers went berserk. So this is definitely a thing.
