Gonçalo Ribeiro

@goncalor@infosec.exchange
342 Followers
445 Following
3.4K Posts
Defend. Pwn. Infosec. Free software. Vim nerd. #rustlang #electronics
websitehttps://goncalor.com
GitHubhttps://github.com/goncalor

My take: clothes are to be used until they rip apart.

#fashion #sustainableFashion

I've iterated bytes from 0x00 to 0xff for each tile and these are the results in terms of colors they produce.

The image below was produced by interspersing incrementing byte values with 0x00 for ease of counting tiles.

The color names I took them from colorhexa.com .

0x00: transparent
0x01: ?? (very dark grayish orange, 686050)
0x02: nature (dark lime green, 008000)
0x03: buildings (dark orange [brown tone], a87430)
0x04: ?? (pure (or mostly pure) blue, 00a0f8)
0x05: track (black)
0x06: ?? (dark grayish lime green, 909490)
0x07: pavements (very dark gray, 505050)
0x08-0x1f: ?? (grayish orange, d0c0a0)
0x20-0xfe: ?? (light grayish lime green)
0xff: ?? (bright magenta, f848e0)

#games #pcgaming #trains #LEGO

Oh my! I wanted to do a last test before I wrapped this, and it was successful!

I could not send trains so far. But I have a good grasp of the map layout update messages. So I tried to send one of those. And it worked!

The video below shows me sending a message that alters the color or 4 tiles in Sarah's map overview as seen by John. I set 4 tiles to 0x02030507 (green, brown, black, gray). Then I increment the counter (message ID?) across the 3 packets (from 0x0e to 0x0f). Then I send the messages. You can notice on the right side that 4 tiles change color on Sarah's map! Then I proceed to change them back to colorless (0x00).

Although this result is simple it's great because it gives me confidence I can send messages to the game, and allows me to reach some conclusions. Namely:

  • the source IP of the packets is not important. I get the same result by spoofing Sarah's IP or by not doing it
  • the counter in the message must be exactly the next one for the message to be accepted, i.e. if the previous message was say 0x0e, we must send 0x0f next. Other values seem not to work

#games #pcgaming #trains #LEGO

The videos below show creating a postcard and a train picking it up and going into a Blue Tunnel. (Note the bad lag in the videos is from the video itself. There's no lag in the game.)

Now there's network traffic. See the #Wireshark screenshot below.

First there's a DNS resolution over UDP of the domain loco.legomedia.com . There's an IP in the response! It's 194.216.90.10 . This IP is from AS702 Verizon Business and it's located in the UK. I've checked #Shodan and there's nothing seen open for it. I'm surprised an FQDN that's clearly specific to a game still has a specific IP associated with it. I write "specific" because legomedia.com or www.legomedia.com resolve to 62.199.219.133 , so this is not a wildcard resolution.

After the DNS resolution, there's a DirectPlay Enum Sessions message sent to the resolved IP over TCP and destination port 31415. There's no response even after TCP retransmissions. The same sequence happens twice with around 50 seconds difference.

#games #pcgaming #trains #LEGO

I haven't yet tried "International Postcards" playing mode. Let's try it. I'm curious about the connections that does.

For that mode I start a single player game but add an Blue International Tunnel.

I've sent a train into the Blue Tunnel and... nothing on the network side. I see... that train had no postcards on it, that's why.

This map doesn't even have a post office, so I'll create a simple test for this next.

#games #pcgaming #trains #LEGO

Ah, I forgot to mention that I wrote a small diff tool to try to figure what was fixed on the messages of a specific train and what wasn't. This is in part because I suspect/suspected that there are extensive regions in a message that are/may be uninitialised.

What this differ tool does is I can feed it hex string from the same type of message and it will check for each nibble which values were found among the messages. Then it represents that by writing lines of hex and spaces where each column represents all the variations found for that nibble.

The screenshot below shows an output example, with a section of a message. Where there's only one value per column it means those nibbles were always the same, so they are probably constant for at least this type of train. There's an highlighted part which is something I had already the theory was constant and this output agreed with.

You'll notice many nibbles with value 0x2. This was purposely caused by filling Sarah's map with "nature" (0x2) elements such that any uninitialised memory had a higher probability of being filled with a recognisable pattern.

I suspect many of the parts in this section of the message (as an example) are uninitialised. But maybe if that was the case I'd have even more nibble values. So I don't really know...

#games #pcgaming #trains #LEGO

When a player right-clicks on a tunnel a window shows the overall look of each player's map and how they are connected. It also shows the location for players' trains.

When this view is opened there are two 14 and 24-byte messages that are exchanged between players every second. One of these clearly contains the coordinates for trains. I only did a cursory analysis of it though to verify the hypothesis.

One interesting thing I found is that the messages sent when the Toybox is closed (that contain map information) don't have information on the exact map elements as I thought before.

I tried placing different elements on the map to get a notion of their codes and found out only four below values (this wasn't an exhaustive test though).

From what I could understand each byte is just transmitting which colour should be shown on the map overview for each tile of the map. I've found the following approximate meanings for each.

0x02: nature (green)
0x03: buildings (brown)
0x05: track (black)
0x07: pavements (grey)

The images below show a screenshot of a map (from one LEGO LOCO's presets, which brings memories) and its representation when right-clicking a blue tunnel.

#games #pcgaming #trains #LEGO

To figure out what I did of the messages, I sent quite a few trains with varying locomotive and carriage types, and among multiple players and their configurations on the overall map.

The first screenshot below shows two of the configurations I used. The remaining screenshots show what the map actually looked like for each of the three players.

It's cool that depending on the zone of the map LOCO creates for you a track that connects the tunnels in a way that make sense for your location on the map. So those three screenshots are from what LOCO did, it wasn't me creating those track configs.

#games #pcgaming #trains #LEGO

I figured out a few more things in the "send train" messages. But I can't figure it out fully. Nor, more disappointingly, can I manage to send trains.

The image shows what I know about the messages involved in sending a train.

And here are some conclusions:

  • the info on carriages is spread between the 1st and 2nd messages (search rex 6.18)
  • there's always a 0x648247006600 some bytes after the carriage type
  • from the first carriage type to the 2nd, there are 1872 bytes
  • from the 2nd to the 3rd there are 840 + 1032 = 1872 bytes

#games #pcgaming #trains #LEGO

I'm continuing to figure out the protocol for sending trains. I'm currently pretty sure about some parts of the message, such as train direction, speed, locomotive type... Now I'm trying to understand how carriages are specified.

Regarding speed, I thought I had that field pretty much figured out. I thought a specific byte at 0x01 meant half speed and 0x04 mean full speed (never mind the weird jump...). But then I saw a train at full speed with value 0x02. I thought "oh well, must not be the speed after all". But then... I realised steam locomotives move slower at full speed than "silver" locomotives!

The view below shows a race between a team locomotive and silver locomotive trains. Silver wins, which matches 0x04 vs 0x02 speeds 😁

#games #pcgaming #trains #LEGO