I can't finish the authentication phase.
What I am using:
SAM module by NXP
Mifare Desfire PICC
I am following the next steps:
Get PICC SerialNumber (or UID) with GetVersion.
GET VERSION:
Tx: 90 60 00 00 00
Rx: 04 01 01 00 02 18 05 91 AF
GET VERSION 2:
Tx: 90 AF 00 00 00 00
Rx: 04 01 01 00 06 18 05 91 AF
GET VERSION 3:
Tx: 90 AF 00 00 00 00
Rx: 04 65 41 49 65 1B 80 8E 65 58 51 30 46 07 91 00
Get encrypted(RndB) from PICC.
Tx: 90 0A 00 00 01 00 00
Rx: 31 15 1A 19 DB ED CD 5A 91 AF
Send to SAM PICC_SN + ek(RndB).
Tx: 80 41 01 03 0F 80 1B 65 49 41 65 04 31 15 1A 19 DB ED CD 5A
Rx: 61 20
Get from SAM encrypted(RndA + RndB_rotated) + 1st half Session Key
Tx: 00 C0 00 00 20
Rx: F3 10 55 B1 D3 18 91 5B 92 48 16 1F E1 58 D5 CB E9 F3 51 04 41 8A 4E A5 A2 B5 67 CA FF D8 D2 35 90 00
Send PICC encrypted(RndA + RndB_rotated).
Tx: 90 AF 00 00 10 F3 10 55 B1 D3 18 91 5B 92 48 16 1F E1 58 D5 CB 00
Rx: 91 AE
So, this is a guide I have received from my suplier, and i don't have explanations about the apdus used; some i have found them on the internet, some others i guessed.
What I need to know is what does the next command i use:
to SAM module: 80 41 01 03 Lc Data
I need to know what encryption it deploys, why it needs PICC's UID (is this the IV), how can i know RndB, and what is expecting the PICC to end the authentication.
Thanks
Pd: Sorry for the text's format, it seems I'm unable to use correctly the tools for posting, everything gets in the same line it's disgusting...
I solved the problem and finished authentication.
The error was that i was requesting RndB encrypted with keyNo = 0, while corresponding key from SAM's key encryption should be keyNo = 2.
So:
--> 90 0A 00 00 01 02 00
<-- 91 B6 08 CE 9F B5 34 3B 91 AF
Carrying on, i finnish authentication:
--> 90 AF 00 00 10 0F DC FA B6 37 5F 30 34 D7 93 2D A1 3D D6 11 10 00
<-- E9 C2 F2 69 FE 38 78 28 91 00
But now I have the next problem. I've authenticated and I can read PICC's data but i'm afraid it's encrypted. I suppose it is encrypted with session key, so I need some apdu command to be sent to SAM, with data and session key, in order to decrypt data retrieved from PICC.
Am I right? if that is... which would be that SAM APDU?
Related
I'm currently working on old system that uses RDP. According to 4.1.4 Server MCS Connect Response PDU with GCC Conference Create Response described in [MS-RDPBCGR], packet is containing modulus, which should be part of RSA key. And I need to know where this came from because I need to decrypt some RDP packets stored as log.
First thing I've done is looking up certificates by using mmc. But there was no certificate matching with modulus. Even if I issued new self-signed certificate, there was no luck. Modulus is not changing by it.
More specifically, this is response packet from testing server(VM) containing modulus.
0000: 03 00 02 15 02 f0 80 7f 66 82 02 09 0a 01 00 02 | ......f......
0016: 01 00 30 1a 02 01 22 02 01 03 02 01 00 02 01 01 | ..0...".........
0032: 02 01 00 02 01 01 02 03 00 ff f8 02 01 02 04 82 | .............
0048: 01 e3 00 05 00 14 7c 00 01 2a 14 76 0a 01 01 00 | .....|..*.v....
0064: 01 c0 00 4d 63 44 6e 81 cc 01 0c 10 00 0c 00 08 | ..McDn.......
0080: 00 00 00 00 00 04 00 00 00 03 0c 10 00 eb 03 04 | ...............
0096: 00 ec 03 ed 03 ee 03 ef 03 02 0c ac 01 02 00 00 | ...........
0112: 00 02 00 00 00 20 00 00 00 78 01 00 00 bb e4 de | ..... ...x...
0128: 58 1a 05 8f 26 89 f8 94 0b 88 d4 79 d4 00 ac bf | X..&.y.
0144: e0 07 72 3a e5 9b 17 7f 17 d6 18 92 7f 01 00 00 | .r:........
0160: 00 01 00 00 00 01 00 00 00 06 00 1c 01 52 53 41 | .............RSA
0176: 31 08 01 00 00 00 08 00 00 ff 00 00 00 01 00 01 | 1..............
0192: 00 2d 13 bc 1d a9 5b c8 60 9b be 66 61 ab 09 13 | .-..[`fa..
0208: 4e 0a 1f 64 27 72 df 92 18 42 ea 2c 05 5d 0d a7 | N..d'r..B,.].
0224: f7 06 51 5d 22 2e 4a fa 03 c5 8d 52 47 7c fa 13 | .Q]".J..RG|.
0240: ec dd bb 81 15 50 4b b3 f0 7b e4 75 0e e6 0d b5 | ..PK{u..
0256: ab d2 4a 9c ab f6 8c 83 a3 53 0b 87 b1 07 fc 0f | JS...
0272: 29 12 f4 c8 18 fb 9f 6d 29 10 34 af 34 d0 ca 8d | )..m).44.
0288: 48 a9 2e 9e 85 9a 39 d6 6c be cb f3 36 75 60 a5 | H.9l6u`
0304: 56 a5 a3 f5 b0 6f af c3 8e 5b 03 11 e4 27 27 bf | Vo.[..''
0320: a0 05 51 aa f1 8d 84 11 53 43 59 b8 83 4f f2 2d | .Q.SCYO-
0336: 40 44 b1 f9 5a 5b e6 2d 32 e4 d8 ef 2a 5a f8 01 | #DZ[-2*Z.
0352: 08 7a 68 a0 05 e2 5b fe 50 b5 38 cd a6 f0 ef e0 | .zh.[P8.
0368: c4 6f 4e f3 f1 9d 0a 89 ce 79 4e 3d 6f e3 a2 b3 | oN.yN=o.
0384: c7 fd dc b2 d8 c6 76 e8 79 67 ca fe 71 5d a5 3d | .vygq]=
0400: d3 40 c4 a4 28 5c 11 b7 2a 51 cd 65 e4 5f fc 2a | #.(\.*Qe_*
0416: bf 4c b1 e0 96 89 05 4b c6 72 1a 62 eb a2 51 0d | L.Kr.bQ.
0432: 45 2f 23 27 67 0e a8 c6 12 ed 81 ee 09 58 10 02 | E/#'g...X..
0448: b2 00 00 00 00 00 00 00 00 08 00 48 00 e9 95 02 | ..........H..
0464: 48 e7 84 d6 fc 60 cd 29 b2 91 7c f4 e8 b4 36 5d | H`)|6]
0480: e5 5e b4 90 d4 d4 5d 6a a1 42 69 c6 4e 5c 87 f2 | ^]jBiN\
0496: 0a cd 86 f5 64 e3 4d 61 60 0a 17 c2 f8 94 93 83 | ..dMa`..
0512: cf 23 7d c4 a3 07 ad f0 b6 bc 1a b1 00 00 00 00 | #}.......
0528: 00 00 00 00 00 | .....
Public exponent is 01 00 01 00, modulus is 2d 13 bc 1d ... 58 10 02 b2 with additional 8 bytes of zero-padding.
After that, if I know what private exponent is, then I can decrypt Client Random and generate session key.
But as I've mentioned, I can't find where modulus is coming from. How can I obtain RSA key(or certificate, so I can use Mimikatz) for it?
Edit
I found there is Proprietary Certificate. It seems this is what I need to find, but I still don't know where it is.
Edit: I came across the Proprietary Certificate, but where is private key?
It was located at registry HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM and is just public key BLOB. Still need to find private key...
Currently I'm looking into registry key Secrets under RCM, but I don't know what are these values right now.
I'm closing this because I found public key BLOB at HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\Certificate from registry though I don't know what private key is.
When inspecting a transport stream using tsduck, I can see that some packets contains a PCR value in Hex. I am not sure how to convert these into timestamps.
For example, in the packet below the PCR value is 0x000002014CE
* Packet 179
---- TS Header ----
PID: 481 (0x01E1), header size: 25, sync: 0x47
Error: 0, unit start: 1, priority: 0
Scrambling: 0, continuity counter: 4
Adaptation field: yes (21 bytes), payload: yes (163 bytes)
Discontinuity: 0, random access: 0, ES priority: 0
PCR: 0x000002014CE
---- PES Header ----
Stream id: 0xE0 (Video 0)
PES packet length: 0 (unbounded)
---- Full TS Packet Content ----
47 41 E1 34 14 12 00 00 0D B0 7E 4E 0C 02 0A 22 8E 00 00 D1 2D 03 64 00
29 00 00 01 E0 00 00 84 C0 0A 31 00 07 44 B7 11 00 05 D4 37 00 00 00 01
09 30 00 00 01 06 01 03 03 84 19 80 00 00 01 41 9A 84 93 D1 13 7F F0 28
2C 26 B5 35 90 10 B7 32 8C FF 00 D3 47 BE 4C 9A 83 AE CD B8 9C 09 5A 60
07 BE C4 F2 2C 5D D3 24 6C 7F A0 E1 C4 7B BC FA 37 CA C5 C0 B0 C4 2C 91
96 09 07 22 C4 A8 55 FF C2 BF 0E 7E 10 74 6D 84 F2 08 9D D0 29 52 7F 2B
F6 3E C8 23 1F BC 4E 80 C3 AE FD AC F4 96 08 E5 13 C8 A7 41 20 B4 F6 F8
E1 14 4A 03 4C 8E 98 00 04 73 2D AE 83 31 0B C8 61 03 3A A1
What I tried is looking at the first few instances of packets that had the PCR values in them, then converting them to decimal and subsequently dividing by 90,000 which is the clock rate of the PCR clock (i.e the timebase).
But looking at the last column, it doesn't look right. It would seem that the intervals are too high. I thought that the PCR must insert PCR stamps at least every 100ms or so, but this seems to be too infrequent....
You are not using the correct time base. If you look at the example you posted, tsduck shows the PCR as 0x000002014CE But that hex value does not show up in that packet at all. The reason is the PCR is more than just a time stamp, Its 2 timestamps. The PCR in the hex is actually 00 00 0D B0 7E 4E So how do we get from 0xDB07E4E to 0x2014CE? We extract the 90 kHz component by shifting 0xDB07E4E right by 15 bits, Then extract the 27MHz component by masking off the top 39 bits. Then multiply the 90kHz component by 300 to convert to 27MHz (300=27000000/90000) and add the two values together:
300*(0xDB07E4E>>15) + (0xDB07E4E&0x1ffff) = 0x2014CE
We now have the 27MHz timestamp. To convert that to seconds, divide by 27000000
0x2014CE/27000000=0.0779
Hence:
0x58e54 = 0.0135
0x78707 = 0.0183
TLDR: time base is 27000000, not 90000
I'm currently working on an old MS-DOS application, which uses DMI to identify the hardware. It worked fine in the past, but it seems to provide invalid data on newer systems (e.g. Skylake). As stated in the spec, we are scanning 0xF0000-0xFFFFF for the "SM" anchor string, this is still working as expected.
But now it seems that the data located at the "Structure table adress" (stored at offset 0x18h in the) are invalid (see dumps below). Tools like dmidecoe deliver correct information (however, it uses GetSystemFirmwareTable() on Windows). What I am doing wrong here?
EDIT (clarify situation)
On an older system I get expected data (dump is done in FreeDOS' debug98 utility) - following come from an IvyBridge system (3rd gen.):
-d F000:04C0
F000:04C0 5F 53 4D 5F 03 1F 02 07-77 00 00 00 00 00 00 00 _SM_....w.......
F000:04D0 5F 44 4D 49 5F E0 6E 04-10 BA 0E 00 17 00 27 00 _DMI_.n.......'.
F000:04E0 1E 66 60 68 00 F0 1F B8-90 D0 83 C0 0F 24 F0 A3 .f`h.........$..
F000:04F0 1D 03 B9 00 E0 2B C8 79-02 33 C9 89 0E 1F 03 33 .....+.y.3.....3
F000:0500 C0 66 2E 8B 1E 63 00 66-83 FB 00 74 0B 66 81 FB .f...c.f...t.f..
F000:0510 00 00 0E 00 72 02 8B C3-A3 19 03 F7 D0 A3 1B 03 ....r...........
F000:0520 66 61 1F C3 00 1E 50 68-00 F0 1F 0B DB 74 28 F7 fa....Ph.....t(.
F000:0530 C3 80 00 74 1C 2E 80 3E-24 05 00 75 43 83 F9 3E ...t...>$..uC..>
-d E000:BA10
E000:BA10 00 18 00 00 01 02 00 F0-03 7F 80 98 89 3F 01 00 .............?..
E000:BA20 00 00 03 0D 04 06 FF FF-41 6D 65 72 69 63 61 6E ........American
E000:BA30 20 4D 65 67 61 74 72 65-6E 64 73 20 49 6E 63 2E Megatrends Inc.
E000:BA40 00 42 51 37 37 52 31 31-31 00 30 37 2F 30 35 2F .BQ77R111.07/05/
E000:BA50 32 30 31 33 00 00 01 1B-01 00 01 02 03 04 00 00 2013............
E000:BA60 01 26 60 24 00 05 00 06-00 07 00 08 00 09 06 05 .&`$............
E000:BA70 06 20 00 20 00 20 00 30-30 30 30 30 31 32 36 36 . . . .000001266
E000:BA80 30 32 34 00 20 00 20 00-00 02 0F 02 00 01 02 03 024. . .........
Newer systems - in this case a Skylake based one (6th gen.) data are different. In the adress the SMI structure points to i do not get the expected data (I expcted to see the BIOS strings, but they are not there):
-d f000:05e0
F000:05E0 5F 53 4D 5F F3 1F 03 00-8C 01 00 00 00 00 00 00 _SM_............
F000:05F0 5F 44 4D 49 5F 15 CE 07-00 90 1D 87 1A 00 30 00 _DMI_.........0.
F000:0600 5F 53 4D 33 5F 4A 18 03-00 00 01 00 CE 07 00 00 _SM3_J..........
F000:0610 00 90 1D 87 00 00 00 00-00 00 00 00 00 00 00 00 ................
F000:0620 1E 66 60 68 00 F0 1F B8-00 C6 83 C0 0F 24 F0 A3 .f`h.........$..
F000:0630 8E 03 B9 00 E0 2B C8 79-02 33 C9 89 0E 90 03 33 .....+.y.3.....3
F000:0640 C0 66 2E 8B 1E 63 00 66-83 FB 00 74 0B 66 81 FB .f...c.f...t.f..
F000:0650 00 00 0E 00 72 02 8B C3-A3 8A 03 F7 D0 A3 8C 03 ....r...........
-d 871d:9000
871D:9000 76 06 D1 E9 73 08 8A 05-A4 88 44 FF 74 08 8B 05 v...s.....D.t...
871D:9010 A5 89 44 FE E2 F8 5F 5E-5D C2 04 00 55 8B EC 4C ..D..._^]...U..L
871D:9020 4C 56 57 83 7E 04 02 73-2D 83 7E 04 02 74 03 E9 LVW.~..s-.~..t..
871D:9030 18 01 8B 46 06 03 06 AC-10 8B F8 50 FF 76 06 FF ...F.......P.v..
871D:9040 16 AE 10 59 59 0B C0 7F-03 E9 FE 00 FF 76 06 57 ...YY........v.W
871D:9050 E8 9D FF E9 F4 00 8B 46-04 48 F7 2E AC 10 8B 56 .......F.H.....V
871D:9060 06 03 D0 8B FA 8B 46 04-D1 E8 F7 2E AC 10 8B 56 ......F........V
871D:9070 06 03 D0 8B F2 57 56 FF-16 AE 10 59 59 0B C0 7E .....WV....YY..~
Your SMBIOS structures are located at physical address 0x871d9000 (as seen from offset f000:0610, or offset x10 from the '_SM3_' anchor string), as Michael Petch points out.
This is a minor point but could be important depending on how your software is constructed. Keep in mind this is a SMBIOS 3.0 conforming structure (per the "_SM3_" anchor string) and that the structure table address can be on any 64-bit address. To ensure your software works in all systems, you should use the _SM3_ structure table address when present and enable your software to read any 64-bit physical address using big-real mode or other mechanism. When the _SM3_ structure is not present, then revert back to your old software flow.
As for why you are just now seeing this, is this the first time you have encountered a data structure that is above 1MB physical address?
I have Googled a lot and failed to find the decoding algorithm for the PDF417 barcode used by United States Postal Service. I want to fetch recipient and sender information with tracking number out of it.
I have successfully decoded the FedEx barcode with ANSI MH10.8.3 standard.
My question is, am I scanning the correct barcode (I am not from USA, so I don't know which barcode label USPS applies to their parcels) ? If no, then what barcode should I look for to fetch required information ? If Yes, then how can I decode this barcode ?
Please help,
Thanks.
Edit:
Here is another similar barcode
You should check this webpage:
https://en.wikibooks.org/wiki/International_Postage_Meter_Stamp_Catalog/United_States_of_America,_Part_3
As well as this page:
http://www.stamps.com/postage-online/how-it-works/
Your first barcode seems to have been generated by Endicia software (ID# starts with 071V), while the second example barcode was generated by stamps.com (as printed, and also ID# starts with 062S).
It seems that stamps.com service allows you to print stamps without providing the recipient address. For this reason, the barcode probably doesn't include any information about the recipient.
For the record, the decoded bars are as follows:
0000 50 01 dc 78 0c 00 30 37 31 56 57 6c 08 00 7a 86 | P~~x~~071VWl~~z~ |
0010 09 c5 4e d8 27 00 8a b7 32 01 24 4f 00 00 67 49 | ~~N~'~~~2~$O~~gI |
0020 6d 15 00 b5 c3 00 00 00 00 06 c1 31 02 b9 02 90 | m~~~~~~~~~~1~~~~ |
0030 d0 a4 4a 1c 02 2a 42 8f a7 3f 6d c7 03 ea e5 d7 | ~~J~~*B~~?m~~~~~ |
0040 3c 69 86 3c 50 29 28 32 11 74 6a 7f b4 af c7 90 | <i~<P)(2~tj~~~~~ |
0050 16 c3 90 bb fb 2a fa 4e 78 95 e6 20 69 c7 75 01 | ~~~~~*~Nx~~ i~u~ |
0060 00 00 | ~~ |
and:
0000 05 01 ff ff 00 00 30 36 32 53 3b 47 70 00 f2 ed | ~~~~~~062S;Gp~~~ |
0010 10 00 00 14 1e 00 56 52 33 01 59 33 01 00 00 00 | ~~~~~~VR3~Y3~~~~ |
0020 00 00 00 00 04 00 02 00 00 5c da 00 00 38 30 33 | ~~~~~~~~~\~~~803 |
0030 34 ae 69 57 0d 59 42 1c d4 0b 00 f2 d3 7f 4f f8 | 4~iW~YB~~~~~~~O~ |
0040 ef 69 53 a0 aa fb 9b cf 30 16 13 c3 08 3e 86 4a | ~iS~~~~~0~~~~>~J |
0050 7a e8 4c fe 1f eb 4d 2c 52 05 00 6f 33 01 00 | z~L~~~M,R~~o3~~ |
Bytes 06-09 (0-indexed) is the ID prefix in ASCII.
Bytes 0A-0D is the rest of the ID, encoded in binary in little endian. 3B 47 70 00 is 0x0070473B = 7358267, for the second stamp.
For the second stamp, bytes 5B-5D (6F 33 01) is actually 01 33 6F = 78703, the zip it was posted from. Unfortunately, it doesn't work with the first stamp.
Trying to understand PNG format.
Consider this PNG Image:
The Image is taken from here
In Hex Editor , it looks like this:
89 50 4E 47 0D 0A 1A 0A 00 00 00 0D 49 48 44 52 00 00 00 80 00 00 00 44 08 02 00 00 00
C6 25 AA 3E 00 00 00 C2 49 44 41 54 78 5E ED D4 81 06 C3 30 14 40 D1 B7 34 DD FF FF 6F
B3 74 56 EA 89 12 6C 28 73 E2 AA 34 49 03 87 D6 FE D8 7B 89 BB 52 8D 3B 87 FE 01 00 80
00 00 10 00 00 02 00 40 00 00 08 00 00 01 00 20 00 00 04 00 80 00 00 10 00 00 02 00 40
00 00 08 00 00 01 00 20 00 00 00 D4 5E 6A 64 4B 94 F5 98 7C D1 F4 92 5C 5C 3E CF 9C 3F
73 71 58 5F AF 8B 79 5B EE 96 B6 47 EB F1 EA D1 CE B6 E3 75 3B E6 B9 95 8D C7 CE 03 39
C9 AF C6 33 93 7B 66 37 CF AB BF F9 C9 2F 08 80 00 00 10 00 00 02 00 40 00 00 08 00 00
01 00 20 00 00 04 00 80 00 00 10 00 00 02 00 40 00 00 08 00 00 01 00 20 00 00 8C 37 DB
68 03 20 FB ED 96 65 00 00 00 00 49 45 4E 44 AE 42 60 82
Equivalent characters:
‰PNG........IHDR...€...D.....Æ%ª>...ÂIDATx^íÔ..Ã0.#Ñ·4Ýÿÿo³tVê‰.l(sâª4I.‡ÖþØ{‰
»R.;‡þ..€.......#....... ....€.......#....... ...Ô^jdK”õ˜|Ñô’\\>Ïœ?sqX_¯
‹y[î–¶GëñêÑζãu;湕.ÇÎ.9ɯÆ3“{f7Ï«¿ùÉ/.€.......#....... ....€.......#....... ..Œ7Ûh.
ûí–e....IEND®B`‚
The same is shown in following Screenshot of the HEX Editor:
I am trying to reverse engineer this image to extract the header part and the RGB pixel values. I read about the PNG and also here , and so far I have noted the following about this Image:
The IHDR chunk must appear FIRST. It contains:
Width: 4 bytes
Height: 4 bytes
Bit depth: 1 byte
Color type: 1 byte
Compression method: 1 byte
Filter method: 1 byte
Interlace method: 1 byte
Below I am starting reading the HEX Data in sequence:
1- First 8-bytes: This is the 8-Byte signature
89 50 4E 47 0D 0A 1A 0A
Equivalently this is : %PNG as can be seen in HEX Editor
A valid PNG image must contain an IHDR chunk, one or more IDAT chunks, and an IEND chunk.
2- Chunk: Length
00 00 00 0D
3-Chunk: Chunk Type
49 48 44 52
Which is IHDR.
http://www.w3.org/TR/PNG-Chunks.html
4- Chunk: Width of the Image (in Decimal 128)
00 00 00 80
5- Chunk: Height of the image (in Decimal 68)
00 00 00 44
6- Chunk: BIT DEPTH (1 byte )
08
7- Chunk: Color Type
02
8- Compression method
00
9- Filter method:
00
10- Interlace method:
00
11- What is the following data?
C6 25 AA 3E 00 00 00 C2
12-- IDAT
49 44 41 54
13- What is this data (after IDAT):
78 5E ED D4 81 06 C3 30 14 40 D1 B7 34 DD FF FF 6F B3 74 56 EA 89 12 6C 28 73 E2 AA 34 49 03 87 D6 FE D8 7B 89 BB 52 8D 3B 87 FE 01 00 80 00 00 10 00 00 02 00 40 00 00 08 00 00 01 00 20 00 00 04 00 80 00 00 10 00 00 02 00 40 00 00 08 00 00 01 00 20 00 00 00 D4 5E 6A 64 4B 94 F5 98 7C D1 F4 92 5C 5C 3E CF 9C 3F 73 71 58 5F AF 8B 79 5B EE 96 B6 47 EB F1 EA D1 CE B6 E3 75 3B E6 B9 95 8D C7 CE 03 39 C9 AF C6 33 93 7B 66 37 CF AB BF F9 C9 2F 08 80 00 00 10 00 00 02 00 40 00 00 08 00 00 01 00 20 00 00 04 00 80 00 00 10 00 00 02 00 40 00 00 08 00 00 01 00 20 00 00 8C 37 DB 68 03 20 FB ED 96 65 00 00 00 00
14- IEND:
49 45 4E 44
15- Last 4 bytes
AE 42 60 82
What are these ?
Can some help me understand, points 11, 13 and 15 above? And where are the Pixel values? The Image is having (128 x 68 pixels)
Purpose of knowing these details:
Once I know these details, I will generate my own 16 bit PNG image. I already have pixel values, so my job would be to introduce headers etc.
I dont know if there is software that can perform this job.
UPDATE
I understand now because of compression, I would not be able to locate the pixel values.
I got the idea that I can write a file in OpenCV and save it as png. Well now my direct question is: I have a binary file having gray-scale 16 bit-pixel values. Can I write this in OpenCV as 16 bit PNG ?
Although it might be interesting to learn about what PNG Images actually are, and how the image is actually represented in the file, you don't need to know this to generate a PNG file.
Note that PNG uses lossless compression, which means you won't get two bytes per pixel.
You can generate your image in a program and output it in PNG format using many of the libraries that there are out there.
For example, you can make your image in OpenCV and then output it with imWrite. One of the parameters can make it output to a PNG.
If you have the gray-scale 16-bit pixel values, then you can put them into a Mat.
Then convert that to an IplImage: Converting cv::Mat to IplImage*
Then you can output it to a file.
Just for completeness (eboix's answer is right on the spot)
11- What is the following data?
C6 25 AA 3E 00 00 00 C2
Each chunk ends with a CRC (4 bytes), and starts with 4 bytes that tell its length.
So, C6 25 AA 3E is the CRC of the previous chunk (IHDR) and 00 00 00 C2 (194) is the length of the following (IDAT) chunk.
In the same way, the last 4 bytes is the CRC of the IEND chunk.
I did not look too carefully but from looking at the structure...
Q11.
C6 25 AA 3E = CRC32
00 00 00 C2 = Size of next chunk
Q13.
check the png spec's you referred to earlier that looks like the IDAT chunk you allready know the compression applied to it!
Q15.
AE 42 60 82 = CRC32