💬 Lasst uns eine Petition an den #WDR starten...
✴️✴️✴️✴️✴️✴️✴️✴️✴️✴️
#KommInsFediverseMaus
✴️✴️✴️✴️✴️✴️✴️✴️✴️✴️
Ich werde den #WDR anschreiben und ihnen mitteilen, dass sich diese vielen* Menschen "#DieMaus" im FEDIVERSE wünschen❗
⬇️⬇️⬇️⬇️⬇️
Wie könnt IHR euch daran beteiligen?
✅ * ALLE, die sich positiv im #Kommentar dazu äußern oder dieses Posting teilen, werde ich als Unterzeichner.innen im ANSCHREIBEN aufzählen
When I was a kid, I sometimes wondered how a sprinkler "knew" how to change directions without being powered with electronics. I think it wasn't until I was in my late 30s that I came across this GIF and I realized how insanely genius a simple sprinkler really is.
EDIT: Some people have kindly pointed out that this GIF was in fact from a demonstration on how different gears function and not from an actual sprinkler as I had originally led to believe. Other people have been assholes about it.
Die Antwort auf meine ewige Frage "In welcher Welt leben wir eigentlich?" ist "Nicht in der selben!"
👋
Ich suche Speaker*innen (explizit nicht Typen) im #ITSecurity Umfeld, bestenfalls mit und rund um #OpenSource Technologien.
Solltest du dich da sehen, aber nochnie darüber erzählt haben helfe ich auch super gerne bei der Erarbeitung einer Präsentation.
Gerne teilen fürs Hivemind!
english version below ⬇️
Anyone can recommend forgotten books about designing and programming text user interfaces (TUI) for consoles/terminals, also known as screen design back in the 80s?
*Not* curses or using existing libraries, but more like relying directly on ANSI/VT100 control sequences. And *no*, I'm not asking for a list of escape sequences :)
The kind of material I'm thinking of is something close to the 1989 "Programming the User Interface: Principles and Examples" by Judith R. Brown and Steve Cunningham. But focused on TUI exclusively. The more (pseudo-)code, the better.
Gibt es jemanden in meiner Bubble der mir für ein paar Tage ein Differential-#GPS / #GNSS-Gerät in Geodäsie-Qualität leihen könnte?
Bevor ich damit anfange das Katasteramt zur Vermessung und setzen von Grenzsteinen bei meinem kleinen Biotop (ich vermute der Bauer nebenan ackert da immer mehr hinein) einzubinden, will ich das erst selber ausmessen, ob das tatsächlich passiert.
Not Japan-related, but since we all need a distraction from The Horrors, Takaya Suzuki points out a study that examined 408 sleeping cats and found the majority (65%) curl leftwards.
I'm not sure how useful this information is, but...it's yours now.
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.
» Aakerbeere 🏖️ 
Sean Kleefeld
Fuzzy Leapfrog
It's FOSS
pitch R.
ultrageranium
datenwolf
Jan Beta
Christoph Stoettner
Unseen Japan
Gonçalo Ribeiro0x02: 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