I am trying to publish multiple ble advertisements in a UWP app in c#. I can add 2 manufactor data to one publisher and those will be transmitted. However if I want to publish more the data is not possible. Is this even possible?
Sample code so far:
var publisher = new BluetoothLEAdvertisementPublisher();
publisher.Advertisement.ManufacturerData.Add(CreateData("Test");
publisher.Advertisement.ManufacturerData.Add(CreateData("AnotherTest");
publisher.start();
BluetoothLEManufacturerData CreateData(string data)
{
var dataWriter = new DataWriter();
dataWriter.WriteInt32(data.Length);
dataWriter.WriteString(data);
return new BluetoothLEManufacturerData(0xFFFE, dataWriter.DetachBuffer());
}
Tried to add another manufactor data, but I get an exception
Tried multiple bluetooth adapters but windows don't seem to start the second adapter.
Also tried multiple Windows.Devices.Bluetooth.Advertisement.BluetoothLEAdvertisementPublisher but that also does not do the trick
We can put multiple manufacturer data in one BluetoothLE Advertisement. However, please note that the max length of an advertisement payload is 31 bytes.
Ref ADVERTISING AND SCAN RESPONSE DATA FORMAT (BLUETOOTH SPECIFICATION Version 4.0 [Vol 3] Page 375 )
The format of Advertising data and Scan Response data is shown in Figure
11.1. The data consists of a significant part and a non-significant part. The
significant part contains a sequence of AD structures. Each AD structure shall
have a Length field of one octet, which contains the Length value, and a Data
field of Length octets. The first octet of the Data field contains the AD type field. The content of the remaining Length - 1 octet in the Data field depends on the value of the AD type field and is called the AD data. The non-significant part extends the Advertising and Scan Response data when necessary and shall
contain all-zero octets.
BluetoothLEManufacturerData is one of these AD structures which AD Type is 0xFF.
For your first manufacturer data CreateData("Test"), its length is 1 (Lenght) + 1 (Type) + 2 (Company Id) + 8 (Your specific data), which is 12 bytes. And for the second manufacturer data, its length is 19 (1+1+2+15) bytes. With these two manufacturer data, the advertisement payload has already been 31 bytes. That's why you get an exception, when you try to add another manufacturer data. Actually, if you add one character in your date, for example using CreateData("Test=") instead of CreateData("Test"), you will also get the Invalid advertisement payload detected error.
So please make sure that the buffer length can fit within an advertisement payload. You can put multiple manufacturer data as long as its length is less than 31 bytes.
var publisher = new BluetoothLEAdvertisementPublisher();
publisher.Advertisement.ManufacturerData.Add(CreateData("T"));
publisher.Advertisement.ManufacturerData.Add(CreateData("A"));
publisher.Advertisement.ManufacturerData.Add(CreateData("S"));
publisher.start();
Related
I'm new to Pcapng files. I've read the 40+ page whitepaper and I'm still scratching my head and sweating. I understand that the Pcapng file is:
Made up of a Section Header Block - This is the start of every Pcapng file.
Question 1: How large is this?
It appears that it's BlockType (4 Bytes) + BlockTotalLength (4 bytes) + Byte Order Magic (4 Bytes) + Mahor and Minor Version (4 bytes total, 2 bytes each) + Section Length (4 bytes) + Options (Variable) + Block Total length (again, 4 bytes).
If I'm building a parser, how would I know how many bytes I need to skip to arrive at my first data frame block?
Question 2: Where is the data stored? By data I mean the entire frame that contains Ethernet, IP, and TCP Data, as shown in the picture below (Figure 1).
The documentation states that:
A section includes data delimited by two section header blocks.
When doing a manual inspection (yes, I went byte by byte over a file to see how many bytes lie in between two frames :'( ), I noticed there were 35 bytes in between each message (each message shown on wireshark had 35 bytes in between). Are these bytes related to a pcapng block?
Once I understand how to get to the first tcp frame, and how many bytes I need to skip to get to the next, I can build my parser.
I'm willing to send Bitcoin/Monero to anyone who can help me understand how I can best parse these pcapng messages. Thanks!
If I'm building a parser, how would I know how many bytes I need to skip to arrive at my first data frame block?
That's not how you do it.
If you're building a parser, note that a parser must look at more than just the first data frame block.
First of all, it must look at the Section Header Block (SHB), to determine the byte order of the data in all the subsequent blocks by looking at the Byte-Order Magic field.
After that, you need to look at all subsequent blocks, looking for Interface Description Blocks and Enhanced Packet Blocks (EPBs), Simple Packet Blocks (SPBs), and possibly Packet Blocks (PBs) (those are obsolete, so no program should write them, but programs should be prepared to read them). Each EPB or PB has an interface ID that refers to an IDB, which must have appeared before the EPB or PB in question; an SPB implicitly refers to the first IDB, which, again, must have appeared before the SPB in question.
The format of the packet data in an EPB, SPB, or PB depends on the link-layer type specified by the IDB to which it refers, so you need to have read the IDB in question.
And, as the above indicates, there is no fixed number of bytes between the SHB and the first EPB, SPB, or PB, so there is no simple fixed number of bytes to skip to get to the first data frame block. For one thing, there's a variable number of bytes, which you can only determine by reading all the blocks before the first EPB, SPB, or PB. For another thing, you can't skip them, you have to read them to get enough information to interpret the packet data in them.
Where is the data stored? By data I mean the entire frame that contains Ethernet, IP, and TCP Data, as shown in the picture below (Figure 1).
It's stored in EPBs, SPBs, or PBs. See the descriptions of those three block types; frames are in the "Packet Data" fields of those blocks.
So I'm at my Interface Description Block and the 64 bit number that contains both a Timestamp Resolution of 9 (10^-9, Nanoseconds?) and 6 (10^-6, Microseconds).
As Christopher Maynard indicated, the 9 isn't a timestamp resolution, it's an option type. Pcapng blocks have both fixed information at the beginning and options; an option begins with an option type and option value length, followed by the option data. An IDB if_tsresol option has
2 bytes of option type, with the value 9;
2 bytes of option value length, with the value 1;
1 byte of option value, with the value as specified in the description of that option.
A value of 6 means the time stamp resolution is 1/10^6 of a second, which means 1 microsecond.
I think #tee-zad-awk found an answer that helped over at https://ask.wireshark.org/question/15159/how-can-i-display-as-much-pcapng-information-as-possible/, but for the benefit of anyone else looking for an answer to this question, I've linked it here and have provided my answer below, just in case the link is ever broken someday.
It seems that, after reading the 40 page whitepaper on Pcapng ...
The current PCAP Next Generation (pcapng) Capture File Format draft document is 52 pages, so perhaps you're not looking at the most recent version? Other versions do exist, such as those at https://datatracker.ietf.org/doc/html/draft-tuexen-opswg-pcapng-00, https://pcapng.github.io/pcapng/ or https://www.tcpdump.org/pcap/pcap.html and probably others, but they're all obsolete.
If you're looking for a pcapng parser to help you decipher the file, then look no further than Wireshark itself. If you've loaded a pcapng file into Wireshark, you can use "View -> Reload as File Format/Capture" (Ctrl+Shift+F) to cause Wireshark to load and display the raw file contents itself rather than to load and display the packets from the file. This should cause you to be able to see the various pcapng blocks and be able to drill down into them. For example:
Frame 1: 184 bytes on wire (1472 bits), 184 bytes captured (1472 bits)
MIME file
PCAPNG File Format
Block: Section Header Block 1
Block: Interface Description Block 0
Block: Enhanced Packet Block 1
You can also have a look at the Wireshark source code, such as the epan/dissectors/file-pcapng.c and wiretap/pcapng.c files.
By the way, if you're looking to support all extensions, the Wireshark [PcapNg wiki page] (https://wiki.wireshark.org/Development/PcapNg) has a link to Augmented PCAP Next Generation Dump File Format page that you might also want to take a look at. I don't know how many other extensions may have been implemented but not included in the main pcapng file format specification, but hopefully not many, as this could quickly become problematic with different projects possibly using the same block type for different blocks. That practice should be highly discouraged.
In order to find it out, it is helpful to read the specifications of the protocol of the network device and the package that has been sent. For example, we need to know the frame description of an Ethernet device and the package description of a TCP/IP package in order to understand the raw data. Having studied this, we record some traffic in Wireshark and select a block in the upper window of Wireshark. The middle window will tell you in clear text what Wireshark has received. On clicking on any of the lines in the middle window, Wireshark will mark the bytes of the raw data in the lower window that bear the information of the clicked line. Also, you can click on the raw data and then the clear text is marked. Moreover, the status line also informs you about it. This is very helpful for understanding the data.
I needed to read the TCP / IPv4 packages of Ethernet traffic. The block starts with the identification block type = 0x00000006 and the length of the block. The device was Ethernet so that I had the link type LINKTYPE_ETHERNET. The section length can be taken from byte 16-23. The other entries of the block header can be taken from here.
After the block header or after 28 bytes , the Ethernet frame came with the following entries (see here for a description):
mac address destination, 6 bytes
mac address source, 6 bytes
type: 0x0800 for IPv4, 0x0806 for ARP, 0x86DD for IPv6, 0x8100 for the presence of an IEEE 802.1Q tag.
For an IPv4 package or type = 0x0800, the following bytes are the IPv4 header (see here for a description):
IP version and header length, 1 byte
differentiated services field, 1 byte
total length, 2 bytes
identification, 2 bytes
flags, 1 byte
fragment offset, 1 byte
time to live, 1 byte
protocol with 0x06 for TCP, 1 byte
header checksum, 2 bytes
source IP address
destination IP address
options
The total length is very important: the byte that follows the last byte of the IPv4 + TCP package is located at total length bytes after the entry IP version and header length. However, this entry can be tricky. I head an entry with length 0 though the IP header length already had 20 bytes. In this case, Wireshark was helpful. It reported
[Total Length: 1547 bytes (reported as 0, presumed to be because of "TCP segmentation offload" (TSO))]
A detailed description of this phenomenon can be taken from here. In this case I could compute the payload length by the section length from above minus the length of the Ethernet frame (14 bytes) minus the length of the IP Header minus the length of the TCP header. However, padding problems could arise though I did not have these problems. A padding problem occurs when the package length is extended to a multiple of 4 bytes or something.
If the protocol of the IPv4 header is 0x06, the TCP package follows. The details of an TCP package can be taken from here. Of course, Wireshark also helps you interpreting the TCP package: just click on the lines in the middle window that belong to the TCP package or click on the raw data.
As outlined here, the interpretation of a pcapng file has many ifs and whens.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I am trying to build an application to read/encode data on Cards, information like PAN, expiry, customer name, PIN etc, So far I could figure out that I need to send APDU commands to read data from Card but there seems to be no clear documentation available as to what commands are used for what purpose and in what particular sequence, I couldn't find out specifications from Mastercard/VISA. Is there some documentation that can be referred to?
Thanks,
Null
Extending the other answer:
SELECT PSE:
T-->C - 00A404000E315041592E5359532E444446303100 # select PSE
T<--C - response with FCI
T-->C - 00B2010C00
T<--C - reponse with record from selected file, read records starting from 1 until receive 6A83 (optional step in your case)
SELECT application DF with AID received in step 1):
T-->C - 00A4040007A000000003101000 # as example, Visa AID
T<--C - response with application DF FCI
GET PROCESSING OPTIONS - initialize transaction:
T-->C - 80A8000002830000 # check if PDOL presents on card, if not, only 8300 should be added to DATA filed of APDU
T<--C - 771282023C00940C0802020010010300180102019000 # just example reswponse, it will differ on different cards
The response on GET PROCESSING OPTIONS above is TLV encoded:
77 12 - response templait, containing response data
82 02 3C00 - AUC
94 0C 080202001001030018010201 - AFL
9000 - SW (Status Word), response ofapplication, telling you, that no errors occured
Note, that response to GET PROCESSING OPTIONS may be returned as 80 template, in that case, you must parse it yourelf:
80 0E - response templait, containing response data
3C00 - AUC (always 2 bytes long)
080202001001030018010201 - AFL
9000 - SW (Status Word), response ofapplication, telling you, that no errors
You are interesting in AFL, which points you, where to read data from (files and record numbers):
94 0C
08020200
08 - SFI (Short File Identifier)
02 - first record in file
02 - last record in file
00 - no of records to be added to Static Data Authentication
10010300
10 - SFI
01 - first record in file
03 - last record in file (respectively, 3 records to be read - 01, 02, 03)
00 - no of records to be added to Static Data Authentication
18010201
18 - SFI
01 - first record in file
03 - last record of file
01 - count of records from first record to be used for Static Data Authentication (01 record must be used)
SFI is encoded as follows:
08 = 0000 1000 - first 5 bits are real SFI, it equals to 01, last 3 bits are always set to 0
READ APPLICATION DATA - for precize READ APPLICATION DATA command coding check 3rd EMV Book:
T-->C - 00B2020C00 # SFI = 01, record = 02
T<--C - response with record
T-->C - 00B2021400 # SFI = 02, record = 01
T<--C - response with record
T-->C - 00B2031400 # SFI = 02, record = 02
T<--C - response with record
etc until you process last AFL record...
PAN, expiry, effective date, track 2 equivalent data, etc... usually is located in records which are set to be used in Sighed Data Authentication in AFL.
The example above is for T=1 protocol. If card runs T=0 protocol, in response to each APDU which assumes R-APDU (Response APDU) to contain Data field, card will return byte count ready to be read and you should issue GET RESPONSE commands which is described in Book 1 of EMV specification.
Hope it helps.
You must check EMV ICC card specifications to understand, how to read data from ICC, specifications are freely available to download. Specification is splitted into 4 parts (4 books). You are interested in 1st and 3rd books to read application.
The sequence of APDUs to read application data is the following:
1) SELECT PSE (Payment System Environment file), it contains a list of Application DFs installed on smart card. DFs are named by AID (Application ID), which you will use to create a list of available applications (candidate list) for selection, if you want it, or just find AID with the most less Application Priority Indicator (check EMV Book 1 for more information). This is optional step, you can start from step 2) and try to select both Visa and MasterCard AIDs to check which of them is available on ICC.
2) SELECT application which you want to run using correct AID from list you have got in step 1). AIDs of Visa and MasterCard:
A0000000041010 - MasterCard
A0000000031010 - Visa
It will return FCI (File Control Information) of Application file and make Application SELECTED on ICC itself (Check EMV Book 1 for more information).
3) GET PROCESSING OPTIONS - initiate transaction on ICC. This APDU increments ATC (Application Transaction Counter) and returns AUC (Application Usage Control) and AFL (Application File Locator), which must be used to read data you need (Check EMV Book 3 for info).
4) READ APPLICATION DATA - using AFL returned in 3) you can read Application data. AFL is constructed from several parts: containing information about file (SFI - Short File Identifier), first record number, last record number and count of records used in Signed Data Authentication:
1st byte - SFI
2nd byte - First record ID
3rd byte - Last record ID
4th byte - Count of records in file to be used in Signing Data Authentication
It contains 4 byte long information on every file with records to be read during transaction. Just run over AFL and read records from every SFI from first to last records, that is all (consult book 3 for more information).
You will be unable to read PIN from card, PIN is personalized in records, which are not available to read from outside. ICC uses PIN only inside using VERIFY command, and ICC just returns PIN verification result and PIN try counter if PIN was wrong.
EMV Book 1,also, describes 2 used data transmission protocols, T=0 and T=1. To work with ICCs it is essential to understand a difference between these protocols.
Each step above starts from APDU name to make you easier find information into EMV Books 1 and 3.
To encode data to different card - it is completely different story. You should check EMV CPS (Common Personalization Specification) and GlobalPlatorm specifications. Personalization process is much more complex.
I am in the process of developing a MDB software in C# as a payment reader media that communicates with a vending machine through MDB protocol. Currently everything works OK and i am able to communicate with the vending machine. The communication is like expected after reading the MDB protocol but i am having trouble understanding some commands/respones...
I just have one question regarding a response i should send back to the vending machine that may be really stupid, but i really don't understand how it should be sent.
As shown in the MDB protocol, when i get a POLL from the MDB machine and the state of the reader (my computer) is "Session Idle", i can then send a "Begin Session" command to the vending machine. The commands are sent in bytes over serial port and are shown as HEX or Binary in the MDB protocoll. The BEGIN SESSION command should contain the following:
Z1 Begin Session
Z2-Z3 Funds Available
Z4-Z7 Payment media ID
Z8 Payment Type
Z9-Z10 Payment Data
I understand Z1-Z7 because of good examples in the MDB protocol, but i am having trouble understanding Z8-Z10 (payment type and payment data).. The examples are not self explained in my head..
The MDB protocol says the following:
""""""""""""""""""""""""""""""""""""""""""""""""""""""""
Z8 : Type of payment:
00xxxxxxb = normal vend card (refer EVA-DTS Standard, Appendix A.1.1 Definitions)
x1xxxxxxb = test media
1xxxxxxxb = free vend card
xx000000b -0 VMC default prices
xx000001b -1 User Group (Z9 = EVA-DTS Element DA701)
Price list number (Z10 = EVA-DTS Element LA101)*
xx000010b
-2 User Group (Z9 = EVA-DTS Element DA701)
Discount group index (Z10 = EVA-DTS Element MA403)
xx000011b
-3 Discount percentage factor (Z9=00, Z10 = 0 to 100**,
report as positive value in EVA-DTS Element MA404)
xx000100b
-4 Surcharge percentage factor (Z9=00, Z10 = 0 to 100**,
report as negative value in EVA-DTS Element MA404)
* User Group is a segmentation of all authorized users.
It allows selective cost allocation.
A User Group usually has no direct relation to a price list.
Price Lists are tables of prices.
Each Price List contains an individual price for each product.
Discount Group indicates the Price List on which the Percentage Factor will be applied.
If the User Group, the Price List or Discount Group is unknown by the VMC,
the normal prices are used (Z8 is defaulted to 00h).
Minimum value for Z9 and Z10 is 0.
** Percentages are expressed in binary (00 to 64h)
Note: These functions may NOT be supported by all VMCs.
Z9-Z10 : Payment data as defined above
""""""""""""""""""""""""""""""""""""""""""""""""""""""""
Can somebody please tell me how Z8 and Z9-Z10 should be sent to the vending machine. Now i have been sending (in hex): "0x02 (Z8), 0x10 (Z9) and 0x10 (Z10)" which is just a wild guess and it is working. Don't really know why but its probably not correct.
How should Z8 and Z9-Z10 be sent?
The EVA-DTS standard is its own separate standard.
MDB-ICP is a communication protocol.
EVA-DTS is a data format standard.
MDB optionally (keyword optionally) uses/integrates EVA-DTS data, which is what its asking for here.
EVA-DTS data is human readable values in ascii text/numbers separated by asterixes in a defined order and length. Each unit of data between an asterisk, is called a data element.
Z9 in options 1&2, refers to data element DA701, where if you look in Appendix A of the EVA-DTS-6.2.2 standard, the DA701 has the element name "Cashless1 user group number", which is of data type N0 meaning a number without any implied decimal points, a minimum length of 1 digit and a maximum of 13. In MDB, isn't sent as an ASCII string of characters like "15", instead, you use hexadeximal numerical representations, so usergroup 15 would be 0x0F. The usergroup if not using it,you can just put 0x01 for everyone. Its used to group people, with different price tables, giving different prices to different people. Not sure if thats a MDB feature, but any VMC could implement it if not. All optional.
Z9 you can look up yourself
Z8, First two Most Significant bits are used to indicate if it was a vend card paying (as in credit card, or any real form of cashless payment). the rest of the digits it depends on the vend. you use one of the 4 options (read appendix A section 1.1 of the DTS standard to get definitions of what they mean and which ones are appropriate in that situations. Depending on the option used (1, 2, 3, or 4) that decides what Z9 & Z10 are, like option 3 says z9 would be 0x00 and Z10 would become a percentage (since z8 would describe a percentage discount given), while if u pick option one, Z10 instead contains the value of DTS element LA101.
Hope that's not too wordy or incoherent. good luck too, we're competitors.
I'm passing messages between Windows C# client and Linux C++ server via TCP sockets. C# code uses protobuf-net v2, Linux Google's version of protobuf. Small test object that I pass has 6 fields ( Enum, Int, String). I need help with two problems:
C# portion unable to deserialize data sent from Linux, unless the Memory stream used as the storage for the data is initialized with the binary array in the constructor. Array can not be larger than the data sent from Linux ( 9 bytes in my case ). Code sample - byte[] data = new byte[9], copy data from the socket into the array.
MemoryStream myStream = new MemoryStream(data), pass myStream to Serializer.Deserialize...
If I initialize MemoryStream without bynary buffer or with array of 1024 bytes, Deserialize will create empty object, without processing data.
When I try to serialize the same object with the same values as Linux same in C# the size of the data is 11 bytes vs 9 on Linux. I checked the byte array in the debugger, C# version has the same 9 fields as Linux data in the indexes 2-11 of the array. Index 0 is 8 and index 1 is 9. I can try to get around the problem, by modifying Linux deserialization code, just need to know, if I always have to deal with two extra fields at the beginning of the message. Also, I can add two extra fields to messages generated on Linux if it going to fix my deserialization in C#, just need to know how to generate values for these two fields.
Thanks.
Alex.
Protobuf data is not self-terminating, simply. You can, however, create either a MemoryStream or ProtoReader that takes a larger payload, but is limited to a virtual length. If you are sending multiple messages, you will need to know the length of the payload - that is inescapable. This is often achieved via a length prefix. I would expect this to throw random errors - most likely "invalid field header 0" - and I wonder if you are swallowing that exception
impossible to comment without the specific example; most likely something to do with the default value of field number 1 (header 8 === "field 1 varint")
I'm writing some code using PacketDotNet and SharpPCap to parse H.225 packets for a VOIP phone system. I've been using Wireshark to look at the structure, but I'm stuck. I've been using This as a reference.
Most of the H.225 packets I see are user information type with an empty message body and the actual information apparently shows up as a list of NonStandardControls in Wireshark. I thought I'd just extract out these controls and parse them later, but I don't really know where they start.
In almost all cases, the items start at the 10th byte of the H.225 data. Each item appears to begin with the length which is recorded as 2 bytes. However, I am getting a packet that has items starting at the 11th byte.
The only difference I see in this packet is something in the message body supposedly called open type length which has a value of 1, whereas the rest all appear to be 0. Would the items start at 10 + open type length? Is there some document that explains what this open type length is for?
Thanks.
H.225 doesn't use a fixed length encoding, it user ASN.1 PER encoding (not BER).
You probably won't find a C# library. OPAL is adding a C API if you are able to use that.