When I was young I had a #LEGO computer game called LEGO LOCO. It's a game where you can build a 2D LEGO city with train tracks running through it. I loved this game.
I've created an ISO image from the CD a few years back and now I've put it to work.
I've tried to run it under #Wine, but I could not make it work. The game only runs in some specific resolutions and color 16-bit color depth (which I managed to work around using Xephyr). I managed to install it under Wine and have it run. But I could not go farther than the initial screen.
So I installed #Windows 98 SE into a VM. Since I was at it, I created a #Vagrant image anyone can use. It has working display and audio drivers. Link below.
This way I (and whoever) can quickly launch a VM and install games from this era without having to deal with the quirks or Wine.
https://portal.cloud.hashicorp.com/vagrant/discover/goncalor/windows-98-se
Now, other than playing the game, I wanted to try something.
See, I knew for long this game was playable on a LAN. I knew it had tunnels to where you could direct your trains and they would end up in someone else's computer. How cool is that?! 😁
But when I was young, I could never try it. Two computers in a room? That didn't happen at home, where I played.
So I want to try it now!
Let's refer to the manual to understand better what LAN features are available.
Wait what?! You could actually send your trains with postcards not only to your LAN, but to the Internet? Anywhere in the world?! 🤯
And on the LAN you could attack files to postcards! Up to 1 MB. Sharing files on the LAN by train. Amazing!
https://archive.org/details/LEGOLoco-manual-US-IB2G-LOC3/page/n1/mode/2up
So it seems there are three game modes. A summary:
From the manual, full text on the modes:
"Single User
In single user mode (choosing the Single Station Master button on the start
screen) you will be able to create your own layout and help your mini-figs
travel around that layout.
By placing blue tunnels you can send Postcards to several LOCO characters,
(e.g. The Professor). A train carrying a card addressed to one of these
characters will leave through the Blue Tunnel and deliver a card to them…
who knows, they may even send you a reply!
International Postcards
If you have a MODEM and an Internet connection you can send random
postcards in Single User Mode to other LEGO LOCO users around the
world. Remember, for any train to leave your computer you must have
placed a Blue International Tunnel.
Trains carrying Postcards will leave your layout and travel to the LEGO LOCO
International Post Office Sorting Computer, from here it will travel around the world to who knows where. If you are lucky you may receive a Postcard
from someone from another country!
To send a postcard please ensure that your modem is switched on and
that you have connected to the Internet. Now start LEGO LOCO and
design your card. Address your card to ‘ANYONE’ (from the
pop down list) and make sure a postal train takes it out of a Blue Tunnel.
National Mode
In National Mode, up to nine people can connect to a huge LEGO LOCO
layout. Each individual can take control of a certain part of the National
Map, and can build layouts as normal.
The cool thing about National Mode is that you can send trains and e-mails
and attachments to anyone connected to your session."
I want to try the LAN mode between VMs and take a look at the protocol. There should be no encryption, so it should be easy to get a peek.
If the protocol is simple enough, I'm thinking it would be cool to inject trains into a map.
Regarding the international mode, I'm curious about the FQDN that was used, if it still resolves and if there's a server alive there.
If not, maybe we could reimplement the "International Post Office Sorting Computer". I don't think I will do it myself, but it would be cool. Maybe the actual code or executable is somewhere out there. Or LEGO or some former employee has it.
Network errors delivered through postcards. Imagine that! 😁
"If the LOCO desktop fails to contact the Internet server it will place a
YELLOW postcard in your post office and the post office will animate to
attract your attention. The postcard will have text indicating that there was a
network error."
From the main screen one player chooses to be the host, others are guests.
You can choose between TCP or IPX (I only have TCP to chose from in the VM).
The host chooses a grid size from a list of options.
Good news is the network of the VM works, with DHCP. I wasn't really sure if that was the case or not for Windows 98. So the VM boots up and gets an IP automatically.
Now, because I want to capture packets to reverse engineer the protocol, I've set up the VM in bridged mode so that 1) each VM gets its own IP that I can filter easily in captures 2) I can send packets to each VM from the host without having to sep up NAT traversals.
I've done this and VMs get IPs just fine. Then I launched #Wireshark, pinged some host on the internet and I saw the ICMP traffic.
Then I pinged one VM from another... They pong just fine, but in the pcap... Nothing.
So I tried a few things, namely switching Virtualbox network modes. But I could not see packets between the VMs.
I imagine when traffic is between VMs #Virtualbox is not putting the packets in the TCP/IP stack where #Wireshark on the host can see them. Only when the traffic crosses to the host or the network beyond does Wireshark (or #tshark) see it.
I don't want to capture traffic on the VMs themselves (having to install Wireshark or something else on Windows 98...).
So I searched around and found the article below in the Virtualbox wiki on network tracing.
You can essentially configure the NIC on each VM to capture all packets and log them to a pcap. So this is what I'll use.
Okay, if I start a game with John Doe as host (on 192.168.1.241) and Sarah Doe as guest (on 192.168.1.242) this is what Sarah sees when they pick the option to search hosts.
Protocol-wise, #Wireshark identifies (and decodes!) DirectPlay protocol, v6.1.
We see Sarah's machine asks for session enumeration and there's a reply from John's mentioning the "2 X 1.John Doe" session. Then Sarah requests a player ID (actually twice, one seems for a "system player" and the other not), gets an ID and then seems to ask for player creation on the server.
The "Add Forward Request" and "Super Enum Players Reply" are unclear to me.
In the screenshots seen in the post above, Sarah has not yet confirmed they want to join that game (yet it seems their place on it has already been reserved by the game).
After the DirectPlay negotiation, UDP communication starts without any protocol Wireshark recognises. These are probably messages using the game's protocol. One of the first seems to include some info maybe on the map and other particulars from the involved players...? I'm thinking this because I see the player's names and "area13.sav" and "area15.sav", which may refer to the terrain the players are using (actually Sarah's screen hasn't even loaded at this point, so I don't know which map they have).
There's a set of four messages with are exchanged every ~20 seconds.
Anyway... None of this is traffic from trains going back and forth. That's what I really want to see!
When a train crosses back and forth there's clearly a different message that's sent, with UDP data size of 82 bytes.
At the end of this packet is "John Doe" followed by two null bytes. John Doe was who sent the train.
The first six bytes of the message are non-null. I suspect they will relate to the types of train carriages and maybe directionality and speed of the train.
But it's too soon to understand the messages. I have to send more trains to figure this out! 😁
In the screenshot you can also see there are some larger packets with payload size of 1394 bytes.
I suspect these may be related with the map configuration, since when you right click on the tunnel you get the track configuration on all maps and the train positions (which is really cool!). Actually, you also get the Post Office and Depot locations.
It seems normally packets with that size are sent in pairs. Sometimes from John to Sarah, sometimes the other way around. Maybe they relate to two map layers or something.
For reference, the playing area is of 48 x 48 tiles. 48x48 = 2304. 2304/2 = 1152 < 1394. So each each byte probably would have info for at least 2 tiles (if that's what this message contains at all).
I've bounced the same train back and forth (with a blue signal on John's end, closed Depot on Sarah's) a number of times at full speed, them half. See the setup in the picture.
I've used tshark to get the UDP payloads for each packet send from John to Sarah so that I can then see commonalities/differences between the packets.
tshark -T fields -e udp.payload -r /tmp/loco_sarah.pcap 'len(udp.payload)==82 and ip.src==192.168.1.241'
Every two packets has the same contents, except for a single byte that seems to increment (by two) every time the train is sent through the Tunnel again.
My first definite conclusion from this experiment is that the train speed is not sent in this 82-byte message. Because there's no change in it from sending at full vs half speed.
It seems that "John Doe x" is the name of the train, as possible to see on the interface.
After a few experiments I think the 82-byte packet does not contain carriage, speed and direction info at all. The only thing I'm sure it contains is the train's name.
It looks to me most of the bytes may contain uninitialised memory, so not meaningful data. I think so because I see the exact same train potentially start with many null bytes but some other times have data there, without any clear pattern.
The screenshot shows some division of the message with notes on what each part may be (probably wrong/imprecise).
It's clear I need to look at other messages next.
I should also mention I tried to send some of these messages to Sarah's machine, but no train appeared there. The server replies with something though.
As I now think this message is not what actually "sends" the train that's reason enough for no train to appear. But another reason may be that perhaps the server checks if the player IP is the expected one (and I'm sending packets from a third IP). Curious to find later if that's the case or not.
A problem I have is that since it's #Virtualbox saving the capture, I don't have it loaded in real time in #Wireshark. It would speed things up to see the captured packets and game side by side in real time...
Ah! Solved it!
With the following I create a virtual interface that gets new packets as they are written to the file. File must be read from the start, so that #Wireshark considers it a valid pcap file, hence the -c +0.
wireshark -k -i <(tail -f -c +0 /tmp/loco_sarah.pcap)
I've figured out the 1394-byte message!
It's actually part of a set of three messages: two 1394-byte long and one 335.
As I suspected, those 1394 transmit map information. But the full map information is split across those 3 packets. Maybe because they're UDP and LEGO didn't want the packet to be too long not to cause problems..?
These 3 messages are sent every time the Toybox is closed by a player.
To figure out what the messages were and their structure, first I made Sarah destroy the full map with the bomb in the Toybox (the Blue Tunnel remains there though). Then I started adding elements such one track and one tile to coordinates (0,0), then the full first row, then the final row. Then the whole map.
Conclusions:
PS: I had written previously that the map was 48 by 48 tiles, which is wrong.
Tracks are represented by 0x05. Grey tiles by 0x07. Those are the only ones I checked for now.
A Blue Tunnel is a 3 by 3 square filled with 0x05.
The screenshot shows what I've been able to figure out of the messages so far. I know there are some fixed bytes that seen to vary with the message number; some counters; there's the DirectPlay ID of the player who closed the Toybox; and of course the tile info.
But there are two chunks of bytes I have no idea about so far.
I really hope there are no checksums involved here 
Just noticed that now right clicking on the Tunnel from John's side shows Sarah's map as all grey.
For a moment I thought this could mean Sarah was offline. Nope! It's a representation of Sarah's fully grey-tiled map! So it seems this view may actually show not only tracks and related buildings, but an overall view of what the other player has placed in the map!
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 😁
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:
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.
Some bytes seems to be the locomotive or carriage types. I've taken note of the hex string for each type as I've understood it.
Gonçalo Ribeiro0418. yellow loco
0618. silver loco
0818. steam loco
6618. silver carriage
6818. blue carriage
6a18. green carriage
6c18. yellow carriage
6e18. gas carriage
7018. mail carriage
There's a one byte that seems to indicate the direction of travel between the maps of two players, as follows:
00 ↑
0e ←
5a →
b4 ↓
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.
Regarding being unable to send trains... It's a shame I'm unable to send trains because that would allow me to run experiments and understand the protocol much faster... And probably find some weird stuff/quirks.
As a test I've tried to essentially replay trains that I captured in pcaps. I did this in multiple ways.
My basic attempt was just to send messages with perl + #ncat as follows. I sent the three main messages by putting these commands in script with a sleep of a few milliseconds between them.
perl -e 'print pack("H*", $ARGV[0])' <hex string> | ncat -vu 192.168.1.242 31415
As that didn't work I tried changing the message counter, the train ID, etc. I thought maybe the game checks for duplicate messages or something based on the counters, which would mean the replay of an exact previous message would fail.
Next, I had the theory that maybe the game was checking the source IP address of the packet to see it if matched the expected player's address based on the DirectPlay protocol phase.
So I added the following #iptables rule such that any traffic coming from the host towards Sarah's VM (192.168.1.242) would appear as if had come from James' VM (192.168.1.243).
iptables -t nat -A POSTROUTING -p udp -s <my ip> -d 192.168.1.242 -j SNAT --to-source 192.168.1.243
In the packet captures I could see that the source IP changed as intended and Sarah's game responded to these messages, but no trains were produced.
Lastly, I thought maybe I was missing something... maybe there was another message other than those three main ones which had to be send to say "okay, that's it, that' the train right there in the previous packets!"
So I tried to replay a set of packets exactly as I captured them. To do this I filtered a set of James's packets, saved a pcap with them and used #tcpreplay to send them.
Again... no train.
Worth to consider though that with this test I used the correct source address for James (with iptables rule), and sent exact packets seen before, so any counters or similar that may need incrementing were left as is, which may be problem.
In short, I can say for now I'm beat. (Or that at least I'm not willing to invest more time in this right now.)
I started this thread with the idea to explore a bit how things worked. I thought maybe it was a simple protocol which I could figure out and send some trains! Turns out it's not that simple.
But still, I found a few interesting things both in terms of gameplay and on how things work in the background to support that experience. So I still consider this a success in that regard.
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...
To ease testing with multiple players I made LEGO LOCO run on startup via a registry key. The method in Windows 98 still exists today:
[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run]
"LOCO"="C:\Program Files\LEGO Media\Constructive\LEGO LOCO\Exe\Loco.exe"
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.
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.
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:
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)
@robert yeah, I thought about doing that, but haven't tried. Since I saw the DirectPlay message I suspect the protocol will be pretty similar if not equal to the one used among players on LAN.
I could try just to point an International Postcards session at a multiplayer session server and see what happens...
Crovanian (CamstonIsland)
Eliza Swan
Rob\Viewdata UK