Arbitrary Code Execution Over Radio

Computers connected to networks are constantly threatened by attackers who seek to exploit vulnerabilities wherever they can find them. This risk is particularly high for machines connected to the Internet, but any network connection can be susceptible to attacks. As highlighted by security researcher and consultant [Rick Osgood], even computers connected to nothing more than a radio can be vulnerable to attacks if they’re using certain digital modes of communication.

The vulnerability that [Rick] found involves exploiting a flaw in a piece of software called WinAPRS. APRS is a method commonly used in the amateur radio community for sending data over radio, and WinAPRS allows for this functionality on a PC. He specifically sought out this program for vulnerabilities since it is closed-source and hasn’t been updated since 2013. After some analysis, he found a memory bug which was used to manipulate the Extended Instruction Pointer (EIP) register which stores the memory address of the next instruction to be executed by the CPU. This essentially allows for arbitrary code execution on a remote machine via radio.

The exploit was found while using Windows XP because it lacks some of the more modern memory protection features of modern operating systems, but the exploit does still work with Windows 10, just not as reliably and with a bit of extra effort required. It’s a good reminder to use open-source software when possible so issues like these can get resolved, and to regularly install security updates when possible. If you’re looking to delve into the world of APRS in more modern times, take a look at this project which adds APRS to budget transceivers. Just make sure you get your license first.

71 thoughts on “Arbitrary Code Execution Over Radio

  1. > It’s a good reminder to use open-source software when possible so issues like these can get resolved

    Is it better though?

    There aren’t that many honest people actively poring over every bit of open source code finding the bugs. Meanwhile, people who would do so for criminal purposes are plenty – and they don’t have to publish their findings.

    1. I was just going to point out that very thing with reminder that a decades old bug was found in code that had no doubt been “peer reviewed” many many times over that period.

      1. I think it depends on the quality and quantity of people that review. And at the very least, OSS can be patched and redeployed rather quickly whereas closed source abandonware remains unpatched and vulnerable forever.

        1. “Can be” usually means “is not” There are plenty of abandoned OSS projects.

          And it isn’t enough to just patch the bugs, you have to actively FORCE your uses to upgrade, many are lazy and don’t see the need so they don’t take the time. There are PLENTY of examples of hackers leveraging bugs that were fixed long ago but people did not upgrade.

          With paid for software you can threaten to cut off support to users who don’t upgrade, you can even go in and upgrade them anyway against their will if you put that in the support contract. Apple Microsoft and Google will all shove updates down your throat if they deem it necessary.

          1. Of course, if you are a Mozilla Dev, you ‘encourage’ your users to upgrade from older versions by deleting all of their saved bookmarks and other setup information when they upgrade. That’s the ‘professional’ way of doing development.

          2. “you can even go in and upgrade them anyway against their will if you put that in the support contract. Apple Microsoft and Google will all shove updates down your throat if they deem it necessary”

            Reminds me of the Ukraine Invasion.. Russia Bricked a lot of E-Net Modems by forcing a fake update..

          3. You are getting forced upgrades for free software from Ubuntu and redhat and google. They will all update your software whether you want it or not,

            You freely choose to use this software and you accepted these conditions when you hit the continue button in the installer. They are all laid out in the fine print which you apparently didn’t read. If you don’t like it you are free to uninstall it and choose something else.

            Freedom does not mean you are free to harbor malware on your systems and infect others.

          4. I’m not sure where you get the idea that upgrades are forced by Redhat. You can choose to enable or disable the update daemon, or specifically exclude packages from being upgraded.

            I am free to do anything I like with MY systems and MY networks and you can only choose not to take content from those systems. YOU are responsible for YOUR security and have NOTHING AT ALL to say about MY systems/network security.

        1. If I work for company X and my code changes get reviewed and approved by my fellow developers before committing them, have they not been peer reviewed? Who else are my peers?

        2. There are many examples of closed source code that gets extensive review before release.

          For enterprise business software this is especially true,

          often the customers participate in the testing and review of new releases and the product is not approved for release until the customers are happy that the upgrade will be successful. The customers insist on really extreme and extensive security testing , way beyond the level of scrutiny received by any OSS project.

          1. And there are plenty of examples of closed source software whose code never gets peer reviewed until a customer jumps up and down because of a bug. Take the company I work for, for example 😁 Maybe not for long though.

          2. You’re talking about acceptance testing, which is very much not code review, and is almost never security vulnerability auditing, despite your insistence here.

          3. Customers today are insisting on full security audits by third parties for ALL software included in their systems whether open or closed source. These audits involve source code analysis and review of development workflow processes. Most free software fails these audits in spectacular fashion because people do not perform the requirements unless they are paid to do so.

            For example only a very very tiny minority of npm packages are capable of passing any kind of security audit. Most have no tests at all and virtually nobody does any sort of test coverage analysis.

      2. Crypto AG is a good example of this. It’s not computer code, but it is cryptography which was about as open-source as it gets. It had a mathematical backdoor hidden in it and wasn’t detected for decades. US intelligence sold it all over the world through a front and used the exploit to great effect.
        So think about that next time you feel like trusting cryptography which originates within the US government (Tor, probably Bitcoin) which is nevertheless open-source. Open code review is no guarantee at all. It’s probably still pwned

    2. I’m solidly in favor of open-source development, but I don’t think there’s any guarantee open-source applications get but fixes more reliably than proprietary ones. The open-source advantage is that bugs may be identified sooner (assuming many eyes are looking at the code).

      If I find a bug in an open-source project and if I have the ability I can craft a patch… Which the maintainers may or may not check in for myriad reasons. Or maybe I just file a bug report which sits unacknowledged for weeks or months or longer because the project has a single maintainer without the time to address every but that comes in, or who no longer has time to work on it at all. In a perfect world every project would have at least a few dedicated, capable individuals to share the maintenance burden, but that’s not the reality.

      1. > I don’t think there’s any guarantee open-source applications get but fixes more reliably than proprietary ones.

        You’re right and it’s more about open source gives anyone with the skill to fix bugs the ability to, as you mentioned.

      1. Distinguishing between “amateurs” and “professionals” is no different in software development than it is in any other discipline. If you want quality work you have to throw money at the problem.

          1. Show me a successful thriving company that is relying on homegrown amateur written software for their critical business operations. Hint: it doesn’t exist.

          2. Anonymous is right!! Only fools think engineers should be managed by carrots and sticks. They don’t understand the stupid triangle of scope, cost and schedule, and quality. Increase the scope without increasing the cost and schedule, what’s going to give? Example of a company who develops bad software that’s thriving today? How about Toyota? Remember the infamous petal position sensor? It wasn’t sensor which Toyota tried to at first place the blame, wasn’t the floormat that they later alleged to have trapped the pedal under it. Now, this case is not so much about security as is functional safety, but the same FMEA concepts apply. Toyota’s software was discovered to have a MISRA score that was so high that the software was considered UNMAINTAINABLE!!! That’s pretty bad! Open source projects give engineers the freedom to do what they love to do and do it well. That’s why Wikipedia is the oustanding online encyclopedia even when Microsoft spent millions trying. That’s why companies that develop electronic systems are split between Altium and KiCAD. They are all going to have bugs, open or closed. When talking about reviews, based on what? The V-model? Do these enterprise companies even know what a V-model is?

          3. My previous comment regarding Toyota was in reference to their sudden vehicle acceleration issue back around the end of the last century. A newer example is Boeing (737MAX Angle of Attack Sensor fault). Although dual redundancy was present, the software was not designed for a safe state in the event that one of the two angle of attack sensors should fail. The test engineer signed off on the testing under pressure to get it done only to find the corner case later that could result in catastrophe (which it did with the crashing of two commercial airliners). He tried to report it up doing the right thing but executive management decided to let it go. Murphy is the hacker of lacking functional safety.

        1. How are you defining ‘amateur’ and ‘professional’ here? Whether the developers are degreed? Whether they’re paid? Whether they’re self-employed or working for a company?

          1. Are you working under a contract that stipulates milestones and rewards the completion of the milestones or are you acting on your own with no customers and no external reward for fulfilling requirements.

            If nobody is paying you to write all of the required 2048 test cases then you sure are not going to write them for free unless you are fine with getting a divorce.

        2. This does not mean that open-source software does not get money thrown at it. For instance, the Linux kernel regularly receives contributions from companies like Intel, Google, … because they use it.

        3. I think it’s important to keep in mind what the terms actually mean.

          In ham radio, an “amateur” is someone who doesn’t have money on the mind.
          The licensed amateur radio operator is skilled, since he passed a test successfully, at the very least.

          A “professional” by contrast, is someone who does it for money.
          As a profession, as a job. He/she/they may or may not be skilled.
          Some jobs require no qualification (no test) also: everyone can attempt to do them.

          That’s something to keep in mind, I think.
          Laymen often think that a radio “amateur” must be a wannabe operator, because of “amateur”.
          A bungler, an incompetent individual, so to say. To them, the opposite is the “professional”.

          Sadly, that’s how language has become meantime.

      2. The case is worse when it is both open source and abandonware, because there’s nobody “upstream” to distribute your patches anyways. Who’s gonna trust some random nobody to “fix” their software for security?

      3. Good distinction. I think the author makes a little bit of a leap in logic by saying that the problem here is the closed source nature of the software. It has more to do with the fact that it hasn’t been updated in a decade.

    3. I’d say the moral of the story is more along the lines of “Don’t use a piece of software that hasn’t been updated in the last decade on an unsupported operating system”
      It’s not really a fair comparison, a modern, well-maintained piece of software is likely going to be more secure than some obscure open-source one-man weekend project.
      It’s just a blanket statement that generalizes too much

      1. >“Don’t use a piece of software that hasn’t been updated in the last decade on an unsupported operating system”
        Seeing as these “updates” and “support” keep producing software that needs more “updates” and “support”, I don’t think those things matter as much as you think they do.

        1. So software is different from everything else in the world? Every complex system needs maintenance and updates whether it is your car or your furnace or your web server.

          1. In the early 70’s I remember the Odd Group that sat in the Corner of the Cafeteria in the Hospital I worked at.. I asked somebody what they did here.. The answer was Software Maintenance..

            I stood there looking stupid.. and asked, How does software ‘Break’?..

            I think I learned a little from that day..

          2. Software breaks all the time when tax laws change or politicians mess with daylight savings time or an upstream service changes or when faster hardware induces buffer overflows. Any tiny change to any other component can trigger a latent race condition that never happened before. Y2K caused many failures in software that was “working just fine”. Browsers depreciate old stuff all the time and web apps subsequently break, 2038 will break a lot of software that uses dates.

            Rare indeed is the software package that has never suffered a regression from external changes.

    4. There might be an argument that the code of a living company (at least a regulated one) might get more attention due to the blackmail/shorting potential. Once a commercial enterprise is dead though all closed source bugs are permanent.

      1. Nope, with commercial software the source code is held in escrow by a third party and released to the customers if the company goes bankrupt or they violate their contract.

        1. This obviously doesn’t hold for individual end users, who will never see the source code of their software whether they’ve paid for it or not.

          You see, what most people are thinking about is software like GIMP, which is aimed at individual desktop users. They’re not thinking about commercial business software made for purpose under contract.

    5. Criminals scrutinize both open-source and closed-source software.
      For open-source software, at least it can be fixed.

      For Amateur Radio, for some reason (I don’t know if it’s ego or something else, such as terrible code quality and shame), most commonly used software is closed-source. There have been cases of the author disappearing (death, or other reasons) and communities of thousands of users finding themselves with no way to update the primary software they use.

      Additionally, open-source software usually receives contributions from a wider range of authors, who are more likely to combine skills, so it is much more likely that security vulnerabilities will be fixed. Whereas if you have a single author, if that person doesn’t happen to have some security sensibility, the software will be plagued with holes.

      I hope that this event around WinAPRS will get wildly reported and that we will get a push for more open-source software in amateur radio.

    6. I think what was meant here is that with closed source software, if it’s not maintained anymore, a vulnerability won’t get fixed after it’s found. With open source, you could fix it yourself, at least in theory.

    7. It’s better, just not by a large margin. Perhaps the key benefit here though is that the only solution right now is a from scratch rewrite or substitute software, as you couldn’t patch this package, whereas if it was open source the bug might have still been there but at least a keen developer could potentially deploy a once off fix.

  2. Fully on board with the general comments here. Being Open or Closed source doesn’t chi angle the security model in any significant way. Being several years old without updates is an indication it could be a problem, but even that is dependent on other external factors.

    Plenty of open source projects have had bugs go missed for years that had significant security implications; they don’t magically float to the surface just because they are open source.

    I use open source code daily, and support some in a development environment as well,but the idea it’s more secure because it’s open source is fundamentally flawed.

    Some open source is evaluated for security vulnerabilities and therefor has some level of reduced risk; but then some closed source is too.

    Now let me get back to my FT8 contacts on 15m and try and get those elusive DX contacts from Europe, Asia and Oceana. My magloop antenna, in my concrete bunker of an apartment keeps making think it’s possible before subsequently disappointing me in reality.

  3. It might be “free software” but when it is used in the business environment, it gets supported and updated just like the closed source software and this level of suppoet needs to be paid for. In fact the customer doesn’t care whether the software is open or closed source, what they care about is the support that they are paying for. The customer is paying for free software whether they pay an outside party for support or they pay their own people to support and update it.

    “Free software” doesn’t actually exist, everyone in the process is really “paying it forward”

    1. I find it both cool and super sad. Super sad because it really shows that amateur radio is stuck decades ago. Attempts to modernize it are plagued with closed-source and proprietary protocols like C4FM. Open standards like M17 seem to have a lot of difficulty taking off.

      1. It’s not as stuck as it seems. There’s FX.25 extension for AX.25, which ads FEC.. And IL2P (?) protocol that’s not backeards compatible, though.

        Performance of classic APRS could be greatly increased if Digipeater were upgraded and running Direwolf or soundmodem.

        Or simply, if the old AFSK TNCs were *finally* correctly adjusted.
        There’s the problem with wrong loudness levels, distortion, and the main problem:
        The wrong levels of “mark” and “space” frequencies (in quotation marks becsuse of NRZ I encoding, rather 1200 and 2200 Hz tones).

        The buzzwords are “emphasis”/”emphasis”, I believe.
        The issue also occurs if FM and PM radios talk to each others.

        It’s not the fault of the vintage TNCs, but inadequate educated amateurs and cheap two way radios of the far east.
        Real FM synthesis requires sophisticated filtering (or a DSP), while PM (phase modulation) can be cheaper implemented.

        How to fix it? Either the user’s 2m radios improve to real FM (like it used to be) , or the digipeater must downgrade to cheap PM radios.
        Or, modern dual PM/FM radios must be used – with modern SDR and DSP technology it’s feasible.


        But yes I agree, , personally, I also find it sad that amateur radio nolonger is taking the lead as it used to do. Instead of creating own infrastructures and technology, “we” radio enthusiasts got too lazy and mainstream.

        For example, “we” adopt way too much boring mainstream technology that’s based on the internet, LAN/Ethernet, the TCP/IP and UDP protocols or has a capitalistic/commercial background. Like LoRA, for example. Or WiFi based HamNet. Or PACTOR 4. Super closed and heavily patented.

        We need more good inventions like WSPR, Codec 2, or VARA.. More individualism, more think outside the box. That’s what ham radio used tp be strong in. 🙂👍

        1. Uhhhh….. Dude. VARA is locked down just like PACTOR 2/3/4 !

          John – G8BPQ has offered a few times to make the code work
          under Linux and VARA dude has refused. (It would have still been
          closed source, so no loss of income to VARA )

          1. Relax, it was meant as an example only. There are other, better examples for sure. I’m just not up-to-date at the moment due to real life problems. If everything was fine, I could probably have mentioned a few more things. 🙂

      2. Another thing are the vintage computer scene or retro gaming scene.

        It consists of individuals that love to tinker with old school tech.
        Paradoxically, though, they’re also highly creative and have no trouble using modern technology.

        I’m thinking of the ChipTune musicians or the indie developers.
        Games like “Pier Solar and the great architects” or “Tanglewood” are made using modern development tools.

        Such rather young people working on stuff like this do optimize their games using assembler code or implement multitasking, realtime code/data decompression from scratch.

        In amateur radio, similar minded people also exist. Ironically, those “stuck in the past” ones are exactly those who didn’t give up their values. They still repair and tinker, because they have an emotional bond to something.

        By contrast, most of the modern amateurs who always use the newest tech are mainly consumers. They don’t create or fix, they buy. And if they say they “tinker” it means they’re combing ready-made modules. The have an ego to care for. They’re after diplomas and contests, about having best modulation.

        Unfortunately, the young or unexperienced fall for the “up to date” guys, because they seem to be superior. They use them as orientation, think “so that’s amateur radio”. Then they get an FT-817..

        That’s sad, because the oldtimers know old tricks that are timeless and can still be useful (making antennae, how to solder, how to use tools, how to make ham furniture, how to use coax cables, how to measure, how to troubleshoot).

        In essence, those “old farts” are a bit like your typical grandparents. They’re outdated a bit and live another way of life, but they also went through suffering and trial&error. Unlike those up-to-date hams who have no sentimental relationship to the hobby or their gear. They simply replace if something is old or broken. Or someone.

      3. I forgot one important “bit” (pun intended).
        Venerable applications like UI-View and UI-View32 can be extended in functionality by using extensions/plug-ins.

        PS: One of the reasons why popular programs and modes aren’t being updated anymore is because their creators passed away.
        That’s in part also because some of those technologies have been developed in earlier times.

        Please let’s keep in mind that open source as a concept is quite recent, also.
        Prior to it, there was “Public Domain” (PD), as used early on by hams and hackers. Then, Freeware and Shareware followed. And crippled demo/trial versions.

        The old GNU license 1.x was from ~1990 – and before the year ~2000, almost no one had heard about open source.
        If it wasn’t for, say, GNU Chess or Linux, the majority of geeks/users wouldn’t even have heard about it, even, I believe.

  4. Mother Nature broke google earth and google maps when it spewed lava onto towns on the big island of Hawaii. Google says there is a road and houses there but in fact it’s a steaming lava flow! It’s a bug!

    The local contractor has induced a bad bug in google earth by constructing a whole bunch of new houses that are still showing up as vacant lots. If you don’t think that this is a bug, try talking to the people who live in those houses.

  5. Thanks for sharing my research! I had wanted to look into this for years but only really gained the skills I needed to get started in 2021 and was finally able to publish something in 2022. I really just wanted to see someone catch a shell over ham radio and was super excited when I was able to make it happen.

    1. It’s an impressive piece of work! I had a similar thought last year, which is when I then discovered your write-up while googling around. I think we need more of this type of high quality content in the HAM community.

  6. If nobody is paying you to write your software, you’re doing it wrong. The folks who want to use your software are willing to pay you for it. Your task is figure out how to get the business model to work for you. RedHat makes billions of dollars selling software that you can get for free.

    Things that live and grow have to learn how to sustain themselves, otherwise they wither and die quickly when conditions change.

    1. The obvious thing is, people who distribute free software and sell support are shipping products that are broken out of the box, or simply too difficult to figure out by yourself, or both. How else could they stay in business?

      That’s why the siren song of Free Open Source Software is so misleading.

      1. Companies, like my employer, insist on some level of support, the more they push for “Enterprise” level support the more expensive it gets, but we often pay for it like insurance, not because we need it today, but because we might need it tomorrow.

        I support a bunch of ope source tools we use, and only occasionally do we reach outside of the organization for support.

      2. In my experience there’s tons of things I can do easily on Linux that are a pain in the ass on Windows despite the former being free and the latter being hundreds of dollars. It’s hardly a siren song, the praise for using open source software generally comes from sysadmins who practice what they preach.

    2. There are successful open source software projects that thrive without direct revenue, such as Red Hat’s business model. Sustainability of software projects is not solely about money, but also community support and value creation

    3. Not everything on life is like money money money grind grind grind, thats how you end up with no hair on your head, passed out half-dead in an overheated hot-tub while your screaming dependents smear your income all over your beige walls. sometimes human beings like to make software because its fun. Sometimes people like to make a fun project and then work on it with other people. So then they share their project. Then other fun people come and share their talents together. And then get this: if the creator gets bored and wants to work on another project, then the project can keep going. Wow isn’t that like so crazy bro? So then like the show goes on even if radio-dave got flattened by an alcoholic dodge ram driver. This isn’t 1985, its 2023, we like to have fun and make fun things. Every one of your comments show some archaic McAffee/WinRAR/discjuggler brain mentality. The solely proprietary mindset is already archaic, but it is downright cringe for hobby stuff.

      1. Moreover, I see volunteering on open source projects advantageous to build experience, repport, and reputation. Visialize working at the company as a software engineer for a five years or better. The people that can best vouch for your skills as references are your current colleagues and managers. You’re absolutely stuck in your job that is likely underpaying as companies do not reward advancement and you can’t ask the people you currently work with to provide a reference. The open source project is another avenue to get backing needed for excelling the career.

  7. I used to work for a radio manufacturer and was always disappointed that my security bugs were dismissed as ‘improbable’ and ‘edge cases’. This was a manufacturer that sold to governments and organisations working within hostile environments.

    So during a trial I used said radio to remotely shut down a base station and suddenly my ‘paranoid’ bugs were taken more seriously.

    Unfortunately in commercial software development, software is usually released with some known bugs as a trade-off between release timing and stability. Software bugs talk, but money shouts.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.