Bash extracting multiple values - bash

I'm working on extracting data from SNMP services. The output looks like this.
experimental.94.4.5.1.6.16.0.0.192.221.13.147.179.0.0.0.0.0.0.0.0.1 = Hex-STRING: 00 00 00 1A 85 95 13 F4
experimental.94.4.5.1.6.16.0.0.192.221.13.147.179.0.0.0.0.0.0.0.0.24 = Hex-STRING: 00 00 10 8E 0C F4 99 1C
experimental.94.4.5.1.6.16.0.0.192.221.31.68.71.0.0.0.0.0.0.0.0.10 = Hex-STRING: 00 00 17 10 45 A5 13 3C
I would like the output to be in three parts.
192.221.13.147.179 1 0000001A859513F4
192.221.13.147.179 24 0000108E0CF4991C
192.221.31.68.71 10 0000171045A5133C
I can accomplish all 3 individually using awk but not all at once.
awk '{print substr($0,28,35)}'


you can use:
awk 'BEGIN{FS="[.: ]"}{print $10"."$11"."$12"."$13"."$14" "$23" "$27$28$29$30$31$32$33$34}'

Related

Authentication Error: DESfire against SAM with 3DES algorithm

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?

Which Registry Editor Version to initiate reg file with when editing the Windows registry (if needed at all)?

According to Microsoft knowledge base article 310516, one should initiate .reg files editing the Windows registry with either
Windows Registry Editor Version 5.00
for Windows 2000, Windows XP, and Windows Server 2003
or
REGEDIT4
for Windows 95, Windows 98 and Windows NT 4.0.
When on Windows 7, is it correct to initiate with Windows Registry Editor Version 5.00 or should one state version 6 instead?
Is it in fact needed at all when running a .bat file instead?
For current version click in Registry Editor in menu Help on menu item About Registry Editor.

There are used mainly two standard applications to process Windows registry from within a batch file:
reg.exe
regedit.exe
On Windows x64 both exist as 32-bit and as 64-bit applications whereby the 32-bit versions access the registry like 32-bit applications which means registry redirector is active and registry keys for 64-bit applications are not visible for 32-bit REG and REGEDIT.
It is in general better to use REG instead of REGEDIT for getting (read access) or setting (write access) just a few keys or values in batch files.
The usage of REGEDIT requires always administrator privileges since Windows Vista even when just used to export keys into a registry file (read access) or when importing data from a registry file (write access) to HKEY_CURRENT_USER (short: HKCU).
By using REG many operations like QUERY (read access) or ADD (write access) to HKCU don't need administrator privileges. Of course a write access to HKEY_LOCAL_MACHINE (short: HKLM) requires administrator privileges as also other not often used operations. Running in a command prompt window reg /? shows the available operations. reg query /? and reg add /? executed in a console window displays syntax and options to get (query) or set (add) data in Windows registry.
A *.reg file is interpreted on import only as file with valid registry data if the first line of the file contains
REGEDIT4
or
Windows Registry Editor Version 5.00
This is not the version of registry editor or the Windows version. It is a version information for format of the registry data in the file itself. So it is a registry file format version. The first line of a registry file must have one of those two strings.
An attempt importing a *.reg file without this header line results in an error.
Windows 2000 (has also regedt32.exe) and later versions of Windows support registry files in both format versions, 4 and 5.
Windows 95, 98, Millennium and NT4 support only registry files in format 4.
So it depends nowadays (year 2016) mainly on the data which format to use for a registry file.
The main difference is the supported encoding of text data.
Registry files in format REGEDIT4 can be only text files with 1 byte per character using the code page defined in Windows Locales and Languages settings for non Unicode aware applications which is Windows-1252 for North American and Western European countries. Therefore registry files in format REGEDIT4 cannot contain Unicode characters with a code value greater 255 (decimal, 0xFF hexadecimal).
Registry files in format Windows Registry Editor Version 5.00 support text encoded with more than 1 byte per character according to Unicode standard. Therefore *.reg files in format Windows Registry Editor Version 5.00 are created by REGEDIT as UTF-16 Little Endian encoded text files with Byte Order Mark (FF FE).
So it does not matter which file format to use if the data to import / export is binary or text using only ASCII characters (code value < decimal 128) as 99.99 % of all registry data.
For non ASCII characters it is already important to know which code page is used by Windows command interpreter as this is usually an OEM code page like code page 437 (US, Canada) or code page 850 (Western Europe) being different from GUI code page Windows-1252. Running in a command prompt window chcp or mode con outputs the default code page used on current computer by Windows command interpreter for console.
If it is really necessary to support also Unicode strings, it is necessary to use format Windows Registry Editor Version 5.00.
Let us look on a hypothetical Unicode example:
In Windows registry under key HKCU\RegFormat there are two Unicode strings defined:
A string of type REG_SZ with name Two Not Equal 3 with Unicode string value:
2 ≠ 3
A multi-line string of type REG_MULTI_SZ with name Formulas with Unicode string value:
2 µs × 3 = 6 µs
A = π × r²
See the Microsoft articles Registry Value Types, Distributing Registry Changes and Data Types in the Registry for details about registry value types.
Exporting key HKCU\RegFormat in format Windows Registry Editor Version 5.00 being the standard format since Windows 2000 results in a UTF-16 LE encoded text file with 596 bytes with content:
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\RegFormat]
"Two Not Equal 3"="2 ≠ 3"
"Formulas"=hex(7):32,00,20,00,b5,00,73,00,20,00,d7,00,20,00,33,00,20,00,3d,00,\
20,00,36,00,20,00,b5,00,73,00,00,00,41,00,20,00,3d,00,20,00,c0,03,20,00,d7,\
00,20,00,72,00,b2,00,00,00,00,00
The byte stream of this file is displayed in a hexadecimal viewer/editor as:
00000000h: FF FE 57 00 69 00 6E 00 64 00 6F 00 77 00 73 00 ; ÿþW.i.n.d.o.w.s.
00000010h: 20 00 52 00 65 00 67 00 69 00 73 00 74 00 72 00 ; .R.e.g.i.s.t.r.
00000020h: 79 00 20 00 45 00 64 00 69 00 74 00 6F 00 72 00 ; y. .E.d.i.t.o.r.
00000030h: 20 00 56 00 65 00 72 00 73 00 69 00 6F 00 6E 00 ; .V.e.r.s.i.o.n.
00000040h: 20 00 35 00 2E 00 30 00 30 00 0D 00 0A 00 0D 00 ; .5...0.0.......
00000050h: 0A 00 5B 00 48 00 4B 00 45 00 59 00 5F 00 43 00 ; ..[.H.K.E.Y._.C.
00000060h: 55 00 52 00 52 00 45 00 4E 00 54 00 5F 00 55 00 ; U.R.R.E.N.T._.U.
00000070h: 53 00 45 00 52 00 5C 00 52 00 65 00 67 00 46 00 ; S.E.R.\.R.e.g.F.
00000080h: 6F 00 72 00 6D 00 61 00 74 00 5D 00 0D 00 0A 00 ; o.r.m.a.t.].....
00000090h: 22 00 54 00 77 00 6F 00 20 00 4E 00 6F 00 74 00 ; ".T.w.o. .N.o.t.
000000a0h: 20 00 45 00 71 00 75 00 61 00 6C 00 20 00 33 00 ; .E.q.u.a.l. .3.
000000b0h: 22 00 3D 00 22 00 32 00 20 00 60 22 20 00 33 00 ; ".=.".2. .`" .3.
000000c0h: 22 00 0D 00 0A 00 22 00 46 00 6F 00 72 00 6D 00 ; ".....".F.o.r.m.
000000d0h: 75 00 6C 00 61 00 73 00 22 00 3D 00 68 00 65 00 ; u.l.a.s.".=.h.e.
000000e0h: 78 00 28 00 37 00 29 00 3A 00 33 00 32 00 2C 00 ; x.(.7.).:.3.2.,.
000000f0h: 30 00 30 00 2C 00 32 00 30 00 2C 00 30 00 30 00 ; 0.0.,.2.0.,.0.0.
00000100h: 2C 00 62 00 35 00 2C 00 30 00 30 00 2C 00 37 00 ; ,.b.5.,.0.0.,.7.
00000110h: 33 00 2C 00 30 00 30 00 2C 00 32 00 30 00 2C 00 ; 3.,.0.0.,.2.0.,.
00000120h: 30 00 30 00 2C 00 64 00 37 00 2C 00 30 00 30 00 ; 0.0.,.d.7.,.0.0.
00000130h: 2C 00 32 00 30 00 2C 00 30 00 30 00 2C 00 33 00 ; ,.2.0.,.0.0.,.3.
00000140h: 33 00 2C 00 30 00 30 00 2C 00 32 00 30 00 2C 00 ; 3.,.0.0.,.2.0.,.
00000150h: 30 00 30 00 2C 00 33 00 64 00 2C 00 30 00 30 00 ; 0.0.,.3.d.,.0.0.
00000160h: 2C 00 5C 00 0D 00 0A 00 20 00 20 00 32 00 30 00 ; ,.\..... . .2.0.
00000170h: 2C 00 30 00 30 00 2C 00 33 00 36 00 2C 00 30 00 ; ,.0.0.,.3.6.,.0.
00000180h: 30 00 2C 00 32 00 30 00 2C 00 30 00 30 00 2C 00 ; 0.,.2.0.,.0.0.,.
00000190h: 62 00 35 00 2C 00 30 00 30 00 2C 00 37 00 33 00 ; b.5.,.0.0.,.7.3.
000001a0h: 2C 00 30 00 30 00 2C 00 30 00 30 00 2C 00 30 00 ; ,.0.0.,.0.0.,.0.
000001b0h: 30 00 2C 00 34 00 31 00 2C 00 30 00 30 00 2C 00 ; 0.,.4.1.,.0.0.,.
000001c0h: 32 00 30 00 2C 00 30 00 30 00 2C 00 33 00 64 00 ; 2.0.,.0.0.,.3.d.
000001d0h: 2C 00 30 00 30 00 2C 00 32 00 30 00 2C 00 30 00 ; ,.0.0.,.2.0.,.0.
000001e0h: 30 00 2C 00 63 00 30 00 2C 00 30 00 33 00 2C 00 ; 0.,.c.0.,.0.3.,.
000001f0h: 32 00 30 00 2C 00 30 00 30 00 2C 00 64 00 37 00 ; 2.0.,.0.0.,.d.7.
00000200h: 2C 00 5C 00 0D 00 0A 00 20 00 20 00 30 00 30 00 ; ,.\..... . .0.0.
00000210h: 2C 00 32 00 30 00 2C 00 30 00 30 00 2C 00 37 00 ; ,.2.0.,.0.0.,.7.
00000220h: 32 00 2C 00 30 00 30 00 2C 00 62 00 32 00 2C 00 ; 2.,.0.0.,.b.2.,.
00000230h: 30 00 30 00 2C 00 30 00 30 00 2C 00 30 00 30 00 ; 0.0.,.0.0.,.0.0.
00000240h: 2C 00 30 00 30 00 2C 00 30 00 30 00 0D 00 0A 00 ; ,.0.0.,.0.0.....
00000250h: 0D 00 0A 00 ; ....
The first 2 bytes being displayed with code page Windows-1252 as ÿþ are the two bytes of the UTF-16 LE BOM which is not displayed by text editors in text editing mode.
But exporting key HKCU\RegFormat in format REGEDIT4 by clicking on file type drop down list in export dialog and selecting Win9x/NT4 registry files results in an ANSI (more precise: Windows-1252) encoded text file with just 180 bytes with content:
REGEDIT4
[HKEY_CURRENT_USER\RegFormat]
"Two Not Equal 3"="2 ? 3"
"Formulas"=hex(7):32,20,b5,73,20,d7,20,33,20,3d,20,36,20,b5,73,00,41,20,3d,20,\
c0,20,d7,20,72,b2,00,00
The byte stream of this file is displayed in a hexadecimal viewer/editor as:
00000000h: 52 45 47 45 44 49 54 34 0D 0A 0D 0A 5B 48 4B 45 ; REGEDIT4....[HKE
00000010h: 59 5F 43 55 52 52 45 4E 54 5F 55 53 45 52 5C 52 ; Y_CURRENT_USER\R
00000020h: 65 67 46 6F 72 6D 61 74 5D 0D 0A 22 54 77 6F 20 ; egFormat].."Two
00000030h: 4E 6F 74 20 45 71 75 61 6C 20 33 22 3D 22 32 20 ; Not Equal 3"="2
00000040h: 3F 20 33 22 0D 0A 22 46 6F 72 6D 75 6C 61 73 22 ; ? 3".."Formulas"
00000050h: 3D 68 65 78 28 37 29 3A 33 32 2C 32 30 2C 62 35 ; =hex(7):32,20,b5
00000060h: 2C 37 33 2C 32 30 2C 64 37 2C 32 30 2C 33 33 2C ; ,73,20,d7,20,33,
00000070h: 32 30 2C 33 64 2C 32 30 2C 33 36 2C 32 30 2C 62 ; 20,3d,20,36,20,b
00000080h: 35 2C 37 33 2C 30 30 2C 34 31 2C 32 30 2C 33 64 ; 5,73,00,41,20,3d
00000090h: 2C 32 30 2C 5C 0D 0A 20 20 63 30 2C 32 30 2C 64 ; ,20,\.. c0,20,d
000000a0h: 37 2C 32 30 2C 37 32 2C 62 32 2C 30 30 2C 30 30 ; 7,20,72,b2,00,00
000000b0h: 0D 0A 0D 0A ; ....
What are the differences?
REGEDIT first converted the string of type REG_SZ from Unicode to code page Windows-1252 and then exported the data. The result is character ? instead of not equal sign with Unicode value U+2260 in string of type REG_SZ because this character is not available in code page Windows-1252.
The multi-line string has just halve of the hexadecimal values (just 1 byte per character instead of 2 bytes per character).
The small PI with Unicode value U+03C0 is stored with value C0 (just low byte) and is therefore now the character À as this character has code value 0xC0 in code page Windows-1252.
Importing the data from file in format Windows Registry Editor Version 5.00 results in getting same data in Windows registry as before.
But importing the data from file in format REGEDIT4 results in:
A string of type REG_SZ with name Two Not Equal 3 with ANSI string value:
2 ? 3
A multi-line string of type REG_MULTI_SZ with name Formulas with Unicode string value:
2 µs × 3 = 6 µs
A = À × r²
The characters µ and × and ² have a code value < 255 (decimal) and can be therefore correct stored also in registry file of format REGEDIT4. But ≠ and π can't be correct encoded in format 4.
A registry file of format Windows Registry Editor Version 5.00 must not be itself a Unicode encoded text file. It is also possible to have a Windows-1252 encoded registry file with content:
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\RegFormat]
"Two Not Equal 3"=hex(1):32,00,60,22,33,00
"Formulas"=hex(7):32,00,20,00,b5,00,73,00,20,00,d7,00,20,00,33,00,20,00,3d,00,\
20,00,36,00,20,00,b5,00,73,00,00,00,41,00,20,00,3d,00,20,00,c0,03,20,00,d7,\
00,20,00,72,00,b2,00,00,00,00,00
being displayed in a hexadecimal viewer/editor as:
00000000h: 57 69 6E 64 6F 77 73 20 52 65 67 69 73 74 72 79 ; Windows Registry
00000010h: 20 45 64 69 74 6F 72 20 56 65 72 73 69 6F 6E 20 ; Editor Version
00000020h: 35 2E 30 30 0D 0A 0D 0A 5B 48 4B 45 59 5F 43 55 ; 5.00....[HKEY_CU
00000030h: 52 52 45 4E 54 5F 55 53 45 52 5C 52 65 67 46 6F ; RRENT_USER\RegFo
00000040h: 72 6D 61 74 5D 0D 0A 22 54 77 6F 20 4E 6F 74 20 ; rmat].."Two Not
00000050h: 45 71 75 61 6C 20 33 22 3D 68 65 78 28 31 29 3A ; Equal 3"=hex(1):
00000060h: 33 32 2C 30 30 2C 36 30 2C 32 32 2C 33 33 2C 30 ; 32,00,60,22,33,0
00000070h: 30 0D 0A 22 46 6F 72 6D 75 6C 61 73 22 3D 68 65 ; 0.."Formulas"=he
00000080h: 78 28 37 29 3A 33 32 2C 30 30 2C 32 30 2C 30 30 ; x(7):32,00,20,00
00000090h: 2C 62 35 2C 30 30 2C 37 33 2C 30 30 2C 32 30 2C ; ,b5,00,73,00,20,
000000a0h: 30 30 2C 64 37 2C 30 30 2C 32 30 2C 30 30 2C 33 ; 00,d7,00,20,00,3
000000b0h: 33 2C 30 30 2C 32 30 2C 30 30 2C 33 64 2C 30 30 ; 3,00,20,00,3d,00
000000c0h: 2C 5C 0D 0A 20 20 32 30 2C 30 30 2C 33 36 2C 30 ; ,\.. 20,00,36,0
000000d0h: 30 2C 32 30 2C 30 30 2C 62 35 2C 30 30 2C 37 33 ; 0,20,00,b5,00,73
000000e0h: 2C 30 30 2C 30 30 2C 30 30 2C 34 31 2C 30 30 2C ; ,00,00,00,41,00,
000000f0h: 32 30 2C 30 30 2C 33 64 2C 30 30 2C 32 30 2C 30 ; 20,00,3d,00,20,0
00000100h: 30 2C 63 30 2C 30 33 2C 32 30 2C 30 30 2C 64 37 ; 0,c0,03,20,00,d7
00000110h: 2C 5C 0D 0A 20 20 30 30 2C 32 30 2C 30 30 2C 37 ; ,\.. 00,20,00,7
00000120h: 32 2C 30 30 2C 62 32 2C 30 30 2C 30 30 2C 30 30 ; 2,00,b2,00,00,00
00000130h: 2C 30 30 2C 30 30 0D 0A 0D 0A ; ,00,00....
Importing this registry file produces nevertheless in Windows registry the Unicode strings:
2 ≠ 3
2 µs × 3 = 6 µs
A = À × r²
Using binary representation hex(1) for a value of type REG_SZ is not standard. This example was created manually by me to demonstrate that it is possible to import a Unicode string of type REG_SZ also with a non Unicode encoded registry file which is easier to produce from within a batch file.
But if the name of a key or value contains itself a Unicode character with a code value greater U+00FF, it is really necessary to use registry file format Windows Registry Editor Version 5.00 with registry file being also Unicode encoded using 16-bit Unicode Transformation Format with little-endian format.
See function SHRegWriteUSValue for hex(?) ... REG_? registry type table.
By the way: I wrote once the UltraEdit script GetStringFromRegHex.js to get the hexadecimal values of type hex(2) ... REG_EXPAND_SZ and hex(7) ... REG_MULTI_SZ selected in a registry file opened in text editor UltraEdit displayed as text because the hexadecimal values are really hard to "read as text" for a human.
The command line
%SystemRoot%\System32\regedit.exe /a /e "%USERPROFILE%\Desktop\EntireWindowsRegistry.reg"
exports the entire Windows registry to Windows desktop in ANSI using registry file format 4.
The same command line without option /a results in an export of entire Windows registry in Unicode using registry file format 5.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts]"Segoe UI (TrueType)"="""Segoe UI Bold (TrueType)"="""Segoe UI Bold Italic (TrueType)"="""Segoe UI Italic (TrueType)"="""Segoe UI Light (TrueType)"="""Segoe UI Semibold (TrueType)"="""Segoe UI Symbol (TrueType)"=""[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontSubstitutes]"Segoe UI"="NEW-FONT-NAME"

Why is the card refusing the GPO command?

I am working with a Visa CDET contact-less test card. I have successfully selected the Application, which gave me the following result:
<= 6f 29 84 07 a0 00 00 00 03 10 10 a5 1e 50 0b 56 49 53 41 20 43 52 45 44 49 54 5f 2d 02 65 6e 9f 38 09 9f 66 04 9f 02 06 9f 37 04
The result included a PDOL which asked for the following items:
Terminal Transaction Qualifiers
Length: 4 bytes
Authorised Amount
Length: 6 bytes
Unpredictable Number
Length: 4 bytes
When it comes to the GPO command, I do have all the elements needed as shown below:
=> 80 a8 00 00 10 83 0e f3 20 40 00 00 00 00 00 12 00 bc 4b a2 3f 00
But when i run the command, I received a 67 00 error: Wrong Lc length. What could be the issue? Keep in mind the same program works perfectly when working with Visa CDET Contact test cards from the same kit.
EDIT:
About the same problem, I have a test reader that I use to confirm my readings. The reader and its program can get the GPO options and return the result for other cards, but my program is not giving me any results when I try the EXACT same command using the EXACT same card in my custom program. The result is a blank, yet the status words are 90 00 (they are separate from the returned data). Why is that?

Just assume first, that the card is right: If the length of data object 83 is 0x0F (instead of 0x0E) if I counted correctly, then the total length to be supplied in LC has to be 0x11 instead of 0x10 (tag and length to be added). This does not explain, why the contact version works, but possibly it still will work after the adjustment.

I received a 67 00 error: Wrong Lc length.
ok, its because you dont have Lc=0x00 in APDU
just add 0x00 to APDU

Decoding USPS PDF417 2D Barcode?

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 extract pixel values from a given PNG image

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

Resources