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

As you can see on this image :

enter image description here

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

Here it is :


And when I decode it, I get the following :

enter image description here

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!

  • 3
    Never mind the barcode, I'm wondering what those random(?) mathematical symbols at the bottom are about. Dec 20, 2014 at 22:25

3 Answers 3


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.

  • Hey thanks, I have been looking up for days for this information, and you found it in minutes... sigh...
    – user66792
    Dec 19, 2014 at 17:26
  • Happy to help. Here's the search that found it for me: google.com/… -- it's the third hit. Dec 19, 2014 at 17:43

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.


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.


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)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.