This is the hardest message I have ever written.
Does anyone in have a lead on a company that would be willing to sponsor a web development technical lead?
I am open to most Euro, Japan, and Oceania.
My German is bad. My Japanese is a bit better. I would love to get better.
It seems like things are going to be no longer safe for my family.
Help me.
Please boost. 🙇
Hey, if you're interested in doing signal processing on embedded devices using OpenEmbedded, and maybe shy away from corporate pricing for OE workshops:
@gnuradio #GRCon25 features a workshop "GNU Radio on Embedded SDRs" by Philip Balister @Crofton (of OE fame) and Toby Flynn (of RedWire Technologies).
There's week/1day tickets available & if you're into SDR, #GPU-accelerated DSP, satellite comms, radio astronomy, physics with SDR, DSP architecture, radio metrology, …, it's a really nice conf.
💬 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.
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.
C.B.Leslie
Tonya Marie 🏳️⚧️
Marcus Müller
» Aakerbeere 🏖️ 
Sean Kleefeld
Fuzzy Leapfrog
It's FOSS
pitch R.
ultrageranium
datenwolf
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.
Andrew Borley