xssfox

Strap in, this story involves a cheese fortune teller, the department of war, and nearly every other government department in between.

In 2017 (I think?) I was introduced to weather balloon hunting by Mark VK5QI. At the time the Australian balloon chasing community was small. Only Melbourne and Adelaide radiosondes (the transmitter on weather balloons) were being tracked on a website called Habhub - high altitude ballooning hub. This site was designed for amateur balloons and not meteorological weather balloons.

Over time more and more radiosondes were tracked on Habhub and eventually Habhub admins introduced a default filter that removed weather balloons by default. A query parameter could be added to the URL to remove the filter and on 12th of May 2018 sondehub.org registered with a single purpose - a URL redirect to Habhub with a radiosonde specific filter. To be clear - this was more of a joke than a decision to run a radiosonde tracking service. You’d go to sondehub.org and it would redirect you to habhub.org. That was it.

However Habhub was never designed for so many unique balloons each day. By July we decided to start proxying radiosonde ingestion data through SondeHub. This allowed us to capture more data as well (no longer rate limiting our selves). This went to a seperate OpenSearch cluster, however at this stage we didn’t use or expose this data. I was using this more as a toy - to play around with different Amazon Web Services (AWS) services and analytics platforms.

By 2019 the Habhub servers were really struggling - aprs.fi as well. We realised that we needed to run our own service and our initial plan was that we would build new APIs, and eventually new frontend. We then started getting information requests from government agencies regarding radiosonde data. For example we received a request regarding an insurance claim about a radiosondes hitting a horse, causing it to bolt through a fence. One of the reasons for this is because unlike official software at the time, our system tracked the radiosondes all the way to the ground.

Also in 2019 we detected a drop in radiosonde launches. This lined up with the GPS rollover date - we thought our software was broken however it turned out to be issues with Vaisala’s equipment which prevented launches from occuring. Funnily enough our software handled the rollover ok.

In 2020/2021 we ended up doing was building backwards compatible APIs for the Habhub frontend and started testing the Habhub frontend pointed at our backend. It mostly worked. We started receiving all the data rather than just partial data and providing open access to our data via S3. We even started running our own predictor - which is used by my entities today.

With our own predictor running Mark developed a system we call reverse predictions. This is where we take data from an already launched radiosonde and use the wind model to run the predictor backwards which determines a rough the launch location prediction. It works extremely well. We could detect a bunch of radiosonde launch sites that were poorly otherwise documented along with start assigning balloons to launch sites.

Our first taste of dealing with the military

Then in 2021 we received an email

sensitive/military/… installation. As such, we really prefer that it is not explicitly marked on any map.

The thing is though that wind data isn’t just used for predicting the weather. It’s also used to calculate artillery ranging. What we had started doing is accidentally mapping out artillery sites. We decided to keep reverse predictions but we delete launch sites on genuine requests.

The reverse prediction system has also detected many number of military vessels in the ocean.

Lots more development happened on SondeHub with features like websockets and MQTT for live feeds. We disconnected Habhub backend from our proxy and with grant funding from ARDC we were able to setup a prototype amateur high altitude balloon version of SondeHub.

Eventually Habhub was shutdown due to a lack of maintenance and we rushed together to migrate what we could to SondeHub.

$439,000 missile vs party balloon

All was going fine until the 2023 “China spy balloon” incident. SondeHub had a lot more traffic - but our architecture made it fairly manageable.

Then Feb 11th 2023 the US allegedly used AIM-9X Sidewinder to shot down an amateur radio balloon. That morning I woke to high usage alarms in my inbox. SondeHub had been linked to on the Washington Post. Our site managed to handled the extra traffic reasonably well.

Since then we’ve many support requests from .mil and .gov addresses. We’ve also had requests from aviation industry / air control towers.

In Dec 2024 - alarms in my inbox again. This time getting alarms for predictions. Someone decided to smash our api. This seemingly starts happening every week.

Full scale invasion

We turn on logging. The requests coming from a single IP. We had some suspicions that a private company was using our backend to generate predictions. We poke their website to see - sure enough they are - an angry email to them. However they weren’t the problem.

We ask some people.

Note that the precision of these points has been intentionally been reduced. This data is also significantly old and does not show the entire dataset. This blog post has been delayed until balloon warfare was more common knowledge.

Fuck. And Fuck Russia.

(for time travellers and people in the future - in 2022 started a “special military operation” - aka a full scale invasion into Ukraine. The war continues at time of writing. Fuck Russia)

Suddenly my mind was filled with ethic and legal questions. We also suspected they aren’t using the API correctly. However we didn’t know how to get in contact.

We did eventually got some messages out via a contact

“We work with mHAB’s as you know, but some other groups likely fly fixed-wing and use Sondehub to help them “surf” the sky to target areas.

“Sent this in Ukrainian to a few milchats and will see what turns up: “I wish everyone good health. If anyone knows of a deep strike team that uses a python script with some open source wind forecasting engine, please contact me directly. They are causing numerous problems with queries, which can lead to them being blocked and they need to take action to be able to continue using the prediction system.””

I also quickly rushed together a docker compose file so anyone could quickly run their own predictor that wasn’t reliant on us.

Meanwhile (and you might have noticed me asking for AWS help on fedi) we contacted AWS as the source IP was from an AWS network. It was very important however to make sure the AWS support did not shutdown access.

Our messaging included:

It is incredibly important that the http request data is not distributed. It is also important that the source AWS account is not blocked, rate limited or terminated - loss of life could occur.

Something that I thought I’d never have to write in support emails. The messaging was important because I did not want the service cut off, and I did not want the data to reveal launch sites.

After a bit of waiting we received:

AWS reached out to me that a lambda function of mine was flagged for potentially scraping api.v2.sondehub.org and they told me to reach out to you to get this resolved.

We emailed back and forth and provided documentation on how to run the predictor locally.

Office of the Secretary of War (Intelligence and Security)

In 2025 we received a request for data from the “Office of the Secretary of War (Intelligence and Security)” (US). Generally if there’s mutual community benefit we’ll find, process and release the data for free. However given this is was the Department of War and no expected community benefit we decided they should pay for the data. I was hesitant even working with them, as I don’t really want to help military, let alone the US - but since our data is public if we didn’t do it someone else probably would. So my reasoning shifted to, may as well extract some funds to pay for SondeHub infrastructure at the very least.

An invoice was created and sent through - but never paid or followed up on. I have no idea why they were requesting the data or what it was about.

Other tidbits along the way

It hasn’t just been the military that we get emails from. Occasionally citizens who find radiosondes end up contacting us (often we don’t know how they even find us), along with a range of other organisations.

National Transportation Safety Board (US)

In September 2025 the NTSB contacted us. My first reaction was to search for news stories.

do you have information on any balloons in the Utah are between 1200 and 1300 UTC on 10/16/2025

We provided our data but also started hearing some rumours about a possible plane / weather balloon collision that was reported via ACARS. While none of the balloons tracked by SondeHub lined up, we did forward some information that a Windborne balloon was in the area. Windborne later confirmed this was the likely collision and have made several changes to their system to prevent future issues.

We have a number for you to call when you’re ready to copy

Please contact us as soon as practicable with more information… Contact our Operations Manager at

This was a really strange interaction for us. A tower(?) operations supervisor was requesting information about balloons in the area. The balloons in question were meteorological weather balloons. Not launched by amateurs. We had to explain that they are normally scheduled, not controlled, and fall (probably, not a lawyer) within Part 101.D of FAA regs. Along with that we didn’t have contacts or registration details of these launches.

We have a lot of Aircraft in the sky that don’t want to get too close to one of these balloons! Is there any way to coordinate more directly with the controlling entity, or to have them give us mission details and contact information ahead of time? It sounds like you guys have a big operation, I don’t know if this is a one off event or if you have systems in place to communicate these things

Explaining to the FAA that weather balloons exist wasn’t on my bingo card.

Hit and run

On 2/5 around 8pm was there a balloon located in Anamosa Iowa?

Someone recovered a radiosonde from a property but ran into a building along the way. They left without leaving a note. The property owner contacted us for help to locate the person.

Jam, tasty tasty jam

There’s a great site that uses ADSB data to track GPS jamming called gpsjam.org. We’ve also been detecting not only a lot of GPS jamming but also GPS spoofing. I always find the patterns interesting. I’ve been presuming that the pattern is either for making the impacted targets easier to identify or to crash the vehicle in a specific way?

The cheese fortune teller and other job titles we’ve seen over the years

Probably the most interesting job title we’ve had the pleasure of reading in an email is from Jennifer Billock, Freelance Writer and Author, Certified Tea Specialist, Cheese Fortune Teller. Jennifer wrote an article for STNDRDS about weather balloons which is outside our usual places of exposure.

During this time we’ve seen many job titles and subjects, I’ve started collecting them.

• [SEC=🌶️🌶️🌶️]
• Naval Air Warfare Center – Aircraft Division Maritime Patrol and Reconnaissance Aircraft (MPRA) Program
• Acquisition Program Manager Integrated Processes Branch HQ AFRL/XPOP
• Upper Air Quality Assurance Meteorologist Observing Systems & Operations, Data & Digital Group
• Senior Advisor for Safety and Quality
• Meteorologist Weather Forecast Office
• Manager Upper Air Network
• General Manager Observing Systems and Operations and Chief Engineer
• Meteorologist National Weather Service
• Field Research Manager, Center for Western Weather and Water Extremes
• Video Journalist, Visual Investigations - NY Times
• Senior Meteorologist, National Transportation Safety Board
• Operations Supervisor U.S. Department of Transportation/FAA
• STNDRDS Freelance Writer and Author, Certified Tea Specialist, Cheese Fortune Teller
• Meteorológiai fejlesztő (met.hu)
• SUNY Oswego Lab Technician Atmospheric and Geological Science
• SpaceBalloon Project
• Any many more

The weird

Most organisation and vendors are willing to work with us. This is because chasing radiosondes removes them from the environment and promotes citizen science. I asked “Meteolabor AG” for one of their radiosondes so that we could confirm compatibility. This is what I received back.

Official response from Meteolabor AG: For strategic reasons, we do not provide any data or sample devices. Our transmitters shut down after a certain period of time, at the latest when the battery capacity is exhausted. This is due, among other things, to strategic considerations.

We are aware of the so-called waste problem.

---

Personal comment: I would personally like to draw attention to military activities, particularly in the Middle East, which result in significantly (exponentially) more waste and toxic substances being released into the atmosphere and left lying around in the environment – or entering the food and water cycles

In addition to military operations, countless “missions” are currently being flown over Europe with the aim of leaving “contrails” in the sky [rather “chemtrails”]. I know their purpose; I know what NetZero is supposed to achieve, and what decarbonization and CO2 reduction are intended to accomplish. I am well-informed about the climate hoax.

Start there! The people to talk to are politicians, NGOs, and very wealthy old white men.

Which is… certainly something.

Onwards

I hope you liked this selection of SondeHub chaos. I haven’t included every interaction we’ve received over the years, so there might be a part 2 to this post in the future.

While taking some rubbish down I spotted a Cricut Maker in e-waste. A quick look at it revealed that the it was in fairly good cosmetic condition with the exception of the rollers being perished. I guessed that the rollers were the reason why the unit was trashed and decided to take it back home to investigate. I knew that Cricut were pretty aggressive with disabling/locking machines, but I gathered it would still be worth playing around for some fun. As it turns out this machine was locked, which was pretty expected. However with some hacking I was able to return it to having full functionality. It’s very likely that the last user either received a warranty replacement or a discount on a newer model.

Alex did some quick searching and found that replacement rollers were readily available for very few dollarbucks. Even with powering the machine off 12v instead of the apparently required 18v, it showed signs of life with it passing it’s self test and communicating with the software - although showing the dreaded “Machine deactivated” message when connecting to it.

The first approach I thought I’d investigate is if there was an eeprom on the motherboard that I could rewrite the serial number. Disassembly isn’t for the fainthearted - it’s involved but I would need to do this to replace the rollers regardless. I didn’t find any eeprom and the MCU being used is something I didn’t have a debugger for.

My second thought here was to intercept the network connection and either replace the serial number or return a success message instead. However various application security measures made it more annoying than I wanted to disable certificate pinning. That’s not to say you can’t - it’s just I didn’t figure out how to do this trivially.

My focus changed to performing a intercept on the communication between the cutter and computer itself. I fired up wireshark to capture USB messages between the Cricut and my machine. It uses USB CDC for communication and very quickly I found the packets responsible for sending the serial number. There didn’t appear to be any checksumming or crypto. So I borrowed a RPi RP2040 from Droppy which was able to act as both USB Host and USB Client.

Using the TinyUSB Arduino examples for USB Host and CDC simple echo, I was able to cobble together a simple proxy/rewriting device. There was nothing to special about this, however it did take me a little while to figure out that the USB Host doesn’t work correctly unless overclocked to 240MHz. I also configured all the USB metadata like vendor/product id and descriptions to match the unit. When it detects a packet from the cutter that matches the right length, and has the command / serial number in it, it replaces it out with a different serial number. Serial numbers seem to be issued sequentially and you can see the status of all the units on Cricuts own webpage.

With the rewriting device replacing out the serial number at a hardware level the software is none the wiser. The unit shows up in my account. I could even register serial numbers that didn’t exist on the Cricut machine status page.

Obviously this raises the question about random strangers being able to get other users Cricut serial numbers locked out or added to their accounts….

After cleaning up the unit, replacing the rollers (hint, use hot water to soften the new rollers to install them), reassembling the Cricut and printing a little case for the RP2040 - I was able to use the unit as if it were brand new.

The approach I took to return this Cricut to functioning is probably the least user friendly way however, as I believe software only solutions exist. Some alternatives that come to mind are:

• Intercept network traffic or patch the application to report a different serial
• Write a driver that pretends to be a Cricut USB CDC connection and proxies the serial
• Write a driver that pretends to be a Cricut USB CDC connection but connects to the Cricut via Bluetooth
• Figure out the firmware update process and utilise that to patch the serial number as part of the update
• A device that acts as a bluetooth proxy
• Add another MCU between the bluetooth chip and the Cricut MCU to rewrite the serial number before it goes to the bluetooth chip

I’m not going to investigate any of these because I have something that works for me, but those are all viable options to explore. Additionally I’m not going to share the code required to perform the serial number change as this might not be exempt in Australian Copyright law (not a lawyer ect….), but it’s pretty close to the included examples in the TInyUSB Arduino library

Caution. Using traffic preemption devices such as described in this blog post could impact emergency response times. The use of these devices outside their approved use may be illegal in your area. Traffic light preemption systems are typically logged and intersections often have video recordings. Traffic lights might not respond how you expect. All information in this blog was derived from reading manuals and testing in a lab.

Additionally - I’m not an expert in this field. I don’t maintain emergency vehicles, traffic controls systems or have any formal training. This is just me vomiting up information I read.

Say you are an paramedic and the patient in the back of your ambulance is leaking all the human goo required to keep them alive. Alternatively you can be Karen in the family SUV taking your 2 kids to band practice 600m away from home. Between you and success are 18 thousand traffic lights and 2 million vehicles because of car centric design. It would be great if in emergencies (like being late to band practice) you could magically control the traffic lights to give yourself all greens.

This is what traffic preemption is. For emergency vehicles this is usually called Emergency Vehicle Preemption or EVP. There is also Transit Signal Priority, TSP, which is used for mass transit such as buses and trams.

There’s many different systems for EVP and TSP. We’ll be looking at just a single type in this post, but first I want to explain some of the hidden complexities in these systems. Obviously we want to turn the light green when there’s an emergency but whats involved with that.

• First the driver of the vehicle needs to declare an emergency - we don’t want every off duty emergency vehicle stopping traffic lights
• Then the traffic lights need to know there’s an emergency.
• Specifically, the set of traffic lights that the vehicle is driving to - we don’t want every set of traffic lights to change in the city
• The traffic lights themselves also need to know where the vehicle is coming from. We want all greens, not all reds

Before the days of super reliable vehicle positioning solutions, this was a bit of tricky problem to solve. Additionally, not all traffic lights are wired up to a central location. Some solutions involved directional antennas. Some systems tried to identify strobing lights. While there have been several solutions to this problem, the one that really won out in the 90s and 2000s was infrared. It might be a bit of a surprise to think that the principals behind a TV remote ended up as critical infrastructure.

Infrared works really well in this use case as an emergency vehicle can flip a switch (maybe its just wired to the same one as sirens). The emitter can be placed on the roof of the vehicle and pointed in the forwards direction. At the traffic lights several detectors can be placed facing various directions of traffic flow. An optical signal processor will receive the data from the detectors and determine which cycle the traffic lights should switch to.

Ah, so the Flipper Zero can control traffic lights?

At this point in our story. Maybe. There are several videos on YouTube, forums and social media sites claiming this. The thing is, it’s very very very easy to fake a video like this. Wait for the traffic light cycle to just about start - hit the button, look amazed. At the same time, it does actually work…. for some traffic lights.

Some systems have confirmation lights to let emergency services know that the signal worked - though I haven’t seen many of these in practice. A good way to confirm if these videos are real is checking for these confirmation lights.

The early implementations of this infrared detection system used IR pulses at 14.035 hz. The Flipper Zero can likely replicate this just fine. For transit priority this is usually lower, like 10hz, 9.something or 6hz.

Obviously having people mess with traffic lights using an IR LED and a 555 timer is not a good thing™. So both GTT (3M at the time) Opticom systems and Tomar Strobecom implemented different ways of encoding data into the signal. Not only did this allow for security, but allowed extra functionality like deciding which vehicles get priority over others and opening gates. Of course these two systems are patented and each company even has patents on how they could interoperability, ffs. GTT and Tomar also got into a patent tiff with the two settling out of court. I love when emergency/critical infrastructure is locked behind patents and trade secrets.

We’ll be talking about the Tomar Strobecom system, however the briefly before that, lets take a quick look at the GTT (3M) Opticom system. Through eBay (which doesn’t actually permit selling these devices) I was able to obtain a “Tomar 970APRE-PS-T792” power supply. This might be confusing you as I said GTT system, along with this is the power supply, not the emitter.

Tomar uses Xenon flash tubes to generate the IR signal. The emitters in the Tomar system are actually just the tubes. The logic/smarts happens in the power supply. Tomar sells a range of devices which are compatible with the GTT system and this power supply is one of them.

I hooked this unit up to my scope (noting that since we are dealing with possibly kilovolts here we need to be careful…) and recorded a capture.

In the GTT system you can see that the data is encoded by skipping bits. Something that the Flipper Zero could do if you recorded one of the signals of a configured vehicle ID.

I also went through the joy of de-potting this power supply. Unsurprisingly its a PIC16F628. I believe I can change the ID of this unit, however I haven’t figured out how yet. I believe it’s via J1708/J1587 - it’s also possible I killed it during de-potting…

Why do I care about the Tomar Strobecom II system so much anyway?

Well mostly because I wondered what the little Strobecom II detectors were on traffic lights. I came across VicRoads TCS 055-1-2005.

2.2 SYSTEM SECURITY The EVP system shall be a secure system that prevents false activations, unauthorised activations and ‘hacking’.

Games on.

The other reason is many government tender and policy docs specify things like:

be a Tomar® 2140 Optical Signal Processor or similar, fully compatible, processor

Without knowing how these systems work, it’s impossible to building a competing product that would meet the tender requirements, even ignoring patents issues. And I think thats a problem when we are talking about critical life saving infrastructure. Lower cost can mean more installs.

Quick note around Victoria’s EVP system: The TCS 055 copy I have is dated 2005. When observing vehicles today, I see very few with EVP emitters installed and I haven’t managed to capture a real world sample of the signal they emit. My suspicion here is that the Strobecom system is no longer maintained and that GPS / radio based system is used instead. This is just speculation however.

So what do we know about the Tomar Strobecom II system?

We know:

• it’s not the GTT system - so likely isn’t using missing pulses to encode data
• the emitters are Xenon tubes not LEDs - so bursts of data is unlikely - additionally the Tomar system is specifically designed to require a max of 10 microsecond rise time for the pulses (according to datasheets)
• the emitters will likely still be detected by legacy 14.035hz systems

This a bit rough to work with, but we can get some extra clues from patents.

• US5519389A “Signal synchronized digital frequency discriminator” is Tomar’s key patent for Strobecom - effectively showing that Tomar can check the timing of pulses
• US7417560B2 (and a few others) “Multimode traffic priority/preemption intersection arrangement” from 3M mentions how the Strobecom II system uses variable length delays between pulses to encode data. Annoyingly it doesn’t mention how long, or the format - but its a hint.

Recording pulses

My next thought was, why don’t we just record some. I built this little detector using a Pixel headphone/microphone adapter, wired an IR photodiode in series with a resistor across the microphone and ground pin.

I then tested with a camera flash - and sure enough it recorded the pulse. I was probably a bit too close to the photodiode and the signal went straight into clipping. But that’s ok.

As mentioned above however, the Strobecom system is less widely used in Victoria than I first thought, so even though I have recorded several passings of lights/sirens vehicles, none of them appeared to have Strobecom running/installed. (Annoyingly I’m pretty certain there was one emitting just before I built this device).

Sit at traffic lights and try all the combinations

Just kidding. No ones taken away my eBay account yet so I bought my own Tomar Strobecom 2140 Optical Signal Processor (OSP). The same one listed in the VicRoads specification. This was a bit of a risky purchase because at this stage I didn’t know how much smarts were in the detectors vs the optical signal processor. It’s possible that the detectors decode the ID and just pass it to the signal processor… Ideally I would have purchased detectors as well, but those were on the much more expensive side.

At this stage I have a OSP, with no rack to put it in, no detectors, and no emitters. Usually this is fed from 240v off the traffic controller card slot. I don’t want to deal with mains, so figured out where 5v was being regulated and found some pin headers to supply my own power. The card itself has a PIC for each decoding channel, and then a central controller. They talk over I2C - my card had two channels installed. There’s a RS232 port used for configuring/talking to the central controller. The switches on the front allow testing that the card is functioning correctly - important to note here that these switches do not create test signals on the decoders - it just tells the decoder to send a preempt signal to the main controller.

So simple, we turn it on, use the software to configure the controller to allow everything, then throw some signals at it to see what decodes.

Even traffic light yaks need shaving

It was pretty easy to identify the baud rate (4800 8N1) of the RS232 connection, however the software to talk to the card isn’t available online. You can purchase it from Tomar for $600.00 USD - which is pretty rough that you have to buy along side the hardware - yay capitalism. Even if I did sink money on that, I wasn’t sure if they would actually sell it to me.

Configuring the card was important as I needed to know what codes were configured and have a way for automating logging of successful detection.

This stumped me for the longest time as I couldn’t figure anything out of the output by just guessing its protocol.

That is until I found a really old copy of “OSPsoft 2 User Manual” using the way back machine on the Tomar website.

This little section of the manual provided the hex values of the commands and also what the error codes were - along with hints of the data format.

From that I was able to piece together enough information to change ranges, enable uncoded signals and look at logs. The other part was that the user interface in the manual nearly matched the data that was sent in each configuration message. So I was able to work through the screenshots to determine what bytes did what things.

There were a few fun quirks along the way. A lot of the values are hex encoded for some reason, and sometimes ascii encoded. For example getting or setting a sub group requires sending a byte with the ascii encoded number of that group so for group 1 would would send b'1' using Python. However there are 16 sub groups and you can only send a single byte for this parameter. They actually overflow the ASCII conversion so the 10-15 become b':', b';', b'<', b'=', b'>' and b'?'.

With the uncoded ID enabled, I was able to wire up an Arduino Nano and generate a 14.035hz tone and successfully get the unit to show an emergency preemption light on the front panel - along with log some output. Seeing that little light come on was a relief because up until this point I wasn’t sure if the signal processor actually processed the pulses.

Coded messages

The next challenge was coded messages. The first thing I did was run a bunch of tests with the unencoded message to understand what the limits were. It took 33 bits to trigger an unencoded preemption, the min pulse gap length was about 71.010ms, and the longest was around 71.260ms.

From the GTT patents I expected there to be two pulse lengths, a short and long, and based on the spec sheet from Tomar it supports 65000 vehicles - so roughly 16 bits of vehicle ID information.

We still have some questions though:

• Is there a preamble - and if so how long and what does it look like. If not, how does the system know the start of an ID
• Is there a checksum
• Are the vehicle IDs using some sort of gray code or De Bruijn sequence?

I pretty much started with shoving random bit patterns into the system and logging what came out. The intention here so to find something that decodes - even if we don’t know what it means. We vary the pulse delays from the range we found above.

This didn’t get me very far, so I built something a bit more controlled. I programmed a bunch of formats/rules to try - such as repeat the sequence every 15,16,17,18 bits. Use a nominal frequency every 2nd pulse.

My thought process is that if a checksum existed, it would be a max of 16 bits. Eventually we might find a match. I tried a bunch of experiments.

Eventually one of the experiments returned two different successful decodes. The pulse stream was logged. The problem was that playing those back again didn’t result in a decode. I did however find that playing it back it would decode once in maybe 10-20 decodes. Not great but it’s a starting point. The pulse stream was effectively repeated at 17 pulses, the last pulse delay was long.

From here my thought was that one of the bits were being flipped creating a valid preamble. I started flipping bits but this made decoding worse! If there’s no preamble - how does it know the start or finish of the vehicle ID?

The secret third option. The last pulse in the repeating pattern was a long delay. What if I bump just that pulse out by even longer. Success, reliable decodes.

I ran through some ranges of pulse delay timings and figured out reliable timings (note that were are using delay/delayMicroseconds in Arduino, so aren’t exact figures. I don’t have a great way of measuring exact pulse delay times)

l 71215  +/- 10 (safe)
s 71090  +/- 10 (safe)
p 71260 +/- 10 (safe)
[p,   s,s,s,l, s,s,s,s, l,l,s,l, l,s,s,s] (repeat at least twice)
Decodes as 61,223 (0xEF27)

The vehicle ID isn’t encoded in any special way, the key part is having an extra slightly longer delay for the first/last pulse and repeat at least twice (to get up to 33 pulses - both sequences must match).

Transmitting

As a PoC I built my own little detector. It’s not using the amplifier circuit, is missing all the filtering and is generally just terrible because I don’t know what I’m doing - but it works well enough to test.

In the video I demonstrate IR signal triggering the signal processor for a coded Strobecom II signal.

I also built using a Raspberry Pi Pico (important, the PCB must be pink) and connected an IR LED to it via a resistor.

#define l 71225 - 0xffff
#define s 71100 - 0xffff
#define p 71270 - 0xffff
#define LENGTH 17
#define on 200

unsigned int payload[LENGTH] = {p,    s,s,s,l, s,s,s,s,  l,l,s,l, l,s,s,s };
int pos=0;

void setup() {
  pinMode(0, OUTPUT);
  digitalWrite(0, LOW);
}

void loop() {
  delayMicroseconds(0xffff-on);
  delayMicroseconds(payload[pos]);
  digitalWrite(0, HIGH);
  delayMicroseconds(on);
  digitalWrite(0, LOW);
  pos++;
  if (pos >= LENGTH){
    pos = 0;
  }
}

I adjusted the timing a little bit for the Pico but now get reliable decodes with the above code by pointing the IR blaster at my make shift detector.

But I still need to find the vehicle ID to “hack” the system right?

Yes. Kind of. Maybe

Some of the Tomar controllers don’t actually permit configuration. So as long as you configure an ID within the default range you are done.

Systems that do allow configuring - might be left with the default configuration. As above, if this is the case, you are done.

For systems that are configured, we should look at how that works. First quirk is that the controllers I’ve looked at require setting a ID range. This is a max of 1000 sequential vehicle IDs. This is due to the limited amount of memory on the controllers. So while it can decode 65,000 vehicle IDs you must set a range, such as 4000 to 5000, that your system will use. Inside that range you can enable/disable different IDs. By default they will all be enabled. I suspect in most cases this is most the configuration done.

In the case that the controllers have disabled all vehicle IDs by default, then you can expect maybe 50-100 vehicle IDs to be enabled in a typical system. Given that it takes 2.5 seconds to send a signal, binary searching this space isn’t all that time consuming when its 100/65000 codes.

The worst case is that the system is programmed with a single ID. That would take 45 hours. On the flip side, if the system is coded with a single ID, it’s really hard for them to change that ID as multiple vehicles will need to be reprogrammed.

What can be done?

Both Tomar and GTT know that these systems are insecure. Both have various patents (sigh) of alternative authentication schemes, such as using a combination of IR and radio. I imagine most traffic agencies are moving away from this optical based approach anyway. Every state/area has different approaches to EVP.

So can the Flipper Zero be used to change the traffic lights?

Probably. The thing is though, I don’t own one and I don’t have a Strobecom detector.

The timing on the Tomar system is tight, flashing roughly 14hz isn’t good enough. If your LEDs don’t have a quick rise time, then they’ll get filtered out and if the system requires codes you need an active code. There’s also nothing stopping you from adding a xenon flasher (apart from the risk of high voltage electronics) to a Flipper Zero.

I’m pretty certain that it’s possible to get a Flipper Zero to trigger Strobecom II preemption - I just don’t think anyone has done it yet. Opticom on the other hand, probably has happened.

Further research

My OSP only lets me configure up to the advertised 65,000 IDs. That means there are 536 IDs that are unconfigurable. After this post goes up I’m going to try to send some of these IDs to see if they trigger anything fun.

I’ve placed my notes, Pi Pico code and OSP reverse engineering in this GitHub repo.