I need to get only the payload of network packets (without Ethernet header). I used TCPDump, I get something like :
0x0000: 4500 013f 7913 4000 4006 72ee ac10 01e3 E..?y.#.#.r.....
0x0010: c732 d894 b826 0050 9455 3f65 51f9 a5f4 ./...&.P.U?eQ...
0x0020: 8018 0990 4ee9 0000 0101 080a 0079 6387 ....N........yc.
[...]
I also tried with Scapy :
>>>hexdump(p)
0000 00 19 4B 10 38 79 00 26 5E 17 00 6E 08 00 45 00 ..K.8y.&^..n..E.
0010 00 40 90 E7 40 00 40 11 26 66 C0 A8 01 0E C0 A8 .#..#.#.&f......
0020 01 01 97 F1 00 35 00 2C 06 5A 6E 18 01 00 00 01 .....5.,.Zn.....
Do you know how to get only the middle column? (preferably all on one line)
(I tried Tshark, but it doesn't correspond to my expectations)
Thanks
There is a tcpick project on sourceforge that should do what you want.
You can use wireshark to analyzes the packets.And also you get more detailed description
Related
Does JCOP/J3A081 support int data type?
I am using latest eclipse JCOP tools for java card applet development. I need to store big integer values in a card so I have used the INTEGER data type (int) for balance in my applet. it is compiling without any error but getting error 6A80 on uploading the CAP file into JCOP J3A081 cards. I have tried all combinations of GP 2.1.1, GP 2.2.1, JDK 2.2.2, JDK 3.0.4 library but getting the same error.
Are int data type variables and JCint library supported by J3A/J2A series cards? if yes how to resolve the issue?
Applet source code:
Note: if I remove int data type variable and JCint references then no error comes.
- version
current version is 5.32.0.4 [1]
build timestamp is 27-01-2020 12:10:53
- /terminal
--Opening terminal
Session ID: 6527B91D44DD89CDE6AB60FCA590DF06
> /list-readers
----------------------
Name ( Type )
----------------------
> /card -v
Warning: Usage of /atr with no preceding of /reset is deprecated. /reset is invoked.
IOCTL().
ATR: 3B89800150565F4A334130383150
ATR:
Hist = PV_J3A081
T = 0
T = 1
=> 00 A4 04 00 00 .....
(12493 usec [SYS])
<= 6F 65 84 08 A0 00 00 00 03 00 00 00 A5 59 9F 65 oe...........Y.e
01 FF 9F 6E 06 47 91 00 78 34 00 73 4A 06 07 2A ...n.G..x4.sJ..*
86 48 86 FC 6B 01 60 0C 06 0A 2A 86 48 86 FC 6B .H..k.`...*.H..k
02 02 01 01 63 09 06 07 2A 86 48 86 FC 6B 03 64 ....c...*.H..k.d
0B 06 09 2A 86 48 86 FC 6B 04 02 15 65 0B 06 09 ...*.H..k...e...
2B 85 10 86 48 64 02 01 03 66 0C 06 0A 2B 06 01 +...Hd...f...+..
04 01 2A 02 6E 01 02 90 00 ..*.n....
Status: No Error
FCI Data:
Max. Block Length: 255
CPLC Data:
Operating System ID : 4791
Operating System release date : 0078 (18.3.20X0)
Operating System release level : 3400
Security Domain Management Data:
Global Platform Version: 2.1.1
Secure Channel Protocol: 02 (option 15)
cm> /identify
FABKEY ID: 0x02
PATCH ID: 0x21
TARGET ID: 0x00 (null)
MASK ID: 0x34 (52)
CUSTOM MASK: 00000000
MASK NAME: NX011D
FUSE STATE: fused
ROM INFO: 58E957
COMBO NAME: null-m34.02.21-NX011D
cm> get-cplc -v
=> 80 CA 9F 7F 00 .....
(8475 usec [SYS])
<= 9F 7F 2A 47 90 51 68 47 91 00 78 34 00 31 30 04 ..*G.QhG..x4.10.
81 33 96 75 18 48 12 31 37 00 00 00 00 0F 20 38 .3.u.H.17..... 8
34 38 31 33 33 00 00 00 00 00 00 00 00 90 00 48133..........
Status: No Error
IC Fabricator : 4790
IC Type : 5168
Operating System ID : 4791
Operating System release date : 0078 (18.3.20X0)
Operating System release level : 3400
IC Fabrication Date : 3130 (10.5.2003)
IC Serial Number : 04813396
IC Batch Identifier : 7518
IC Module Fabricator : 4812
IC Module Packaging Date : 3137 (17.5.2003)
ICC Manufacturer : 0000
IC Embedding Date : 0000
IC Pre-Personalizer : 0F20
IC Pre-Perso. Equipment Date : 3834
IC Pre-Perso. Equipment ID : 38313333
IC Personalizer : 0000
IC Personalization Date : 0000
IC Perso. Equipment ID : 00000000
cm> /cap-info "C:\Users\pp\eclipse-workspace\testJCOP\bin\com\pryogika\jc\javacard\jc.cap"
CAP file name : C:\Users\pp\eclipse-workspace\testJCOP\bin\com\pryogika\jc\javacard\jc.cap
CAP file version : 2.2
Java package name : com.pryogika.jc
Internal pkg. name : com/pryogika/jc
CAP file components :
Header.cap (38 Bytes)
Directory.cap (36 Bytes)
Import.cap (36 Bytes)
Applet.cap (22 Bytes)
Class.cap (17 Bytes)
Method.cap (82 Bytes)
StaticField.cap (13 Bytes)
ConstantPool.cap (41 Bytes)
RefLocation.cap (16 Bytes)
Descriptor.cap (90 Bytes)
Debug.cap (500 Bytes)
Integer support : yes
Package version : 1.0
Package AID : "HelloJCOP"
Import AIDs :
A0000000620101 (javacard.framework) version 1.3
A00000006202080101 version 1.0
A0000000620001 (java.lang) version 1.0
Applet AIDs :
"HelloJCOPApplet"
Code size to load : 301 bytes
Code size on card :
pkgAID : 9
applet AIDs : 22
classes : 17
methods : 82
statics : 0
exports : 0
-------------------------------------
overall : 130 bytes
SHA-256 (Load File data): FD9E6BDB25A9C863B83C1ECE829F66DBEAA64B38BF5CD4EA953651B110AAD209
SHA-256 (Load File dbg) : 07F25D2E0A470C0AFECCADEF1387986D70C71606E33DD339ED89F4CE1CA84467
SHA-256 (Load File) : CE72441BF5B56BB36A4AEBE3F3A96725D0A36926697B9187C3873C3437CBEAA4
SHA-1 (Load File data): C5EFC5FAAE4FB711E327F5563C48888EA56F81D5
SHA-1 (Load File dbg) : 41264E6C8F21F1C46F2BE7EBCF70CAE00624A277
SHA-1 (Load File) : EB826D7E56AFF5AAF4C4CD3FC4FB5850DD81D91F
DAP block(s) : none
Load Token(s) : none
Install Token(s) : none
Delete Token(s) : none
cm> set-key 1/1/DES-ECB/404142434445464748494a4b4c4d4e4f 1/2/DES-ECB/404142434445464748494a4b4c4d4e4f 1/3/DES-ECB/404142434445464748494a4b4c4d4e4f
cm> init-update
=> 80 50 00 00 08 11 A9 0F 67 2B 22 B6 E1 00 .P......g+"...
(37691 usec [SYS])
<= 00 00 31 30 04 81 33 96 75 18 01 02 00 3E 60 17 ..10..3.u....>`.
08 B3 12 20 F1 76 A5 F1 D0 6D 12 BD 90 00 ... .v...m....
Status: No Error
cm> ext-auth plain
=> 84 82 00 00 10 3F BE FC 67 E2 96 5E DF A7 85 B1 .....?..g..^....
9C CF C3 A4 F2 .....
(42458 usec [SYS])
<= 90 00 ..
Status: No Error
cm> card-info
=> 80 F2 80 00 02 4F 00 00 .....O..
(8862 usec [SYS])
<= 08 A0 00 00 00 03 00 00 00 07 9E 90 00 .............
Status: No Error
=> 80 F2 40 00 02 4F 00 00 ..#..O..
(7220 usec [SYS])
<= 6A 88 j.
Status: Reference data not found
=> 80 F2 10 00 02 4F 00 00 .....O..
(8838 usec [SYS])
<= 6A 88 j.
Status: Reference data not found
Card Manager AID : A000000003000000
Card Manager state : INITIALIZED
cm> upload -b 250 "C:\Users\pp\eclipse-workspace\testJCOP\bin\com\pryogika\jc\javacard\jc.cap"
=> 80 E6 02 00 16 09 48 65 6C 6C 6F 4A 43 4F 50 08 ......HelloJCOP.
A0 00 00 00 03 00 00 00 00 00 00 00 ............
(13758 usec [SYS])
<= 00 90 00 ...
Status: No Error
=> 80 E8 00 00 FA C4 82 01 2D 01 00 23 DE CA FF ED ........-..#....
02 02 05 00 01 09 48 65 6C 6C 6F 4A 43 4F 50 0F ......HelloJCOP.
63 6F 6D 2F 70 72 79 6F 67 69 6B 61 2F 6A 63 02 com/pryogika/jc.
00 21 00 23 00 21 00 13 00 21 00 26 00 0E 00 4F .!.#.!...!.&...O
00 0A 00 0D 00 00 00 57 00 00 00 00 00 00 00 00 .......W........
03 01 00 04 00 21 03 03 01 07 A0 00 00 00 62 01 .....!........b.
01 00 01 09 A0 00 00 00 62 02 08 01 01 00 01 07 ........b.......
A0 00 00 00 62 00 01 03 00 13 01 0F 48 65 6C 6C ....b.......Hell
6F 4A 43 4F 50 41 70 70 6C 65 74 00 08 06 00 0E oJCOPApplet.....
00 00 00 80 03 00 FF 00 07 01 00 00 00 1C 07 00 ................
4F 00 01 10 18 8C 00 00 7A 05 30 8F 00 01 3D 8C O.......z.0...=.
00 02 18 1D 04 41 18 1D 25 8B 00 03 7A 04 23 18 .....A..%...z.#.
8B 00 04 60 03 7A 19 8B 00 05 2D 1A 04 25 73 00 ...`.z....-..%s.
1B 00 00 00 00 00 09 12 0A 36 1A 08 23 8D 00 06 .........6..#...
3B 19 08 07 8B 00 07 70 08 11 6D 00 8D 00 08 7A ;......p..m....z
08 00 0A 00 00 00 00 00 00 00 00 00 00 05 00 00 ................
(25820 usec [SYS])
<= 6A 80 j.
Status: Wrong data
jcshell: Error code: 6a80 (Wrong data)
jcshell: Wrong response APDU: 6A80
cm> /list-v
Global:____________________________________________
SESSION.ID=0FA5DF09FC02F2276D5A113D1591EE7C
cap.applet.aids=48656C6C6F4A434F504170706C6574
cap.package.aid=48656C6C6F4A434F50
exec.dir=C:\Users\pp\Desktop
jcop.v242=false
last.apdu.executiontime=25.717
last.apdu.executiontime.unit=msec
last.executiontime=52.0
last.executiontime.unit=msec
last.response.status=6a80
logfile.list=
cm> card-info
=> 80 F2 80 00 02 4F 00 00 .....O..
(17196 usec [SYS])
<= 08 A0 00 00 00 03 00 00 00 07 9E 90 00 .............
Status: No Error
=> 80 F2 40 00 02 4F 00 00 ..#..O..
(20679 usec [SYS])
<= 6A 88 j.
Status: Reference data not found
=> 80 F2 10 00 02 4F 00 00 .....O..
(8299 usec [SYS])
<= 6A 88 j.
Status: Reference data not found
Card Manager AID : A000000003000000
Card Manager state : INITIALIZED
No, these cards have not supported the int type. For full certainty simply ask for the data sheet or user's manual from NXP, and if it is not in there, ask them directly.
If you want to support bigger data types then this is of course possible, but you'll have to program it yourself. In that case the fact that objects are stored in persistent memory will of course not be of any help, but it can be done.
Otherwise: it depends on what kind of integer support you require. Just addition or subtraction is very easy to implement yourself on a byte-by-byte base. For cryptographic purposes you may need to look a lot deeper. Sometimes you can also use existing API's such as DH key agreement to perform e.g. modular exponentiation. There are for instance libraries to perform Elliptic Curve calculations (which require big integer).
I am taking hex dump of the same file from two Machines ( Mac & Linux), but the order bytes looks different in both. I am something wrong?
Hexdump output from OSX
➜ samples hexdump 1500_77807e3eb2eeacd9ac870c24103f5b_fno.bin
0000000 02 20 00 01 01 0b 1a 02 59 5a 2a 2a 31 32 33 00
0000010 40 00 05 4a fa a4 77 00 00 1c 28 40 28 02 17 ef
0000020 6a 36 00 e0 4c 01 b8 f5 32 20 a0 00 07 01 d6 00
0000030 02 00 00 c3 1f 00 01 40 1f 18 67 8f 00 2f 26 43
0000040 2d 40 96 30 89 40 11 4b a0 ff 28 34 00 35 00 02
0000050 02 58 40 bd 25 40 ec 40 01 01 40 a6 26 20 61 34
0000060 40 2d c2 5f 16 00 03 27 00 2d 11 be 00 4b 5d 0c
0000070 c0 bd 2c 40 2d 4d a0 be 06 72 40 2f 52 00 05 7e
0000080 00 96 5d 57 a0 5c 80 2d 5c be 04 b0 5d 61 bc 03
0000090 00 00 41 1c f7 a0 80 1f 05 c5 70 7d 40 c2 ce 2a
00000a0 e9 00 0e 2c dd 00 0e 24 ef 00 0e b7 f0 83 54 61
00000b0 d7 03 bb 3c 43 57 03 c6 c7 be 99 84 60 44 36 03
00000c0 54 41 d7 03 b0 e2 a2 96 00 e1 00 2e af 5c bc 43
00000d0 b7 03 ad 6d c0 5c 41 4e 9f 6c 28 00 2e 9c c9 28
00000e0 00 2e b9 43 dc 41 1d b9 c2 c4 43 b7 03 ba 51 27
00000f0 03 e7 03 bb af a0 2e 0e a6 5d dc bc 43 17 d0 a0
0000100 40 80 1f d3 30 80 c3 54 62 cc 62 ac c0 0c 11 00
0000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
00005d0 00 00 00 00 00 00 00 00 00 00 00 00
00005dc
Hexdump output of the same file from Ubuntu server SSH ed in from OSX
exdump 1500_77807e3eb2eeacd9ac870c24103f5b_fno.bin
0000000 2002 0100 0b01 021a 5a59 2a2a 3231 0033
0000010 0040 4a05 a4fa 0077 1c00 4028 0228 ef17
0000020 366a e000 014c f5b8 2032 00a0 0107 00d6
0000030 0002 c300 001f 4001 181f 8f67 2f00 4326
0000040 402d 3096 4089 4b11 ffa0 3428 3500 0200
0000050 5802 bd40 4025 40ec 0101 a640 2026 3461
0000060 2d40 5fc2 0016 2703 2d00 be11 4b00 0c5d
0000070 bdc0 402c 4d2d bea0 7206 2f40 0052 7e05
0000080 9600 575d 5ca0 2d80 be5c b004 615d 03bc
0000090 0000 1c41 a0f7 1f80 c505 7d70 c240 2ace
00000a0 00e9 2c0e 00dd 240e 00ef b70e 83f0 6154
00000b0 03d7 3cbb 5743 c603 bec7 8499 4460 0336
00000c0 4154 03d7 e2b0 96a2 e100 2e00 5caf 43bc
00000d0 03b7 6dad 5cc0 4e41 6c9f 0028 9c2e 28c9
00000e0 2e00 43b9 41dc b91d c4c2 b743 ba03 2751
00000f0 e703 bb03 a0af 0e2e 5da6 bcdc 1743 a0d0
0000100 8040 d31f 8030 54c3 cc62 ac62 0cc0 0011
0000110 0000 0000 0000 0000 0000 0000 0000 0000
*
Even the 1st word is different 0220 & 2002
It looks like you're having an issue with both endianness and hexdump defaulting to single bytes on your OSX environment and 2-byte words on your Linux environment.
To get identical output you might need to explicitly provide a format string.
Running hexdump -e \"%07_ax\ \"\ 16/1\ \"\ %02x\"\ \"\\n\" 1500_77807e3eb2eeacd9ac870c24103f5b_fno.bin should give you the same result in both environments.
The format string is "%08_ax " 16/1 " %02x" "\n" with escaping.
Have tried to establish the SSL connection to the Linux server machine from an STB client device. Am getting the following SSL error,
error:1408F10B:lib(20):func(143):reason(267) (find reason(code) at openssl/ssl.h)
On checking with openssl command, am getting the following information,
CONNECTED(00000003)
write to 0x7ee98 [0x8a153] (148 bytes => 148 (0x94))
0000 - 16 03 00 00 8f 01 00 00-8b 03 00 50 40 64 2c 41 ...........P#d,A
0010 - 53 23 c1 e1 9a dd e3 40-61 b3 71 cb 38 fe ba c9 S#.....#a.q.8...
0020 - 6b d7 b4 00 0d 21 88 19-6a 7c 56 00 00 64 c0 14 k....!..j|V..d..
0030 - c0 0a 00 39 00 38 00 37-00 36 00 88 00 87 00 86 ...9.8.7.6......
0040 - 00 85 c0 0f c0 05 00 35-00 84 c0 13 c0 09 00 33 .......5.......3
0050 - 00 32 00 31 00 30 00 9a-00 99 00 98 00 97 00 45 .2.1.0.........E
0060 - 00 44 00 43 00 42 c0 0e-c0 04 00 2f 00 96 00 41 .D.C.B...../...A
0070 - 00 07 c0 11 c0 07 c0 0c-c0 02 00 05 00 04 c0 12 ................
0080 - c0 08 00 16 00 13 00 10-00 0d c0 0d c0 03 00 0a ................
0090 - 00 ff 01 ...
0094 - <SPACES/NULS>
read from 0x7ee98 [0x85c03] (5 bytes => 5 (0x5))
0000 - 48 54 54 50 2f HTTP/
write to 0x7ee98 [0x8f610] (7 bytes => 7 (0x7))
0000 - 15 03 00 00 02 02 28 ......(
3069535440:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:362:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 5 bytes and written 7 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : SSLv3
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1516869657
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Exact error am getting is 3069535440:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:362:.
Please have someone help to resolve this issue?
As you can see in the error information you provided there is a routines:SSL3_GET_RECORD:wrong version error. It seems to me that you try to use SSL3 although the Sever and/or Client is not supporting this SSL-Version.
Try to change the used method and try again.
EDIT: The protocol is supported due to Verify return code with Protocol SSLv3 being 0.
I'm trying to edit a binary file directly and I know two editors, vi and hexedit. But when I open a binary file separately using them, the cotens are different. Below is what I did.
First I use "dd if=/dev/sda of=mbr bs=512 count=1" to generate the binary file, which contains the mbr data. Then I open it using "hexedit mbr", and it displays this:
beginning:
00000000 EB 63 90 D0 BC 00 7C 8E C0 8E D8 BE 00 7C BF 00
00000010 06 B9 00 02 FC F3 A4 50 68 1C 06 CB FB B9 04 00
00000020 BD BE 07 80 7E 00 00 7C 0B 0F 85 0E 01 83 C5 10
ending:
000001E0 FF FF 83 FE FF FF 00 40 D6 02 00 38 2B 01 00 00
000001F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA
I using "vi mbr" open it and type":%!xxd", it displays this:
beginning:
0000000: c3ab 63c2 90c3 90c2 bc00 7cc2 8ec3 80c2
0000010: 8ec3 98c2 be00 7cc2 bf00 06c2 b900 02c3
0000020: bcc3 b3c2 a450 681c 06c3 8bc3 bbc2 b904
ending:
00002b0: bfc3 bf00 40c3 9602 0038 2b01 0000 0000
00002c0: 0000 0000 0000 0000 0000 0000 55c2 aa0a
The hexedit displaying is what I expect in mbr. But what to say with vi displaying? Also the vi displaying seems wrong because there are more than 512 bytes.
Thank you for any explainations!
The command :%!xxd uses the external program xxd, so you should first try to check its output by typing:
xxd mbr
If it looks good, try opening vi in binary mode (no EOL):
vi -b mrb
then :%!xxd
The bytes you see in "vi" seem to be exactly the UTF-8 representation of the binary code.
Maybe "vi" converts the data read in from binary to UTF-8 before passing it to "xxd".
Firstly , I am mentioning whatever happened on my linux mint/ubuntu system ...
udit#udit-Dabba ~/ah $ xxd -r -p input.txt output.txt
udit#udit-Dabba ~/ah $ cat input.txt
60 00 00 00 00 14 06 20 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 02 00 15 00 15 7A 32 B1 08
00 00 00 00 50 02 FF FF 7E 95 00 00 00 00 02 29
udit#udit-Dabba ~/ah $ cat output.txt
` z2P��~�)
udit#udit-Dabba ~/ah $ hexdump -C output.txt
00000000 60 00 00 00 00 14 06 20 00 00 00 00 00 00 00 00 |`...... ........|
00000010 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 |................|
00000020 00 00 00 00 00 00 00 02 00 15 00 15 7a 32 b1 08 |............z2..|
00000030 00 00 00 00 50 02 ff ff 7e 95 00 00 00 00 02 29 |....P...~......)|
00000040
udit#udit-Dabba ~/ah $ od -x output.txt
0000000 0060 0000 1400 2006 0000 0000 0000 0000
0000020 0000 0000 0000 0100 0000 0000 0000 0000
0000040 0000 0000 0000 0200 1500 1500 327a 08b1
0000060 0000 0000 0250 ffff 957e 0000 0000 2902
0000100
Now when I tried same thing on red hat , some strange behaviour is occuring.
[root#cc]$ xxd -r -p input.txt output.txt
[root#cc]$ cat input.txt
60 00 00 00 00 14 06 20 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 02 00 15 00 15 7A 32 B1 08
00 00 00 00 50 02 FF FF 7E 95 00 00 00 00 02 29
[root#cc]$ cat output.txt
` P~)[root#cc]$ hexdump -C output.txt
00000000 60 00 00 00 00 14 06 20 00 00 00 00 00 00 00 00 |`...... ........|
00000010 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 |................|
00000020 00 00 00 00 50 02 ff ff 7e 95 00 00 00 00 02 29 |....P...~......)|
00000030
[root#cc]$ od -x output.txt
0000000 0060 0000 1400 2006 0000 0000 0000 0000
0000020 0000 0000 0000 0100 0000 0000 0000 0000
0000040 0000 0000 0250 ffff 957e 0000 0000 2902
0000060
I am not able to find out why this discrepency occcuring between outputs of red hat and linux mint/ubuntu.
If possible tell me some awk/shell to perform the same in place of xxd -r -p
Pleae help me !!
EDIT:
On linux mint/ubuntu system ..
udit#udit-Dabba ~/ah $ hexdump -C input.txt
00000000 36 30 20 30 30 20 30 30 20 30 30 20 30 30 20 31 |60 00 00 00 00 1|
00000010 34 20 30 36 20 32 30 20 30 30 20 30 30 20 30 30 |4 06 20 00 00 00|
00000020 20 30 30 20 30 30 20 30 30 20 30 30 20 30 30 20 | 00 00 00 00 00 |
00000030 0a 30 30 20 30 30 20 30 30 20 30 30 20 30 30 20 |.00 00 00 00 00 |
00000040 30 30 20 30 30 20 30 31 20 30 30 20 30 30 20 30 |00 00 01 00 00 0|
00000050 30 20 30 30 20 30 30 20 30 30 20 30 30 20 30 30 |0 00 00 00 00 00|
00000060 20 0a 30 30 20 30 30 20 30 30 20 30 30 20 30 30 | .00 00 00 00 00|
00000070 20 30 30 20 30 30 20 30 32 20 30 30 20 31 35 20 | 00 00 02 00 15 |
00000080 30 30 20 31 35 20 37 41 20 33 32 20 42 31 20 30 |00 15 7A 32 B1 0|
00000090 38 20 0a 30 30 20 30 30 20 30 30 20 30 30 20 35 |8 .00 00 00 00 5|
000000a0 30 20 30 32 20 46 46 20 46 46 20 37 45 20 39 35 |0 02 FF FF 7E 95|
000000b0 20 30 30 20 30 30 20 30 30 20 30 30 20 30 32 20 | 00 00 00 00 02 |
000000c0 32 39 20 0a 0a 0a 0a 0a |29 .....|
000000c8
On red hat machine ..
[root#cc]$ hexdump -C input.txt
00000000 36 30 20 30 30 20 30 30 20 30 30 20 30 30 20 31 |60 00 00 00 00 1|
00000010 34 20 30 36 20 32 30 20 30 30 20 30 30 20 30 30 |4 06 20 00 00 00|
00000020 20 30 30 20 30 30 20 30 30 20 30 30 20 30 30 0a | 00 00 00 00 00.|
00000030 30 30 20 30 30 20 30 30 20 30 30 20 30 30 20 30 |00 00 00 00 00 0|
00000040 30 20 30 30 20 30 31 20 30 30 20 30 30 20 30 30 |0 00 01 00 00 00|
00000050 20 30 30 20 30 30 20 30 30 20 30 30 20 30 30 20 | 00 00 00 00 00 |
00000060 0a 30 30 20 30 30 20 30 30 20 30 30 20 30 30 20 |.00 00 00 00 00 |
00000070 30 30 20 30 30 20 30 32 20 30 30 20 31 35 20 30 |00 00 02 00 15 0|
00000080 30 20 31 35 20 37 41 20 33 32 20 42 31 20 30 38 |0 15 7A 32 B1 08|
00000090 20 0a 30 30 20 30 30 20 30 30 20 30 30 20 35 30 | .00 00 00 00 50|
000000a0 20 30 32 20 46 46 20 46 46 20 37 45 20 39 35 20 | 02 FF FF 7E 95 |
000000b0 30 30 20 30 30 20 30 30 20 30 30 20 30 32 20 32 |00 00 00 00 02 2|
000000c0 39 20 20 0a |9 .|
000000c4
I have no idea whats happening, but the third line is being eaten on red hat.
This is what you asked for. Reverse hexdump with awk+bash.
echo 'ibase=16' | cat - hdump | tr ' ' \; | bc | awk '{printf("%c",$0)}'
replace hdump with input.txt
echo 'ibase=16' | cat - input.txt | tr ' ' \; | bc | awk '{printf("%c",$0)}' > output.txt
codes were found here:
http://www.unix.com/shell-programming-scripting/132294-reverse-hexdump-without-xxd.html#post302404631
A late answer, but hopefully may help to somebody else reading this:
xxd had buggy handling of spaces in "-r -p" mode. As it scanned the characters, if it hit 2 consecutive non-hex characters, it would throw away everything until the next newline or end of file. If the second of the 2 consecutive characters was itself the newline character (i.e., the line ended with a space followed by a newline), the net effect would be to discard the entire next line.
I am pretty certain this is what caused Udit's problem. (I think the hexdump he later added of input.txt did not actually reflect the original state of that file.)
It looks like xxd is primarily maintained as part of the vim distribution. I looked at the xxd source included with vim 7.3, and it has the buggy handling problem fixed. Unfortunately nobody bothers to update the version #, so it still reports the same xxd 1.10 version string.
Try creating this test file (with 1 blank space at the end of the first line and none on the second; should be a 22 byte file on Linux/Unix; if you run "xxd -p" on it, it should report 3230200a34652034662035340a34322034312034340a):
20
4e 4f 54
42 41 44
If you run "xxd -r -p" on this, with a version of xxd exhibiting the buggy handling, you should see it print BAD. With a newer (fixed) version of xxd, it'll print NOTBAD.
If you run into this buggy handling and updating to a newer version of xxd is not an option, you can avoid this problem with some sed preprocessing, e.g.,
$ sed -e 's/ *//g' -e '/^$/d' input.txt | xxd -r -p > output.txt
I'd say that you have some invisible character in the input.txt file that makes the third line look invalid somehow.
And maybe the invalid character is encoding-dependent, and that's why it works in one machine and not in other.
It would be helpful to see the result of hexdump -C input.txt to check that.
$ cat foo
60 00 00 00 00 14 06 20 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 02 00 15 00 15 7A 32 B1 08
00 00 00 00 50 02 FF FF 7E 95 00 00 00 00 02 29
$ cat foo | xxd -r -p | hexdump -C
00000000 60 00 00 00 00 14 06 20 00 00 00 00 00 00 00 00 |`...... ........|
00000010 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 |................|
00000020 00 00 00 00 00 00 00 02 00 15 00 15 7a 32 b1 08 |............z2..|
00000030 00 00 00 00 50 02 ff ff 7e 95 00 00 00 00 02 29 |....P...~......)|
00000040