Alesis QS MIDI Sysex Data Conversion - midi

My aim is to convert a stream of byte code sent from an Alesis synthesizer to a human readable format. I need to be able to take a "Program Dump" and read the 10 character string that makes up the patch name.
In order to receive the "Program Dump" from the synth, I sent the synth the following command via MIDI-OX:
F0 00 00 0E 0E 01 73 F7
I requested that it send me the dump for program 73.
I received this:
F0 00 00 0E 0E 00 73 00 60 24 0B 27 27 01 64 1E 19 19 05 23 19 1E 2A 41 0D 23 46 19 1E 06 00 47 0D 23 30 6C 18 63 30 6C 18 40 3F 0A 67 1B 16 20 40 00 60 18 00 18 06 05 0C 2B 41 13 70 05 30 40 31 63 70 05 00 40 31 63 70 05 00 40 31 63 00 4C 2A 51 00 46 7F 78 18 40 0F 40 31 40 31 04 30 0C 00 30 6C 03 30 3C 0F 00 00 05 0A 0F 14 19 1E 23 28 2D 72 00 76 34 3C 54 42 19 46 0C 33 3C 0C 00 0E 1B 46 60 58 31 46 61 58 31 00 7F 14 4E 37 6C 74 13 00 40 31 00 30 0C 0A 18 56 02 27 60 0B 60 00 63 46 61 0B 00 00 63 46 61 0B 00 00 63 46 01 18 55 22 01 0C 7F 71 31 00 1F 00 63 00 63 08 60 18 00 60 58 07 60 18 1E 00 00 0A 14 1E 28 32 3C 46 50 5A 64 01 0C 2D 15 29 05 36 0C 19 66 78 18 00 1C 36 0C 41 31 63 0C 43 31 63 00 7E 29 1C 6F 58 00 01 02 00 63 00 60 18 14 30 2C 05 4E 40 17 40 01 46 0D 43 17 00 00 46 0D 43 17 00 00 46 0D 03 30 2A 45 02 18 7E 63 63 00 3E 00 46 01 46 11 40 31 00 40 31 0F 40 71 3D 00 00 14 28 3C 50 64 78 0C 21 35 49 03 58 4C 71 31 1C 6C 18 32 4C 71 31 00 38 6C 18 02 63 46 19 06 63 46 01 7C 53 00 60 18 53 37 6C 70 0D 03 40 31 28 60 58 0A 1C 01 2F 00 03 0C 1B 06 2F 00 00 0C 1B 06 2F 00 00 0C 1B 06 60 54 0A 05 30 7C 47 47 01 7C 00 0C 03 0C 23 00 63 00 00 63 1E 3C 63 18 00 00 28 50 78 20 49 71 19 42 6A 12 07 F7
MIDI-OX told me that it received 408 bytes.
This jives with the specification:
"There are 400 data bytes sent for a single program dump, which corresponds to 350
bytes of program data. With the header, the total number of bytes transmitted with
a program dump is 408. The location of each parameter within a program dump is
shown in the next section."
The "Program Dump" should be composed of these values:
F0 00 00 0E 0E 00 <program#> <data> F7
That means the data should begin with "00 60" and end with "07 F7".
Now I should be able to convert these 400 bytes to the "350 bytes of packed parameter data" for this program. Following the "Program Data Format", 10 digits of the program name should be located within the packed data somewhere. Patch 73 is called either "BlowDeTune" or "PanBristle", not totally sure if it starts at 0 or 1.
So how do you go about make the conversion? Page 1 of the specification gives the transmission format, but I don't understand how to unpack it.
Can anyone help?
The Alesis QS MIDI Sysex Specification is here:
http://www.midiworld.com/quadrasynth/qs_swlib/qs678r.pdf
MIDI-OX can be found here:
http://www.midiox.com/

You are lucky, because some years ago I played a bit with Midi (with my Atari ST 520) so I had enough interest in the topic to investigate a bit...
For the record, I found the MIDI System Exclusive Message format, in accordance with the reference you give for your synth.
I first thought the packing algorithm was described in this page, but after implementing its decoding and founding garbage, I saw I was wrong... I will give this code just in case it could be useful to you elsewhere...
This first try was useful because when I re-read the spec in the PDF file, I understood the A7 to G0 symbols were actually bits...
Data is "packed" because Midi non-control words must be 7bit clean (high bit always unset).
They take 7 bytes of raw data, see it as a big word of 56 bits, and split that word every 7 bits, leaving the high bit always at 0:
Original data (using a different notation):
0 - b07 b06 b05 b04 b03 b02 b01 b00
1 - b17 b16 b15 b14 b13 b12 b11 b10
2 - b27 b26 b25 b24 b23 b22 b21 b20
3 - b37 b36 b35 b34 b33 b32 b31 b30
4 - b47 b46 b45 b44 b43 b42 b41 b40
5 - b57 b56 b55 b54 b53 b52 b51 b50
6 - b67 b66 b65 b64 b63 b62 b61 b60
Transmitted/encoded data:
0 - 0 b06 b05 b04 b03 b02 b01 b00
1 - 0 b15 b14 b13 b12 b11 b10 b07
2 - 0 b24 b23 b22 b21 b20 b17 b16
3 - 0 b33 b32 b31 b30 b27 b26 b25
4 - 0 b42 b41 b40 b37 b36 b35 b34
5 - 0 b51 b50 b47 b46 b45 b44 b43
6 - 0 b60 b57 b56 b55 b54 b53 b52
7 - 0 b67 b66 b65 b64 b63 b62 b61
So we have:
0 - 00000000 0x00
1 - 01100000 0x60
2 - 00100100 0x24
3 - 00001011 0x0B
4 - 00100111 0x27
5 - 00100111 0x27
6 - 00000001 0x01
7 - 01100100 0x64
0 - 00011110 0x1E
1 - 00011001 0x19
2 - 00011001 0x19
3 - 00000101 0x05
4 - 00100011 0x23
5 - 00011001 0x19
6 - 00011110 0x1E
7 - 00101010 0x2A
and once decoded, we should have:
0 - 00000000 0x00
1 - 00110000 0x30
2 - 01101001 0x69
3 - 01110001 0x71
4 - 00111010 0x3A
5 - 00000101 0x05
6 - 11001000 0xC8
0 - 10011110 0x9E
1 - 01001100 0x4C
2 - 10100110 0xA6
3 - 00110000 0x30
4 - 11001010 0xCA
5 - 01111000 0x78
6 - 01010100 0x54
I believe I decoded correctly the data, but still have garbage (ie. non readable strings)...
Perhaps you will see a logic error in my code, which might be a starting point anyway.
I saw that MIDI-OX can be scripted with WSH, so I wrote a JS script which I ran with WSH, with output on console:
var midiData =
[
0xF0, 0x00, 0x00, 0x0E, 0x0E, 0x00, 0x73,
0x00, 0x60, 0x24, 0x0B, 0x27, 0x27, 0x01, 0x64, 0x1E, 0x19, 0x19, 0x05, 0x23, 0x19, 0x1E, 0x2A,
0x41, 0x0D, 0x23, 0x46, 0x19, 0x1E, 0x06, 0x00, 0x47, 0x0D, 0x23, 0x30, 0x6C, 0x18, 0x63, 0x30,
0x6C, 0x18, 0x40, 0x3F, 0x0A, 0x67, 0x1B, 0x16, 0x20, 0x40, 0x00, 0x60, 0x18, 0x00, 0x18, 0x06,
0x05, 0x0C, 0x2B, 0x41, 0x13, 0x70, 0x05, 0x30, 0x40, 0x31, 0x63, 0x70, 0x05, 0x00, 0x40, 0x31,
0x63, 0x70, 0x05, 0x00, 0x40, 0x31, 0x63, 0x00, 0x4C, 0x2A, 0x51, 0x00, 0x46, 0x7F, 0x78, 0x18,
0x40, 0x0F, 0x40, 0x31, 0x40, 0x31, 0x04, 0x30, 0x0C, 0x00, 0x30, 0x6C, 0x03, 0x30, 0x3C, 0x0F,
0x00, 0x00, 0x05, 0x0A, 0x0F, 0x14, 0x19, 0x1E, 0x23, 0x28, 0x2D, 0x72, 0x00, 0x76, 0x34, 0x3C,
0x54, 0x42, 0x19, 0x46, 0x0C, 0x33, 0x3C, 0x0C, 0x00, 0x0E, 0x1B, 0x46, 0x60, 0x58, 0x31, 0x46,
0x61, 0x58, 0x31, 0x00, 0x7F, 0x14, 0x4E, 0x37, 0x6C, 0x74, 0x13, 0x00, 0x40, 0x31, 0x00, 0x30,
0x0C, 0x0A, 0x18, 0x56, 0x02, 0x27, 0x60, 0x0B, 0x60, 0x00, 0x63, 0x46, 0x61, 0x0B, 0x00, 0x00,
0x63, 0x46, 0x61, 0x0B, 0x00, 0x00, 0x63, 0x46, 0x01, 0x18, 0x55, 0x22, 0x01, 0x0C, 0x7F, 0x71,
0x31, 0x00, 0x1F, 0x00, 0x63, 0x00, 0x63, 0x08, 0x60, 0x18, 0x00, 0x60, 0x58, 0x07, 0x60, 0x18,
0x1E, 0x00, 0x00, 0x0A, 0x14, 0x1E, 0x28, 0x32, 0x3C, 0x46, 0x50, 0x5A, 0x64, 0x01, 0x0C, 0x2D,
0x15, 0x29, 0x05, 0x36, 0x0C, 0x19, 0x66, 0x78, 0x18, 0x00, 0x1C, 0x36, 0x0C, 0x41, 0x31, 0x63,
0x0C, 0x43, 0x31, 0x63, 0x00, 0x7E, 0x29, 0x1C, 0x6F, 0x58, 0x00, 0x01, 0x02, 0x00, 0x63, 0x00,
0x60, 0x18, 0x14, 0x30, 0x2C, 0x05, 0x4E, 0x40, 0x17, 0x40, 0x01, 0x46, 0x0D, 0x43, 0x17, 0x00,
0x00, 0x46, 0x0D, 0x43, 0x17, 0x00, 0x00, 0x46, 0x0D, 0x03, 0x30, 0x2A, 0x45, 0x02, 0x18, 0x7E,
0x63, 0x63, 0x00, 0x3E, 0x00, 0x46, 0x01, 0x46, 0x11, 0x40, 0x31, 0x00, 0x40, 0x31, 0x0F, 0x40,
0x71, 0x3D, 0x00, 0x00, 0x14, 0x28, 0x3C, 0x50, 0x64, 0x78, 0x0C, 0x21, 0x35, 0x49, 0x03, 0x58,
0x4C, 0x71, 0x31, 0x1C, 0x6C, 0x18, 0x32, 0x4C, 0x71, 0x31, 0x00, 0x38, 0x6C, 0x18, 0x02, 0x63,
0x46, 0x19, 0x06, 0x63, 0x46, 0x01, 0x7C, 0x53, 0x00, 0x60, 0x18, 0x53, 0x37, 0x6C, 0x70, 0x0D,
0x03, 0x40, 0x31, 0x28, 0x60, 0x58, 0x0A, 0x1C, 0x01, 0x2F, 0x00, 0x03, 0x0C, 0x1B, 0x06, 0x2F,
0x00, 0x00, 0x0C, 0x1B, 0x06, 0x2F, 0x00, 0x00, 0x0C, 0x1B, 0x06, 0x60, 0x54, 0x0A, 0x05, 0x30,
0x7C, 0x47, 0x47, 0x01, 0x7C, 0x00, 0x0C, 0x03, 0x0C, 0x23, 0x00, 0x63, 0x00, 0x00, 0x63, 0x1E,
0x3C, 0x63, 0x18, 0x00, 0x00, 0x28, 0x50, 0x78, 0x20, 0x49, 0x71, 0x19, 0x42, 0x6A, 0x12, 0x07,
0xF7
];
// Show original data
DumpData(midiData, 16);
var headerLength = 7; // Bytes to skip
var resultData = new Array();
var decodedByteCount = 0; // Number of expanded bytes in result
var cumulator = 0;
var bitCount = 0;
for (var i = headerLength; // Skip header
i < midiData.length - 1; // Omit EOF
i++)
{
var rank = (i - headerLength) % 8; // We split the data in runs of 8 bytes
// We cumulate the bits of these runs (less the high bit) to make a big word of 56 bits
/*
cumulator |= midiData[i] << (7 * rank);
if (rank == 7) // End of the run
{
// Split the cumulator in 7 bytes
for (var j = 0; j < 7; j++)
{
var shift = 8 * j;
var byte = (cumulator & (0xFF << shift)) >> shift;
WScript.StdOut.Write(ByteToHex(byte) + ' ');
resultData[decodedByteCount++] = byte;
}
cumulator = 0; // Reset the buffer
}
*/
// Actually, we cannot do that, because JS' bit arithmetic seems to be limited to signed 32 bits!
// So I get the bytes out as soon as they are complete.
// Somehow, it is more elegant anyway (but reflects less the original algorithm).
cumulator |= midiData[i] << bitCount;
bitCount += 7;
//~ WScript.StdOut.Write((i - 7) + ':' + ByteToHex(midiData[i]) + ' (' + bitCount + ') ' + DecimalToHex(cumulator) + '\n');
if (bitCount >= 8)
{
var byte = cumulator & 0xFF;
bitCount -= 8;
cumulator >>= 8;
resultData[decodedByteCount++] = byte;
//~ WScript.StdOut.Write((i - 7) + ':' + ByteToHex(midiData[i]) + ' (' + bitCount + ') ' + DecimalToHex(cumulator) + ' > ' + ByteToHex(byte) + '\n');
}
}
DumpData(resultData, 14);
The utility routines:
function DumpData(data, lineLength)
{
WScript.StdOut.Write("Found " + data.length + " bytes\n");
var txt = '';
for (var i = 0; i < data.length; i++)
{
var rd = data[i];
if (rd > 31)
{
txt += String.fromCharCode(rd);
}
else
{
txt += '.';
}
WScript.StdOut.Write(ByteToHex(rd) + ' ');
if ((i+1) % lineLength == 0)
{
WScript.StdOut.Write(' ' + txt + '\n');
txt = '';
}
}
WScript.StdOut.Write(' ' + txt + '\n');
}
function NibbleToHex(halfByte)
{
return String.fromCharCode(halfByte < 10 ?
halfByte + 48 : // 0 to 9
halfByte + 55); // A to F
}
function ByteToHex(dec)
{
var h = (dec & 0xF0) >> 4;
var l = dec & 0x0F;
return NibbleToHex(h) + NibbleToHex(l);
}
function DecimalToHex(dec)
{
var result = '';
do
{
result = ByteToHex(dec & 0xFF) + result;
dec >>= 8;
} while (dec > 0);
return result;
}
Output:
Found 350 bytes
00 30 69 71 3A 05 C8 9E 4C A6 30 CA 78 54 .0iq:.ÈL¦0ÊxT
C1 C6 C8 98 F1 18 00 C7 C6 08 C6 C6 8C 61 ÁÆÈñ..ÇÆ.ÆÆa
6C 0C F0 A7 38 6F 2C 20 20 00 8C 01 60 0C l.ð§8o, ..`.
05 C6 2A 38 81 17 60 C0 D8 18 5E 00 00 63 .Æ*8.`ÀØ.^..c
63 78 01 00 8C 8D 01 4C 55 14 60 FC E3 31 cx...LU.`üã1
C0 07 30 06 8C 11 60 0C 00 8C 3D 80 F1 1E À.0..`..=ñ.
00 40 41 F1 A0 64 3C 23 54 4B 0E B0 D3 78 .#Añ d<#TK.°Óx
54 61 C6 C8 98 F1 18 00 C7 C6 08 C6 C6 8C TaÆÈñ..ÇÆ.ÆÆ
61 6C 0C F0 A7 38 6F 6C FA 04 00 8C 01 60 al.ð§8olú...`
0C 05 C6 2A 38 81 17 60 C0 D8 18 5E 00 00 ..Æ*8.`ÀØ.^..
63 63 78 01 00 8C 8D 01 4C 55 14 60 FC E3 ccx...LU.`üã
31 C0 07 30 06 8C 11 60 0C 00 8C 3D 80 31 1À.0..`..=1
1E 00 40 41 F1 A0 64 3C 23 54 4B 0E 30 5A ..#Añ d<#TK.0Z
95 54 C1 C6 C8 98 F1 18 00 C7 C6 08 C6 C6 TÁÆÈñ..ÇÆ.ÆÆ
8C 61 6C 0C F0 A7 38 6F 2C 20 20 00 8C 01 al.ð§8o, ..
60 0C 05 C6 2A 38 81 17 60 C0 D8 18 5E 00 `..Æ*8.`ÀØ.^.
00 63 63 78 01 00 8C 8D 01 4C 55 14 60 FC .ccx...LU.`ü
E3 31 C0 07 30 06 8C 11 60 0C 00 8C 3D 80 ã1À.0..`..=
F1 1E 00 40 41 F1 A0 64 3C 23 54 4B 0E B0 ñ..#Añ d<#TK.°
CC 78 8C C3 C6 C8 98 F1 18 00 C7 C6 08 C6 ÌxÃÆÈñ..ÇÆ.Æ
C6 8C 61 6C 0C F0 A7 00 30 66 7A 63 C3 1B Æal.ð§.0fzcÃ.
03 60 0C 05 C6 2A 38 81 17 60 C0 D8 18 5E .`..Æ*8.`ÀØ.^
00 00 63 63 78 01 00 8C 8D 01 4C 55 14 60 ..ccx...LU.`
FC E3 31 C0 07 30 06 8C 11 60 0C 00 8C 3D üã1À.0..`..=
BC 31 06 00 40 41 F1 A0 64 3C 23 54 4B 0E ¼1..#Añ d<#TK.
And just in case, the other unpacking algorithm:
// Here the 8 bits of 7 bytes of raw data are coded as 7 bytes of data stripped off of the high bit,
// while the stripped bits are grouped in the first byte of the data run.
// In other words, when we have a run of 8 bytes, the first one groups the high bits of the 7 next bytes.
// Information found at http://crystal.apana.org.au/ghansper/midi_introduction/file_dump.html
var headerLength = 7;
var resultData = new Array();
var decodedByteCount = 0; // Number of expanded bytes in result
var runCount = -1; // Number of runs in the encoded data
for (var i = headerLength; // Skip header
i < midiData.length - 1; // Omit EOF
i++)
{
var rank = (i - headerLength) % 8; // We split the data in runs of 8 bytes
if (rank == 0) // Start of the run
{
// Get the high bits
var highBits = midiData[i];
runCount++;
//~ WScript.StdOut.Write(runCount + ' > ' + (i - 7) + ' >> ' + ByteToHex(highBits) + '\n');
}
else
{
resultData[decodedByteCount++] = midiData[i] |
((highBits & (1 << (7 - rank))) << rank);
//~ WScript.StdOut.Write((i - 7) + ' >> ' + ByteToHex(midiData[i]) + ' > ' +
//~ ByteToHex(midiData[i] | ((highBits & (1 << (7 - rank))) << rank)) + '\n');
}
}

Thanks to your great work I came up with this as the pack algorithm.
It seems that the Alesis uses the same schema as the Moog Voyager.
packSysex : function(midiData) {
var header = [0xF0, 0x04, 0x01, 0x00, 0x03, 0x00]; //Voyager Single Preset Dump.
var resultData = new Array();
var packedByteCount = 0;
var bitCount = 0;
var thisByte;
var packedByte;
var nextByte = 0x0;
for (var i = 0; i <= midiData.length; i++)
{
thisByte = midiData[i];
packedByte = ((thisByte << bitCount) | nextByte) & 0x7F;
nextByte = midiData[i] >> (7-bitCount);
resultData[packedByteCount++] = packedByte;
bitCount++;
if(bitCount >= 7) {
bitCount = 0;
//Fill last byte
packedByte = nextByte & 0x7F;
resultData[packedByteCount++] = packedByte;
nextByte = 0x0;
}
}
resultData[packedByteCount++] = 0xF7;
resultData = header.concat(resultData);
return resultData;
},

Related

packing an incrementing counter into hex with perl

i am trying to create a 12 byte header and i am using pack. everything was going awesome until i needed to include an incrementing value in the pack function..
EDIT:
i have an open ffmpeg pipe that i am capturing the output from. the captured data is going to be a payload that will be encrypted and appended to the end of the header. my loop is not a for loop but i thought i would make it a little easier for the readers to understand.
so let me update the question here in hopes it clears any confusion. if i need to provide any more information let me know.
my $m = 00;
my $n = 00;
while( <$source_audio> ) {
if(($n % 16) == 0){
$m++; #this should increment when n reaches 0xff
}
my $header = pack( 'C C n n C*', 0x80, 0x78, $m, $n, 0x12, 0x34, 0x98, 0x76, 0x01, 0x02, 0x03, 0x04 );
print $file $header ;
$n++;
}
i just need to be able to pack $m and $n so i get the expected output:
80 78 00 01 12 34 98 76 01 02 03 04
80 78 00 02 12 34 98 76 01 02 03 04
80 78 00 03 12 34 98 76 01 02 03 04
80 78 00 04 12 34 98 76 01 02 03 04
80 78 00 05 12 34 98 76 01 02 03 04
... iterating 0x0000 to 0xFFFF ...
80 78 FF FB 12 34 98 76 01 02 03 04
80 78 FF FC 12 34 98 76 01 02 03 04
80 78 FF FD 12 34 98 76 01 02 03 04
80 78 FF FE 12 34 98 76 01 02 03 04
80 78 FF FF 12 34 98 76 01 02 03 04
EDIT2:
this gives me the desired output, but i get errors with strict and warnings enabled:
my $m = 0x00;
my $n = 0x00;
my $message = "this";
while ( <$source_audio> ) {
my $header = pack('C*', 0x80, 0x78, $m, $n, 0x12, 0x34, 0x98, 0x76, 0x01, 0x02, 0x03, 0x04);
if(($n % 0xFF) == 0 and $n != 0x00){
$m++;
}
$n++;
print $temp $header;
}
Character in 'C' format wrapped in pack
Solution was exactly as ikegami pointed out:
pack('C C n C*', 0x80, 0x78, $n, 0x12, 0x34, 0x98, 0x76, 0x01, 0x02, 0x03, 0x04);
The problem has nothing to do with pack or your use of it. The problem is that you are miscalculating $m and $n. The warning is the result of $m exceeding 0xFF, which clearly should not happen.
The following properly calculates $m and $n (which I renamed to $hi and $lo for reasons that will soon become obvious):
my $hi = 0x00;
my $lo = 0x00;
while ( <$source_audio> ) {
my $header = pack( 'C*',
0x80, 0x78, $hi, $lo, 0x12, 0x34, 0x98, 0x76, 0x01, 0x02, 0x03, 0x04 );
...
if ( $lo == 0xFF ) {
$lo = 0;
++$hi;
} else {
++$lo;
}
}
This could also be written as follows:
$lo = ( $lo + 1 ) & 0xFF;
++$hi if !$lo;
But we're really just incrementing one number which is stored across two octets.
my $n = 0;
while ( <$source_audio> ) {
my $hi = $n >> 8;
my $lo = $n & 0xFF;
my $header = pack( 'C*',
0x80, 0x78, $hi, $lo, 0x12, 0x34, 0x98, 0x76, 0x01, 0x02, 0x03, 0x04 );
...
++$n;
}
But let's leave the packing to pack! We're trying to store the value as a 16 bit unsigned int using big-endian byte order. Consulting Formats for Packing and Unpacking Numbers or the documentation for pack shows we can use S> or n.
my $n = 0;
while ( <$source_audio> ) {
my $header = pack( 'C C n C*',
0x80, 0x78, $n, 0x12, 0x34, 0x98, 0x76, 0x01, 0x02, 0x03, 0x04 );
...
++$n;
}

Swift/URLSession returns a different public key than OpenSSL

I have this code (can be run in a playground):
import UIKit
import CryptoKit
let url: URL = URL(string: "https://apple.com")!
final class SSLExtractor: NSObject, URLSessionDelegate {
private var session: URLSession!
init(url: URL) {
super.init()
let session = URLSession.init(configuration: .default, delegate: self, delegateQueue: nil)
session.dataTask(with: url).resume()
}
func urlSession(_ session: URLSession, didReceive challenge: URLAuthenticationChallenge, completionHandler: #escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void) {
guard challenge.protectionSpace.authenticationMethod == NSURLAuthenticationMethodServerTrust,
let serverTrust = challenge.protectionSpace.serverTrust,
let publicKey = SecTrustCopyKey(serverTrust),
let publicKeyData = SecKeyCopyExternalRepresentation(publicKey, nil)
else { return }
let publicKeyHash = SHA256.hash(data: publicKeyData as Data)
print("publicKey: \(publicKey)")
print("publicKey: \(publicKeyData)")
print("publicKey: \((publicKeyData as Data).base64EncodedString() )")
print(publicKeyHash)
}
}
let extractor = SSLExtractor(url: url)
Supposedly the last print should give me the server's public key:
SHA256 digest: b0faa00170de7c1ac7994644efadb59f149656546394bd22c95527e78f1984b6
However, when I use OpenSSL:
$ openssl s_client -connect apple.com:443 | openssl x509 -pubkey -noout | openssl rsa -pubin -outform der| openssl dgst -sha256
I get a different hash:
1786e93d8e16512ea34ea1475e39597e77d7e39239ba1a97dcd71f97e64d6619
How to get the correct hash ?
Edit: Also tried
let certificate = SecTrustGetCertificateAtIndex(serverTrust, 0),
let certifKey = SecCertificateCopyKey(certificate),
let certifPubKey = SecKeyCopyPublicKey(certifKey),
let certifPubKeyData = SecKeyCopyExternalRepresentation(certifPubKey, nil)
But I got the same result
Only sort of an answer but too much for comments. You found that the 'external' publickey provided (and hashed) by Swift is a suffix of that used by OpenSSL.
OpenSSL uses, as I referenced, the 'SPKI' (SubjectPublicKeyInfo) structure defined by X.509/PKIX=RFC5280 section 4 which is a DER-encoded ASN.1 SEQUENCE containing an AlgorithmIdentifier and a BIT STRING cotaining embedded algorithm-specific data. RFC 7468 section 13 (which partly officializes OpenSSL, although it doesn't say so) confirms this is the content of a 'standard' public key representation, and RFC 3279 section 2.3.1 defines that for RSA (which the Apple cert's key is) the content of the BIT STRING part is the ASN.1 structure RSAPublicKey which actually was defined (though 3279 doesn't say so for the key, while it does for the signature in 2.2.1) in PKCS1 currently RFC8017 section A.1.1 (but unchanged from earlier versions).
Because of the way DER encoding works, the content of the BIT STRING -- in this case the ASN.1 structure RSAPublicKey -- is exactly a suffix of the encoding of the whole SPKI.
If we look at, and parse, the SPKI OpenSSL gets from the cert (with x509 -pubkey)
$ openssl rsa -pubin -in applespki -outform der |od -Ax -tx1
writing RSA key
000000 30 82 01 22 30 0d 06 09 2a 86 48 86 f7 0d 01 01
000010 01 05 00 03 82 01 0f 00 30 82 01 0a 02 82 01 01
000020 00 e0 e5 ca aa 34 ea 32 d1 f5 e3 56 e5 05 e8 07
000030 c3 d3 3b 86 93 60 94 37 20 9f 8d d0 17 8f ba da
000040 16 f1 b2 6a bc 41 7a 6f dc 22 87 4b 05 e8 57 48
000050 56 3c da a2 02 e5 57 73 94 95 18 dd 7c c9 b0 68
000060 fe 17 2c 8b 6f fa 42 a9 b1 a8 77 88 22 d4 41 08
000070 08 d9 80 59 92 bc e9 3a 0a 17 e0 2b 13 fe bf ec
000080 69 7d 61 15 14 21 71 73 a0 70 fd 6d a0 0f 46 13
000090 60 8d c1 bd 8c 66 60 04 05 e0 44 f0 a1 53 b7 00
0000a0 7f a3 f3 55 da d2 6c c6 dd 7f 83 79 1f 6e cb 1d
0000b0 78 3e d9 9f fa 58 34 38 41 c5 70 c1 c7 dd ea b0
0000c0 81 c0 d4 a3 18 a4 da 02 15 b8 cb 48 10 fa 42 86
0000d0 75 1c 55 51 6b 48 6e 37 43 98 09 af 4f 52 c0 c8
0000e0 75 40 a5 e7 65 ba 62 2a be 6c 2a 6d 72 5b 82 21
0000f0 d1 75 97 ea 7e 21 a1 04 f4 76 7c 85 db 50 c7 9f
000100 b5 d8 f7 80 15 ba a5 83 9e 2c da f0 73 c6 14 9a
000110 fd 35 07 41 4b 53 21 8d 0d 01 f1 05 b3 04 05 83
000120 cb 02 03 01 00 01
000126
$ openssl asn1parse -i -dump -in applespki1
0:d=0 hl=4 l= 290 cons: SEQUENCE
4:d=1 hl=2 l= 13 cons: SEQUENCE
6:d=2 hl=2 l= 9 prim: OBJECT :rsaEncryption
17:d=2 hl=2 l= 0 prim: NULL
19:d=1 hl=4 l= 271 prim: BIT STRING
0000 - 00 30 82 01 0a 02 82 01-01 00 e0 e5 ca aa 34 ea .0............4.
0010 - 32 d1 f5 e3 56 e5 05 e8-07 c3 d3 3b 86 93 60 94 2...V......;..`.
0020 - 37 20 9f 8d d0 17 8f ba-da 16 f1 b2 6a bc 41 7a 7 ..........j.Az
0030 - 6f dc 22 87 4b 05 e8 57-48 56 3c da a2 02 e5 57 o.".K..WHV<....W
0040 - 73 94 95 18 dd 7c c9 b0-68 fe 17 2c 8b 6f fa 42 s....|..h..,.o.B
0050 - a9 b1 a8 77 88 22 d4 41-08 08 d9 80 59 92 bc e9 ...w.".A....Y...
0060 - 3a 0a 17 e0 2b 13 fe bf-ec 69 7d 61 15 14 21 71 :...+....i}a..!q
0070 - 73 a0 70 fd 6d a0 0f 46-13 60 8d c1 bd 8c 66 60 s.p.m..F.`....f`
0080 - 04 05 e0 44 f0 a1 53 b7-00 7f a3 f3 55 da d2 6c ...D..S.....U..l
0090 - c6 dd 7f 83 79 1f 6e cb-1d 78 3e d9 9f fa 58 34 ....y.n..x>...X4
00a0 - 38 41 c5 70 c1 c7 dd ea-b0 81 c0 d4 a3 18 a4 da 8A.p............
00b0 - 02 15 b8 cb 48 10 fa 42-86 75 1c 55 51 6b 48 6e ....H..B.u.UQkHn
00c0 - 37 43 98 09 af 4f 52 c0-c8 75 40 a5 e7 65 ba 62 7C...OR..u#..e.b
00d0 - 2a be 6c 2a 6d 72 5b 82-21 d1 75 97 ea 7e 21 a1 *.l*mr[.!.u..~!.
00e0 - 04 f4 76 7c 85 db 50 c7-9f b5 d8 f7 80 15 ba a5 ..v|..P.........
00f0 - 83 9e 2c da f0 73 c6 14-9a fd 35 07 41 4b 53 21 ..,..s....5.AKS!
0100 - 8d 0d 01 f1 05 b3 04 05-83 cb 02 03 01 00 01 ...............
we can see the content of the BIT STRING, skipping the first byte 00 because of the way DER works for BIT STRING, and thus starting at offset 24=0x18 and continuing to the end, is itself a DER encoding of RSAPublicKey (30 82 01 0a is the SEQUENCE, 02 82 01 01 ... is the INTEGER (signed) modulus, 02 03 01 00 01 is the INTEGER (signed) publicExponent). OpenSSL 1.0.0 up (which is now ubiquitous, though I remember when it wasn't) can extract this, and get your expected hash:
$ openssl rsa -pubin -in applespki -RSAPublicKey_out -outform der |od -Ax -tx1
writing RSA key
000000 30 82 01 0a 02 82 01 01 00 e0 e5 ca aa 34 ea 32
000010 d1 f5 e3 56 e5 05 e8 07 c3 d3 3b 86 93 60 94 37
000020 20 9f 8d d0 17 8f ba da 16 f1 b2 6a bc 41 7a 6f
000030 dc 22 87 4b 05 e8 57 48 56 3c da a2 02 e5 57 73
000040 94 95 18 dd 7c c9 b0 68 fe 17 2c 8b 6f fa 42 a9
000050 b1 a8 77 88 22 d4 41 08 08 d9 80 59 92 bc e9 3a
000060 0a 17 e0 2b 13 fe bf ec 69 7d 61 15 14 21 71 73
000070 a0 70 fd 6d a0 0f 46 13 60 8d c1 bd 8c 66 60 04
000080 05 e0 44 f0 a1 53 b7 00 7f a3 f3 55 da d2 6c c6
000090 dd 7f 83 79 1f 6e cb 1d 78 3e d9 9f fa 58 34 38
0000a0 41 c5 70 c1 c7 dd ea b0 81 c0 d4 a3 18 a4 da 02
0000b0 15 b8 cb 48 10 fa 42 86 75 1c 55 51 6b 48 6e 37
0000c0 43 98 09 af 4f 52 c0 c8 75 40 a5 e7 65 ba 62 2a
0000d0 be 6c 2a 6d 72 5b 82 21 d1 75 97 ea 7e 21 a1 04
0000e0 f4 76 7c 85 db 50 c7 9f b5 d8 f7 80 15 ba a5 83
0000f0 9e 2c da f0 73 c6 14 9a fd 35 07 41 4b 53 21 8d
000100 0d 01 f1 05 b3 04 05 83 cb 02 03 01 00 01
00010e
$ openssl rsa -pubin -in applespki -RSAPublicKey_out -outform der |openssl sha256
writing RSA key
(stdin)= b0faa00170de7c1ac7994644efadb59f149656546394bd22c95527e78f1984b6
This only works for RSA. It might be interesting to see how your Swift code handles a certificated non-RSA key, although at present those are hard to find on the public web; the only stable ones I currently know of are at 'badssl' like https://ecc256.badssl.com .

Desfire Getting 1E (INTEGRITY_ERROR) on changeKey and changeKeySettings

I'm trying to change key and key settings but always getting same error.
List of my commands:
-----Authenticate
Key: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Vector: 00 00 00 00 00 00 00 00
Command: 0A 00
Response: AF 8B 95 99 DC C7 71 F4 DB
RndB: 8B 95 99 DC C7 71 F4 DB
Decrypted RndB:3E 48 AA 0B D6 1F 2E EA
Shifted:48 AA 0B D6 1F 2E EA 3E
RnbA: 5A AC 38 6E 0E 0B 80 F4
RnbAB:5A AC 38 6E 0E 0B 80 F4 48 AA 0B D6 1F 2E EA 3E
Encrypted RndAB:F7 69 E9 95 DF A2 3E A0 5D 5F 47 A9 6A 15 40 AD
Command: AF F7 69 E9 95 DF A2 3E A0 5D 5F 47 A9 6A 15 40 AD
Response: 00 1F 59 B1 E0 AC FC BD 3E
newRnbA:1F 59 B1 E0 AC FC BD 3E
decrypted newRnbA: AC 38 6E 0E 0B 80 F4 5A
Session key: D9 1C AD FD 8D 2A 61 41 DA 5F 54 3C 7C EF 5D 37 D9 1C AD FD 8D 2A 61 41
-----ChangeKeySettings
Key: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Vector: 00 00 00 00 00 00 00 00
Session key: D9 1C AD FD 8D 2A 61 41 DA 5F 54 3C 7C EF 5D 37 D9 1C AD FD 8D 2A 61 41
New Key Setting
Crc: A9 09
Decrypted data: 0F 09 A9 00 00 00 00 00
Encrypted data: 68 31 80 24 AE 26 43 B5
Command: 54 68 31 80 24 AE 26 43 B5
Response: 1E 90 00
-----ChangeKey
Old Key: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Vector: 00 00 00 00 00 00 00 00
New key: 00 10 20 31 40 50 60 70 80 90 A0 B0 B0 A0 90 80
CRC: 89 FF
Cryptogram: 00 10 20 31 40 50 60 70 80 90 A0 B0 B0 A0 90 80 FF 89 00 00 00 00 00 00
CryptogramEcn: 95 6D E0 F8 8F 26 83 96 E6 5D 1C 88 9E 9D EA 89 9E 8D A5 61 19 F7 90 48
Command: C4 00 95 6D E0 F8 8F 26 83 96 E6 5D 1C 88 9E 9D EA 89 9E 8D A5 61 19 F7 90 48
Response: 1E 90 00
Encription method is: 2K3DES
Q1: is my crc16 is right?
Q2: is my encryption is right?
Q3: If yes, what is wrong?
I'm hoping on fast help.
Thank you

Problems with sending UDP packets (milight, limitlessled)

I trying to write a menubar app to get control over my lights via Mac.
I'm using the system of milight (limitless, easybulbs...).
They have an open system were you can send commands via UDP.
I'm able to control my lights via python-limitless library in python, so I know the networking thing such as IP and port is right.
So I think I do anything wrong with this UDP stuff I never worked with.
I'm trying to use SwiftSocket library to send my commands but nothing happens, I've been trying it since 2 days.
Here ist what I'm trying:
let host = "192.168.2.102"
let port = 5987
var client: UDPClient!
#IBAction func lightOn(_ sender: NSButton) {
let bridgeon: [UInt8] = [0x31, 0x00, 0x00, 0x00, 0x03, 0x03, 0x00, 0x00, 0x00, 0x01]
let rgbwon: [UInt8] = [0x31, 0x00, 0x00, 0x07, 0x03, 0x01, 0x00, 0x00, 0x00, 0]
print("Licht an")
print(client.send(data: bridgeon))
sleep(1)
print(client.send(data: rgbwon))
sleep(1)
}
#IBAction func lightOff(_ sender: NSButton) {
print("Licht aus")
}
override func viewDidLoad() {
super.viewDidLoad()
client = UDPClient(address: host, port: Int32(port))
}
When I compare this with the complexity of the pythonlibrary I'm sure I forget something important. I haven't worked with networks yet so be lenient with me.
thanks and greetings.
I'm a bit late, but I hope it can help you :
Before sending your lighton request you have to send a first request to get, the wifi bridge session. You also need to compute what Milight called the "checksum" based on your request.
You also make sure about what kind of bulb you have, is it WW bulb or CW? I was stuck for severals days because I was sending wrong request..
I made an implementation, It's in php but you can use it same way in Objective-C.
Check it out : https://github.com/winosaure/MilightAPI
UPDATE :
According to limitlessled "documentation" (http://www.limitlessled.com/dev/) this is how a request is composed :
UDP Hex Send Format: 80 00 00 00 11 {WifiBridgeSessionID1}
{WifiBridgeSessionID2} 00 {SequenceNumber} 00 {COMMAND} {ZONE NUMBER}
00 {Checksum}
This is why you must get wifibridge session first then you need to calculate the checksum.
Let me take one example about how to turn on the light.
The documentation says that :
31 00 00 08 04 01 00 00 00 = Light ON
31 00 00 08 04 01 00 00 00 refer to {COMMAND} above.
So far the full request must be :
80 00 00 00 11 {WifiBridgeSessionID1} {WifiBridgeSessionID2} 00 {SequenceNumber} 00 31 00 00 08 04 01 00 00 00 {ZONE NUMBER} 00 {Checksum}
Now let's get the Wifibridge session. The documention says :
to get the WifiBridgeSessionID1 and WifiBridgeSessionID2 send this
command UDP.
SEND hex bytes: 20 00 00 00 16 02 62 3A D5 ED A3 01 AE 08
2D 46 61 41 A7 F6 DC AF (D3 E6) 00 00 1E <-- Send this to the ip
address of the wifi bridge v6
That's why I'm doing this:
private function getWifiBridgeSession()
{
$command = array (
0x20,0x00, 0x00,
0x00, 0x16, 0x02,
0x62, 0x3A, 0xD5,
0xED, 0xA3, 0x01,
0xAE, 0x08, 0x2D,
0x46, 0x61, 0x41,
0xA7, 0xF6, 0xDC,
0xAF, 0xD3, 0xE6,
0x00, 0x00, 0x1E);
return $this->sendCommand($command);
}
Once you send a UDP request with this command, you will get a result.
The Wifi Bridge session1 refers to the 20th byte of the response and WifiBridge Session2 will refer to the 21th byte response (Don't forget that we start to count from 0, so you must take something like "response[19]" and "response[20]").
Let's say, after sending this request I get this response :
28 00 00 00 11 00 02 AC CF 23 F5 7A D4 69 F0 3C 23 00 01 05 00
So my "WifiBridgesession1" is 0x05 and "Wifibridgesession2" is 0x00
So now our request to "turn on" the light is :
80 00 00 00 11 0x05 0x00 00 {SequenceNumber} 00 31 00 00 08 04 01 00 00 00 {ZONE NUMBER} 00 {Checksum}
So now we need to find out {SequenceNumber} {Zone Number} and {Checksum}
What is a "Sequence Number"?
The doc says :
Sequential byte just helps with keeping commands in the correct order,
and it helps to ignore duplicate packets already received. increment
this byte for each new command by 1.
So put what you want and increase this value to 1 for each request. (Personnally I always send 0x01).
"Zone number" refers to which zone you synchronized your light.
Valid List for {ZONE NUMBER} 0x00 All 0x01 Zone1 0x02 Zone2 0x03
Zone3 0x04 Zone4
Let's say, our "zone" is 0x01.
Almost done. we just need now to calculate the "checksum".
The doc says :
take the 9 bytes of the command, and 1 byte of the zone, and add the 0
= the checksum = (checksum & 0xFF) e.g. SUM((31 00 00 08 04 01 00 00 00)(command) 01(zone) 00) = 3F(chksum)
So the checksum for our command is :
31+00+00+08+04+01+00+00+00+01+00 = 0x54
I add all byte of the command (turn on) + 0x01 for the zone + 0x00
So now we have everything and the full request to turn on the light is :
80 00 00 00 11 05 00 00 01 00 31 00 00 08 04 01 00 00 00 01 00 54
That's it.
Note : Do not just copy and paste the request, I calculated the value based on example, the request to turn on the light will change each time, based on what you will calculate.
Maybe you got noticed that I wrote "00 31 00 00 08 04 01 00 00 00" to do the "turn on" command, this will work only for CW bulb. The doc does not specify that...
The same Command for WW bulb is 00 31 00 00 07 03 01 00 00 00
So the full command for WW bulb will be :
80 00 00 00 11 05 00 00 01 00 31 00 00 07 03 01 00 00 00 01 00 54
What is the difference between CW and WW bulb?
I can tell that CW refers to "Cold White" and WW to "Warm White". But as I am not an expert in "led bulb" I cannot explain more, I don't know why we need to write a different request for both, either.
Anyway I wish I was clear enough.
Let me know how things are working.

scapy command for defining the data part of udp packet

I had used the following command to generate a GTP packet using sendp
>>>sendp(Ether()/IP(dst="1.1.1.1", proto=17,
len=124)/UDP(sport=2152,dport=2152,len=104)/Raw(load=('32 ff 00 58 00 00 00 01 '
'28 db 00 00 45 00 00 54 00 00 40 00 40 00 5e a5 ca 0b 28 9e c0 a8 28 b2 08 00 '
'be e7 00 00 28 7b 04 11 20 4b f4 3d 0d 00 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 '
'14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d '
'2e 2f 30 31 32 33 34 35 36 37')), iface="eth1", loop=1, inter=1.0002)
In Wireshark,
Click on the following link for wireshark view :
http://imgur.com/M1Hpl7P
Expecting the Data of UDP packet as -
32 ff 00 58 00 00 00 01 28 db 00 00 45 00 00 54 00 00 40 00 40 00 5e a5 ca 0b 28
9e c0 a8 28 b2 08 00 be e7 00 00 28 7b 04 11 20 4b f4 3d 0d 00 08 09 0a 0b 0c 0d
0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28
29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37
But I found this data at "right most side of the packet description", instead of "Middle portion of the packet description".
Could you please let me know the command to be used to correct this.
I assume you want the above hex values to be the data in the UDP packet.
What you provided to Raw was a string of characters, spaces included, not hex code in Python. We will first convert your string of characters into a valid hex string in Python, then provide that to Scapy so the data will go on the wire as you want it.
I'll also show you some nice functions to preview what you will see in Wireshark.
First we'll put your data into its own variable.
>>> data = ('32 ff 00 58 00 00 00 01 '
... '28 db 00 00 45 00 00 54 00 00 40 00 40 00 5e a5 ca 0b 28 9e c0 a8 28 b2 08 00 '
... 'be e7 00 00 28 7b 04 11 20 4b f4 3d 0d 00 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 '
... '14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d '
... '2e 2f 30 31 32 33 34 35 36 37')
Then split that up into a nice list.
>>> data_list = data.split(" ")
>>> data_list
['32', 'ff', '00', '58', '00', '00', '00', '01', '28', 'db', '00', '00', '45',
'00', '00', '54', '00', '00', '40', '00', '40', '00', '5e', 'a5', 'ca', '0b',
'28', '9e', 'c0', 'a8', '28', 'b2', '08', '00', 'be', 'e7', '00', '00', '28',
'7b', '04', '11', '20', '4b', 'f4', '3d', '0d', '00', '08', '09', '0a', '0b',
'0c', '0d', '0e', '0f', '10', '11', '12', '13', '14', '15', '16', '17', '18',
'19', '1a', '1b', '1c', '1d', '1e', '1f', '20', '21', '22', '23', '24', '25',
'26', '27', '28', '29', '2a', '2b', '2c', '2d', '2e', '2f', '30', '31', '32',
'33', '34', '35', '36', '37']
Generate the string which can be passed to Raw as the binary data you want to appear in the packet.
>>>data_s = ''.join(data_list).decode('hex')
>>>data_s
'2\xff\x00X\x00\x00\x00\x01(\xdb\x00\x00E\x00\x00T\x00\x00#\x00#\x00^\xa5\xca
\x0b(\x9e\xc0\xa8(\xb2\x08\x00\xbe\xe7\x00\x00({\x04\x11K\xf4=\r\x00\x08\t\n\x0b
\x0c\r\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f
!"#$%&\'()*+,-./01234567'
Use this string for your UDP Payload and build your packet!
>>> packet = IP(dst="1.1.1.1", proto=17,
... len=124)/UDP(sport=2152,dport=2152,len=104)/Raw(load=data_s)
>>> packet.show()
###[ IP ]###
version= 4
ihl= None
tos= 0x0
len= 124
id= 1
flags=
frag= 0
ttl= 64
proto= udp
chksum= None
src= 0.0.0.0
dst= 1.1.1.1
\options\
###[ UDP ]###
sport= gtp_user
dport= gtp_user
len= 104
chksum= None
###[ Raw ]###
load= '2\xff\x00X\x00\x00\x00\x01(\xdb\x00\x00E\x00\x00T\x00\x00#\x00#
\x00^\xa5\xca\x0b(\x9e\xc0\xa8(\xb2\x08\x00\xbe\xe7\x00\x00({\x04
\x11K\xf4=\r\x00\x08\t\n\x0b\x0c\r\x0e\x0f\x10\x11\x12\x13\x14
\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f !"#$%&\'()*+,-./0
1234567'
This should produce the expected data in Wireshark. Here is a hexdump of what you should see. I excluded the Ethernet layer, was giving Scapy on my machine some trouble for an unknown reason.
>>> hexdump(p)
0000 45 00 00 7C 00 01 00 00 40 11 78 6F 00 00 00 00 E..|....#.xo....
0010 01 01 01 01 08 68 08 68 00 68 90 1A 32 FF 00 58 .....h.h.h..2..X
0020 00 00 00 01 28 DB 00 00 45 00 00 54 00 00 40 00 ....(...E..T..#.
0030 40 00 5E A5 CA 0B 28 9E C0 A8 28 B2 08 00 BE E7 #.^...(...(.....
0040 00 00 28 7B 04 11 20 4B F4 3D 0D 00 08 09 0A 0B ..({.. K.=......
0050 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B ................
0060 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B .... !"#$%&'()*+
0070 2C 2D 2E 2F 30 31 32 33 34 35 36 37 ,-./01234567