tutorial about web security computer networking

Kamis, 21 Mei 2009

The Real Deal on Kylin

If you want the real deal on Kylin, the best public discussion is probably taking place at the Dark Visitor Blog. As you might expect of a blog that's run by people who actually speak Chinese and follow that country's scene, the story there is more believable than the sensationalism posted elsewhere.

I downloaded and tried installing KYLIN-2.1-1A.iso but didn't get far. It seems far newer versions are available if you know where to look.

Richard Bejtlich is teaching new classes in Las Vegas in 2009. Regular Las Vegas registration ends 1 July.

PSIRT Equals Getting Serious About Product Security

15.15 psirt No comments

Last fall I wrote Tips for PSIRTs, pointing to a new CERT document giving advice for Product Security Incident Response Teams. Today I read Adobe shifts to Microsoft patching process, incident response plan by Robert Westervelt. The company maintains an Adobe Secure Software Engineering Team and an Adobe Product Security Incident Response Team. All of this is a sign that Adobe is getting serious about product security. It mirrors Microsoft's evolution, and I am glad to see it happening.

I'd like to be able to do a search for "Oracle PSIRT" or "Apple PSIRT" and get real results. The Google Online Security Blog isn't a real PSIRT, either. Just as you should have a CIRT if you use computers, you should have a PSIRT if you sell software.

Richard Bejtlich is teaching new classes in Las Vegas in 2009. Regular Las Vegas registration ends 1 July.

24th Air Force to be Headquartered at Lackland AFB

08.56 afcert No comments

Congratulations to Lackland AFB in San Antonio, Texas for being chosen to host the headquarters for 24th Air Force, a "cyber numbered Air Force." Lackland is home to the AF ISR Agency (previously AIA), the AF Information Operations Center (previously AFIWC), and the 33rd Network Warfare Squadron (previously the 33 IOS, and before that the AFCERT).

It's been six years since I visited the place, but I think it's a great choice for the 24th.

Richard Bejtlich is teaching new classes in Las Vegas in 2009. Regular Las Vegas registration ends 1 July.

Host Protection: Working with Microsoft's Firewall

09.30 ICF;Cygwin;Microsoft's Firewall No comments

Both network and host protection are recommended. Each OS has native firewall host protection:

OpenBSD: pf

FreeBSD: pfsense

Fedora Cora: iptables with SELinux

Windows XP,2003,2008,Vista,7 : Windows Firewall (ICF)

Microsoft's native firewall on XP SP3 can be told to log all incoming and outgoing packets up to a maximum log size of 32676 bytes(2^15). It will turn over twice before rewriting the old log file name. A full examination of the Firewall's configuration is beyond the scope of this post. A regedt32 query of StandardProfiles and DomainProfiles for all Control Sets for all globally open ports and authorized applications is recommended as is a manual exploration of the appropriate regedt32 keys. (Netsh commands are available for all Firewalled Windows. Please see http://support.microsoft.com/kb/947709 . Powershell can also be used to configure Microsoft's Firewall. ):

regquery HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\AuthorizedApplications\List | findstr Enabled

reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\GloballyOpenPorts\List | findstr Enabled

reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\DomainProfile\AuthorizedApplications\List | findstr Enabled

reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\DomainProfile\GloballyOpenPorts\List | findstr Enabled

reg query HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\AuthorizedApplications\List | findstr Enabled

reg query HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\GloballyOpenPorts\List | findstr Enabled

reg query HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\SharedAccess\Parameters\FirewallPolicy\DomainProfile\AuthorizedApplications\List | findstr Enabled

reg query HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\SharedAccess\Parameters\FirewallPolicy\DomainProfile\GloballyOpenPorts\List | findstr Enabled

A sample partial result would be:

reg query HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\GloballyOpenPorts\List | findstr Enabled

139:TCP REG_SZ 139:TCP:LocalSubNet:Enabled:@xpsp2res.dll,-22004

445:TCP REG_SZ 445:TCP:LocalSubNet:Enabled:@xpsp2res.dll,-22005

137:UDP REG_SZ 137:UDP:LocalSubNet:Enabled:@xpsp2res.dll,-22001

138:UDP REG_SZ 138:UDP:LocalSubNet:Enabled:@xpsp2res.dll,-22002

53:UDP REG_SZ 53:UDP:LocalSubNet:Enabled:DNS-UDP

53:TCP REG_SZ 53:TCP:LocalSubNet:Enabled:DNS

500:UDP REG_SZ 500:UDP:*:Enabled:@xpsp2res.dll,-22017

The pfirewall.log gives a considerable amount of information as such:

more pfirewall.log

#Version: 1.5

#Software: Microsoft Windows Firewall

#Time Format: Local

#Fields: date time action protocol src-ip dst-ip src-port dst-port size tcpflags tcpsyn tcpack tcpwin icmptype icmpcode info path

2009-04-23 10:24:55 DROP UDP 192.168.0.4 192.168.0.255 137 137 96 - - - - - - - RECEIVE

2009-04-23 10:24:56 DROP UDP 192.168.0.4 192.168.0.255 137 137 96 - - - - - - - RECEIVE

2009-04-23 10:24:57 DROP UDP 192.168.0.4 192.168.0.255 137 137 96 - - - - - - - RECEIVE

2009-04-23 10:24:57 DROP UDP 192.168.0.4 192.168.0.255 138 138 202 - - - - - - - RECEIVE

2009-04-23 10:24:57 DROP UDP 192.168.0.4 192.168.0.255 137 137 78 - - - - - - - RECEIVE

2009-04-23 10:24:57 DROP UDP 192.168.0.4 192.168.0.255 137 137 96 - - - - - - - RECEIVE

....

Using Cygwin's Bash client and gawk, a list of src and dst ports can be obtained:

cat /cygdrive/D/pfirewall.log | awk -F" " '{print $7}' | sort -nr | uniq -c | sort -nr | more

cat /cygdrive/D/pfirewall.log | awk -F" " '{print $8}' | sort -nr | uniq -c | sort -nr | more

Gawk's conditional logic coupled with pcregrep quick searching helps us print the frequency of a destination IP and accompanying port(s) for a specified source IP:

cat /cygdrive/D/pfirewall.log | pcregrep OPEN | awk -F" " '{if ($5=="192.168.0.8") print $6 ":" $8}' | sort -nr | uniq -c | sort -nr | more

16138 192.168.0.1:53

902 192.168.0.1:80

446 74.125.242.24:80

359 65.214.57.165:80

304 216.73.87.115:80

272 85.13.200.108:110

247 70.32.92.85:80

240 216.73.87.152:80

215 75.101.163.8:80

208 68.142.93.133:80

203 74.125.127.191:80

201 128.111.41.37:80

....

Now we choose to sort by the frequency of one specific dst port for each dst IP from the specified (local) source IP:

cat /cygdrive/D/pfirewall.log | pcregrep OPEN | awk -F" " '{if ($5=="192.168.0.8") print $6 ":" $8}' | sort -nr | uniq -c | pcregrep ':443' | sort -nr

113 74.125.53.147:443

92 74.125.53.83:443

78 208.235.248.150:443

50 208.75.76.32:443

46 74.125.127.103:443

30 74.125.53.97:443

24 74.125.127.120:443

23 65.55.157.60:443

22 96.6.248.124:443

21 74.125.53.99:443

...

For example, I was surprised to find all the foreign addresses that my local computer asked NBNS queries of:

cat /cygdrive/D/pfirewall.log | pcregrep OPEN | awk -F" " '{if ($5=="192.168.0.8") print $6 ":" $8}' | sort -nr | uniq -c | pcregrep ':137' | sort -nr

42 192.168.0.4:137

39 192.168.0.6:137

36 192.168.0.2:137

16 192.168.0.9:137

15 206.51.224.187:137

14 208.117.252.85:137

14 192.168.0.1:137

13 206.72.124.93:137

11 74.125.103.33:137

10 64.94.107.20:137

10 64.236.79.54:137

10 206.191.161.8:137

...

The dates and times of those queries could be found with:

cat /cygdrive/D/pfirewall.log | pcregrep OPEN | awk -F" " '{if ($5=="192.168.0.8") print $1 ":" $4 ":" $6 ":" $8}' | pcregrep ':137' | sort -nr | more

2009-05-14:UDP:192.168.0.4:137

2009-05-06:UDP:75.52.124.131:137

2009-05-06:UDP:74.125.103.28:137

2009-05-06:UDP:69.64.6.21:137

2009-05-06:UDP:66.35.45.202:137

2009-05-06:UDP:66.35.45.201:137

2009-05-06:UDP:65.55.52.84:137

2009-05-06:UDP:65.55.52.148:137

2009-05-06:UDP:65.55.185.61:137

2009-05-06:UDP:65.55.185.29:137

2009-05-06:UDP:65.55.184.189:137

2009-05-06:UDP:65.173.218.69:137

2009-05-06:UDP:64.94.107.16:137

2009-05-06:UDP:64.236.115.52:137

2009-05-06:UDP:4.71.104.187:137

....

These two commands are also recommended:

C:\WINDOWS\system32\drivers\etc>net config server

C:\WINDOWS\system32\drivers\etc>net config workstation

Bash 4.0,awk,geoiplookup and pcregrep are fast

20.30 Bash 4.0;awk;geoiplookup;pcregrep; No comments

Bash 4.0,awk,geoiplookup and pcregrep make a powerfully fast search team. Here I find out how many sockets pairs are in my Snort dump:

bash-4.0# snort -qdevX -r May12085154PDT2009.1242143514 | pcregrep TTL | awk -F":" '{print $1}' | wc -l

372

Then I find out how many uniqe SIPs are in those socket pairs:

bash-4.0# snort -qdevX -r May12085154PDT2009.1242143514 | pcregrep TTL | awk -F":" '{print $1}' | uniq | sort -nr | wc -l

226

Then I find my top ten Source IP Addresses:

bash-4.0# snort -qdevX -r May12085154PDT2009.1242143514 | pcregrep TTL | awk -F":" '{print $1}' | sort | uniq -c | sort -nr | head -n 10

62 218.103.62.150

15 222.215.230.49

14 221.195.73.68

11 121.15.245.215

10 119.161.130.75

8 209.85.163.126

8 125.65.165.139

7 66.35.46.195

7 209.85.201.125

6 64.106.128.150

....

Then I determine what source ports my top SIP (foreign address) has initiated connections to:

bash-4.0# snort -qdevX -r May12085154PDT2009.1242143514 | pcregrep 218.103.62.150 | awk -F":" '{print $3}'| awk -F" " '{print $1}' | sort -n | uniq

113

160

1433

1434

2967

5554

6429

7212

12712

16896

17337

17681

17919

18448

18487

18488

18649

18932

19899

33436

38507

Next I find what are the top source ports for my top ten SIPs:

bash-4.0# for i in `cat temp.txt`; do echo $i && snort -qdevX -r May12085154PDT2009.1242143514 | pcregrep $i | awk -F":" '{print $3}'| awk -F" " '{print $1}' | sort | uniq -c | sort -nr; done

218.103.62.150

3 6429

3 5554

3 38507

3 33436

3 2967

3 19899

3 18932

3 18649

3 18488

3 18487

3 18448

3 17919

3 17681

3 17337

3 16896

3 160

3 1434

3 1433

3 12712

3 113

2 7212

222.215.230.49

6 7212

6 3128

3 8000

221.195.73.68

7 8000

7 7212

121.15.245.215

7 3128

4 8000

119.161.130.75

10 2967

209.85.163.126

8 33137

125.65.165.139

4 8000

4 3128

66.35.46.195

7 33436

209.85.201.125

3 18205

3 18184

1 18077

64.106.128.150

6 33442

Last, I retrieve those top ten SIP city locations:

bash-4.0# for i in `cat temp.txt`; do echo $i `snort -qdevX -r May12085154PDT2009.1242143514 | geoiplookup $i -f /usr/local/share/GeoIP/GeoLiteCity.dat` ;done

218.103.62.150 GeoIP City Edition, Rev 1: HK, 00, Kowloon, (null), 22.316700, 114.183296, 0, 0

222.215.230.49 GeoIP City Edition, Rev 1: CN, 32, Chengdu, (null), 30.666700, 104.066597, 0, 0

221.195.73.68 GeoIP City Edition, Rev 1: CN, 10, Hebei, (null), 39.889702, 115.275002, 0, 0

121.15.245.215 GeoIP City Edition, Rev 1: CN, 30, Jiangmen, (null), 22.583300, 113.083298, 0, 0

119.161.130.75 GeoIP City Edition, Rev 1: CN, 19, Chaoyang, (null), 41.570301, 120.458603, 0, 0

209.85.163.126 GeoIP City Edition, Rev 1: US, CA, Mountain View, 94043, 37.419201, -122.057404, 807, 650

125.65.165.139 GeoIP City Edition, Rev 1: CN, 32, Chengdu, (null), 30.666700, 104.066597, 0, 0

66.35.46.195 GeoIP City Edition, Rev 1: US, CO, Denver, 80216, 39.785000, -104.941498, 751, 303

209.85.201.125 GeoIP City Edition, Rev 1: US, CA, Mountain View, 94043, 37.419201, -122.057404, 807, 650

64.106.128.150 GeoIP City Edition, Rev 1: US, NJ, Hoboken, 07030, 40.745800, -74.032097, 501, 201

Understanding an attack

14.25 No comments

Snort can be run in daemon mode, with a configuration file that logs on certain alerts only. For demonstration, we can run Snort in 'packet dump' mode (-dev) for a day or so while using BPF filters for our own needs:

/usr/local/bin/snort -devX -i xl0 -L $(date "+%b%e%H%M%S%Z%Y") 'port not(domain or whois or http or https or syslog or ntp or smtp or 137 or 139)' and 'not(broadcast or icmp or igmp or arp)'

After some awkward awk statements and some ditzy KSH work, we have a list of ports others who are seeking our network seem interested in:

snort -vdeX -r May12085154PDT2009.1242143514 | grep TTL: | awk -F"->" '{print $1 ":" $2 ":" $3}' | awk -F":" '{print $4}' | awk -F" " '{print $1}' | sort -nr | uniq -c | sort -nr

14 2967
6 8000
6 5900
6 3128
6 22
5 23
5 1434
5 12712
4 7212
4 4899
4 1433
1 8080
1 7209
1 65535
1 56017
1 3306
1 23803
1 21
1 19756
1 19696
1 1024

snort -vdeX -r May12085154PDT2009.1242143514 | grep TTL: | awk -F"->" '{print $1 ":" $2 ":" $3}' | awk -F":" '{print $4}' | awk -F" " '{print $1}' | sort | uniq | sort -nr >> ports.txt

for i in `cat ports.txt`; do grep -w $i /usr/local/share/nmap/nmap-services;done

http-proxy 8080/tcp # Common HTTP proxy/second web server port
http-alt 8000/tcp # A common alternative http port
vnc 5900/tcp # Virtual Network Computer display
radmin 4899/tcp # Radmin (www.radmin.com) remote PC control software
mysql 3306/tcp # mySQL
squid-http 3128/tcp #
symantec-av 2967/udp # Symantec AntiVirus (rtvscan.exe)
ms-sql-m 1434/tcp # Microsoft-SQL-Monitor
ms-sql-m 1434/udp # Microsoft-SQL-Monitor
ms-sql-s 1433/tcp # Microsoft-SQL-Server
ms-sql-s 1433/udp # Microsoft-SQL-Server
kdm 1024/tcp # K Display Manager (KDE version of xdm)
telnet 23/tcp #
telnet 23/udp #
ssh 22/tcp # Secure Shell Login
ssh 22/udp # Secure Shell Login
ftp 21/tcp # File Transfer [Control]
ftp 21/udp # File Transfer [Control]

Nmap services file helps explain much here, but why the large interest in a Symantec AntiVirus port? It turns out others have noticed this recently as well and are asking for input:

http://isc.sans.org/diary.html?storyid=6319.
http://msmvps.com/blogs/harrywaldron/archive/2006/11/27/new-botnet-impacts-symantec-client-port-2967-on-unpatched-pcs.aspx
http://www.offensivecomputing.net/?q=node/403

Is this a new or mutated trojan? worm? remote exploit? Multiple addresses are interested in connecting to us on this port:

# snort -vdeX -r May12085154PDT2009.1242143514 | grep TTL: | grep 2967 | sort -nr | uniq -c | sort -nr

3 218.75.95.242:6000 -> 192.168.0.12:2967 TCP TTL:105 TOS:0x20 ID:256 IpLen:20 DgmLen:40
2 119.161.130.75:6000 -> 192.168.0.12:2967 TCP TTL:99 TOS:0x20 ID:256 IpLen:20 DgmLen:40
1 61.191.63.8:6000 -> 192.168.0.12:2967 TCP TTL:103 TOS:0x20 ID:256 IpLen:20 DgmLen:40
1 61.145.62.75:6000 -> 192.168.0.12:2967 TCP TTL:107 TOS:0x20 ID:256 IpLen:20 DgmLen:40
1 60.173.12.60:6000 -> 192.168.0.12:2967 TCP TTL:106 TOS:0x20 ID:256 IpLen:20 DgmLen:40
1 60.172.229.11:6000 -> 192.168.0.12:2967 TCP TTL:105 TOS:0x20 ID:65419 IpLen:20 DgmLen:40
1 60.172.229.11:6000 -> 192.168.0.12:2967 TCP TTL:105 TOS:0x20 ID:42349 IpLen:20 DgmLen:40
1 222.186.26.93:6000 -> 192.168.0.12:2967 TCP TTL:103 TOS:0x20 ID:256 IpLen:20 DgmLen:40
1 121.140.174.105:6000 -> 192.168.0.12:2967 TCP TTL:107 TOS:0x20 ID:256 IpLen:20 DgmLen:40
1 121.14.156.149:6000 -> 192.168.0.12:2967 TCP TTL:102 TOS:0x20 ID:256 IpLen:20 DgmLen:40
1 121.14.156.148:6000 -> 192.168.0.12:2967 TCP TTL:103 TOS:0x20 ID:256 IpLen:20 DgmLen:40

But the packet looks like a simple connection attempt to a remote port. A buffer overflow in Symantec AntiVirus port?

218.75.95.242:6000 -> 192.168.0.12:2967 TCP TTL:105 TOS:0x20 ID:256 IpLen:20 DgmLen:40
******S* Seq: 0x60B40000 Ack: 0x0 Win: 0x4000 TcpLen: 20
0x0000: 00 60 97 30 6B C4 00 09 5B 00 F3 DA 08 00 45 20 .`.0k...[.....E
0x0010: 00 28 01 00 00 00 69 06 55 BE DA 4B 5F F2 C0 A8 .(....i.U..K_...
0x0020: 00 0C 17 70 0B 97 60 B4 00 00 00 00 00 00 50 02 ...p..`.......P.
0x0030: 40 00 F1 34 00 00 00 00 00 00 00 00 @..4........

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

05/13-12:59:50.507559 0:9:5B:0:F3:DA -> 0:60:97:30:6B:C4 type:0x800 len:0x3C
121.140.174.105:6000 -> 192.168.0.12:2967 TCP TTL:107 TOS:0x20 ID:256 IpLen:20 DgmLen:40
******S* Seq: 0x4260000 Ack: 0x0 Win: 0x4000 TcpLen: 20
0x0000: 00 60 97 30 6B C4 00 09 5B 00 F3 DA 08 00 45 20 .`.0k...[.....E
0x0010: 00 28 01 00 00 00 6B 06 66 06 79 8C AE 69 C0 A8 .(....k.f.y..i..
0x0020: 00 0C 17 70 0B 97 04 26 00 00 00 00 00 00 50 02 ...p...&......P.
0x0030: 40 00 60 0B 00 00 00 00 00 00 00 00 @.`.........

A Brief Anatomy of Malware detection and some notes on using traceroute and determining 'intent'

11.29 Win32:SQLSlammer;Malware detection;Snort;Traceroute No comments

From the posts below we can begin to understand why signature identification is so important. We are looking for malware in the packet data itself since any port can be used to send malware and any IP can be spoofed or unwittingly part of a botnet or worm. The packets below are indicative of the "Win32:SQLSlammer" worm attack that has been around for a considerable time. The worm propagates itself by generating random IP addresses. Notice that the first SIP (Source IP) address is either spoofed or "router leakage" : e.g. it comes from RFC1918 "private" (non-internet IPs) subnet: 10.255.255.255. Remember that any of these IP addresses can be either (a) spoofed or (b) botnet victims or (c) unpatched SQL servers so that their ultimate location may not neccessarily tells us anything about 'intent' or 'bad actors'. Note the common signature in these 376 byte packets. The "Win32:SQLSlammer" reeked an extraordinary amount of havoc upon the internet with a very small amount of assembly code. The current Snort rules for this worm look like this:

alert udp $EXTERNAL_NET any -> $HOME_NET 1434 (msg:"SQL Worm propagation attempt"; flow:to_server; content:"|04|"; depth:1; content:"|81 F1 03 01 04 9B 81 F1 01|"; content:"sock"; content:"send"; metadata:policy balanced-ips drop, policy security-ips drop; reference:bugtraq,5310; reference:bugtraq,5311; reference:cve,2002-0649; reference:nessus,11214; reference:url,vil.nai.com/vil/content/v_99992.htm; classtype:misc-attack; sid:2003; rev:12;)

alert udp $HOME_NET any -> $EXTERNAL_NET 1434 (msg:"SQL Worm propagation attempt OUTBOUND"; flow:to_server; content:"|04|"; depth:1; content:"|81 F1 03 01 04 9B 81 F1|"; content:"sock"; content:"send"; metadata:policy balanced-ips drop, policy security-ips drop; reference:bugtraq,5310; reference:bugtraq,5311; reference:cve,2002-0649; reference:nessus,11214; reference:url,vil.nai.com/vil/content/v_99992.htm; classtype:misc-attack; sid:2004; rev:11;)

The packets I captured are below. Note the common ASCII signature

05/11-14:33:07.744419 0:9:5B:0:F3:DA -> 0:60:97:30:6B:C4 type:0x800 len:0x1A2

10.13.3.61:1092 -> 192.168.0.12:1434 UDP TTL:113 TOS:0x20 ID:61068 IpLen:20 DgmLen:404

Len: 376

0x0000: 00 60 97 30 6B C4 00 09 5B 00 F3 DA 08 00 45 20 .`.0k...[.....E

0x0010: 01 94 EE 8C 00 00 71 11 8B AE 0A 0D 03 3D C0 A8 ......q......=..

0x0020: 00 0C 04 44 05 9A 01 80 63 09 04 01 01 01 01 01 ...D....c.......

0x0030: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................

0x0040: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................

0x0050: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................

0x0060: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................

0x0070: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................

0x0080: 01 01 01 01 01 01 01 01 01 01 01 DC C9 B0 42 EB ..............B.

0x0090: 0E 01 01 01 01 01 01 01 70 AE 42 01 70 AE 42 90 ........p.B.p.B.

0x00A0: 90 90 90 90 90 90 90 68 DC C9 B0 42 B8 01 01 01 .......h...B....

0x00B0: 01 31 C9 B1 18 50 E2 FD 35 01 01 01 05 50 89 E5 .1...P..5....P..

0x00C0: 51 68 2E 64 6C 6C 68 65 6C 33 32 68 6B 65 72 6E

0x00D0: 51 68 6F 75 6E 74 68 69 63 6B 43 68 47 65 74 54 QhounthickChGetT

0x00E0: 66 B9 6C 6C 51 68 33 32 2E 64 68 77 73 32 5F 66 f.llQh32.dhws2_f

0x00F0: B9 65 74 51 68 73 6F 63 6B 66 B9 74 6F 51 68 73 .etQhsockf.toQhs

0x0100: 65 6E 64 BE 18 10 AE 42 8D 45 D4 50 FF 16 50 8D end....B.E.P..P.

0x0110: 45 E0 50 8D 45 F0 50 FF 16 50 BE 10 10 AE 42 8B E.P.E.P..P....B.

0x0120: 1E 8B 03 3D 55 8B EC 51 74 05 BE 1C 10 AE 42 FF ...=U..Qt.....B.

0x0130: 16 FF D0 31 C9 51 51 50 81 F1 03 01 04 9B 81 F1 ...1.QQP........

0x0140: 01 01 01 01 51 8D 45 CC 50 8B 45 C0 50 FF 16 6A ....Q.E.P.E.P..j

0x0150: 11 6A 02 6A 02 FF D0 50 8D 45 C4 50 8B 45 C0 50 .j.j...P.E.P.E.P

0x0160: FF 16 89 C6 09 DB 81 F3 3C 61 D9 FF 8B 45 B4 8D ........

0x0170: 0C 40 8D 14 88 C1 E2 04 01 C2 C1 E2 08 29 C2 8D .@...........)..

0x0180: 04 90 01 D8 89 45 B4 6A 10 8D 45 B0 50 31 C9 51 .....E.j..E.P1.Q

0x0190: 66 81 F1 78 01 51 8D 45 03 50 8B 45 AC 50 FF D6 f..x.Q.E.P.E.P..

0x01A0: EB CA ..

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

05/11-14:53:48.630387 0:9:5B:0:F3:DA -> 0:60:97:30:6B:C4 type:0x800 len:0x1A2

202.99.11.99:1231 -> 192.168.0.12:1434 UDP TTL:110 TOS:0x80 ID:26925 IpLen:20 DgmLen:404

Len: 376

0x0000: 00 60 97 30 6B C4 00 09 5B 00 F3 DA 08 00 45 80 .`.0k...[.....E.

0x0010: 01 94 69 2D 00 00 6E 11 4B 31 CA 63 0B 63 C0 A8 ..i-..n.K1.c.c..

0x0020: 00 0C 04 CF 05 9A 01 80 9A 01 04 01 01 01 01 01 ................