Decode MPEG 2,4 AAC-LC LATM bitstream for a2dp - bluetooth

I am trying to decode bitstream that I received from Apple IPhone for bluetooth A2DP profile.
According to Apple the structure should be
The sample bitstream I have is
36 00 47 00 | 80 60 00 01 00 06 3c ab 00 00 00 00 |
47 fc 00 00 b0 90 80 03 00 20 20 66 00 01 98 00 0d e1 20 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1c
First four bytes are L2CAP, next 12 are AVDTP. But I am not able to decode rest of the bytes. Kindly help.
I have seen ISO 14496-3 that define AudioMuxElement but still I am not able to relate it to the bytes.

Recently, I've got very same problem. Since decoding bit-stream on a piece of paper is not very handy, I've created a simple decoder (for debugging purposes) based on ISO/IEC 14496-3 reference implementation.
Properly decoded stream from the question:
useSameStreamMux:1 = 0 => 0
audioMuxVersion:1 = 1 => 1
audioMuxVersionA:1 = 0 => 0
bytesForValue:2 = 00 => 0
valueTmp:8 = 11111111 => 255 (taraBufferFullness)
allStreamsSameTimeFraming:1 = 1 => 1
numSubFrames:6 = 000000 => 0
numProgram:4 = 0000 => 0
numLayer:3 = 000 => 0
bytesForValue:2 = 00 => 0
valueTmp:8 = 00010110 => 22 (ascLen)
audioObjectType:5 = 00010 => 2
samplingFrequencyIndex:4 = 0100 => 4
channelConfiguration:4 = 0010 => 2
frameLengthFlag:1 = 0 => 0
dependsOnCoreCoder:1 = 0 => 0
extensionFlag:1 = 0 => 0
fillBits:6 = 000000 => 0
frameLengthType:3 = 000 => 0
latmBufferFullness:8 = 11000000 => 192
otherDataPresent:1 = 0 => 0
crcCheckPresent:1 = 0 => 0
tmp:8 = 00100000 => 32 (MuxSlotLengthBytes)
payload:8 = 00100000 => 32
...
payload:8 = 00011100 => 28
byteAlign:0 = 0 => 0

"ISO/IEC 14496-3, Subpart 1: Main, Section 1.6: Interface to 14496-1" is the right place to look.
First look into AudioSyncStream():
AudioSyncStream()
{
while(nextbits()==0x2B7) // 11-bits
{
audioMuxLengthBytes; // 13-bit
AudioMuxElement(1); // proceed to decode AudioMuxElement
}
}
LATM should start withg 11-bit long syncword: syncword==(2B7)hex==(1010110111)bin. This does not seem to be the case with your stream: (47FC)hex==(0100011111111100)bin, first 11 bits being (01000111111)bin.

I was able to decode the header as follows:
Use same stream config = 0 (1 bit)
StreamMuxConfig():
AudioMuxVersion = 1 (1 bit)
AudioMuxVersionA = 0 (1 bit)
LATM value Temp Bytes = 00 (2 bit)
Fullness value = 1111 1111 ( 8 Bit)
AllStreamsUseSameTimeFrame = 1 (1 bit)
numSubFrames = 000000 (6 bits)
num program = 0000 (4 bits)
num layer = 000 ( 3 bits)
use same config = 0 (1 bit)
Fill + other bits = 0000 1010 0 (9 bits)
AudioSpecificConfig():
Object Type (aac) = 00010 ( 5 bits)
Sample Type = 0100 ( 4 bits)
Channel = 0010 ( 4 bits)
GAS specific config = 000 (3 bits)
Looks like I was having an older version of spec. The correct version of Spec to look for is ISO/IEC 14496-3:2005. Also there are typo errors in Apple's Bluetooth design guidelines doc (it refers to non-existent doc 13818-3:2005 !).

Related

How to read perfectly a .pcap file

Using tcpdump im trying to sniff some packets. The result is this:
reading from file /tmp/prueba.pcap, link-type LINUX_SLL (Linux cooked v1)
13:35:51.767194 IP6 fdc1:41d:9c3:dbef:a6e9:69f0:59aa:b70a.47193 > fdc1:41d:9c3:dbef:0:ff:fe00:8c00.47193: UDP, length 63
0x0000: 6000 0000 0047 1140 fdc1 041d 09c3 dbef `....G.#........
0x0010: a6e9 69f0 59aa b70a fdc1 041d 09c3 dbef ..i.Y...........
0x0020: 0000 00ff fe00 8c00 b859 b859 0047 d42e .........Y.Y.G..
0x0030: 3f0c 0000 0dc2 50f1 0d7b 2254 696d 6522 ?.....P..{"Time"
0x0040: 3a5b 3136 3632 3033 3933 3531 2c22 225d :[1662039351,""]
0x0050: 2c22 4d6f 6417 0012 320f 00f0 0352 6f6c ,"Mod...2....Rol
0x0060: 6c22 3a5b 3533 302c 2264 c2ba 225d 7d l":[530,"d.."]}
The point is in the line with address 0x0050 we can read "Mod...2". That "Mod" means "Mode" but I don't understand why is not the whole word "Mode". ¿Where is the "e"? I need to read that message perfectly for automate a program reading values from there.
I discarded a puntual problem transmiting the message because every time I sniff a packet that contain that info, the format is exactly the same.
Regards,
There are indications that the packet is not correct in other ways than a missing e. For example, the ether type is 0x09c3 and not 0x86dd (IPv6).
Maybe this code to create a PCAP file can help. Using the raw packet you provided as input the output file is bad.pcap and you could use a tool like Wireshark to examine the packet in more detail, see here
import codecs
from scapy.all import wrpcap, Ether, IP, IPv6, UDP, Raw
data = (
'60 00 00 00 00 47 11 40 fd c1 04 1d 09 c3 db ef '
'a6 e9 69 f0 59 aa b7 0a fd c1 04 1d 09 c3 db ef '
'00 00 00 ff fe 00 8c 00 b8 59 b8 59 00 47 d4 2e '
'3f 0c 00 00 0d c2 50 f1 0d 7b 22 54 69 6d 65 22 '
'3a 5b 31 36 36 32 30 33 39 33 35 31 2c 22 22 5d '
'2c 22 4d 6f 64 17 00 12 32 0f 00 f0 03 52 6f 6c '
'6c 22 3a 5b 35 33 30 2c 22 64 c2 ba 22 5d 7d' )
data_list = data.split( " " )
data_s = codecs.decode(''.join(data_list), 'hex')
packet = Raw(load=data_s)
wrpcap('bad.pcap', [packet])
data = (
'3f 0c 00 00 0d c2 50 f1 0d 7b 22 54 69 6d 65 22 '
'3a 5b 31 36 36 32 30 33 39 33 35 31 2c 22 22 5d '
'2c 22 4d 6f 64 17 00 12 32 0f 00 f0 03 52 6f 6c '
'6c 22 3a 5b 35 33 30 2c 22 64 c2 ba 22 5d 7d' )
data_list = data.split( " " )
data_s = codecs.decode(''.join(data_list), 'hex')
packet = Ether(dst="60:00:00:00:00:47", src="11:40:fd:c1:04:1d") / IPv6(dst="fdc1:41d:9c3:dbef:0:ff:fe00:8c00", src="fdc1:41d:9c3:dbef:a6e9:69f0:59aa:b70a" ) / UDP(sport=47193, dport=47193, len=0x0047 ) / Raw(load=data_s)
wrpcap('better.pcap', [packet])
The hex dump begins with the IPv6 header; the link-layer header is not being dumped, so the Ethertype that would appear in the LINKTYPE_SLL_LINUX link-layer header isn't shown.
So the header is:
6000 0000: version (6), traffic class (0), flow label (0)
0047: payload length (0x47 = 71)
1140: next header (0x11 = 17 = UDP), hop limit (0x40 = 64)
fdc1 041d 09c3 dbef a6e9 69f0 59aa b70a: source IPv6 address (fdc1:41d:9c3:dbef:a6e9:69f0:59aa:b70a)
fdc1 041d 09c3 dbef 0000 00ff fe00 8c00: destination IPv6 address (fdc1:41d:9c3:dbef:0:ff:fe00:8c00)
The next header field is 17, so what follows that is a UDP header:
b859: source port (0x5859 = 47193)
b859: destination port (0x5859 = 47193)
0047: length (0x47 = 71)
d42e: checksum
Those 71 bytes are the UDP header (8 bytes) plus the UDP payload (71 - 8 = 63 bytes).
Port 47193 is a in the "registered" port range; however, it does not appear in the current list of well-known and registered ports.
It does, however, appear, from some web searches, to be the default gateway port for MQTT-SN. MQTT "is a lightweight, publish-subscribe, machine to machine network protocol", and MQTT-SN, according to that page, "is a variation of the main protocol aimed at battery-powered embedded devices on non-TCP/IP networks".
If this is MQTT-SN, then, according to the protocol specification for MQTT-SN, the payload would be:
3f0c: length (0x3f = 63), message type (0c = PUBLISH)
00: flags (0x0000)
000d: TopicId
c250: MsgId
f1 0d7b 2254 696d 6522 3a5b 3136 3632 3033 3933 3531 2c22 225d 2c22 4d6f 6417 0012 320f 00f0 0352 6f6c 6c22 3a5b 3533 302c 2264 c2ba 225d 7d: Data
So that data is:
0xf1 0x0d {"Time":[1662039351,""],"Mod 0x17 0x00 0x12 2 0x0f 0x00 0xf0 0x03 Roll":[530,"d 0xc2 0xba "]}
If the published data is intended to be ASCII text, it appears to have been damaged; if this is from a wireless low-power network, perhaps there was radio interference.
The answer is easy... The content of the pcap packet was compressed with lz4...

Why RDATA in EDNS(0) resource record has 1 octet?

I want to understand why EDNS(0) resource records contains an extra octet? I read RFC 6891 and RFC 1035. It says nothing about case when RDLENGHT == 0 but RDATA == "\0".
To test this here python code
import binascii
import socket
def send_udp_message(message, address, port):
"""send_udp_message sends a message to UDP server
message should be a hexadecimal encoded string
"""
message = message.replace(" ", "").replace("\n", "")
server_address = (address, port)
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
try:
sock.sendto(binascii.unhexlify(message), server_address)
data, _ = sock.recvfrom(4096)
finally:
sock.close()
return binascii.hexlify(data).decode("utf-8")
def format_hex(hex):
"""format_hex returns a pretty version of a hex string"""
octets = [hex[i:i+2] for i in range(0, len(hex), 2)]
pairs = [" ".join(octets[i:i+2]) for i in range(0, len(octets), 2)]
return "\n".join(pairs)
message = "AA AA 01 00 00 01 00 00 00 00 00 01 " \
"07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 01 "
# EDNS(0) resource record
message += "00 00 " # NAME
message += "29 00 " # TYPE
message += "FF 00 00 80 " # TTL
message += "00 00 " # RDLENGTH
# message += "00" # RDATA
response = send_udp_message(message, "8.8.8.8", 53)
print(format_hex(response))
Dns query returns here error. But if uncomment RDATA line it returns success.
You misread section §6.1.2 of RFC 6891, so the RFCs are not "lies".
It says:
+------------+--------------+------------------------------+
| Field Name | Field Type | Description |
+------------+--------------+------------------------------+
| NAME | domain name | MUST be 0 (root domain) |
| TYPE | u_int16_t | OPT (41) |
| CLASS | u_int16_t | requestor's UDP payload size |
| TTL | u_int32_t | extended RCODE and flags |
| RDLEN | u_int16_t | length of all RDATA |
| RDATA | octet stream | {attribute,value} pairs |
+------------+--------------+------------------------------+
so 6 pieces of information while your code has only 5 pieces:
# EDNS(0) resource record
message += "00 00 " # NAME
message += "29 00 " # TYPE
message += "FF 00 00 80 " # TTL
message += "00 00 " # RDLENGTH
# message += "00" # RDATA
You are missing the CLASS between TYPE and TTL, hence things are not interpreted the way you think they are.
You are also misreading how the bytes work for the name.
It is not:
00 00 NAME
29 00 TYPE
FF 00 00 80 TTL
00 00 RDLENGTH
but really:
00 NAME (root domain per EDNS(0) specification, which is a sole zero)
00 29 TYPE (41, per specification)
00 FF CLASS (255, considered as payload)
00 00 80 00 TTL, read as 00 = EXTENDED-CODE, 00 = VERSION (mandatory), 80 = DO set plus everything else 0 as the final 00 byte, per specification
00 RDLENGTH
and the final item RDLENGTH is then not properly formatted per the RFC 1035 specification as it is 2 bytes (16 bits).
Once you comment your last line, RDLENGTH becomes 00 00 and then is valid.
And there is indeed no RDATA part in your message.
What you believe being a 00 value in RDATA is in fact the last byte of RDLENGTH but you did not parse the stream correctly.
Had you used dnspython as advised to you, you would have seen the problem immediately with the proper mapping of fields:
In [1]: import dns
In [2]: import dns.message
In [10]: stream = 'AA AA 01 00 00 01 00 00 00 00 00 01 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 01 00 00 29 00 FF 00 00 80 00 00 00'
In [11]: data=''.join(chr(int(x, base=16)) for x in stream.split(' '))
In [12]: m = dns.message.from_wire(data)
In [13]: print m
id 43690
opcode QUERY
rcode NOERROR
flags RD
edns 0
eflags DO
payload 255
;QUESTION
example.com. IN A
;ANSWER
;AUTHORITY
;ADDITIONAL
Had you wanted to do that you could have simulated the expected bytes stream that way:
(starting from your message)
In [31]: m = dns.message.from_wire(data)
In [32]: print m
id 43690
opcode QUERY
rcode NOERROR
flags RD
edns 0
eflags DO
payload 255
;QUESTION
example.com. IN A
;ANSWER
;AUTHORITY
;ADDITIONAL
(creating a new one to look like yours)
In [39]: mm = dns.message.make_query('example.com.', 'A', use_edns=0, payload=255, want_dnssec=True)
In [40]: mm.id=43690
In [41]: print mm
id 43690
opcode QUERY
rcode NOERROR
flags RD
edns 0
eflags DO
payload 255
;QUESTION
example.com. IN A
;ANSWER
;AUTHORITY
;ADDITIONAL
(now looking at its wire representation)
In [46]: print ' '.join(hex(ord(d)) for d in mm.to_wire())
0xaa 0xaa 0x1 0x0 0x0 0x1 0x0 0x0 0x0 0x0 0x0 0x1 0x7 0x65 0x78 0x61 0x6d 0x70 0x6c 0x65 0x3 0x63 0x6f 0x6d 0x0 0x0 0x1 0x0 0x1 0x0 0x0 0x29 0x0 0xff 0x0 0x0 0x80 0x0 0x0 0x0
Comparing with your bytestream:
dnspython: AA AA 01 00 00 01 00 00 00 00 00 01 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 01 00 00 29 00 FF 00 00 80 00 00 00
you: AA AA 01 00 00 01 00 00 00 00 00 01 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 01 00 00 29 00 FF 00 00 80 00 00
Note the missing final 00 being in your commented line.
This shows that existing good libraries, as dnspython is, really help sometimes better understanding RFCs or other specifications. And in the world of DNS there are many RFCs, sometimes conflicting between each other, with ambiguous parts, etc. So using existing libraries for tests and/or studying their source code really helps, if you want this advice.

Why "cksum" is not compute in Scapy

I wrote this code in a scapy script.
The goal is to generate ICMP v6 Request and get the checksum.
def generate_frame():
eth = Ether()
eth.dst = "00:50:56:9E:7B:BB"
eth.src = "00:50:56:9E:78:AA"
eth.type = 0x8100
ip = IPv6()
ip.src = "2002:c000:0203:0000:0000:0000:0000:00AA"
ip.dst = "2002:c000:0203:0000:0000:0000:0000:00BB"
icmp =ICMPv6EchoRequest(seq=0x1, id=0x792)
icmp.data = "test"
icmp = ICMPv6EchoRequest(icmp.do_build())
ip = IPv6(ip.do_build())
return eth/Dot1Q(vlan=0x185)/ip/icmp
frame = generate_frame()
hexdump(frame)
#frame.pdfdump(layer_shift = 1)
frame.getlayer(ICMPv6EchoRequest).show2()
print "CRC :"+ str(frame['ICMPv6EchoRequest'].cksum)
I get the result :
0000 00 50 56 9E 7B BB 00 50 56 9E 78 AA 81 00 01 85 .PV.{..PV.x.....
0010 86 DD 60 00 00 00 00 00 3B 40 20 02 C0 00 02 03 ..`.....;# .....
0020 00 00 00 00 00 00 00 00 00 AA 20 02 C0 00 02 03 .......... .....
0030 00 00 00 00 00 00 00 00 00 BB 80 00 00 00 07 92 ................
0040 00 01 74 65 73 74 ..test
###[ ICMPv6 Echo Request ]###
type = Echo Request
code = 0
cksum = 0x0
id = 0x792
seq = 0x1
data = 'test'
CRC :0
But the cksum attribute still not evaluated.
I don't understand my mistake.
Many thanks for your help
Don’t use the do_build function. It is a private function that should not be used (it is the second part of a 3-step building process).
Also, it is unnecessary to build each layer. You can just stack them and build the whole packet at the end.
To build an entire packet, call bytes() on it. Building a packet generates the checksums. A good option is to call Ether(bytes(packet)) to get the packet built
Use
def generate_frame():
eth = Ether()
eth.dst = "00:50:56:9E:7B:BB"
eth.src = "00:50:56:9E:78:AA"
eth.type = 0x8100
ip = IPv6()
ip.src = "2002:c000:0203:0000:0000:0000:0000:00AA"
ip.dst = "2002:c000:0203:0000:0000:0000:0000:00BB"
icmp =ICMPv6EchoRequest(seq=0x1, id=0x792)
icmp.data = "test"
packet = eth/Dot1Q(vlan=0x185)/ip/icmp
# Build and recalculate the whole packet
packet = Ether(bytes(packet))
return packet
It should fix your issue

EMV: Second Generate AC Results in 6985 SW_Error Access condition not satisfied

I'm doing some EMV testing, and hoping someone can shed some light on what I'm seeing. I'm running the Mastercard M-TIP tests that apply to our solution, and I'm seeing some unexpected results. When running the M-TIP 50 tests (1, 2, 3) with the M-TIP 50 test card, I'm getting errors on the 2nd GENERATE_AC command. Our solution is technically defined as offline with online capability, but we're currently testing in an entirely offline environment.
I've spent a good amount of time reading the EMV books and scouring Google, but I still don't understand why it's returning 6985. The best guess I can come up with at this point is it has something to do with CDA (which should also be happening during this process?)
I've included the 1st and 2nd GEN_AC requests and responses to show what's happening. If someone could provide insight into what's happening or what's going wrong, I would greatly appreciate it.
1st Generate AC (ARQC)
Request : 80 AE 90 00 2F 00 00 00 00 20 00 00 00 00 00 00 00 00 80 00 80 00 08 26 17 01 03 00 B0 32 0F C0 22 00 00 00 00 00 00 00 00 00 00 44 03 02 16 11 12 60 00 80
Class :80
Ins :AE
P1 :90
P2 :00
Lc :2F
Data :00 00 00 00 20 00 00 00 00 00 00 00 00 80 00 80 00 08 26 17 01 03 00 B0 32 0F C0 22 00 00 00 00 00 00 00 00 00 00 44 03 02 16 11 12 60 00 80
Tag 9F 02: Transaction Amount : 00 00 00 00 20 00
Amount value: 20.00
Tag 9F 03: Cashback Amount : 00 00 00 00 00 00
Amount value: 0.00
Tag 95 : Terminal Verification Results (TVR) : 00 80 00 80 00
Byte 1 bit 8 = 0 Offline data authentication was performed
bit 7 = 0 SDA passed or not performed
bit 6 = 0 No ICC data missing
bit 5 = 0 Card does not appear on terminal exception file
bit 4 = 0 DDA passed or not performed
bit 3 = 0 CDA passed or not performed
bit 2 = 0 SDA not selected
bit 1 = 0 RFU
Byte 2 bit 8 = 1 ICC and terminal have different application versions
bit 7 = 0 No Expired application
bit 6 = 0 Application effective
bit 5 = 0 Requested service allowed for card product
bit 4 = 0 No New card
bit 3 = 0 RFU
bit 2 = 0 RFU
bit 1 = 0 RFU
Byte 3 bit 8 = 0 Cardholder verification was successful or not performed
bit 7 = 0 Recognised CVM
bit 6 = 0 PIN Try Limit not exceeded
bit 5 = 0 No PIN entry required (PIN pad may or may not be present or may or may not be working)
bit 4 = 0 No PIN entry required (PIN pad may or may not be present)
bit 3 = 0 No Online PIN entered
bit 2 = 0 RFU
bit 1 = 0 RFU
Byte 4 bit 8 = 1 Transaction exceeds floor limit
bit 7 = 0 Lower consecutive offline limit not exceeded
bit 6 = 0 Upper consecutive offline limit not exceeded
bit 5 = 0 Transaction not selected randomly for online processing
bit 4 = 0 Merchant did not force transaction online
bit 3 = 0 RFU
bit 2 = 0 RFU
bit 1 = 0 RFU
Byte 5 bit 8 = 0 No Default TDOL used
bit 7 = 0 Issuer authentication passed or not performed
bit 6 = 0 Script processing passed before final GENERATE AC or no script received
bit 5 = 0 Script processing passed after final GENERATE AC or no script received
bit 4 = 0 RFU
bit 3 = 0 RFU
bit 2 = 0 RFU
bit 1 = 0 RFU
Tag 5F 2A: Transaction Currency Code : 08 26
Code (num) = 08 26
Code (an) = GBP
Currency = Pound Sterling
Tag 9A : Transaction Date : 17 01 03
Year : 2017
Month: January
Day : 03
Tag 9C : Transaction Type : 00
Purchase (of goods or services)
Tag 9F 37: Unpredictable Number : B0 32 0F C0
Tag 9F 35: Terminal Type : 22
Terminal Type: 22
Attended
Merchant
Offline with online capability
Tag 9F 45: Data Authentication Code : 00 00
Tag 9F 4C: ICC Dynamic Number : 00 00 00 00 00 00 00 00
Tag 9F 34: Cardholder Verification Method (CVM) Results : 44 03 02
Byte 1 bit 8 = 0 (default value)
bit 7 = 1 (Apply succeeding CVM field if this CVM is unsuccessful)
bit 6-1= 000100 (Enciphered PIN verification performed by ICC)
Byte 2 = '03' (If terminal supports the CVM type)
Byte 3 = '02' (Successful)
Tag 9F 21: Transaction Time : 16 11 12
Time = 16:11:12
Hours (HH) = 16
Minutes (MM) = 11
Seconds (SS) = 12
Tag 9F 40: Additional Terminal Capabilities : 60 00 80
Byte 1 bit 8 = 0 Cash NOT supported
bit 7 = 1 Goods supported
bit 6 = 1 Services supported
bit 5 = 0 CashBack NOT supported
bit 4 = 0 Inquiry NOT supported
bit 3 = 0 Transfer NOT supported
bit 2 = 0 Payment NOT supported
bit 1 = 0 Administrative NOT supported
Byte 2 bit 8 = 0 CashBack Deposit NOT supported
bit 7 = 0 RFU
bit 6 = 0 RFU
bit 5 = 0 RFU
bit 4 = 0 RFU
bit 3 = 0 RFU
bit 2 = 0 RFU
bit 1 = 0 RFU
Byte 3 bit 8 = 1 Numeric keys supported
bit 7 = 0 Alphabetic and special characters keys NOT supported
bit 6 = 0 Command keys NOT supported
bit 5 = 0 Function keys NOT supported
bit 4 = 0 RFU
bit 3 = 0 RFU
bit 2 = 0 RFU
bit 1 = 0 RFU
Byte 4 bit 8 = 0 Print, attendant NOT supported
bit 7 = 0 Print, cardholder NOT supported
bit 6 = 0 Display, attendant NOT supported
bit 5 = 0 Display, cardholder NOT supported
bit 4 = 0 RFU
bit 3 = 0 RFU
bit 2 = 0 Code table 10 NOT supported
bit 1 = 0 Code table 9 NOT supported
Byte 5 bit 8 = 0 Code table 8 NOT supported
bit 7 = 0 Code table 7 NOT supported
bit 6 = 0 Code table 6 NOT supported
bit 5 = 0 Code table 5 NOT supported
bit 4 = 0 Code table 4 NOT supported
bit 3 = 0 Code table 3 NOT supported
bit 2 = 0 Code table 2 NOT supported
bit 1 = 0 Code table 1 NOT supported
masterKeyAC: 9E 15 20 43 13 F7 31 8A CB 79 B9 0B D9 86 AD 29
uniqueKeyAC: 80 32 AD CE E0 B9 40 BA FB E3 5B 5B 15 9E 8F EA
MCHIP SKD Session Key Derivation
ATC: 00 08
UN: B0 32 0F C0
Cryptogram Version No.: 10
ICC Master Key AC: 9E 15 20 43 13 F7 31 8A CB 79 B9 0B D9 86 AD 29
Derived Card Unique Key: 80 32 AD CE E0 B9 40 BA FB E3 5B 5B 15 9E 8F EA
Derived Session Key: A1 00 11 56 78 15 15 85 2B 53 76 A9 18 14 AA F2
AC calculation: 00 00 00 00 20 00 00 00 00 00 00 00 00 80 00 80 00 08 26 17 01 03 00 B0 32 0F C0 79 00 00 08 A7 40 0F 04 00 00 80
Amount Authorised : 00 00 00 00 20 00
Amount Other : 00 00 00 00 00 00
Terminal Verification Results : 00 80 00 80 00
Transaction Currency Code : 08 26
Transaction Date : 17 01 03
Transaction Type : 00
Unpredictable Number : B0 32 0F C0
Application Interchange Profile : 79 00
Application Transaction Counter : 00 08
Card Verification Results : A7 40 0F 04 00 00
AC Session Key : A1 00 11 56 78 15 15 85 2B 53 76 A9 18 14 AA F2
CDA Signature Generation
Input data: E0 B8 C8 03 72 22 60 00 80 30 00 00 00 00 00 20 00 00 00 00 00 00 00 00 80 00 80 00 08 26 17 01 03 00 B0 32 0F C0 22 00 00 00 00 00 00 00 00 00 00 44 03 02 16 11 12 60 00 80 9F 27 01 80 9F 36 02 00 08 9F 10 12 02 10 A7 40 0F 04 00 00 00 00 00 00 00 00 00 00 00 FF
ICC dynamic number: 98 43 55 5A 0A C1 C2 4A
ICC private key: 1A C2 53 A6 2F FC 28 F2 CA 67 EE 9B 2C BE 16 C2 38 FB E3 C8 8B 28 4A 81 18 44 4B 6A BD 6F 68 FD F4 70 23 62 20 D1 4A 1A 11 6F E4 A8 5C 33 FE 1E 35 CD 9A 3F 48 44 13 64 A3 E9 50 58 ED 26 35 82 D3 6E FA 8E A4 EF EE A2 42 21 C5 4C 02 FB 5D C3 AE 17 97 8B D6 CE 6B 68 A2 4B 3B 13 C8 61 3A 2E 1E 0A 53 1B A1 71 AF 7E 1E FF 44 4B FF 72 50 03 89 F6 64 2F 0F 62 E4 9A 43 0C 6D F7 0C 07 EE 0D
ICC public modulus: A0 8D F5 E5 1F E8 F5 B0 BE 6F 97 A3 0C 74 88 8D 55 E7 56 B3 42 F1 BF 06 91 99 C4 80 70 9C 75 F3 BA A0 D4 4C C4 E7 BC 9C 68 9F 5B F2 29 37 F4 B5 42 D1 9D 7B B1 98 74 5B D7 77 E2 15 8E E5 41 12 8A 15 8E 73 6A 88 4B 82 C5 21 61 6E F0 6F 8D 26 7C 07 B1 EF 79 8A B5 77 AA A3 C6 DD 89 37 C9 B2 34 4C EC AD 5A B8 D5 29 BC AC A7 F9 EC EA DE 85 99 0F 1E 04 FE AE 9F A0 33 DF 69 12 68 F9 F2 D5
Terminal unpredictable number: B0 32 0F C0
Signature: 89 A6 C6 A0 AD 68 43 14 03 EE 4E 92 4B A8 CE B0 ED D9 F2 23 9A AB C9 90 D6 67 FD D5 B4 FF FC 98 99 AB 66 A7 10 0D 5B EB EE 36 7C 36 79 2D A2 A2 92 11 A2 0C 00 71 86 4B BE 20 BA 44 57 73 E5 0C 2D FB 17 AA DE 5C 85 8B 19 66 B8 F3 40 E0 00 EB BF 10 8B 1C AE 91 BD D0 DC 0C D3 D5 40 85 42 72 B0 E2 2F 30 D5 B5 EA 61 29 C9 9F 4F 39 F3 EE BC 66 06 F7 60 11 4D D6 DB 57 CF 57 F6 C1 EF 8C 35
Signed Dynamic Authentication Data
Evaluated: 6A 05 01 26 08 98 43 55 5A 0A C1 C2 4A 80 EC 19 0A DB E4 1C 90 B0 AA 00 A2 EC B5 50 A9 54 A9 92 00 1E CA 05 21 B1 DD 13 98 ED BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB 8E 73 0F 77 06 61 76 D4 6A 68 EF 7A 9C 45 23 0C 9A 62 43 C6 BC
RecoveredDataHeader '6A'h
DynamicApplicationData_for_signature '05 01 26 08 98 43 55 5A 0A C1 C2 4A 80 EC 19 0A DB E4 1C 90 B0 AA 00 A2 EC B5 50 A9 54 A9 92 00 1E CA 05 21 B1 DD 13 98 ED BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB'h structure
SignedDataFormat '05'h
HashAlgorithmIndicator '01'h
ICCDynamicDataLength 38
ICCDynamicData '08 98 43 55 5A 0A C1 C2 4A 80 EC 19 0A DB E4 1C 90 B0 AA 00 A2 EC B5 50 A9 54 A9 92 00 1E CA 05 21 B1 DD 13 98 ED'h
PadPattern 'BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB'h
HashResult '8E 73 0F 77 06 61 76 D4 6A 68 EF 7A 9C 45 23 0C 9A 62 43 C6'h
RecoveredDataTrailer 'BC'h
Expected: 6A 05 01 .. .. .. .. BC
RecoveredDataHeader '6A'h
DynamicApplicationData_for_signature 05 01 .. .. .. structure
SignedDataFormat '05'h
HashAlgorithmIndicator '01'h
ICCDynamicDataLength Length(ICCDynamicData)
ICCDynamicData .. concatenation
QS{0-}
''h
PadPattern .. concatenation
QS {..}
''h
HashResult .. concatenation
QS{1-}
''h
RecoveredDataTrailer 'BC'h
Previous Transaction History
Response: 61 A5
SW1 SW2: 61 A5 (SW_OK Response bytes available(Le))
Get Response
Request : 00 C0 00 00 A5
Class :00
Ins :C0
P1 :00
P2 :00
Le :A5
Response: C0 77 81 A2 9F 27 01 80 9F 36 02 00 08 9F 4B 81 80 89 A6 C6 A0 AD 68 43 14 03 EE 4E 92 4B A8 CE B0 ED D9 F2 23 9A AB C9 90 D6 67 FD D5 B4 FF FC 98 99 AB 66 A7 10 0D 5B EB EE 36 7C 36 79 2D A2 A2 92 11 A2 0C 00 71 86 4B BE 20 BA 44 57 73 E5 0C 2D FB 17 AA DE 5C 85 8B 19 66 B8 F3 40 E0 00 EB BF 10 8B 1C AE 91 BD D0 DC 0C D3 D5 40 85 42 72 B0 E2 2F 30 D5 B5 EA 61 29 C9 9F 4F 39 F3 EE BC 66 06 F7 60 11 4D D6 DB 57 CF 57 F6 C1 EF 8C 35 9F 10 12 02 10 A7 40 0F 04 00 00 00 00 00 00 00 00 00 00 00 FF 90 00
Ack Byte : C0
Data : 77 81 A2 9F 27 01 80 9F 36 02 00 08 9F 4B 81 80 89 A6 C6 A0 AD 68 43 14 03 EE 4E 92 4B A8 CE B0 ED D9 F2 23 9A AB C9 90 D6 67 FD D5 B4 FF FC 98 99 AB 66 A7 10 0D 5B EB EE 36 7C 36 79 2D A2 A2 92 11 A2 0C 00 71 86 4B BE 20 BA 44 57 73 E5 0C 2D FB 17 AA DE 5C 85 8B 19 66 B8 F3 40 E0 00 EB BF 10 8B 1C AE 91 BD D0 DC 0C D3 D5 40 85 42 72 B0 E2 2F 30 D5 B5 EA 61 29 C9 9F 4F 39 F3 EE BC 66 06 F7 60 11 4D D6 DB 57 CF 57 F6 C1 EF 8C 35 9F 10 12 02 10 A7 40 0F 04 00 00 00 00 00 00 00 00 00 00 00 FF
Tag 77 : Response Message Template Format 2
Tag 9F 27: Cryptogram Information Data (CID) : 80
Byte 1 bit 8-7 = 10 ARQC
bit 6-5 = 00 Payment System specific cryptogram
bit 4 = 0 No advice required
bit 3-1 = 000 No information given
Tag 9F 36: Application Transaction Counter (ATC) : 00 08
Decimal value = 8
Tag 9F 4B: Signed Dynamic Application Data : 89 A6 C6 A0 AD 68 43 14 03 EE 4E 92 4B A8 CE B0 ED D9 F2 23 9A AB C9 90 D6 67 FD D5 B4 FF FC 98 99 AB 66 A7 10 0D 5B EB EE 36 7C 36 79 2D A2 A2 92 11 A2 0C 00 71 86 4B BE 20 BA 44 57 73 E5 0C 2D FB 17 AA DE 5C 85 8B 19 66 B8 F3 40 E0 00 EB BF 10 8B 1C AE 91 BD D0 DC 0C D3 D5 40 85 42 72 B0 E2 2F 30 D5 B5 EA 61 29 C9 9F 4F 39 F3 EE BC 66 06 F7 60 11 4D D6 DB 57 CF 57 F6 C1 EF 8C 35
Tag 9F 10: Issuer Application Data [M/Chip 4] : 02 10 A7 40 0F 04 00 00 00 00 00 00 00 00 00 00 00 FF
Key Derivation Index = 02
Cryptogram Version Number = 10
Card Verification Results (CVR) = A7 40 0F 04 00 00
Byte 1 bit 8-7 = 10 AC Returned in Second Generate AC: Not requested
bit 6-5 = 10 AC Returned in First Generate AC: ARQC
bit 4 = 0 RFU
bit 3 = 1 Offline PIN Verification Performed
bit 2 = 1 Offline Encrypted PIN Verification Performed
bit 1 = 1 Offline PIN Verification Successful
Byte 2 bit 8 = 0 DDA not returned
bit 7 = 1 M/Chip Select 4: Combined DDA/AC Generation Returned in First Generate AC, M/Chip Lite 4: Value not allowed
bit 6 = 0 Combined DDA/AC Generation Not Returned in Second Generate AC
bit 5 = 0 Issuer Authentication not performed
bit 4 = 0 CIAC-Default not skipped on CAT3 or not required
bit 3 = 0 RFU
bit 2 = 0 RFU
bit 1 = 0 RFU
Byte 3 bit 8-5 = 0000 Right nibble of Script Counter : '0'
bit 4-1 = 1111 Right nibble of PIN Try Counter: 'F'
Byte 4 bit 8 = 0 RFU
bit 7 = 0 Unable To Go Online Not Indicated
bit 6 = 0 Offline PIN Verification Performed
bit 5 = 0 No Failure OF Offline PIN Verification
bit 4 = 0 PTL Not Exceeded
bit 3 = 1 International Transaction
bit 2 = 0 International Transaction
bit 1 = 0 Terminal Does Not Erroneously Consider Offline PIN OK
Byte 5 bit 8 = 0 Lower Consecutive Offline Limit Not Exceeded
bit 7 = 0 Upper Consecutive Offline Limit Not Exceeded
bit 6 = 0 Lower Cumulative Offline Limit Not Exceeded
bit 5 = 0 Upper Cumulative Offline Limit Not Exceeded
bit 4 = 0 Go Online On Next Transaction Was Not Set (in this transaction or in a previous one)
bit 3 = 0 No Issuer Authentication Failed (in this transaction or in a previous one)
bit 2 = 0 No Script Received (in a previous transaction)
bit 1 = 0 No Script Failed (in a previous transaction)
Byte 6 bit 8 = 0 RFU
bit 7 = 0 RFU
bit 6 = 0 RFU
bit 5 = 0 RFU
bit 4 = 0 RFU
bit 3 = 0 RFU
bit 2 = 0 No Match found in Additional Check Table
bit 1 = 0 Match Found in Additional Check Table
DAC = 00 00
Counters = 00 00 00 00 00 00 00 FF
SW1 SW2 : 90 00 (SW_OK)
2nd Generate AC (TC)
Request : 80 AE 50 00 23 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 59 33 00 80 00 80 00 B0 32 0F C0 98 43 55 5A 0A C1 C2 4A
Class :80
Ins :AE
P1 :50
P2 :00
Lc :23
Data :00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 59 33 00 80 00 80 00 B0 32 0F C0 98 43 55 5A 0A C1 C2 4A
Tag 91 : Issuer Authentication Data [M/Chip] : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Tag 8A : Authorization Response Code : 59 33
Response Code = 59 33
Meaning = Unable to go online, Requesting for offline approval
Tag 95 : Terminal Verification Results (TVR) : 00 80 00 80 00
Byte 1 bit 8 = 0 Offline data authentication was performed
bit 7 = 0 SDA passed or not performed
bit 6 = 0 No ICC data missing
bit 5 = 0 Card does not appear on terminal exception file
bit 4 = 0 DDA passed or not performed
bit 3 = 0 CDA passed or not performed
bit 2 = 0 SDA not selected
bit 1 = 0 RFU
Byte 2 bit 8 = 1 ICC and terminal have different application versions
bit 7 = 0 No Expired application
bit 6 = 0 Application effective
bit 5 = 0 Requested service allowed for card product
bit 4 = 0 No New card
bit 3 = 0 RFU
bit 2 = 0 RFU
bit 1 = 0 RFU
Byte 3 bit 8 = 0 Cardholder verification was successful or not performed
bit 7 = 0 Recognised CVM
bit 6 = 0 PIN Try Limit not exceeded
bit 5 = 0 No PIN entry required (PIN pad may or may not be present or may or may not be working)
bit 4 = 0 No PIN entry required (PIN pad may or may not be present)
bit 3 = 0 No Online PIN entered
bit 2 = 0 RFU
bit 1 = 0 RFU
Byte 4 bit 8 = 1 Transaction exceeds floor limit
bit 7 = 0 Lower consecutive offline limit not exceeded
bit 6 = 0 Upper consecutive offline limit not exceeded
bit 5 = 0 Transaction not selected randomly for online processing
bit 4 = 0 Merchant did not force transaction online
bit 3 = 0 RFU
bit 2 = 0 RFU
bit 1 = 0 RFU
Byte 5 bit 8 = 0 No Default TDOL used
bit 7 = 0 Issuer authentication passed or not performed
bit 6 = 0 Script processing passed before final GENERATE AC or no script received
bit 5 = 0 Script processing passed after final GENERATE AC or no script received
bit 4 = 0 RFU
bit 3 = 0 RFU
bit 2 = 0 RFU
bit 1 = 0 RFU
Tag 9F 37: Unpredictable Number : B0 32 0F C0
Tag 9F 4C: ICC Dynamic Number : 98 43 55 5A 0A C1 C2 4A
Previous Transaction History
Response: 69 85
SW1 SW2: 69 85 (SW_Error Accesscondition not satisfied)
Test Completed
It seems like you did a lot of "Offline approval" without clear counters.
There are several possible reasons in your case for 6985:
1) AC Session Key Counter Limit Exceeded
Because response code in Second Generate AC is "Unable to go online, Requesting for offline approval" card goes Offline, therefore CTR accumulates and is not reset (it reset only then Online in Generate AC 2).
Try to personalize increased limits or do full Online.
2) Overflow during the amount conversion, if transaction International
(transaction currency != CRM currency Code).
Required full Online
3) Overflow during add the cumulative amount, if transaction Domestic (transaction currency == CRM currency Code).
Required full Onlinе
also, check why "Country code" is absent in Cdol1
I got some help from my test tool's support system. Their response helped explain this scenario:
Response 1:
"The transaction amount in your test cases M-TIP 50 test1, test2, and test 3 are all above the floor limit, so the transactions are supposed to go online. However, due to your test environment is offline, the transactions can not be processed online. I can see the issuer authentication data in the 2nd generate AC are all 0s (They are not returned by the issuer, but the default value set by the terminal). The card validate the authentication data to see if the data is returned by the issuer. In your case, the validation is failed and the card returns "69 85"."
Response 2:
"The MTIP50 test cases are a little special. The issuer authentication data for MTIP50 test cases is 16 bytes which is different than the normal value (10 bytes). Thus BTT has extra checks on the issuer authentication data of MTIP50. Since the issuer authentication data are all zeros in your case, the simulated card thinks they are not valid."
Resolution:
Turns out this was an issue with the testing tool I was using. They recently released a new version of their software and this no longer happens.

What are those 32 bits near the start of a FLAC file?

I am trying to write a parser to extract information from the following FLAC file:
$ hd audio.flac | head -n 6
00000000 66 4c 61 43 00 00 00 22 12 00 12 00 00 00 00 00 |fLaC..."........|
00000010 00 00 0a c4 42 f0 00 78 9f 30 00 00 00 00 00 00 |....B..x.0......|
00000020 00 00 00 00 00 00 00 00 00 00 84 00 02 64 1f 00 |.............d..|
00000030 00 00 47 53 74 72 65 61 6d 65 72 20 65 6e 63 6f |..GStreamer enco|
00000040 64 65 64 20 76 6f 72 62 69 73 63 6f 6d 6d 65 6e |ded vorbiscommen|
00000050 74 10 00 00 00 12 00 00 00 54 49 54 4c 45 3d 52 |t........TITLE=R|
Now, according to the specification, the format should be as follow (numbers are in bits):
<32> "fLaC", the FLAC stream marker in ASCII
<16> The minimum block size (in samples) used in the stream.
<16> The maximum block size (in samples) used in the stream.
<24> The minimum frame size (in bytes) used in the stream.
<24> The maximum frame size (in bytes) used in the stream.
<20> Sample rate in Hz.
<3> (number of channels)-1. FLAC supports from 1 to 8 channels
<5> (bits per sample)-1. FLAC supports from 4 to 32 bits per sample.
<36> Total samples in stream.
<128> MD5 signature of the unencoded audio data.
So, I start to write my parser and, while testing, get very strange results. So I test with a "real" metadata extractor:
$ metaflac --list audio.flac
METADATA block #0
type: 0 (STREAMINFO)
is last: false
length: 34
minimum blocksize: 4608 samples
maximum blocksize: 4608 samples
minimum framesize: 0 bytes
maximum framesize: 0 bytes
sample_rate: 44100 Hz
channels: 2
bits-per-sample: 16
total samples: 7905072
MD5 signature: 00000000000000000000000000000000
From the numbers, I can deduce the following:
66 4c 61 43 00 00 00 22 12 00 12 00 00 00 00 00
~~~~~~~~~~~ ~~~~~~~~~~~ ~~~~~ ~~~~~ ~~~~~~~~ ~~
^ ^ ^ ^ ^ ^
| | | | | |
| | | | | + Etc.
| | | | + Minimum frame size
| | | + Maximum block size
| | + Minimum block size
| + What is that ?!?
+ FLAC stream marker
Where does those 32 bits come from? I see they represent the length of the header, but isn't it against the standard to put it there (Taking into account that we already know the length: (32+16+16+24+20+3+5+36+128)/8)?
The 0x22 (34) is indeed the header block size in bytes as part of the METADATA_BLOCK_HEADER which follows the fLaC marker in the stream. Of the first 8 bits (00), bit 7 indicates that there are more metadatablocks to follow, the next 7 bits indicate that it's a STREAMINFO block. The following 3 bytes (00 00 22) is the length of the contents of the block;
16 + 16 + 24 + 24 + 20 + 3 + 5 + 36 + 128 = 272 bits
272 bits / 8 = 34 (0x22) bytes.

Resources