-1
0x0000:  4500 00bc 0000 4000 4011 281d c0a8 c801  E.....@.@.(.....
0x0010:  c0a8 c8c1 0035 2f16 00a8 bf52 1a74 8183  .....5/....R.t..
0x0020:  0001 0000 0001 0000 0136 0139 0161 0163  .........6.9.a.c
0x0030:  0161 0136 0163 0135 0166 0130 0137 0137  .a.6.c.5.f.0.7.7
0x0040:  0162 0138 0138 0135 0130 0130 0130 0130  .b.8.8.5.0.0.0.0
0x0050:  0130 0130 0130 0130 0130 0130 0130 0130  .0.0.0.0.0.0.0.0
0x0060:  0130 0138 0165 0166 0369 7036 0461 7270  .0.8.e.f.ip6.arp
0x0070:  6100 000c 0001 c04c 0006 0001 0000 0e10  a......L........
0x0080:  003a 0162 0b69 7036 2d73 6572 7665 7273  .:.b.ip6-servers
0x0090:  c050 0a68 6f73 746d 6173 7465 7205 6963  .P.hostmaster.ic
0x00a0:  616e 6e03 6f72 6700 781c 5634 0000 0708  ann.org.x.V4....
0x00b0:  0000 0384 0009 3a80 0000 0e10            ......:.....

The above format is normal text encrypted with some algorithm and converted as payload. How to decrypt and read it as normal form.And please exaplain me what are all these.I assumed all these as a payload.

Artjom B.
  • 61,146
  • 24
  • 125
  • 222
Tech
  • 51
  • 4

1 Answers1

2

This is not encrypted. This is a normal dump of an IP packet. Let's try to read it.

First 4 bits say ip version 4, next 4 bits: header length 5 (5 * 4 = 20 bytes), TOS = 0, total length = 0xBC (which matches the length of the dumped packet so we're on the right track), ID = 0, offset has the "don't fragment" flag set, TTL = 0x40 (64), protocol = 0x11 (UDP), checksum 0x281d, source address = 192.168.200.1, destination address = 192.168.200.193.

Then the UDP packet follows, source port = 53 (which is DNS), destination port = 12054, length = 168, checksum 0xbf52, the rest is the payload which I can't be bothered to decode but it looks like a reverse lookup of an ipv6 address.

Art
  • 19,807
  • 1
  • 34
  • 60
  • For algorithms, look at the Wireshark or tcpdump source code. For details of what an algorithm would do, see [RFC 791](https://tools.ietf.org/html/rfc791) for IPv4, [RFC 768](https://tools.ietf.org/html/rfc768) for UDP, and [RFC 1034](http://tools.ietf.org/html/rfc1034), [RFC 1035](http://tools.ietf.org/html/rfc1035), and all the "Updated by:" links in the latter two. [There is no royal road to packet dissection](https://books.google.com/books?id=JZEHj2fEmqAC&lpg=PP1&pg=PA57#v=onepage&q&f=false). –  Feb 15 '16 at 11:29
  • yup.I asked only about the encrypted data.How to decode that. – Tech Feb 15 '16 at 11:40
  • @Tech There is no encrypted data in the question. As a hint, encrypted data would have no patterns but I see patterns and ASCII text. Here is what random data looks like: `2533 2a61 87d5 04b4 5a72 5575 4663 8618 e119 9401 668d c2fa 6bda 3421 ef02 432f`, do you see and patterns, resemblance to the question data?. – zaph Feb 15 '16 at 14:53
  • E.....@.@.(..... .....5/....R.t.. .........6.9.a.c .a.6.c.5.f.0.7.7 .b.8.8.5.0.0.0.0 .0.0.0.0.0.0.0.0 .0.8.e.f.ip6.arp a......L........ .:.b.ip6-servers .P.hostmaster.ic ann.org.x.V4.. ......:..... – Tech Feb 16 '16 at 04:44
  • In the above comment i specified the encrypted data of a packet – Tech Feb 16 '16 at 04:47
  • 1
    Encrypted. You keep using that word. I do not think it means what you think it means. There's nothing encrypted in there. Nothing at all. – Art Feb 16 '16 at 07:34
  • If by "encrypted" you mean "not ASCII text", that's not the right word. Not all packets have ASCII (or UTF-8) text contents; Ethernet, IPv4 and UDP, for example, have *binary* headers. And even though the DNS part of the packet looks mostly as if it's ASCII text, even *it* isn't completely ASCII. See the RFCs I mentioned in my comment for information on the formats of those packets. –  Feb 18 '16 at 14:14