Revision as of 15:11, 23 July 2022

Current Version (>= 2020?)

Two byte header, fixed 0x0403.
Gzip-compressed payload using deflate compression, starting with the standard Gzip header 0x1f8b0800000000000000.
256 remaining bytes, high entropy and length suggest a cryptographic signature.

Seems byte- rather than bit-aligned.
String encoding is UTF-8.
Number encoding seems big endian.
Content has a high amount of null bytes.
Date/time values are encoded as seconds since 2017-01-01 00:00:00 CET (or 2016-12-31 23:00:00 UTC). Exception: traveler birth date.
Consists of a variable set of blocks.
Block layout is defined by information in the header block, there does not seem to be a TLV-like structure.
Observed block layouts:
- Header block.
- Either passenger or bike addon block.
- Trip block.
- 0-2 reservation/surcharge blocks.

Offset	Size	Data Type	Meaning	Notes
0	17	string	ticket number	printed as "CIV" in the PDF
17	1	null	?	null in all samples
18	2	uint16	UIC company code	issuer?, 0x0483 (1155) for MÁV-Start
20	4	time	issuing time
24	1	?	ticket type??	'C' for bike addon tickets, 'B' or 'D' for regular tickets (with or without seat reservation, 'E' for tickets with surcharge (and with or without seat reservation), null for "connecting ticket to season ticket"
25	2	?	?
27	1	null	?	null in all samples
28	1	?	ticket type??	0x01 for bike addon block, 0x81 for passenger block
29	1	null	?	null in all samples
30	1	uint8	number of reservation/surcharge blocks
31	4	null	?	null in all samples
35	4	?	?	only two distinct values observed in all samples

Offset	Size	Data Type	Meaning	Notes
0	45	string	passenger name	null terminated
45	4	uint32	passenger birth date	year * 10000 + month * 100 + day
49	15	null	?	null in all samples
64	4	?	?

Offset	Size	Data Type	Meaning	Notes
0	4	?	?	values seem fixed in all samples?

Offset	Size	Data Type	Meaning	Notes
0	3	uint24	UIC departure station code	including the national prefix ('55' for HU)
3	3	uint24	UIC arrival station code
6	90	10 * uint24	UIC station codes	list of vias, null if not set
96	1	text	class	"1" or "2"
97	1	?	?	0x01 in all samples
98	4	time	time of validity/travel
102	1	null	?	null in all samples
103	1	?	?	0x00 or 0x05 in all samples
104	1	?	?	varying between samples, 0x01 or 0xef observed
105	1	?	?	same as byte 103
106	4	?	?	varying between samples

57 bytes long.
Also used for surcharge ("Pótjegy") blocks, in which case the fields for coach and seat numbers are all null.
Order of surcharge and reservation blocks seems undefined if both are present.
Follow all other blocks, number of blocks determined by header block byte 30.

Offset	Size	Data Type	Meaning	Notes
0	3	uint24	UIC departure station code
3	3	uint24	UIC arrival station code
6	4	?	?
10	4	time	time of validity/travel
14	2	uint16	UIC company code	operator?, 0x0483 (1155) for MÁV-Start
16	5	string	train number	null-terminated
21	1	?	?	0x01 in all samples
22	3	string	coach number	null terminated
25	2	uint16	seat number
27	2	uint16	seat number	repeated from byte 25/26?
29	28	null	?	null bytes in all samples

~~Station names are not included, but station codes might be. UIC station numbers (possibly without the country prefix) would be the obvious suspect, given the MÁV website uses those as well.~~
~~If the train number is included, one would expect at least the day of travel to be included as well.~~
~~Class: several candidate locations exist, but given it's small footprint we need a lot more samples to confirm one of those.~~

PDF looks generally similar to the above, with slightly smaller PDF417 codes
Unclear whether this supersedes the above format, or whether this only applies to a certain type of ticket.

Only the following sequence has been observed so far, it is possible the optional blocks as noted above would appear in a similar fashion though.

Header block, starting at byte 20, ie. omitting the first 20 bytes (those occur before the compressed payload).
Passenger block, same as above.
Trip block, same as above.

At least the passenger information block described above occurs in exactly the same format in there.

QR code containing a hex string
content of the hex string is zlib-compressed, no header bytes
result of decompression is a UTF-8 encoded string
- the first 512 bytes appear to be a hex string again, length and entropy suggest a cryptographic signature
- the second part looks like a '!' delimited list

Index	Format	Meaning	Notes
0	~<number>	ticket number	printed as "CIV" in the PDF
1		passenger name
2	yyyy.MM.dd	passenger birth date
3		total price	in HUF
4	?	?	"P05"
5	yyyy.MM.dd hh:mm	begin of validity
6	yyyy.MM.dd hh:mm~v	end of validity	no idea what the literal '~v' means there
7	MÁV <number>	travel distance
8	'-' separated string	vias
9		departure station name
10		arrival station name
11			empty?
12			empty?
13			empty?
14			empty?
15		train number	number only, not product/category prefix
16		class
17	yyyy.MM.dd~m	day of travel?
18	string	discount_type	e.g. "Teljesárú" (full price)
19	<number>~h	ticket price	in HUF
20		departure station name	possibly for the seat reservation
21		arrival station name	possibly for the seat reservation
22	yyyy.DD.mm	day of travel?
23	hh:mm	time of departure
24			empty?
25			empty?
26		train number	incl. product/category prefix
27		coach number
28		seat number
29	number	price of reservation	in HUF
30		extension-ticket	"Helyjegy", "Pót- és helyjegy"
31	MÁV <number>	?	same as entry 7, not always present

@@ Line 181: / Line 181: @@
 == Inner Structure ==
-TODO
+Only the following sequence has been observed so far, it is possible the optional blocks as noted above would appear in a similar fashion though.
+* Header block, starting at byte 20, ie. omitting the first 20 bytes (those occur before the compressed payload).
+* Passenger block, same as above.
+* Trip block, same as above.
 * At least the passenger information block described above occurs in exactly the same format in there.