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.
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.
Q: This barcode scanner has a million options, how do we configure them?
A: By showing configuration barcodes to it!
https://downloads.dell.com/manuals/all-products/esuprt_tab_m...
[1] https://cdn.sparkfun.com/assets/b/5/0/e/e/DY_Scan_Setting_Ma...
... but yeah, it should require pressing a recessed button with a pin or something. not allow it all the time.
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.
Aren't they just USB HID (previously: serial) devices that literally just output key codes for the numbers detected?
I also used a 2D scanner and it worked the same way.
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.
The fancier scanners have well over a thousand config variables you can set, for example: https://www.zebra.com/content/dam/zebra_new_ia/en-us/manuals...
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.
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.
https://www.theverge.com/2017/10/24/16505912/floppy-disk-3d-...
See: https://en.wikipedia.org/wiki/EICAR_test_file
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