I originally asked this question on Signal Processing but it was off topic. So, here it goes!
I tried to export a recording from Audacity twice, each time with the same parameters and tags. The resulting files had different checksums. So I opened up an diffed the two files (as binary).
My first try was a wav file containing a 32 bit float PCM. Only 3 bits were different in the whole file.
0000003c: 01000000 01001001 01110000 01010111 01001100 11100111 #IpWL.
became
0000003c: 01000111 01001001 01110000 01010111 01001100 11100111 GIpWL.
My first question is: what are these three bits used for?
Then I tried this same procedure with flac files. I will not paste it here because it would be too long, but what happened is that at the beginning of the file, there were only a few differences here and there, but the farther in the file I got the more it was apparent that the files were different.
Why is that? Isn't the flac compression algorithm deterministic?
Finally I took a wav file containing a 16 bit signed PCM and converted it to a 16 bit signed flac file, and then back to wav. The file I obtained is very similar to the original but it seems data is offseted by 33 bytes, as you can see from these samples of the files:
Original file:
00000294: 11111110 11111111 11111111 11111111 11111101 11111111 ......
0000029a: 11111011 11111111 11111100 11111111 11111110 11111111 ......
000002a0: 00000000 00000000 11111011 11111111 00000000 00000000 ......
000002a6: 00000001 00000000 00000010 00000000 00000001 00000000 ......
000002ac: 11111101 11111111 11111110 11111111 11111100 11111111 ......
000002b2: 11111100 11111111 11111101 11111111 11111101 11111111 ......
000002b8: 00000001 00000000 00000010 00000000 11111100 11111111 ......
000002be: 11111100 11111111 11111011 11111111 11111010 11111111 ......
000002c4: 00000010 00000000 00000010 00000000 00000000 00000000 ......
New File:
000002b2: 00000011 00000000 00000011 00000000 11111110 11111111 ......
000002b8: 11111111 11111111 11111101 11111111 11111011 11111111 ......
000002be: 11111100 11111111 11111110 11111111 00000000 00000000 ......
000002c4: 11111011 11111111 00000000 00000000 00000001 00000000 ......
000002ca: 00000010 00000000 00000001 00000000 11111101 11111111 ......
000002d0: 11111110 11111111 11111100 11111111 11111100 11111111 ......
000002d6: 11111101 11111111 11111101 11111111 00000001 00000000 ......
000002dc: 00000010 00000000 11111100 11111111 11111100 11111111 ......
000002e2: 11111011 11111111 11111010 11111111 00000010 00000000 ......
Why?
Related
I'm trying to map which socket belong to which process, and to do that, i'm parsing /proc/net/tcp file. But sometime, the inode field is zero. What does that mean?
Example output from /proc/net/tcp:
sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode
6: 0100007F:2EE1 00000000:0000 0A 00000000:00000000 00:00000000 00000000 1000 0 54791 1 0000000000000000 100 0 0 10 0
7: 0100007F:5F04 00000000:0000 0A 00000000:00000000 00:00000000 00000000 130 0 56323 1 0000000000000000 100 0 0 10 0
8: 00000000:0386 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 50586 1 0000000000000000 100 0 0 10 0
9: 0100007F:19C8 00000000:0000 0A 00000000:00000000 00:00000000 00000000 1000 0 4831553 1 0000000000000000 100 0 0 10 0
10: 0100007F:61A9 00000000:0000 0A 00000000:00000000 00:00000000 00000000 1000 0 56521 1 0000000000000000 100 0 0 10 0
11: 00000000:93D0 00000000:0000 0A 00000000:00000000 00:00000000 00000000 1000 0 56765 1 0000000000000000 100 0 0 10 0
12: 0100007F:B4C4 0100007F:19C8 06 00000000:00000000 03:00000BC1 00000000 0 0 0 3 0000000000000000
13: 0100007F:B462 0100007F:19C8 06 00000000:00000000 03:00000582 00000000 0 0 0 3 0000000000000000
14: 0100007F:B538 0100007F:19C8 06 00000000:00000000 03:000012CA 00000000 0 0 0 3 0000000000000000
15: 0100007F:B51C 0100007F:19C8 06 00000000:00000000 03:00001139 00000000 0 0 0 3 0000000000000000
I'm making my best effort at following this tutorial as my first bit of ever actually writing assembly. Start small, right? ;)
Anyway... here's what I've got.
[patrick#manifold-arch Assembly]$ cat loader.s
.code16 # we're operating in 16bit real mode
.global begin # make the begin tag globally accessible
begin: # traditionally called _start, but who cares?
jmp begin # infinite loop!
.fill 510-(.-begin), 1, 0 # pad with zeroes till 510 bytes
Cool.
[patrick#manifold-arch Assembly]$ as -o loader.o loader.s
[patrick#manifold-arch Assembly]$ ld -o loader.bin loader.o --oformat binary -e begin --nmagic
[patrick#manifold-arch Assembly]$ ls -lh
total 12K
-rwxr-xr-x 1 patrick patrick 558 Mar 10 11:17 loader.bin
-rw-r--r-- 1 patrick patrick 1.3K Mar 10 11:16 loader.o
-rw-r--r-- 1 patrick patrick 288 Mar 10 10:49 loader.s
First, I was getting 4k files, so I rifled around until I discovered --nmagic. Problem solved. Kind of. My .o file is consistently smaller amusingly enough. But, when I slap the -n flag onto ld, I still wind up with an extra 48 bytes in file size.
[patrick#manifold-arch Assembly]$ objdump -D -Matt,i386 -b binary -m i386 -ls loader.bin
loader.bin: file format binary
Contents of section .data:
0000 04000000 20000000 05000000 474e5500 .... .......GNU.
0010 020001c0 04000000 00000000 00000000 ................
0020 010001c0 04000000 01000000 00000000 ................
0030 ebfe0000 00000000 00000000 00000000 ................
0040 00000000 00000000 00000000 00000000 ................
0050 00000000 00000000 00000000 00000000 ................
0060 00000000 00000000 00000000 00000000 ................
0070 00000000 00000000 00000000 00000000 ................
0080 00000000 00000000 00000000 00000000 ................
0090 00000000 00000000 00000000 00000000 ................
00a0 00000000 00000000 00000000 00000000 ................
00b0 00000000 00000000 00000000 00000000 ................
00c0 00000000 00000000 00000000 00000000 ................
00d0 00000000 00000000 00000000 00000000 ................
00e0 00000000 00000000 00000000 00000000 ................
00f0 00000000 00000000 00000000 00000000 ................
0100 00000000 00000000 00000000 00000000 ................
0110 00000000 00000000 00000000 00000000 ................
0120 00000000 00000000 00000000 00000000 ................
0130 00000000 00000000 00000000 00000000 ................
0140 00000000 00000000 00000000 00000000 ................
0150 00000000 00000000 00000000 00000000 ................
0160 00000000 00000000 00000000 00000000 ................
0170 00000000 00000000 00000000 00000000 ................
0180 00000000 00000000 00000000 00000000 ................
0190 00000000 00000000 00000000 00000000 ................
01a0 00000000 00000000 00000000 00000000 ................
01b0 00000000 00000000 00000000 00000000 ................
01c0 00000000 00000000 00000000 00000000 ................
01d0 00000000 00000000 00000000 00000000 ................
01e0 00000000 00000000 00000000 00000000 ................
01f0 00000000 00000000 00000000 00000000 ................
0200 00000000 00000000 00000000 00000000 ................
0210 00000000 00000000 00000000 00000000 ................
0220 00000000 00000000 00000000 0000 ..............
Disassembly of section .data:
00000000 <.data>:
0: 04 00 add $0x0,%al
2: 00 00 add %al,(%eax)
4: 20 00 and %al,(%eax)
6: 00 00 add %al,(%eax)
8: 05 00 00 00 47 add $0x47000000,%eax
d: 4e dec %esi
e: 55 push %ebp
f: 00 02 add %al,(%edx)
11: 00 01 add %al,(%ecx)
13: c0 04 00 00 rolb $0x0,(%eax,%eax,1)
...
1f: 00 01 add %al,(%ecx)
21: 00 01 add %al,(%ecx)
23: c0 04 00 00 rolb $0x0,(%eax,%eax,1)
27: 00 01 add %al,(%ecx)
29: 00 00 add %al,(%eax)
2b: 00 00 add %al,(%eax)
2d: 00 00 add %al,(%eax)
2f: 00 eb add %ch,%bl
31: fe 00 incb (%eax)
...
I see the zeroes from 13 to 1f, but that only accounts for 12 bytes, yes? It seems like that block shouldn't be there at all, but it still doesn't account for everything that I'm getting as extra.
And when I remove the padding, instead of ending up with a 4 byte binary like the author does, I wind up with a 50 byte binary.
I'm clearly doing something wrong, and it's probably just a flag or something. So I've got two questions: one, what am I doing wrong? And two: why does the author get such different outcomes (particularly regarding page alignment) than I do? The article's from 2018, so surely those commands weren't run on a 32-bit machine? I dunno. All I know is I need a hand. =)
Thanks in advance, and as always.
I just added a 56,212 byte array (declare, not dynamically allocate) to one of device driver (driver is built-in) in Linux 2.6.15 at ARM platform, and always get kernel panic after issue the commands related to process ID (e.g. ps or top) even if that device driver is not running.
Here is the backtrace,
[<c009be04>] (pid_revalidate+0x0/0xa8) from [<c007b934>] (do_lookup+0x18c/0x1b8)
r5 = C5CA9F70 r4 = 00000000
[<c007b7a8>] (do_lookup+0x0/0x1b8) from [<c007c380>] (__link_path_walk+0x8b8/0xd78)
[<c007bac8>] (__link_path_walk+0x0/0xd78) from [<c007c8c4>] (link_path_walk+0x84/0x134)
[<c007c840>] (link_path_walk+0x0/0x134) from [<c007cb10>] (path_lookup+0x19c/0x1a8)
r7 = C48E1000 r6 = 00000000 r5 = C487E000 r4 = C487FF14
[<c007c974>] (path_lookup+0x0/0x1a8) from [<c007cc08>] (__path_lookup_intent_open+0x4c/0x8c)
r7 = 00000001 r6 = C487FF14 r5 = C48E1000 r4 = 00000001
[<c007cbbc>] (__path_lookup_intent_open+0x0/0x8c) from [<c007cc64>] (path_lookup_open+0x1c/0x20)
r7 = 00000005 r6 = 00000004 r5 = C487FF14 r4 = 00000000
[<c007cc48>] (path_lookup_open+0x0/0x20) from [<c007d45c>] (open_namei+0x7c/0x67c)
[<c007d3e0>] (open_namei+0x0/0x67c) from [<c006d28c>] (filp_open+0x2c/0x48)
[<c006d260>] (filp_open+0x0/0x48) from [<c006d55c>] (do_sys_open+0x44/0xd0)
r5 = 00000000 r4 = 00000000
[<c006d518>] (do_sys_open+0x0/0xd0) from [<c006d5f8>] (sys_open+0x10/0x14)
[<c006d5e8>] (sys_open+0x0/0x14) from [<c0020e00>] (ret_fast_syscall+0x0/0x2c)
If I decrease the volume of array to 56,208 bytes, everything is OK.
The "readelf" result of 56,208 bytes array (OK case)
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .init PROGBITS c0008000 008000 018000 00 WAX 0 0 32
[ 2] .text PROGBITS c0020000 020000 24c7f4 00 AX 0 0 32
[ 3] .text.init PROGBITS c026c7f4 26c7f4 000078 00 AX 0 0 4
[ 4] .pci_fixup PROGBITS c026c86c 30a700 000000 00 W 0 0 1
[ 5] .rio_route PROGBITS c026c86c 30a700 000000 00 W 0 0 1
[ 6] __ksymtab PROGBITS c026c86c 26c86c 004458 00 A 0 0 4
[ 7] __ksymtab_gpl PROGBITS c0270cc4 270cc4 000898 00 A 0 0 4
[ 8] __kcrctab PROGBITS c027155c 30a700 000000 00 W 0 0 1
[ 9] __kcrctab_gpl PROGBITS c027155c 30a700 000000 00 W 0 0 1
[10] __ksymtab_strings PROGBITS c027155c 27155c 00b288 00 A 0 0 4
[11] __param PROGBITS c027c7e4 27c7e4 000618 00 A 0 0 4
[12] .data PROGBITS c027e000 27e000 08c6f0 00 WA 0 0 32
[13] .bss NOBITS c030a700 30a700 0248e8 00 WA 0 0 32
[14] .comment PROGBITS 00000000 30a700 0028c8 00 0 0 1
[15] .shstrtab STRTAB 00000000 30cfc8 0000a0 00 0 0 1
[16] .symtab SYMTAB 00000000 30d338 07aa50 10 17 25869 4
[17] .strtab STRTAB 00000000 387d88 057629 00 0 0 1
The "readelf" result of 56,212 bytes array (NG case)
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .init PROGBITS c0008000 008000 018000 00 WAX 0 0 32
[ 2] .text PROGBITS c0020000 020000 24c7f4 00 AX 0 0 32
[ 3] .text.init PROGBITS c026c7f4 26c7f4 000078 00 AX 0 0 4
[ 4] .pci_fixup PROGBITS c026c86c 30a700 000000 00 W 0 0 1
[ 5] .rio_route PROGBITS c026c86c 30a700 000000 00 W 0 0 1
[ 6] __ksymtab PROGBITS c026c86c 26c86c 004458 00 A 0 0 4
[ 7] __ksymtab_gpl PROGBITS c0270cc4 270cc4 000898 00 A 0 0 4
[ 8] __kcrctab PROGBITS c027155c 30a700 000000 00 W 0 0 1
[ 9] __kcrctab_gpl PROGBITS c027155c 30a700 000000 00 W 0 0 1
[10] __ksymtab_strings PROGBITS c027155c 27155c 00b288 00 A 0 0 4
[11] __param PROGBITS c027c7e4 27c7e4 000618 00 A 0 0 4
[12] .data PROGBITS c027e000 27e000 08c6f0 00 WA 0 0 32
[13] .bss NOBITS c030a700 30a700 024908 00 WA 0 0 32
[14] .comment PROGBITS 00000000 30a700 0028c8 00 0 0 1
[15] .shstrtab STRTAB 00000000 30cfc8 0000a0 00 0 0 1
[16] .symtab SYMTAB 00000000 30d338 07aa50 10 17 25869 4
[17] .strtab STRTAB 00000000 387d88 057629 00 0 0 1
The differences between two cases is just the size of .bss. (OK case is 248e8; NG case is 24908)
I was wondering whether I have violated some rules in Linux kernel, or I am debugging in the wrong way?
I am struggling in understanding how a linker perform relocation. According on the ELF manual (Relocation section, pag 27) a relocation of type R_386_PC32 is performed by calculating the quantity S + A - P (see ELF manual at page 29).
Now, consider the following ELF header:
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: REL (Relocatable file)
Machine: Intel 80386
Version: 0x1
Entry point address: 0x0
Start of program headers: 0 (bytes into file)
Start of section headers: 560 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 0 (bytes)
Number of program headers: 0
Size of section headers: 40 (bytes)
Number of section headers: 13
Section header string table index: 10
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .text PROGBITS 00000000 000034 000038 00 AX 0 0 1
[ 2] .rel.text REL 00000000 0001b8 000010 08 I 11 1 4
[ 3] .data PROGBITS 00000000 00006c 000000 00 WA 0 0 1
[ 4] .bss NOBITS 00000000 00006c 000000 00 WA 0 0 1
[ 5] .rodata PROGBITS 00000000 00006c 00000f 00 A 0 0 1
[ 6] .comment PROGBITS 00000000 00007b 000035 01 MS 0 0 1
[ 7] .note.GNU-stack PROGBITS 00000000 0000b0 000000 00 0 0 1
[ 8] .eh_frame PROGBITS 00000000 0000b0 000044 00 A 0 0 4
[ 9] .rel.eh_frame REL 00000000 0001c8 000008 08 I 11 8 4
[10] .shstrtab STRTAB 00000000 0001d0 00005f 00 0 0 1
[11] .symtab SYMTAB 00000000 0000f4 0000b0 10 12 9 4
[12] .strtab STRTAB 00000000 0001a4 000013 00 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
There are no section groups in this file.
There are no program headers in this file.
Relocation section '.rel.text' at offset 0x1b8 contains 2 entries:
Offset Info Type Sym.Value Sym. Name
0000001f 00000501 R_386_32 00000000 .rodata
00000024 00000a02 R_386_PC32 00000000 printf
Relocation section '.rel.eh_frame' at offset 0x1c8 contains 1 entries:
Offset Info Type Sym.Value Sym. Name
00000020 00000202 R_386_PC32 00000000 .text
The decoding of unwind sections for machine type Intel 80386 is not currently supported.
Symbol table '.symtab' contains 11 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 00000000 0 NOTYPE LOCAL DEFAULT UND
1: 00000000 0 FILE LOCAL DEFAULT ABS asd.c
2: 00000000 0 SECTION LOCAL DEFAULT 1
3: 00000000 0 SECTION LOCAL DEFAULT 3
4: 00000000 0 SECTION LOCAL DEFAULT 4
5: 00000000 0 SECTION LOCAL DEFAULT 5
6: 00000000 0 SECTION LOCAL DEFAULT 7
7: 00000000 0 SECTION LOCAL DEFAULT 8
8: 00000000 0 SECTION LOCAL DEFAULT 6
9: 00000000 56 FUNC GLOBAL DEFAULT 1 main
10: 00000000 0 NOTYPE GLOBAL DEFAULT UND printf
No version information found in this file.
and the relative relocatable file:
asd.o: file format elf32-i386
Disassembly of section .text:
00000000 <main>:
0: 8d 4c 24 04 lea 0x4(%esp),%ecx
4: 83 e4 f0 and $0xfffffff0,%esp
7: ff 71 fc pushl -0x4(%ecx)
a: 55 push %ebp
b: 89 e5 mov %esp,%ebp
d: 51 push %ecx
e: 83 ec 14 sub $0x14,%esp
11: c7 45 f4 00 00 00 00 movl $0x0,-0xc(%ebp)
18: 83 ec 08 sub $0x8,%esp
1b: ff 75 f4 pushl -0xc(%ebp)
1e: 68 00 00 00 00 push $0x0
23: e8 fc ff ff ff call 24 <main+0x24>
28: 83 c4 10 add $0x10,%esp
2b: b8 00 00 00 00 mov $0x0,%eax
30: 8b 4d fc mov -0x4(%ebp),%ecx
33: c9 leave
34: 8d 61 fc lea -0x4(%ecx),%esp
37: c3 ret
Given that the symbol printf has type R_386_PC32, the new offset has to be calculated as S + A - P. According the sym table S is equal to 0. The quantity A, according the ELF manual, is implicit in the location to be modified, therefore should be equal to 0xfffffffc (little endianess) and finally P should be r_offset, thus 0x24. It follows that the new offset should be equal to 0xffffffD8.
Instead, after linking the above program, I obtain:
0804840b <main>:
804840b: 8d 4c 24 04 lea 0x4(%esp),%ecx
804840f: 83 e4 f0 and $0xfffffff0,%esp
8048412: ff 71 fc pushl -0x4(%ecx)
8048415: 55 push %ebp
8048416: 89 e5 mov %esp,%ebp
8048418: 51 push %ecx
8048419: 83 ec 14 sub $0x14,%esp
804841c: c7 45 f4 00 00 00 00 movl $0x0,-0xc(%ebp)
8048423: 83 ec 08 sub $0x8,%esp
8048426: ff 75 f4 pushl -0xc(%ebp)
8048429: 68 d0 84 04 08 push $0x80484d0
804842e: e8 ad fe ff ff call 80482e0 <printf#plt>
8048433: 83 c4 10 add $0x10,%esp
8048436: b8 00 00 00 00 mov $0x0,%eax
804843b: 8b 4d fc mov -0x4(%ebp),%ecx
804843e: c9 leave
804843f: 8d 61 fc lea -0x4(%ecx),%esp
8048442: c3 ret
8048443: 66 90 xchg %ax,%ax
8048445: 66 90 xchg %ax,%ax
8048447: 66 90 xchg %ax,%ax
8048449: 66 90 xchg %ax,%ax
804844b: 66 90 xchg %ax,%ax
804844d: 66 90 xchg %ax,%ax
804844f: 90 nop
My question is: how is calculated the value actually stored in the final executable file as argument of the printf call(i.e., 0xfffffead)?
Except printf isn't in your object file, it's undefined. So yes, the specification is correct, it is going to be that address, but from your dump that address is not yet known. PS: also applies to your .rodata relocation.
– Jester
as every Linux sys admin know the IP address of the Linux machine we can get as
ifconfig -a|grep inet | awk -F":" '{print $2}' | head -1 | awk '{print $1}'
or
ip addr
or just look the ifcfg files
but how to know the IP from /proc/net/tcp file?
how to understand from the tcp the IP address?
cat /proc/net/tcp
sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode
0: 0100007F:F780 00000000:0000 0A 00000000:00000000 00:00000000 00000000 10501 0 17506 1 efd8e040 3000 0 0 2 -1
1: 0100007F:F781 00000000:0000 0A 00000000:00000000 00:00000000 00000000 10501 0 17508 1 efd8e4c0 3000 0 0 2 -1
2: 00000000:5281 00000000:0000 0A 00000000:00000000 00:00000000 00000000 10501 0 17195 1 efd8f6c0 3000 0 0 2 -1
3: 00000000:02A1 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 8255 1 f69796c0 3000 0 0 2 -1
4: 0100007F:F782 00000000:0000 0A 00000000:00000000 00:00000000 00000000 10501 0 17510 1 f4a6fb40 3000 0 0 2 -1
5: 0100007F:F783 00000000:0000 0A 00000000:00000000 00:00000000 00000000 10501 0 17512 1 f4a6f6c0 3000 0 0 2 -1
6: 79176A0A:13C4 00000000:0000 0A 00000000:00000000 00:00000000 00000000 14201 0 18908 1 f06864c0 3000 0 0 2 -1
7: 0100007F:F784 00000000:0000 0A 00000000:00000000 00:00000000 00000000 10501 0 17514 1 f4a6f240 3000 0 0 2 -1
8: 00000000:D804 00000000:0000 0A 00000000:00000000 00:00000000 00000000 23200 0 12839 1 f64d2040 3000 0 0 2 -1
9: 0100007F:F785 00000000:0000 0A 00000000:00000000 00:00000000 00000000 10501 0 17516 1 f4a6edc0 3000 0 0 2 -1
10: 00000000:D805 00000000:0000 0A 00000000:00000000 00:00000000 00000000 23200 0 13004 1 f6773b40 3000 0 0 2 -1
11: 00000000:1E25 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 9568 1 f760d240 3000 0 0 2 -1
12: 0100007F:F786 00000000:0000 0A 00000000:00000000 00:00000000 00000000 10501 0 17518 1 f4a6e940 3000 0 0 2 -1
13: 0100007F:D806 00000000:0000 0A 00000000:00000000 00:00000000 00000000 23200 0 13121 1 f6773240 3000 0 0 2 -1
14: 0100007F:F787 00000000:0000 0A 00000000:00000000 00:00000000 00000000 10501 0 17520 1 f4a6e4c0 3000 0 0 2 -1
15: 0100007F:00C7 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 8921 1 f69784c0 3000 0 0 2 -1
16: 0100007F:F788 00000000:0000 0A 00000000:00000000 00:00000000 00000000 10501 0 17522 1 f4a6e040 3000 0 0 2 -1
17: 0100007F:F789 00000000:0000 0A 00000000:00000000 00:00000000 00000000 10501 0 17524 1 f1ec1b40 3000 0 0 2 -1
18: 00000000:1389 00000000:0000 0A 00000000:00000000 00:00000000 00000000 23200 0 13090 1 f64d2940 3000 0 0 2 -1
19: 0100007F:F78A 00000000:0000 0A 00000000:00000000 00:00000000 00000000 10501 0 17526 1 f1ec16c0 3000 0 0 2 -1
20: 00000000:1A0A 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 9026 1 f6978040 3000 0 0 2 -1
21: 0100007F:F78B 00000000:0000 0A 00000000:00000000 00:00000000 00000000 10501 0 17528 1 f1ec1240 3000 0 0 2 -1
22: 0100007F:F78C 00000000:0000 0A 00000000:00000000 00:00000000 00000000 10501 0 17530 1 f1ec0dc0 3000 0 0 2 -1
23: 0100007F:F78D 00000000:0000 0A 00000000:00000000 00:00000000 00000000 10501 0 17532 1 f1ec0940 3000 0 0 2 -1
24: 00000000:060E 00000000:0000 0A 00000000:00000000 00:00000000 00000000 14201 0 18877 1 f0686dc0 3000 0 0 2 -1
25: 0100007F:F78E 00000000:0000 0A 00000000:00000000 00:00000000 00000000 10501 0 17534 1 f1ec04c0 3000 0 0 2 -1
26: 00000000:006F 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 8130 1 f6979b40 3000 0 0 2 -1
27: 0100007F:0610 00000000:0000 0A 00000000:00000000 00:00000000 00000000 14201 0 18909 1 f0687240 3000 0 0 2 -1
28: 0100007F:D994 00000000:0000 0A 00000000:00000000 00:00000000 00000000 48 0 14482 1 f64d2dc0 3000 0 0 2 -1
29: 0100007F:0035 00000000:0000 0A 00000000:00000000 00:00000000 00000000 25 0 7961 1 f760db40 3000 0 0 2 -1
30: 00000000:0016 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 8854 1 f6978dc0 3000 0 0 2 -1
31: 00000000:F297 00000000:0000 0A 00000000:00000000 00:00000000 00000000 10101 0 9618 1 f7bd8040 3000 0 0 2 -1
32: 0100007F:03B9 00000000:0000 0A 00000000:00000000 00:00000000 00000000 25 0 7962 1 f760d6c0 3000 0 0 2 -1
33: 0100007F:F77B 00000000:0000 0A 00000000:00000000 00:00000000 00000000 10501 0 17496 1 f0510040 3000 0 0 2 -1
34: 0100007F:F77C 00000000:0000 0A 00000000:00000000 00:00000000 00000000 10501 0 17498 1 f05104c0 3000 0 0 2 -1
35: 0100007F:F77D 00000000:0000 0A 00000000:00000000 00:00000000 00000000 10501 0 17500 1 f0511b40 3000 0 0 2 -1
36: 0100007F:F77E 00000000:0000 0A 00000000:00000000 00:00000000 00000000 10501 0 17502 1 f05116c0 3000 0 0 2 -1
37: 0100007F:F77F 00000000:0000 0A 00000000:00000000 00:00000000 00000000 10501 0 17504 1 f0511240 3000 0 0 2 -1
38: 00000000:D8FF 00000000:0000 0A 00000000:00000000 00:00000000 00000000 23200 0 13023 1 f67736c0 3000 0 0 2 -1
39: 0100007F:041F 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 8920 1 f6978940 3000 0 0 2 -1
40: 79176A0A:0016 7863770A:8C1E 01 00000000:00000000 02:0000473D 00000000 0 0 19488326 2 f363f240 202 40 14 3 100
41: 0100007F:952C 0100007F:060E 06 00000000:00000000 03:00000C08 00000000 0 0 0 2 e96deec0
42: 0100007F:952F 0100007F:060E 06 00000000:00000000 03:000013D9 00000000 0 0 0 2 e96dee40
43: 0100007F:952E 0100007F:060E 06 00000000:00000000 03:00000FF0 00000000 0 0 0 2 e96de8c0
44: 0100007F:952B 0100007F:060E 06 00000000:00000000 03:00000820 00000000 0 0 0 2 e96def40
45: 0100007F:952A 0100007F:060E 06 00000000:00000000 03:00000438 00000000 0 0 0 2 e96deb40
46: 0100007F:D6D4 0100007F:041F 01 00000000:00000000 00:00000000 00000000 10101 0 9610 1 f7bd8940 202 40 30 2 100
47: 0100007F:D6D1 0100007F:041F 01 00000000:00000000 00:00000000 00000000 10101 0 9594 1 f64d3b40 201 40 28 2 100
48: 0100007F:D6D0 0100007F:041F 01 00000000:00000000 00:00000000 00000000 10101 0 9592 1 f760c940 208 40 32 2 100
49: 0100007F:D6D3 0100007F:041F 01 00000000:00000000 00:00000000 00000000 10101 0 9597 1 f7bd9240 201 40 24 2 100
50: 0100007F:D6D2 0100007F:041F 01 00000000:00000000 00:00000000 00000000 10101 0 9596 1 f7bd9b40 201 40 26 2 100
51: 0100007F:D6E5 0100007F:041F 01 00000000:00000000 00:00000000 00000000 10501 0 15008 1 f67724c0 201 40 30 2 100
52: 0100007F:D6E4 0100007F:041F 01 00000000:00000000 00:00000000 00000000 10501 0 14626 1 f64d3240 201 40 30 2 100
53: 0100007F:D6E7 0100007F:041F 01 00000000:00000000 00:00000000 00000000 10501 0 16296 1 f0510dc0 201 40 30 2 100
54: 0100007F:D6F2 0100007F:041F 01 00000000:00000000 00:00000000 00000000 14201 0 18883 1 f0686940 201 40 30 2 100
55: 0100007F:041F 0100007F:D6D4 01 00000000:00000000 00:00000000 00000000 0 0 9611 1 f7bd84c0 201 40 31 2 100
56: 0100007F:041F 0100007F:D6D0 01 00000000:00000000 00:00000000 00000000 0 0 9593 1 f760c040 211 65 33 2 100
57: 0100007F:041F 0100007F:D6D1 01 00000000:00000000 00:00000000 00000000 0 0 9595 1 f64d36c0 212 46 29 2 100
58: 0100007F:041F 0100007F:D6D2 01 00000000:00000000 00:00000000 00000000 0 0 9599 1 f7bd96c0 205 40 27 2 100
59: 0100007F:041F 0100007F:D6D3 01 00000000:00000000 00:00000000 00000000 0 0 9600 1 f7bd8dc0 205 40 25 2 100
60: 0100007F:DB38 0100007F:D804 06 00000000:00000000 03:00000C44 00000000 0 0 0 2 e96de9c0
61: 0100007F:041F 0100007F:D6E4 01 00000000:00000000 00:00000000 00000000 0 0 14627 1 f6772040 201 40 31 2 100
62: 0100007F:041F 0100007F:D6E5 01 00000000:00000000 00:00000000 00000000 0 0 15009 1 f6772940 201 40 31 2 100
63: 0100007F:041F 0100007F:D6E7 01 00000000:00000000 00:00000000 00000000 0 0 16301 1 f0510940 201 40 31 2 100
64: 79176A0A:0016 58326A0A:82EB 01 00001ACC:00000000 01:00000017 00000000 0 0 19529421 4 f6979240 240 62 3 4 100
65: 0100007F:041F 0100007F:D6F2 01 00000000:00000000 00:00000000 00000000 0 0 18884 1 f0687b40 201 40 31 2 100
Each line starts with a hexadecimal form of IPv4 address and port number, with lower byte representing the first part of the address:
0100007F:0016 == 01.00.00.7F:0016 == 127.0.0.1:22
79176A0A:13C4 == 79.17.6A.0A:13C4 == 10.106.23.121:5060
Reference
The local IP address and port number for the socket. The IP address is displayed as a little-endian four-byte hexadecimal number; that is, the least significant byte is listed first, so you'll need to reverse the order of the bytes to convert it to an IP address. The port number is a simple two-byte hexadecimal number.
Here is a python version to convert to ip:port values from /proc/net/tcp. You can extend and add any other info that you might be interested in
cv#thunder:~/dev/py$ cat parsetcp.py
#!/usr/bin/python
tcpconn = open('/proc/net/tcp','r').readlines()
def hexip2str(hexip):
return '.'.join([ str(int('0x'+ hexip[j:j+2],16)) for j in range(6,-2,-2)])
for conn in tcpconn:
str_conn = [ x.strip() for x in conn.replace(':',' ').split() ]
if str_conn[0].isalpha():
continue
print hexip2str(str_conn[1]) + ':' + str(int(str_conn[2],16)),' => ',hexip2str(str_conn[3]) + ':' + str(int(str_conn[4],16))