First of all, thanks to the community of Stack Overflow. I've found lots of competent answers here, so I'll try to ask my own question.
I have a WinPcap sample program which "dumps" my network traffic as Hexcode.
I made a simple server/client pair which periodically sends some text (22 bytes).
Problem:
Parsing this Hex-dump in C++ and generate an output like Wireshark or phd does (just in the console).
After reading some TCP/IP references (1), I'm not able to determine all bytes "values"
So for example there are 76 bytes, reading backwards:
the first 22 bytes are my Data;
then, there are 20 for the TCP header;
20 for the IP Header and then some other Bytes I don't know what they stand for. I'm not very knowledgeable about the IP protocol.
Here is an example in hex:
08 00 27 b3 23 63 f4 6d 04 2e 68 24 08 00 45 00
00 3e 31 c4 40 00 80 06 45 9e c0 a8 01 03 c0 a8
01 04 0b 27 04 d2 b0 f7 47 61 28 6c fd a7 50 18
fa f0 8e a0 00 00 48 61 6c 6c 6f 20 64 61 73 20
69 73 74 20 65 69 6e 20 54 65 73 74
Question:
Can someone tell me what these first bytes are for, and
where to get a (simple) description of how the network traffic is composed?
(1) TCP Reference, IP Reference
I used Packet Dump Decode and decoded this into the following data... pdd translates the the hex dump into something you can use in wireshark... then I worked backwards from the wireshark info to break the packet down...
Ethernet Header
---------------
08 00 27 b3 23 63 f4 6d 04 2e 68 24 08 00
IP Header
---------
45 00 00 3e 31 c4 40 00 80 06 45 9e
c0 a8 01 03 c0 a8 01 04
TCP Header
----------
0b 27 04 d2 b0 f7 47 61 28 6c fd a7 50 18
fa f0 8e a0 00 00
TCP Data Payload
----------------
48 61 6c 6c 6f 20 64 61 73 20
69 73 74 20 65 69 6e 20 54 65 73 74
And a full wireshark decode...
Frame 1: 76 bytes on wire (608 bits), 76 bytes captured (608 bits)
WTAP_ENCAP: 1
Arrival Time: Nov 24, 2012 07:12:54.000000000 Central Standard Time
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1353762774.000000000 seconds
[Time delta from previous captured frame: 0.000000000 seconds]
[Time delta from previous displayed frame: 0.000000000 seconds]
[Time since reference or first frame: 0.000000000 seconds]
Frame Number: 1
Frame Length: 76 bytes (608 bits)
Capture Length: 76 bytes (608 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ip:tcp:data]
Ethernet II, Src: AsustekC_2e:68:24 (f4:6d:04:2e:68:24), Dst: CadmusCo_b3:23:63 (08:00:27:b3:23:63)
Destination: CadmusCo_b3:23:63 (08:00:27:b3:23:63)
Address: CadmusCo_b3:23:63 (08:00:27:b3:23:63)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Source: AsustekC_2e:68:24 (f4:6d:04:2e:68:24)
Address: AsustekC_2e:68:24 (f4:6d:04:2e:68:24)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: IP (0x0800)
Internet Protocol Version 4, Src: 192.168.1.3 (192.168.1.3), Dst: 192.168.1.4 (192.168.1.4)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
Total Length: 62
Identification: 0x31c4 (12740)
Flags: 0x02 (Don't Fragment)
0... .... = Reserved bit: Not set
.1.. .... = Don't fragment: Set
..0. .... = More fragments: Not set
Fragment offset: 0
Time to live: 128
Protocol: TCP (6)
Header checksum: 0x459e [correct]
[Good: True]
[Bad: False]
Source: 192.168.1.3 (192.168.1.3)
Destination: 192.168.1.4 (192.168.1.4)
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
Transmission Control Protocol, Src Port: msrp (2855), Dst Port: search-agent (1234), Seq: 1, Ack: 1, Len: 22
Source port: msrp (2855)
Destination port: search-agent (1234)
[Stream index: 0]
Sequence number: 1 (relative sequence number)
[Next sequence number: 23 (relative sequence number)]
Acknowledgment number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x018 (PSH, ACK)
000. .... .... = Reserved: Not set
...0 .... .... = Nonce: Not set
.... 0... .... = Congestion Window Reduced (CWR): Not set
.... .0.. .... = ECN-Echo: Not set
.... ..0. .... = Urgent: Not set
.... ...1 .... = Acknowledgment: Set
.... .... 1... = Push: Set
.... .... .0.. = Reset: Not set
.... .... ..0. = Syn: Not set
.... .... ...0 = Fin: Not set
Window size value: 64240
[Calculated window size: 64240]
[Window size scaling factor: -1 (unknown)]
Checksum: 0x8ea0 [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
[SEQ/ACK analysis]
[Bytes in flight: 22]
Data (22 bytes)
0000 48 61 6c 6c 6f 20 64 61 73 20 69 73 74 20 65 69 Hallo das ist ei
0010 6e 20 54 65 73 74 n Test
Data: 48616c6c6f20646173206973742065696e2054657374
[Length: 22]
Related
How to generate RSA public key with no any API. Just using modulus and public exponent.
In our project we are implementing RSA PKCS#8 public key by modulus and public exponent.
However we don't know meaning of ASN.1 binary of PKCS#8 public key.
For understanding PKCS#8 public key ASN.1, we did blow.
1. openssl genrsa -out hoge.key 2048
2. openssl rsa -pubout -in hoge.key
Here we get below infomation.
> -----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7z2oyePt5vNbH7Pbieiw
BOgRnCUyyUvUo6Wi+uqUWvMxrji1vH21ViTZYLjg40RrulSCGFwjzwnI4AMtEdIZ
7uOol12E3xOZYNgwTBaDNCT9p0IYYuFVGfQyxlavr7oSIaaNmlSRy+0os1xi7IiI
PCHE/7nfifDQiqGtb6b6TBOwP3QXg5IdrXiqQJAlk+8S0XPhbnwwzWOhlrR3Wftq
jylBPSGSDJQoF0fJ5h2cA2yJiGqTV37YRTThPWmQEuz8Njx4bTaEaTul5/UNhSel
s7khd/IvHV9oN6T2o4V//fAsyjRZlYKEUHldb3ML/QHxWs7+hqWSa9NCwwXZGhEl
wwIDAQAB
-----END PUBLIC KEY-----
> 0000000 30 82 01 22 30 0d 06 09 2a 86 48 86 f7 0d 01 01
0000010 01 05 00 03 82 01 0f 00 30 82 01 0a 02 82 01 01
0000020 00 ef 3d a8 c9 e3 ed e6 f3 5b 1f b3 db 89 e8 b0
0000030 04 e8 11 9c 25 32 c9 4b d4 a3 a5 a2 fa ea 94 5a
0000040 f3 31 ae 38 b5 bc 7d b5 56 24 d9 60 b8 e0 e3 44
0000050 6b ba 54 82 18 5c 23 cf 09 c8 e0 03 2d 11 d2 19
0000060 ee e3 a8 97 5d 84 df 13 99 60 d8 30 4c 16 83 34
0000070 24 fd a7 42 18 62 e1 55 19 f4 32 c6 56 af af ba
0000080 12 21 a6 8d 9a 54 91 cb ed 28 b3 5c 62 ec 88 88
0000090 3c 21 c4 ff b9 df 89 f0 d0 8a a1 ad 6f a6 fa 4c
00000a0 13 b0 3f 74 17 83 92 1d ad 78 aa 40 90 25 93 ef
00000b0 12 d1 73 e1 6e 7c 30 cd 63 a1 96 b4 77 59 fb 6a
00000c0 8f 29 41 3d 21 92 0c 94 28 17 47 c9 e6 1d 9c 03
00000d0 6c 89 88 6a 93 57 7e d8 45 34 e1 3d 69 90 12 ec
00000e0 fc 36 3c 78 6d 36 84 69 3b a5 e7 f5 0d 85 27 a5
00000f0 b3 b9 21 77 f2 2f 1d 5f 68 37 a4 f6 a3 85 7f fd
0000100 f0 2c ca 34 59 95 82 84 50 79 5d 6f 73 0b fd 01
0000110 f1 5a ce fe 86 a5 92 6b d3 42 c3 05 d9 1a 11 25
0000120 c3 02 03 01 00 01
0000126
we understand above binary as below. However we don't understand some binary.So We would like to know meaning of ASN.1 binary of PKCS#8 public key.
By the way, We have already refer below information. However this does not mention about public key.
https://datatracker.ietf.org/doc/html/rfc5208
30: SEQUEENCE
82: next 2byte is sequence length
01 22: 0x122byte
30: SEWUENCE
0d:?
06:?
09:?
2a 86.. 01 01 01: PKCS#1 rsa Encryption
05: ?
00: ?
03: ?
82: next 2byte is length of bit string
01 0f: length of bit string
00: ?
30 82....: PKCS#1 public key
Taking a huge gamble that what you're really asking is how to obtain the modulus and public exponent from a RSA public key PEM encoding, I invite you on this tryst. If your looking to build this encoding given only the modulus and public exponent, this dissection should show you how it's laid out, and this a somewhat reverse roadmap to get there. Either way, read on.
First of all: "next 2byte is length of bit string" - that's rather assumptive of you. ASN.1 is all about type-length-value (TLV for short) and does not waver from that model. The only reason the "next 2 byte is length of bit string" is because the ASN.1 said it is. (more on that later).
ASN.1 in incredibly flexible. I recently had a colleague jokingly tell me "ASN.1 is just JSON for boomers". Yeah, I took that personally. Since JSON followed ASN.1 by decades, I like to think "JSON is just ASN.1 for millennials".
Anyway, funny thing about ASN.1 (and JSON, for that matter): sometimes there are TLV encodings within TLV encodings, and that is the case here. Specifically an RSAPublicKey sequence will be encoded in an ASN.1 bit-string provided the setup is correct (i.e. the OID matches), and that seems to be the part you're struggling with: how to find it.
I'm going to leave the actual code to do this (which will be tedious, no-doubt fraught with hackery, and ultimately leave you wishing you had just used a crypto-library) as a task. That said, on to the act ripping apart your public key. First, your PEM:
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7z2oyePt5vNbH7Pbieiw
BOgRnCUyyUvUo6Wi+uqUWvMxrji1vH21ViTZYLjg40RrulSCGFwjzwnI4AMtEdIZ
7uOol12E3xOZYNgwTBaDNCT9p0IYYuFVGfQyxlavr7oSIaaNmlSRy+0os1xi7IiI
PCHE/7nfifDQiqGtb6b6TBOwP3QXg5IdrXiqQJAlk+8S0XPhbnwwzWOhlrR3Wftq
jylBPSGSDJQoF0fJ5h2cA2yJiGqTV37YRTThPWmQEuz8Njx4bTaEaTul5/UNhSel
s7khd/IvHV9oN6T2o4V//fAsyjRZlYKEUHldb3ML/QHxWs7+hqWSa9NCwwXZGhEl
wwIDAQAB
-----END PUBLIC KEY-----
Decoding the base64 to DER, then displayed through xxd, it looks like this:
00000000: 30 82 01 22 30 0d 06 09 2a 86 48 86 f7 0d 01 01 0.."0...*.H.....
00000010: 01 05 00 03 82 01 0f 00 30 82 01 0a 02 82 01 01 ........0.......
00000020: 00 ef 3d a8 c9 e3 ed e6 f3 5b 1f b3 db 89 e8 b0 ..=......[......
00000030: 04 e8 11 9c 25 32 c9 4b d4 a3 a5 a2 fa ea 94 5a ....%2.K.......Z
00000040: f3 31 ae 38 b5 bc 7d b5 56 24 d9 60 b8 e0 e3 44 .1.8..}.V$.`...D
00000050: 6b ba 54 82 18 5c 23 cf 09 c8 e0 03 2d 11 d2 19 k.T..\#.....-...
00000060: ee e3 a8 97 5d 84 df 13 99 60 d8 30 4c 16 83 34 ....]....`.0L..4
00000070: 24 fd a7 42 18 62 e1 55 19 f4 32 c6 56 af af ba $..B.b.U..2.V...
00000080: 12 21 a6 8d 9a 54 91 cb ed 28 b3 5c 62 ec 88 88 .!...T...(.\b...
00000090: 3c 21 c4 ff b9 df 89 f0 d0 8a a1 ad 6f a6 fa 4c <!..........o..L
000000a0: 13 b0 3f 74 17 83 92 1d ad 78 aa 40 90 25 93 ef ..?t.....x.#.%..
000000b0: 12 d1 73 e1 6e 7c 30 cd 63 a1 96 b4 77 59 fb 6a ..s.n|0.c...wY.j
000000c0: 8f 29 41 3d 21 92 0c 94 28 17 47 c9 e6 1d 9c 03 .)A=!...(.G.....
000000d0: 6c 89 88 6a 93 57 7e d8 45 34 e1 3d 69 90 12 ec l..j.W~.E4.=i...
000000e0: fc 36 3c 78 6d 36 84 69 3b a5 e7 f5 0d 85 27 a5 .6<xm6.i;.....'.
000000f0: b3 b9 21 77 f2 2f 1d 5f 68 37 a4 f6 a3 85 7f fd ..!w./._h7......
00000100: f0 2c ca 34 59 95 82 84 50 79 5d 6f 73 0b fd 01 .,.4Y...Py]os...
00000110: f1 5a ce fe 86 a5 92 6b d3 42 c3 05 d9 1a 11 25 .Z.....k.B.....%
00000120: c3 02 03 01 00 01 ......
Regular ASN.1 encoding, as expected. For a PKCS8 encoded key, it should look like this:
PublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
PublicKey BIT STRING
}
Sending our base64-decoded DER data through ASN.1 decoding, we see::
openssl asn1parse -in pubkey.der -inform DER
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
That looks about right. For an RSA public key, the OID is 1.2.840.113549.1.1.1, the NULL, then what should be a RSAPublicKey as the PublicKey key data bit-string, which will look like this:
RSAPublicKey ::= SEQUENCE {
modulus INTEGER, -- n
publicExponent INTEGER -- e
}
From the aforementioned decoding, we know at offset 19 is the actual bit string, which should contain the RSAPublicKey ASN.1 structure. Great, but how? Well, the original parse has the following at offset-19 of the file:
00000010: 01 05 00 03 82 01 0f 00 30 82 01 0a 02 82 01 01 ........0.......
^^^^^^^^^^^^^^
From this we get:
The ASN.1 tag byte, 03, says its a bit-string. Good. We expected that. then...
The length is calculated. Per ASN.1 rules, if the length octet has the high bit lit, it means the remaining bits of that octet tell how many subsequent octets make up the actual length (i.e it can be a multi-byte length). 82 means two octets follow, indicating
the bit-string overall object length: 010f, e.g. 271 bytes.
Immediately following the length description will be a single octet stating the number of padding bits of the bit-string. I can honestly say in a quarter century of staring at these I have never seen this any value other than zero (00) in any RSA encoded public key, but still worth mentioning.
Thereafter is the actual RSAPublicKey ASN.1 structure itself. Past the bit-string type-length-padding description, we can parse the actual RSAPublicKey (finally!). The bit-string content after the type-length and padding bits indicator should be just that. Well, that's at offset 24 of our DER-encoding, so:
openssl asn1parse -in pubkey.der -inform DER -offset 24
0:d=0 hl=4 l= 266 cons: SEQUENCE
4:d=1 hl=4 l= 257 prim: INTEGER :EF3DA8C9E3EDE6F35B1FB3DB89E8B004E8119C2532C94BD4A3A5A2FAEA945AF331AE38B5BC7DB55624D960B8E0E3446BBA5482185C23CF09C8E0032D11D219EEE3A8975D84DF139960D8304C16833424FDA7421862E15519F432C656AFAFBA1221A68D9A5491CBED28B35C62EC88883C21C4FFB9DF89F0D08AA1AD6FA6FA4C13B03F741783921DAD78AA40902593EF12D173E16E7C30CD63A196B47759FB6A8F29413D21920C94281747C9E61D9C036C89886A93577ED84534E13D699012ECFC363C786D3684693BA5E7F50D8527A5B3B92177F22F1D5F6837A4F6A3857FFDF02CCA345995828450795D6F730BFD01F15ACEFE86A5926BD342C305D91A1125C3
265:d=1 hl=2 l= 3 prim: INTEGER :010001
Sure enough, there it is, the modulus and the exponent as expected. Extracting and decoding from there is just a matter of code, but at least now it is code based on decoding by calculation and not guessing.
Fair Warning
The only reason why this worked is because we knew the RSAPublicKey was in the bit string, and the only reason we knew that was because the OID says it was. The form stored in the bit-string is dependent on that OID, so make sure to check it first before assuming the bit-string is RSAPublicKey material.
You are asking how to generate a public key, but I don't understand why you show some binary data you are trying to decode. You can not learn how to generate a public or private key from looking at binary data which i assume is already encrypted.
Why not use a library to generate a key pair and be done with it? Trying to code something yourself, from scratch, is likely (very likely in fact) to have errors which lead to really insecure conditions.
In any event, you can download the source code to ssl libraries like openssl if you want to see what you can learn from them.
I'm working with zlib and have some problem with decompression. I try to decompress packets that come to my program, but only the first packet is decompessed correctly. For example :
//first compressed packet
78 5e 72 65 60 08 65 bf cd c0 60 28 98 3f 95 03
08 18 19 19 25 18 4c af b9 32 38 0a a4 d6 6c 6d
6c 60 60 04 42 20 60 31 2b c9 37 61 c9 2c 28 33
e3 cc cd 4c 2e ca 2f ce 4f 2b 61 4e ce cf 65 00
29 38 c0 03 51 c6 7c 9b 81 e5 40 44 32 23 00
//first decompressed packet
//inflate return 0
45 00 00 55 07 db 00 00 31 11 6f 95 08 08 08 08
01 01 01 18 00 35 d6 45 00 41 10 65 7c b5 81 80
00 01 00 01 00 00 00 00 04 36 74 6f 34 04 69 70
76 36 09 6d 69 63 72 6f 73 6f 66 74 03 63 6f 6d
00 00 01 00 01 c0 0c 00 01 00 01 00 00 03 db 00
04 c0 58 63 01
But when i try to decompress second packet "inflate" function return me -3 and decompress nothing. Example for second compressed packet :
//second compressed packet
//inflate return -3
72 65 60 f0 62 bf 03 36 74 3e c2 d0 77 cb 19 cc
de cc d8 18 8c 30 94 b9 20 b1 92 35 33 bf 38 b1
84 a9 a8 14 c5 24 17 2f 06 96 88 63 e7 ad 01 00
I try to initialize decompresor with parameters MAX_WBITS,-MAX_WBITS,30 but it did not help.How can I solve this problem?
Code example :
//functions
InitZDecompressor = ( int (WINAPI *)( z_stream_s*, int,const char*,int)) GetProcAddress(zlibdll,"inflateInit2_");
ZDecompressor = (int (WINAPI *)(z_stream_s*,int)) GetProcAddress(zlibdll,"inflate");
ResetZDecompressor = (int (WINAPI *)(z_stream_s*)) GetProcAddress(zlibdll,"inflateEnd");
//initialize
__int32 Decoder(unsigned __int8* PDU, unsigned __int32 size, unsigned __int8 * out_b, z_stream_s & stream, bool & IsInit)
{
if (IsDllLoaded == false || PDU == nullptr) { return 0; }//if Zlib DLL was not loaded, or incoming packet is not cTCP
if ( !IsInit )
{
SecureZeroMemory(&stream, sizeof(stream));
auto res = InitZDecompressor( &stream, MAX_WBITS , "1.2.11", sizeof(z_stream_s));//initialize only one time
IsInit = true;
}
stream.next_in = PDU;
stream.avail_in = size;
stream.next_out = out_b;
stream.avail_out = 1048576;
stream.total_out = 0;
__int32 ret = 0;
//inflate
while ( stream.avail_in && ret == 0 )
{
ret = ZDecompressor(&stream, 2);
}
return ret;
}
//inflateEnd
void ResetDecompessor(bool & isInit, z_stream_s & stream)
{
if (isInit){
ResetZDecompressor(&stream);
isInit = false;
memset(&stream, 0 ,sizeof(stream));
}
}
//test func
void testZlib(unsigned __int8 *StPt, __int64 size,z_stream_s & stream,bool & isInit)
{
// StPt - start of compressed data
//size - size of compressed data
//isInit - is zStream already initialize
unsigned __int8 * OutBuf = new unsigned __int8[ 1048576 ];
auto res = zlib->Decoder( StPt,size, OutBuf, stream, isInit );
delete [] OutBuf;
}
What's happening here is that the sender is flushing the deflate compressor with an empty stored block in order to produce a decompressible packet, and then deleting the last four bytes of the empty stored block, expecting you, the receiver, to insert that.
So what you need to do is insert the bytes 00 00 ff ff between the compressed packets, and then decompress the whole thing as one zlib stream. Do not initialize inflate for the second packet -- just keep feeding compressed data to the inflator (including the inserted bytes).
I try to send header frame and data frame with HPACK, and I received goaway frame with COMPRESSION_ERROR (0x9) from APNS.
my step:
send setting frame
recv setting frame
send ACK
recv ACK
send header frame
send data frame
requset:
HEADERS
- END_STREAM
+ END_HEADERS
:method = POST
:scheme = https
:path = /3/device/ad92823c9e42e37241b6cdf6f583c6cdf5dcc21289c57fb6641213abeff8095d
host = api.development.push.apple.com
DATA
+ END_STREAM
{ "aps" : { "alert" : "Hello" } }
Hex:
00 00 77 01 04 00 00 00 01 HEADER FRAME
83 :method = POST
86 :scheme = https
04 :path = (Literal Header Field without Indexing)
4a length(74)
2f 33 2f 64 65 76 69 63 /3/device/ad92823c9e42e37241b6cdf6f583c6cdf5dcc21289c57fb6641213abeff8095d
65 2f 61 64 39 32 38 32
33 63 39 65 34 32 65 33
37 32 34 31 62 36 63 64
66 36 66 35 38 33 63 36
63 64 66 35 64 63 63 32
31 32 38 39 63 35 37 66
62 36 36 34 31 32 31 33
61 62 65 66 66 38 30 39
35 64
66 host =
1e length(30)
61 70 69 2e 64 65 76 65 api.development.psuh.apple.com
6c 6f 70 6d 65 6e 74 2e
70 75 73 68 2e 61 70 70
6c 65 2e 63 6f 6d
00 00 21 00 01 00 00 00 01 DATA FRAME
7b 20 22 61 70 73 22 20 { "aps" : { "alert" : "hello" } }
3a 20 7b 20 22 61 6c 65
72 74 22 20 3a 20 22 68
65 6c 6c 6f 22 20 7d 20
7d
any tips?
thanks
In the registry there is one (or more) key depending how many monitors you have HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\DISPLAY\DEL404C{Some Unique ID}\Device Parameters\EDID which is a REG_BINARY key. In my case this is :
00 ff ff ff ff ff ff 00 4c 2d 6f 03 39 31 59 4d
07 12 01 03 0e 29 1a 78 2a 80 c5 a6 57 49 9b 23
12 50 54 bf ef 80 95 00 95 0f 81 80 81 40 71 4f
01 01 01 01 01 01 9a 29 a0 d0 51 84 22 30 50 98
36 00 ac ff 10 00 00 1c 00 00 00 fd 00 38 4b 1e
51 0e 00 0a 20 20 20 20 20 20 00 00 00 fc 00 53
79 6e 63 4d 61 73 74 65 72 0a 20 20 00 00 00 ff
00 48 56 44 51 32 30 36 37 37 37 0a 20 20 00 ef
My question is how can I read only model of monitor ("SyncMaster" for example) and not all of the information using C or C++?
The format of EDID is described here: http://en.wikipedia.org/wiki/Extended_display_identification_data
What you're interested in here is the descriptor blocks of the EDID, which are found in the byte ranges 54-71, 72-89, 90-107, and 108-125. Here's those four blocks in your EDID:
#1: 9a29 a0d0 5184 2230 5098 3600 acff 1000 00
#2: 0000 00fd 0038 4b1e 510e 000a 2020 2020 20
#3: 0000 00fc 0053 796e 634d 6173 7465 720a 20
#4: 0000 00ff 0048 5644 5132 3036 3737 370a 00
You can identify the descriptor containing the monitor name because the first three bytes are all zero (so it isn't a detailed timing descriptor), and the fourth one byte FC (indicating the type). The fifth byte and beyond contain the name, which is here:
5379 6e63 4d61 7374 6572 0a20 SyncMaster..
So, in short: Check at offsets 54, 72, 90, and 108 for the sequence 00 00 00 FC; if you find a match, the monitor name is the next 12 bytes.
using FFMPEG API, I try to encode a x264 video to a MP4 file with 0 frame latency and also, in realtime, show the currently encoded frame on screen (with encoding artifacts). The encoding to the file works, but so far I don't get the frames decoded right after writing them to the file. What I try is to feed the packetdata that is returned from avcodec_encode_video() right into avcodec_decode_video2() but the function returns -1 and the cmd output shows:
[h264 # 00000000025F0710] non-existing PPS 0 referenced
[h264 # 00000000025F0710] decode_slice_header error
[h264 # 00000000025F0710] no frame
here is some code i use for encoding:
AVPacket FFMpegEncoder2::write_video_frame(AVFrame* pic, int &numBytes)
{
int out_size, ret;
AVPacket pkt;
/* encode the image */
out_size = avcodec_encode_video(m_cctx, m_outbuf,
m_outbufSize, pic);
/* If size is zero, it means the image was buffered. */
assert(out_size>0) //0 frame delay
av_init_packet(&pkt);
if (m_cctx->coded_frame->pts != AV_NOPTS_VALUE)
pkt.pts = av_rescale_q(m_cctx->coded_frame->pts,m_cctx->time_base, m_video_st->time_base);
if (m_cctx->coded_frame->key_frame)
pkt.flags |= AV_PKT_FLAG_KEY;
pkt.stream_index = m_video_st->index;
pkt.data = m_outbuf;
pkt.size = out_size;
/* Write the compressed frame to the media file. */
ret = av_interleaved_write_frame(m_fctx, &pkt);
if (ret != 0) {
fprintf(stderr, "Error while writing video frame\n");
exit(1);
}
numBytes = out_size;
return pkt;
}
and then I take this returned packet and feed it into the decoder:
const AVFrame* FFMpegDecoder2::decode(AVPacket* packet){
AVPacket pkt;
av_init_packet(&pkt);
pkt.size = packet->size;
pkt.data = packet->data;
int len=0;
int got_picture=0;
while (pkt.size > 0) {
len = avcodec_decode_video2(m_cctx, m_frame, &got_picture, &pkt);
if (len < 0) {
fprintf(stderr, "Error while decoding frame %d\n", m_f);
exit(1);
}
if (got_picture) {
assert(pkt.size==len);
m_f++;
}
pkt.size -= len;
pkt.data += len;
}
assert(got_picture);
return m_frame;
}
but as stated, avcodec_decode_video2() returns -1
what am I doing wrong? Do i need to feed some headerdata into the decoder first somehow?
//edit:
if i set
m_formatCtx->oformat->flags &= ~AVFMT_GLOBALHEADER;
m_codecctx->flags &= ~CODEC_FLAG_GLOBAL_HEADER;
then i can decode the returned packet without error, but the written mp4 file will be black.
//edit: this is how i setup the decoder:
FFMpegDecoder2::FFMpegDecoder2(CodecID id)
: m_codec(NULL)
, m_cctx(NULL)
{
/* Initialize libavcodec, and register all codecs and formats. */
avcodec_register_all();
m_codec = avcodec_find_decoder(id);
if (!m_codec) {
fprintf(stderr, "codec not found\n");
exit(1);
}
m_cctx = avcodec_alloc_context3(m_codec);
m_cctx->codec = m_codec;
m_cctx->pix_fmt = PIX_FMT_YUV420P;
avcodec_open2(m_cctx, m_codec, NULL);
//alloc frame
m_frame = avcodec_alloc_frame();
}
this is what the memory window shows for the first packet (didn't copy all. the size of the first packet is 7859):
0x0000000002E66670 00 00 01 06 05 ff ff 55 dc 45 e9 bd e6 d9 48 b7 96 2c d8 20 d9 23 ee ef 78 32 36 34 20 2d 20 63 6f 72 65 20 31 32 30 20 72 32 31 34 36 20 62 .....ÿÿUÜEé.æÙH·–,Ø Ù#îïx264 - core 120 r2146 b
0x0000000002E6669F 63 64 34 31 64 62 20 2d 20 48 2e 32 36 34 2f 4d 50 45 47 2d 34 20 41 56 43 20 63 6f 64 65 63 20 2d 20 43 6f 70 79 6c 65 66 74 20 32 30 30 33 cd41db - H.264/MPEG-4 AVC codec - Copyleft 2003
0x0000000002E666CE 2d 32 30 31 31 20 2d 20 68 74 74 70 3a 2f 2f 77 77 77 2e 76 69 64 65 6f 6c 61 6e 2e 6f 72 67 2f 78 32 36 34 2e 68 74 6d 6c 20 2d 20 6f 70 74 -2011 - http://www.videolan.org/x264.html - opt
0x0000000002E666FD 69 6f 6e 73 3a 20 63 61 62 61 63 3d 30 20 72 65 66 3d 33 20 64 65 62 6c 6f 63 6b 3d 31 3a 30 3a 30 20 61 6e 61 6c 79 73 65 3d 30 78 33 3a 30 ions: cabac=0 ref=3 deblock=1:0:0 analyse=0x3:0
0x0000000002E6672C 78 31 31 33 20 6d 65 3d 68 65 78 20 73 75 62 6d 65 3d 34 20 70 73 79 3d 31 20 70 73 79 5f 72 64 3d 31 2e 30 30 3a 30 2e 30 30 20 6d 69 78 65 x113 me=hex subme=4 psy=1 psy_rd=1.00:0.00 mixe
0x0000000002E6675B 64 5f 72 65 66 3d 31 20 6d 65 5f 72 61 6e 67 65 3d 31 36 20 63 68 72 6f 6d 61 5f 6d 65 3d 31 20 74 72 65 6c 6c 69 73 3d 30 20 38 78 38 64 63 d_ref=1 me_range=16 chroma_me=1 trellis=0 8x8dc
0x0000000002E6678A 74 3d 31 20 63 71 6d 3d 30 20 64 65 61 64 7a 6f 6e 65 3d 32 31 2c 31 31 20 66 61 73 74 5f 70 73 6b 69 70 3d 31 20 63 68 72 6f 6d 61 5f 71 70 t=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp
0x0000000002E667B9 5f 6f 66 66 73 65 74 3d 30 20 74 68 72 65 61 64 73 3d 31 20 73 6c 69 63 65 64 5f 74 68 72 65 61 64 73 3d 30 20 6e 72 3d 30 20 64 65 63 69 6d _offset=0 threads=1 sliced_threads=0 nr=0 decim
0x0000000002E667E8 61 74 65 3d 31 20 69 6e 74 65 72 6c 61 63 65 64 3d 30 20 62 6c 75 72 61 79 5f 63 6f 6d 70 61 74 3d 30 20 63 6f 6e 73 74 72 61 69 6e 65 64 5f ate=1 interlaced=0 bluray_compat=0 constrained_
0x0000000002E66817 69 6e 74 72 61 3d 30 20 62 66 72 61 6d 65 73 3d 30 20 77 65 69 67 68 74 70 3d 32 20 6b 65 79 69 6e 74 3d 32 35 20 6b 65 79 69 6e 74 5f 6d 69 intra=0 bframes=0 weightp=2 keyint=25 keyint_mi
0x0000000002E66846 6e 3d 32 20 73 63 65 6e 65 63 75 74 3d 34 30 20 69 6e 74 72 61 5f 72 65 66 72 65 73 68 3d 30 20 72 63 3d 61 62 72 20 6d 62 74 72 65 65 3d 30 n=2 scenecut=40 intra_refresh=0 rc=abr mbtree=0
0x0000000002E66875 20 62 69 74 72 61 74 65 3d 34 30 30 20 72 61 74 65 74 6f 6c 3d 31 2e 30 20 71 63 6f 6d 70 3d 30 2e 36 30 20 71 70 6d 69 6e 3d 30 20 71 70 6d bitrate=400 ratetol=1.0 qcomp=0.60 qpmin=0 qpm
0x0000000002E668A4 61 78 3d 36 39 20 71 70 73 74 65 70 3d 34 20 69 70 5f 72 61 74 69 6f 3d 31 2e 34 30 20 61 71 3d 31 3a 31 2e 30 30 00 80 00 00 00 01 65 88 84 ax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00.€....eˆ.
0x0000000002E668D3 11 ef ff f8 22 0f 8a 00 02 09 7e 38 00 08 45 c7 00 01 1d c9 39 3d 87 ff e0 ac 13 03 6d 05 f1 00 10 00 10 12 88 04 00 04 02 60 70 4e 2d cc 38 .ïÿø".Š...~8..EÇ...É9=.ÿà¬..m.ñ.....ˆ....`pN-Ì8
0x0000000002E66902 27 16 e6 07 21 1a e6 1c 84 6b 9f f0 f0 27 15 f2 7b 87 ff c1 58 2a 8a 00 04 b8 80 00 58 00 04 02 62 01 03 c1 c1 04 63 07 04 11 88 90 b1 89 0b '.æ.!.æ..kŸðð'.ò{.ÿÁX*Š..¸€.X...b..ÁÁ.c...ˆ.±..
0x0000000002E66931 1f 2c 11 02 b1 40 00 87 8f a4 f7 0f ff 82 b0 55 06 93 41 c4 10 51 00 00 40 14 00 04 00 a3 b7 35 b7 30 38 26 1e e6 1c 13 0f 73 f2 c1 10 2b 14 .,..±#...¤÷.ÿ.°U.“AÄ.Q..#....£·5·08&.æ...sòÁ.+.
0x0000000002E66960 1f 1f 1c 32 7f 94 11 82 a1 40 01 f1 00 00 40 14 01 22 00 01 e0 1e 22 0a e3 83 1c 19 3d f8 7f e0 b0 16 03 01 22 0f 88 00 02 00 00 16 20 01 17 ...2.”..¡#.ñ..#.."..à.".ãƒ..=ø.à°...".ˆ..... ..
0x0000000002E6698F 03 84 c2 5c 87 09 84 b9 06 4a e4 a4 ae 08 82 d8 e0 00 20 0f 1d 93 df c3 fe 0b 01 54 50 07 88 a8 80 00 64 09 88 58 88 58 83 84 1d 88 38 41 d8 ..Â\.....J䤮..Øà. ..“ßÃþ..TP.ˆ¨€.d.ˆXˆXƒ..ˆ8AØ
0x0000000002E669BE f2 c1 10 2b 14 00 08 f8 e0 00 62 38 64 ff 08 70 13 0a c1 d2 e9 b5 5d ba 10 80 09 a2 01 2e 07 04 c2 dc 87 04 c2 dc 81 c8 66 b9 0e 43 35 cb 0f òÁ.+...øà.b8dÿ.p..ÁÒéµ]º.€.¢....ÂÜ..ÂÜ.Èf..C5Ë.
0x0000000002E669ED ff c1 10 27 2c 00 7e 8e 00 05 64 e4 f6 1f ff 82 28 a0 00 21 99 e3 80 00 99 ac 70 00 11 39 93 93 d8 7f fe 0a c1 40 34 9a 0b e3 40 00 84 40 01 ÿÁ.',.~Ž..däö.ÿ.( .!™ã€.™¬p..9““Ø.þ.Á#4š.ã#..#.
0x0000000002E66A1C 00 01 02 88 fd cd 7d cc 0e 08 a4 dc c3 82 29 37 3f e0 88 14 8b f1 c3 1c 03 27 f0 c3 60 a0 50 62 86 da 36 1f 10 00 0a 80 00 80 14 40 00 20 00 ...ˆýÍ}Ì..¤ÜÃ.)7?àˆ..ñÃ..'ðÃ` Pb.Ú6....€.€.#. .
and this is the encoders output (until after encoding frame 0):
[libx264 # 00000000005ADAA0] using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShu
ffle SSE4.2
[libx264 # 00000000005ADAA0] profile High, level 3.0
[libx264 # 00000000005ADAA0] 264 - core 120 r2146 bcd41db - H.264/MPEG-4 AVC cod
ec - Copyleft 2003-2011 - http://www.videolan.org/x264.html - options: cabac=0 r
ef=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=4 psy=1 psy_rd=1.00:0.00 mixed
_ref=1 me_range=16 chroma_me=1 trellis=0 8x8dct=1 cqm=0 deadzone=21,11 fast_pski
p=1 chroma_qp_offset=0 threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0 b
luray_compat=0 constrained_intra=0 bframes=0 weightp=2 keyint=25 keyint_min=2 sc
enecut=40 intra_refresh=0 rc=abr mbtree=0 bitrate=100 ratetol=1.0 qcomp=0.60 qpm
in=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
Output #0, mp4, to 'out2.mp4':
Stream #0:0: Video: h264, yuv420p, 640x480, q=-1--1, 100 kb/s, 90k tbn, 25 t
bc
[mp4 # 0000000000467570] Encoder did not produce proper pts, making some up.
This my packet data:
00 00 00 01 67 64 00 1F AC 56 24 02 80 DA 10 00
00 03 00 10 00 00 03 03 C0 F1 83 18 98 00 00 00
01 68 E8 8E 0B CB 22 C0 00 00 00 01 65 88 82 00
The first a few bytes for a first h264 packet should somewhat look like this.
00 00 00 01 ?7 ... 00 00 00 01 ?8 ... 00 00 00 01 ?5
?7 -> sps
?8 -> pps
?5 -> idr picture
There might be something else like ?6, which is sei, etc. But with SPS, PPS and the idr picture, the decoder should be able to initialize itself properly.
Another case might be the packet contains more than one picture (00 00 00 01 ?5, or 00 00 00 01 ?1). As far as I know, the decoder cannot handle h264 packets with more than one pictures properly.