




  • 1
    $\begingroup$ most systems on an aircraft do have a physical disconnect, and the fly by wire lets the pilot full control if he needs it $\endgroup$ – ratchet freak Mar 14 '14 at 23:46
  • 4
    $\begingroup$ @ratchet physical disconnect? How can I envision that -- like Scotty crawling through smoking engine shafts?-- My favourite joke is from the German c't magazine... an airplane passenger opens his notebook and freaks when he sees this dialog pop up: "New Bluetooth device detected: Airbus A380. Reset [yes] [no]?" $\endgroup$ – Peter - Reinstate Monica Mar 15 '14 at 3:25
  • 3
    $\begingroup$ @PeterSchneider I meant there is a fusebox right behind the pilot where he can turn off the power to just about all systems $\endgroup$ – ratchet freak Mar 15 '14 at 3:30
  • 1
    $\begingroup$ @ratchet ok, but he wouldn't like that during takeoff or landing. Or flying, as such. $\endgroup$ – Peter - Reinstate Monica Mar 15 '14 at 3:34
  • 2
    $\begingroup$ How about stowing a trained monkey in the wheel well. It may not count as hacking, but you might be able to accomplish the same objective. A trained monkey could be really bad news, especially if it was charming, had a snazzy outfit and had evil intentions. $\endgroup$ – David Mar 15 '14 at 8:07


From a system perspective:

  • Aircraft systems could probably be 'hacked'- assuming you could for instance screw up the flight computer by changing the chips in the belly- but there is no way you could really pull this off without the pilots noticing the course being way off from the compass for instance, so they'd figure out and shut it off. Many systems are not connected in a way that allows them to be cause damage to others. Systems are also pretty dedicated- if it's supposed to fly the plane, that's what it does, if it's supposed to navigate, that's what it does.

  • Systems on aircraft generally a have limited, if any, connection to the outside world. There are a few systems that have the ability to connect to the ground, and this is generally limited to simple text messages. Most of the electronics on the 777 are from the type's introduction in 1994. A decent analogy I think is trying to hack an early cell phone remotely.

And from a practical standpoint:




As for original question link:





  • 8
  • 5
  • 2
    $\begingroup$ @PeterSchneider More what I meant is that you're more likely to see a Windows hacker because there are, literally, billions of users and billions of boxes to practice on. Avionics software...not so much. But yes, still hackable if you had a mind to do it ;). $\endgroup$ – Jay Carr Mar 15 '14 at 3:34
  • 6
  • 2





In short, this isn't really something to worry about.



  • 1
    $\begingroup$ Haha, I like the way they come up everywhere ;) $\endgroup$ – Sunny R Gupta Mar 16 '14 at 8:21
  • $\begingroup$ As somebody who actually wrote automated test software for some controller going into an airplane and looked into the procedures which are done to ensure that the part goes into the airplane in a 100% documented and known state, I think that this is highly unlikely. If anything they would have to hack the manufacturer and add additional (which I think is easier, but very criminal, since you would be breaking the laws of dozens of countries at the same time). $\endgroup$ – Sascha Jan 7 '17 at 21:41
  • $\begingroup$ @Sascha Yet that A400M crashed because of bad software (we are told). $\endgroup$ – curiousguy Jul 2 '18 at 19:56

"Hack" has a variety of definitions, from reading private data off a non-critical system, to disrupting or confusing an avionics mode, to taking control of the plane and locking out pilots. This complicates the discusion of how likely planes are to be "hacked".

In general, the recent consensus seems to be that under some definitions of "hack", this certainly is possible, even without insider knowledge. There's some reports of successful hacks out there, though since the details are confidential it's hard to tell what researchers accomplished or their method of attack. Both researchers and plane manufacturers seem to agree that even with insider knowledge or prolonged access the plane it would be extremely difficult, but not impossible, to take control of an airplane for more than a few seconds.

Current policy guidance by the FAA can be found in PS-AIR-21.16-02. I've heard that the FAA will eventually recognize DO-326 as a means of compliance.

I'm going to provide some information on safety and integrity measures that are standard in the industry and make hacking avionics difficult. In particular, hacking avionics is a type of safety-critical embedded device hacking, not server or personal computer hacking. Safety critical embedded devices have a much smaller attack surface and many more mitigation methods in place, as outlined below.

Threat model and differences from computers

The threats you face on planes are very different from servers and laptops. Personal computers are ripe for viruses because they use a lot of dangerously flexible techniques. They execute arbitrary code. They have software that reconfigures itself. They take in text and even commands from unverified sources. Most of these are not true for avionics, so it's hard to specify a threat model.

Especially for the most critical systems like displays and autopilots, datatypes are strict, messaging is scheduled, processing time is limited, and strings are rarely used. To accomplish most tasks, you would have to break these protocols. This is similar to other kinds of embedded programming where the software is so inflexible that the attack surface is small.

Some things that definitely help attackers here include physical access to the software update process, being able to work with the plane for several days, insider knowledge, simple RF equipment, or ability to hijack satellite communications to the plane. If your attacker has some of those the threat is much more serious.


Is it possible to mess with the availability of aircraft systems? Yes, if you can manipulate the right signals. You could, for example, make the flight control computer think a sensor has gone bad. You could throw off a lot of sensors with powerful enough radio signals. Also, most flight computers use off-the-shelf processors with lots of weird behaviors, and especially if an exploit lets you execute arbitrary assembly code, you could exploit some of these to take the avionics system offline.

However, availability isn't as big of a concern as integrity of the avionics. Most people don't stay up at night worrying about their pilot having to fly by hand because of a hacker. Most people are really concerned about a hacker taking complete control of the plane.


Different functions, especially ones at different safety levels, are by regulation insulated from each other. Aircraft have historically had dedicated hardware for each component, like one computer for the autopilot, another computer for the warning system, another computer for the data processing. Nowadays much of this software is run on shared LRU computers (this is called an IMA architecture). But despite sharing hardware, the software processes are strictly insulated from each other and it is assumed that no processor faults, error conditions, overflows, etc. could transfer from one process to another, especially not a higher level process. Yes, signals pass between partitions, but any signals passing from a lower safety level to a higher level are individually justified to ensure they won't cause safety issues.

In order for an exploit to have catastrophic effect, it would have to get around these by either by 1) working directly with level-A hardware and processes 2) finding a poor assumption about the impact of a lower-level signal.

See DO-297 and DO-178C for more information on this partitioning.


Many hacks in personal computers happen because of inadequate testing that lets exceptions and faults into the system. Level A software is tested far more comprehensively than most apps or PC software. Every line is tested for MC-DC coverage (not exhaustive, but every decision has to be exercised as both True and False). Structural coverage is also evaluated to make sure unintended interactions don't occur. If faults do occur, the RTOS is designed to take care of these faults predictably and reliably.

Software updates

Ok, say you can't find a way to execute arbitrary code, can you mess up the software update process? This initially seems viable, especially given the new tendency to update avionics firmware over networks. There are several issues here.

  • Most aircraft are not directly connected to the internet for avionics updates. They are connected to a local network which gets the latest software from the web. So you'd have to get access to the local network for updates and then also get access to the planes using this network. This extra layer provides some mitigation.
  • Most software updates use a high-fidelity integrity check, for which you'd need an incredibly difficult hash collision. Some update processes don't have high fidelity checks, but if this is the case they must qualify to authorities that their update process is stable and error-proof. So your only option would be to forge the CRC as well for the update and/or to find an exploit in a qualified loading process.
  • Network based updates also keep track of the version numbers and may keep track of the integrity checks for the software. So you can't exactly force an update from version 13 to a hacked v. 13.1 without someone noticing.
  • Currently supply chain attacks are becoming more and more frequent. While I'm sure a supply chain attack might be feasible, regulations such as DO-330 tool qualification and DO-178 configuration control have protected against inadvertent changes during software builds for years already. Tested and reviewed versions of code are under careful control and compared against the final versions, software build environments are locked down and qualified, and lists of included libraries are documented and approved. You'd have to find a blind spot in these processes to attack the software supply chain.
  • Software updates (not navigational database updates) are performed infrequently, maybe once every three years if that, greatly mitigating the opportunity to hack a software load. Interlocks are in place to prevent reloading the software when not desired. This infrequency also leads to greater scrutiny of the entire process.

For more analysis of safety measures to prevent corrupt software or databases from being uploaded, I'd suggest you consult the standards for this process: DO-200A, Chapter 5 of FAA Order 8110.49,and FAA AC 20-153.

Manual and Automatic Disconnect

Usually the autopilot and other software is managed by another system which has interlocks and disengage logic. These have safety standards and tests written to make sure they work reliably, making it tricky to find an exploit here without, say, already being able to execute arbitrary code.

Even if this disengagement software doesn't work, pilots have circuit breakers and can disable the entire avionics system, then fly the airplane by hand. See BigHomie's answer for a discussion of how feasible it is to hack this.

In theory, this should work, but in certain situations the plane could be put in an unsafe situation before the pilot could regain control. A sudden pitch down on approach would be difficult to recover from, even if you can manually disengage the autopilot.

Note: I'm not an expert in avionics or embedded device security. Hacking tends to be about thinking outside the box, so let me know if anything I assume here is inaccurate or if I miss anything.

  • 1
    $\begingroup$ "Software updates use a high-fidelity integrity check" We were told that the A400M crashed in Seville because the fuel control software was corrupted... $\endgroup$ – curiousguy Jul 2 '18 at 19:54
  • $\begingroup$ @curiousguy In that crash the torque parameters were wiped during a software load, although I can't find out what that means exactly. It sounds like they weren't following directives to make sure their "update process is stable and error-proof.", and even though the software program itself was configured correctly (matching CRC's and such), some of the airplane-specific data was missing. $\endgroup$ – Cody P Jul 5 '18 at 22:31
  • $\begingroup$ Most aircraft don't get their updates from a network at all, they require a hard link to the storage medium holding the data/updates. Think a USB stick in modern aircraft or some other data cartridge in older ones (compact flash cards come to mind, or even magnetic tape). Of course those can be fed with corrupted data, but it adds yet another layer of security. $\endgroup$ – jwenting Jul 10 '18 at 5:04






  • 1
  • 1
    $\begingroup$ Passing amperage through a switch to blow it would only work in an incredibly bad novel/film. It's not realistic in an avionics perspective. -source: Avionics technician for ten years... $\endgroup$ – davewasthere Jul 6 '14 at 14:42
  • 1
    $\begingroup$ @davewasthere why? I'm not doubting you, just curious, because from an Engineering perspective, the switch has a current limit, which hopefully is at least twice its nominal rating. Can you discuss what safeguards are in place to prevent damage? $\endgroup$ – MDMoore313 Jul 6 '14 at 15:01
  • $\begingroup$ Any computer can be hacked. If the computer has no connectivity, only if you can get physical access to it. There are commercial systems, inside very secure buildings, with no connectivity to the outside world. They are unhackable. The critical systems on aircraft have no connectivity except within the aircraft. Therefore, you would need physical access to the aircraft. Now we are in the realms of James Bond. $\endgroup$ – Simon Feb 5 '16 at 16:25
  • 1
    $\begingroup$ @BigHomie Er, I think that's exactly what I said ;) $\endgroup$ – Simon Feb 5 '16 at 19:39

protected by Community Mar 19 '14 at 15:12


Would you like to answer one of these unanswered questions instead?
