When calling putAt() on a Map with a String as a key, the Object version of putAt() is selected over the Map version. In other words, it will only call Map.put() if a property with the same name does not exist. However, calling getAt() on a Map will only call Map.get(), and will never return an object property.

class A extends HashMap { String y; } // any Map

a = new A();

a['x'] = 1;
a['x'];           // => 1
a.get('x');       // => 1
a.putAt('x', 2);
a.getAt('x');     // => 2

a['y'] = 1;
a['y'];           // => null
a.get('y');       // => null
a.putAt('y', 2);
a.getAt('y');     // => null
org.codehaus.groovy.runtime.DefaultGroovyMethods.putAt(a, 'y', 3)
a.getAt('y');     // => 3 !?

class B { String y = "hi"; }
(new B()).getAt('y');  // => "hi"
(new B())['y'];        // => "hi"

class C implements Map { String y; /* implement Map methods */ } 
(new C()).getAt('y');  // => null
(new C())['y'];        // => null

Ranges

The exclusive range operator (..<) generates a Range where the ending value is one step closer to the beginning value. The less-than symbol can be somewhat unintuitive for descending ranges.

enum E { ONE, TWO, THREE, FOUR }
((E.ONE)..(E.THREE)).toList()  // [ONE, TWO, THREE]
((E.ONE)..<(E.THREE)).toList() // [ONE, TWO]
((E.THREE)..(E.ONE)).toList()  // [THREE, TWO, ONE]
((E.THREE)..<(E.ONE)).toList() // [THREE, TWO]

Indexing a List with a Range only considers from and to values after the above adjustment; the result of Range.toList() is irrelevant, and whether or not it was an exclusive range is not known. Three steps are performed to get the result:

1. Negative values are normalized to positive values by adding them to List.size()
2. The result is generated from List.subList( min(from, to), max(from, to) )
3. If from > to, the result is reversed

In Ruby, a[0...-1] means “From the 0th element up to and excluding the last element,” whereas the ostensibly equivalent construct in Groovy, a[0..<-1], means “From the 0th element to the 0th element.”

a = [0,1,2,3,4]

a[0..-1]             // => [0, 1, 2, 3, 4]
a[0..-2]             // => [0, 1, 2, 3]
a[0..<-1]            // => [0]
a[0..<-2]            // => [0, 1, 2, 3, 4]

a[0..-2]             // => [0, 1, 2, 3]
a[-1..-2]            // => [5, 4]
a[-1..<-2]           // => [5]

Compare to Ruby:

a[0..-1]              # => [0, 1, 2, 3, 4]
a[0..-2]              # => [0, 1, 2, 3]
a[0...-1]             # => [0, 1, 2, 3]
a[0...-2]             # => [0, 1, 2]

a[0..-2]              # => [0, 1, 2, 3]
a[-1..-2]             # => []
a[-1...-2]            # => []

git filter-branch --env-filter "\
  export GIT_AUTHOR_NAME=Dade\ Murphy \
         GIT_AUTHOR_EMAIL=zer0cool@example.com \
         GIT_COMMITTER_NAME=Dade\ Murphy \
         GIT_COMMITTER_EMAIL=zer0cool@example.com "

Source: serverfault

There are three doors, and one of them has a prize. You choose one of the doors, and Monty opens one of the others that is not a winner. Now you have the option to stick with your original choice, or switch to the remaining door. It might seem counter-intuitive, but switching doubles your odds of winning.

Some people have attempted to apply the same logic to scouting as Zerg using an overlord and a drone in Starcraft. Stated similarly, the problem goes like this:

There are three starting locations, and one of them has your enemy base. You send a drone to one location, and your overlord gets to one of the other locations and discovers no enemy base. Now you have the option to stick with your original choice, or send your drone to the remaining location.

Sounds the same, but in this case, switching has no effect on your odds of winning. It is the same as the “Monty Fall” or “Ignorant Monty” variant of the Monty Hall problem, where Monty opens a door completely at random rather than one which is a non-winner.

The difference is because in the classic Monty Hall problem, you are initially choosing one door, which gives you 1/3 odds of your first choice being right. If you could choose to switch to both other doors, you’d obviously have a 2/3 chance of winning. In fact, this is exactly what you are doing when you switch, even after one of the doors has been revealed.

In the Starcraft problem, you are choosing two locations to begin with, which gives you a 2/3 chance of being right. If you choose to switch your drone to the remaining location at any point, the overlord still has a 1/3 chance and the drone still has a 1/3 chance. In the Monty Hall problem, you switch from only an unknown door (1/3), to the empty door and an unknown door (2/3). In the Starcraft problem, you switch from both an empty location and an unknown location (2/3), to the same empty location and a different unknown location (2/3).

To demonstrate this visually, I’ve made a simulator in Javascript.

Update (5/3):
I added a “Monty Hall mode” to the simulator, the implementation of which may help make this even clearer. Normally, I choose two random locations from the possible enemy starting points, and send the overlord to the first and the drone to the second. This leads to 3 possibilities with an equal chance of occuring: the overlord finds the base, the drone finds the base, or neither finds the base. Only in the final case, which occurs 1/3 of the time, would it be correct to switch. In “Monty Hall mode,” the overlord is not allowed to find the base – so the 1/3 of the time where the overlord would normally have found the base, is now added to the 1/3 of the time when neither finds the base, making it correct to switch 2/3s of the time.

I also added a “Stupid Overlord mode” which demonstrates that the order is important. If the overlord chooses an empty base first, rather than the drone choosing first, the chances of the drone being correct are (obviously) 1/2.

To prevent these exploits, developers are generally advised to canonicalize input and encode data in output. While this is correct, I think it is important to also understand that it shouldn’t be that way. Developers should have to go an extra mile to cause data to be interpreted as code, not the other way around.

Consider this common SQL injection scenario:

$result = mysql_query( "select id, name, pass from users where name='$name'", $db );

While it’s clear that $name is simply data to the developer, it’s being crammed into a string along with code and handed off to another system for re-interpretation. A common solution to prevent injection is something like this:

$query = sprintf( "select id, name, pass from users where name='%s' ", mysql_real_escape_string($name) );
$result = mysql_query( $query, $db );

It’s true that this solution fixes the vulnerability in this instance, but it’s a heavy burden: always remember to add a whole bunch of code every time you perform this incredibly common task, or you will introduce one of the most serious vulnerabilities possible into your application. In my opinion, even though the code may be “secure,” it is still wrong. You are still mixing up code and data in the same place on the same channel. Here is a better solution:

$stmt = $mysqli->prepare("select id, name, pass from users where name=?");
$stmt->bind_param("s", $name);
$stmt->execute();

This looks similar, but it’s important to understand how it works. The first line sends all of the code to be parsed and prepared by the server. Data to be filled in later is represented by question marks, which can only be used where data is expected. After this point, nothing is re-interpreted. When we send the data on the second line, the server is only reading data, and no special encoding is required to prevent it from being treated as code.

Even though it suffers the same criticism of being extra code every time you want to execute a SQL query, a developer used to coding this way is much less likely to make a mistake than a developer used to the previous example. The statements could also be prepared in an initializer somewhere completely different instead of right next to where data is being bound, to make it even harder to make a mistake.

Imagine if HTML/HTTP had something similar:

<html>
<div class="title">&data[0,16];</div>
<div class="body">&data[17,256];</div>
</html>
Data until EOF. <!-- &amp; No possibility of being interpreted as html. <script>alert(1);</script>

Note that the data part is a complete black box and terminated out-of-band (by closing the connection). There aren’t lengths or other special markers embedded in the data. I’m not suggesting this is a realistic possibility for HTML or any other established standard. I just want to make the point that a protocol which makes it impossible to confuse code and data is invulnerable to injection attacks by default.

A related idea is identifying the source of data. When an application includes user input in its own output, or in SQL statements, or anywhere else, it takes responsibility for it; to other applications, it’s data (or code) coming from the first application, not data coming from a user or third-party application somewhere else.

In cases where user input needs to be specially interpreted, especially by some other application – when you want to let people include a little HTML in a post, for example – then you have a more difficult problem which can’t be solved by shoving it all into a separate black box. But imagine how nice it would be if you could specify that some bit of HTML was from a user, or some other website (perhaps with digital signatures), or whatever, and the browser could handle sandboxing and cross-domain policies and everything else it already has the ability to do.

I think it is important to address this idea up front not just when designing a protocol or file format, but when designing APIs and internal interfaces to existing systems. Even if you have to output HTML or actual SQL statements, an interface to generate the output which cleanly separates code and data can relieve the burden from developers, isolate potential weaknesses in one place, and go a long way to improve the security of a system.

What’s the result of (unsigned int)atoi("4294967295") in C?

Even if you know the answer, how quickly can you prove it? How concisely can you communicate the proof via IM or email? What if it’s a poorly documented third-party library function, and not a standard one?

For quick tasks, you can just use gdb which is probably already present on any system that has gcc. Just fire up gdb on any binary, set a breakpoint on main, and run. When it stops you will be able to call functions and examine their results, and many other common REPL tasks. The binary doesn’t matter much, but you should prefer ones with debugging symbols, and if you want to call functions in a particular library, you should use a binary that is linked to that library.

Example session:

~% gdb ./test
(gdb) break main
Breakpoint 1 at 0x8048452
(gdb) run
Starting program: /home/pcl/sandbox/test
Breakpoint 1, 0x08048452 in main ()
(gdb) set $a = malloc(1234)
(gdb) call sprintf($a, "Hello %d", 12345*12345*12345)
$1 = 15
(gdb) print (char*)$a
$2 = 0x96c6008 "Hello 170287977"
(gdb) print (unsigned int)atoi("-1")
$3 = 4294967295
(gdb) print (unsigned int)atoi("4294967295")
$4 = 2147483647

gdb lets you use arbitrarily-named, untyped convenience variables, as you can see in the example. The only practical difference between print $var = expr, call $var = expr, and set $var = expr seems to be that set does not additionally assign the result to a history variable. Obviously you also have the full debugging facilities of gdb available as well.

It is also possible to do this on stripped binaries with no ‘main’ function, but there are many disadvantages:

~% gdb `which echo`
(gdb) inf files
	Entry point: 0x8048be0	0x08048154 - 0x08048167 is .interp
(gdb) break *0x8048be0
Breakpoint 1 at 0x8048be0

For a fully featured REPL for C, check out c-repl.

The system in question is called GEMINI CDS Ban Relay and is advertised as a simple object which detects avatars entering your sim, and uses “a team of bots with special abilities” to determine if the avatar is “harmful.” If they are, it adds them to an external database, and can optionally ban or teleport them home. Entries in the database are permanent, so if an avatar has been considered harmful once, they are always considered harmful in the future. It claims to use several frequently updated methods to detect “illegitimate” clients.

The most obvious detection method, and the only one I discovered, is a script that triggers as soon as you enter a protected sim and tells your client to load up a special media URL. Using a tool like Wireshark or ngrep, it is trivial to watch the HTTP request.

Broken down, the requested URL in my case was:

http://media.syscast.net/youtube.php
  ? licensekey = KBVaQkxGH1lDVRdBWA1GVEdaTFpQF1ReWUcREU9YEFxBRgxE
  & title      = BEYeQR8TAxxOLE8eBk0T
  & licensedon = B1IAQhUG
  & tvowner    = eBVbGUdLQFxeVA%3D%3D
  & videoid    = eEJVE0xDHwxZAUQSWBJFARMJV1RTE19BWUETGBMNQg0%3D

At a glance, the values are obviously all Base64 encoded — the trailing %3Ds on the last two fields are a dead giveaway. Decoding them doesn’t produce anything human-readable, though; one online service gives me “(ZBLFYCUAXFTGZLZPT^YGOX\AFD” for the first field.

It’s easy to decode them in Ruby, where we can play with them a little more:

irb(main):002:0> CIPHERTEXT = Base64.decode64('KBVaQkxGH1lDVRdBWA1GVEdaTFpQF1ReWUcREU9YEFxBRgxE')
=> "(\025ZBLF\037YCU\027AX\rFTGZLZP\027T^YG\021\021OX\020\\AF\fD"

irb(main):003:0> CIPHERTEXT.length
=> 36

36 bytes is the same length as a UUID in canonical form, so it’s a pretty reasonable guess that this is my avatar’s UUID encrypted somehow. The only real encryption facility LSL makes available is XORing Base64-encoded strings together. XOR has an interesting property: a ⊕ b = c ⇒ a ⊕ c = b; that is, if XORing some plaintext and some key produces some ciphertext, then XORing that ciphertext and the plaintext produces the key. Let’s give it a shot:

irb(main):004:0> PLAINTEXT = 'a27b84f0-2757-4176-9579-43a181d4a5a0'
=> "a27b84f0-2757-4176-9579-43a181d4a5a0"

irb(main):007:0> CIPHERTEXT.bytes.each_with_index {|v,i| key << (v ^ PLAINTEXT[i])}; key
=> "I'm trying to replace msmtp with smt"

That was easy enough. Using the key to decode the rest of the fields, we can see what is really being sent:

http://media.syscast.net/youtube.php
  ? licensekey = a27b84f0-2757-4176-9579-43a181d4a5a0
  & title      = Masakazu Kojima
  & licensedon = Numbat
  & tvowner    = 1269399503
  & videoid    = 1e8381fe7fdf727dce67632245c8dd6e

The second field (title) turns out to be my avatar name, followed by the sim name (licensedon), a UNIX time value (tvowner), and what looks like an MD5 hash (videoid). The time value is apparently used to prevent replay attacks: it is possible to immediately replay the request exactly and get a success response, but after about 30 seconds it causes an internal server error instead.

Visiting the parcel again to get another URL shows that only the time and MD5 hash change. Tampering with the values causes an immediate error redirect, which suggests that the MD5 hash is a signature to prevent forged messages. So, even though we could encrypt arbitrary values and send them, we’d need to know how the signature is generated for them to work.

The response from the server is innocent enough:

<!--
-->
<html><head></head><body bgcolor="#7f7f7f" leftmargin="0" topmargin="0"><img src="video-background.gif" width="2000px" height="2000px" border="0px" /></body></html>

The video-background.gif file is just a transparent 1×1 GIF image:

00000000  47 49 46 38 39 61 01 00  01 00 80 00 00 7f 7f 7f  |GIF89a..........|
00000010  00 00 00 21 f9 04 00 00  00 00 00 2c 00 00 00 00  |...!.......,....|
00000020  01 00 01 00 00 02 02 44  01 00 3b                 |.......D..;|

These are the only requests that are performed. Nothing nefarious appears to be taking place. There is no evidence of any kind of exploit, or the transmission of any kind of private information. So how does the service detect “illegitimate” clients?

The magic turns out to be in the “User-Agent” request header, which identifies the client. In my case: Mozilla/5.0 (Windows; U; Windows NT 6.0; chrome://navigator/locale/navigator.properties; rv:1.8.1.21) Gecko/20090305 SecondLife/Emerald Viewer (default skin)

By using curl to replay an old request, and simply replacing “Emerald Viewer” with the name of a random client from the Onyx project (NeilLife), I was able to get the system to ban an alternate account I created. Note that this worked even though the time value was old, and the HTTP response status was a 500 error, so it would appear that the system to prevent replay attacks is broken. Looks like they’re up to at least 1 false positive, even if it’s a technicality. Also note that the actual response body did not change, so there doesn’t seem to be any kind of exploit that is only sent to users of “bad” clients.

Using the same IP address and computer, I was able to go back to the same parcel on my main account with no trouble.

Conclusions

Despite all the subterfuge, the Gemini CDS system seems to simply rely on “illegitimate” clients to identify themselves in an HTTP request. The message encryption is trivial to break, and it would seem that is only a matter of time before someone cares enough to figure out how to forge the message signature. It is trivial to avoid detection by this method, though the system may employ additional detection methods: the common way for third-party clients to identify each other is by the unique texture UUIDs they use for skin layer protection, which is passive and undetectable.

There is no evidence that the system uses any kind of exploit or other nefarious tactic. The system does not appear to record any data other than the avatar and client self-identification information.

It’s actually really easy to fix this:

export FIGNORE=.svn

$FIGNORE is just a colon-separated list of suffixes to ignore when doing tab completion.

In my setup, my computer is 192.168.0.100 and the phone is 192.168.0.200. You will have to replace them with your own IP addresses.

Here is the command to start gstreamer on the phone. You will probably want to put it in a script:

gst-launch v4l2camsrc device=/dev/video0 ! \
           dsph264enc ! \
           rtph264pay ! \
           udpsink host=192.168.0.100 port=5434

If gst-launch is not found, you probably need to install the gstreamer-tools package:

apt-get install gstreamer-tools

To use the camera on the front of the phone, you can change the device to /dev/video1.

Here is the minimal sdp file I was able to use with VLC to get it to play. Using the “Open Network” dialog to try and play an RTP stream did not work.

v=0
m=video 5434 RTP/AVP 96
c=IN IP4 192.168.0.200
a=rtpmap:96 H264/90000

The second line (m=) contains the port, the third (c=) contains the IP address of the phone, and the fourth (a=) specifies the codec.

To use MP4 instead of H264, you can just change h264 to mp4v everywhere. In the SDP file, it should be MP4V-ES, as in: a=rtpmap:96 MP4V-ES/90000. If you get errors in VLC like:

avcodec warning: cannot decode one frame (14922 bytes)

Then add send-config=true to the rtpmp4v part of the gstreamer pipeline, and make sure you start VLC before you start streaming:

gst-launch v4l2camsrc device=/dev/video0 ! \
           dspmp4venc ! \
           rtpmp4vpay send-config=true ! \
           udpsink host=192.168.0.100 port=5434

For H263, you can try dsph263enc, rtph263pay and H263-1998 or H263-2000, but I couldn’t get it to work.

I don’t know if there’s a way to control the focus, white balance, etc, but I was able to use the flashlight-applet to turn on the camera LEDs while streaming after I downgraded to 0.2-0:

apt-get install flashlight-applet=0.2-0

PHREAK: Alright, what are the three most commonly used passwords?
JOEY: love, secret, and uh, sex. But not in that order, necessarily, right?
CEREAL: Yeah but don’t forget GOD. System operators love to use GOD. It’s that whole male ego thing.

Analyses of various password leaks:

• 32 million RockYou passwords (December 2009)
• 47,380 phished MySpace passwords (2006), 28,644 phpBB.com mailing list passwords (January 2009), and 40,758 singles.org passwords (February 2009)
• 10,000 phished Hotmail passwords (October 2009)
• 8,000 Comcast passwords (March 2009)

I think it is interesting that as bad as the passwords in Hackers seem, the passwords people actually use are somehow even worse. Where it’s allowed, 123456 always takes the number one spot, usually by a huge margin; in the RockYou leak, 123456 was used 4x more than its closest competitor (12345). When purely numeric password are forbidden, password is the clear winner, and continues to take the number one spot as requirements are added.

Require a capital letter? Password
Number? password1
Both? Password1

The top three I’d try, without knowing the requirements:

1. 123456
2. password
3. password1