Reverse Engineering Quebec Canada PDF417 restaurant bills

Question

Let me explain what I'm trying to do, and then where I am at...

As you can see on this image :

There is a PDF417 at the end containing a string that at my best guess is some base64 string.

Here it is :

3GLDjVKaUbwysHTAffMyChP1wqzvc/h41aebPrw0PsprtPy85tBa87vzsLw6hL8t5FBJLGlHODGQ0O8ml0OKs7mmqgB1pZsAvcs2CyAgICA0MzA2MzjAyzYLICAgICBKdWxpZSAgIDMwU09CUwAApQAAagcAAAAAAAAA

And when I decode it, I get the following :

I kind of found the waitress name "Julie" and in front of it, there is a bunch of space characters, which I guess it is because there is a limited size to the name.

Same for the bill number, and the table number.

But I was wondering what kind of information was in the previous bits, so any idea how to proceed to decode/decrypt this information would be greatly appreciated.

---

The machine used for the generation of the base64 string and its content is a "AEC-6822".

And here is some unrelated information to what I'm trying to do, but may help... (I hope) http://www.revenuquebec.ca/documents/en/publications/in/in-577-v(2013-08).pdf

Thank you very much, ANY help is greatly appreciated!

Answer 1

From https://www.ctf.ca/ctfweb/Documents/PDF/2009ctj/09ctj4-ainsworth.pdf --

In addition to ensure the integrity of the information presented on the receipt, the solution designed by Revenu Québec ensures that the bar-code scanned by the [handheld] reader is produced by the certificate delivered by [Revenu Québec] to the specific MEV [SRM] which generates this signature. The signature is produced by a combination of SHA-256 and ECC-224.

This method uses a certificate which includes a public and a private key issued for each MEV [SRM] with information that identifies the MEV [SRM] and the restaurant.

We choose the elliptic curve algorithm (ECC) to reduce the length of the result (to be converted to a barcode) and to maintain a good strength.

So apparently the previous bits in the barcode make up a digital signature, which would explain the high entropy.

Answer 2

I once had a set of receipts and chewed through the statistics of how often the symbols are repeated. That shows that there most likely are 256 symbols, which would make the row of symbols contain 96 = 12 * 8 bits.

https://www.ietf.org/mail-archive/web/81attendees/current/msg00986.html

Checking the Unicode charts, almost all of the symbols are on the page U+22xx, "Mathematical symbols". I haven't tracked down the rest, some of which are seriously obscure, but some seem to be sans-serif Hebrew letters. I am guessing that the symbols not in U+22xx are to replace some symbols on that page that are too much like others.

There doesn't seem to be any ordinary data processing purpose that the symbols could serve, since any information you wanted to be machine processable you'd put in the barcode. My guess is that the symbols are a hash, summary, or subset of the information in the barcode and function as a "receipt number" that the recipient can read, so that if two buyers purchase the same thing, the establishment cannot give them two copies of one (recorded) receipt but rather has to record two receipts to give to each of them.

This explanation accounts for why the symbols are easily human recognizable. It is also based on an experience in the Musée de la civilisation à Québec: I purchased a tea from the cafe, and my companion purchased a tea as well, immediately after me, from the same cashier. Our receipts had the same line of symbols, a surpasingly unlikely event, which suggests that we received duplicate copies of one recorded receipt.

Answer 3

Based on a few samples, here is an overview of some fields that can be read in clear.

Source: https://github.com/fproulx/tastybits/blob/master/NOTES.md

Datasets: https://github.com/fproulx/tastybits/tree/master/sample-data

Unofficial specification

• PDF417 barcode with BASE64 encoded binary payload
• Always 0x7A bytes long == 122 bytes == 976 bits
• Endianness appears to be Little Endian (Intel)
• [0x00, 0x39] Unknown data. Always differs from bill to bill.
• [0x40, 0x43] MEV serial number
  • Notes: left-aligned binary 32-bits little endian, zero padded (0x00)
• [0x44, 0x47] MEV transaction counter (monotonically increasing)
  • Notes: left-aligned binary 32-bits little endian, zero padded (0x00)
• [0x48, 0x4B] Unknown data
• [0x4C, 0x55] Unique bill/transaction number
  • Notes: right-aligned ASCII text, whitespace padded (0x20)
• [0x56, 0x59] Bill datetime
  • Note: Number of seconds from MRQ Epoch (2009-01-01)
• [0x5A, 0x63] Employee name
  • Notes: right-aligned ASCII text, whitespace padded (0x20)
• [0x64, 0x6B] Vendor field, typically table number, takeout, etc.
  • Notes: right-aligned ASCII text, whitespace padded (0x20)
• [0x6C, 0x6E] TPS value in cents
  • Notes: left-aligned binary 24-bits, little-endian, zero padded (0x00)
• [0x6F, 0x71] TVQ value in cents
  • Notes: left-aligned binary 24-bits, little-endian, zero padded (0x00)
• [0x72, 0x77] Total price (including TPS+TVQ) in cents
  • Notes: left-aligned binary 24-bits, little-endian, zero padded (0x00)
• [0x78, 0x7A] Constant data (0C:43:0E)