FMS vulnerabilities highlighed at Net Security conference

[jportzer]

This article is obviously going for the shock factor (I tried to tone down the headline) but it seems like this guy has found some interesting vulnerabilities?


Hijacking airplanes with an Android phone

An extremely well attended talk by Hugo Teso, a security consultant at n.runs AG in Germany, about the completely realistic scenario of plane hijacking via a simple Android app has galvanized the crowd attending the Hack In The Box Conference in Amsterdam today.

http://www.net-security.org/secworld.php?id=14733It's still curious to me how he thinks he can "hack"an FMS via ACARS or ADS-B... I sincerely hope that's hyperbole.

[PJ2]

I'm more curious about why people would attend such a presentation. Rationality has departed; credulity has no bounds in our wiki age and this article reflects the current depth and quality of investigative journalism. Frightening people has become an easy pastime.

There is no link between the described systems that will move the flight controls of the aircraft and that leaves the crew at the mercy of an Android phone.

[fizz57]

He's talking about a "payload" (think "virus") that could be deployed on the FMS computer. I've no idea how (or if) this can be done, but if it could then it should be relatively easy to modify the FMS's inputs so as to deliver the desired outputs.

While ACARS/ADSB normally have no connection with the flight controls, my understanding is that this connection is precisely what this "payload" provides. But it doesn't have to - it may just contain the instruction to fly into the ground on the 4th of July, for example. Of course, that wouldn't be as cool as controlling the plane through your Android phone.

The real challenge isn't in programming the payload, it's in delivering it (or preventing its delivery, depending on your point of view). One hopes that the security measures involved with program updates (and possibly also nav data) are up to the task.

It's been done with industrial control systems (stuxnet), no fundamental reason why it can't be done with an FMC.

[Outlook]

Researcher hacks aircraft controls with Android smartphone ? The Register (http://www.theregister.co.uk/2013/04/11/hacking_aircraft_with_android_handset/)

A presentation at the Hack In The Box security summit in Amsterdam has demonstrated that it's possible to take control of aircraft flight systems and communications using an Android smartphone and some specialized attack code.

Hugo Teso, a security researcher at N.Runs and a commercial airline pilot, spent three years developing the code, buying second-hand commercial flight system software and hardware online and finding vulnerabilities within it. His presentation will cause a few sleepless nights among those with an interest in aircraft security.

Teso's attack code, dubbed SIMON, along with an Android app called PlaneSploit, can take full control of flight systems and the pilot's displays. The hacked aircraft could even be controlled using a smartphone's accelerometer to vary its course and speed by moving the handset about.

"You can use this system to modify approximately everything related to the navigation of the plane," Teso told Forbes. "That includes a lot of nasty things."

First, Teso looked at the Automatic Dependent Surveillance-Broadcast (ADS-B) system that updates ground controllers on an aircraft's position over a 1Mb/s data link. This has no security at all, he found, and could be used to passively eavesdrop on an aircraft's communications and also actively interrupt broadcasts or feed in misinformation.

Also vulnerable is the Aircraft Communications Addressing and Reporting System (ACARS), the communication relay used between pilots and ground controllers. Using a Samsung Galaxy handset, he demonstrated how to use ACARS to redirect an aircraft's navigation systems to different map coordinates.

"ACARS has no security at all. The airplane has no means to know if the messages it receives are valid or not," he said. "So they accept them and you can use them to upload data to the airplane that triggers these vulnerabilities. And then it's game over."

Teso was also able to use flaws in ACARS to insert code into a virtual aircraft's Flight Management System. By running the code between the aircraft's computer unit and the pilot's display he was able to take control of what the aircrew would be seeing in the cockpit and change the direction, altitude, and speed of the compromised craft.

He admitted that some of this was moot, given that the human pilot could always override the automatic systems, but the software could be used to make cockpit displays go haywire or control other functions, like deploying oxygen masks or lights.

The precise nature of the code flaws wasn't released – for understandable reasons – but Teso says the Federal Aviation Administration and the European Aviation Safety Administration have both been informed and are working on fixing the issue. ®



Skipping the usual press over hype - but still.... Really?

[uncle.slacky]

There's more information here (http://www.forbes.com/sites/andygreenberg/2013/04/10/researcher-says-hes-found-hackable-flaws-in-airplanes-navigation-systems/) and his presentation is here (http://conference.hitb.org/hitbsecconf2013ams/materials/D1T1%20-%20Hugo%20Teso%20-%20Aircraft%20Hacking%20-%20Practical%20Aero%20Series.pdf) (in PDF format).

[riverrock83]

So with the right radio / software, could you manipulate the ADS-B information that is part of Transponder Mode-S data to initiate a TCAS RA?

I suppose the question is - are there any vulnerabilities in the FMS which allow the FMS to be programmed via ACARS?
If the answer is no, then the attack potential is to retrieve lots of data and send bogus messages and flight plans into it. I would be very surprised if you can send something to an FMS and for that thing to be automatically used / executed without Pilot involvement?

[areobat]

I just read this over the The Register and I suspect that everything he says is possible is indeed possible. These systems were designed with the assumption that both the transmitting device and the receiving device were validated. I'm sure a great deal of time and effort went into validation and testing to make sure the transmitted messages were properly formatted, transmitted, and received. I'm sure the system was also tested for its ability to detect and reject messages corrupted by random interference.

But the complete lack of any authentication security tells me that there was no attempt to validate the system for deliberately constructed malicious messages. In networking systems, maliciously constructed messages/packets are probably the most common attack vector. And they often succeed, even on networks hardened against such attacks. I should think that do what he claims would be child's play for someone with in-depth knowledge of those systems.

[MG23]

In networking systems, maliciously constructed messages/packets are probably the most common attack vector.

But the ACARS network is more like your home LAN than the Internet; there are few legitimate routes into the system and they're validated as trustworthy before they're allowed to send data. An evil person at an ATC centre could send evil messages, but you pretty much have to trust them regardless of how the messages are transferred.

For this to work, they'd presumably need a suicidal passenger on the aircraft carrying a radio transmitter powerful enough to override the ground transmitters. Which doesn't seem too easy to me.

[FlightPathOBN]

I will look at the feed, but unfortunately, I would assume it is valid.
ADSB issues are one of the biggest reasons that ADSB-IN is not moving forward.

In regards to the FMS, those of us who work with the system architecture, understand the potential vulnerabilities. It is somewhat unfortunate that this issue has been brought forward in a hacker format...

Edit: In looking through the presentation, I dont have the verbiage of how or what was explained, but the presentation is very accurate. :eek:

[PJ2]

Well, before we all set our hair on fire over some half-baked notions we need to think about this, with some understanding of the systems involved and not just ride off in all directions with ill-considered claims. The sky is not falling . . .

1. Neither the ADS nor the ACARS are directly linked / connected to the flight control system, period.

2. The FMS is connected to the flight control system when the autoflight / autothrust systems are being guided by the flight plan data and (to a much lesser extent) the weight-and-balance data entered during the ramp check.

2. The ADS system is an ATC communications system which has no connection to the FMS. ATC cannot control the routing, speed or altitude of the aircraft through ADS.

3. While some operators routinely upload flight plan and weight-and-balance data via ACARS during the ramp flight preparation sequence, many operators' do not have this auto-upload capability and the data is entered manually. In manually-entered circumstances there is no way to upload changes to the flight plan routing via the ACARS to affect aircraft navigation through the FMS which is connected to the autoflight system.

4. Given system and aircraft design, logically the autoflight system must be engaged for this to "work". The FMS has the route data and the autoflight is designed to follow that data.

5. FMS data cannot control altitude and will not command the aircraft to climb or descend even if cruise altitude changes and descent points have previously been entered or otherwise programmed in the FMS. Neither can ACARS nor ADS do this.

6. Within a narrow Mach or CAS range, when routinely engaged, the autoflight / autothrust systems are controlled by the FMS which in turn will control aircraft cruise speed. Cruise speed and speed restrictions at certain waypoints, (oceanic entry and exit points, for example), may be part of the flight plan. As with any FMS entries, there are reasonableness checks which reject incorrect or inappropriate data.

7. Should something like that which is claimed actually succeed, there are at least two human pilots in the cockpit, sometimes three or four depending upon phase of flight, etc who can fly the aircraft manually. When the autoflight system is disconnected none of this works. Also, routine enroute waypoint checks confirm position, speed, altitude, next position and so on and, should immediate but subtle anomalies occur enroute, they would be caught at such waypoints.

This doesn't deny the possibility that ACARS has vulnerabilities, but such potential is not about to take over an airliner in flight as implied by the use of the word, "hijack".

In my view, making claims that it is somehow possible to command an airliner to "dive" or do other untoward maneuvers beyond the crew's ability to counter, using an Android cellphone, is irresponsible.

When the exact method by which the claims in Mr. Teso's article are made is clearly explained and, as such things normally are required to be, peer-reviewed to substantiate serious claims of compromise, then we might take all this seriously. At present, it seems entertainment is where one finds it.

PJ2

[Fullblast]

I would put this topic along with chemical contrails.

FB

[FlightPathOBN]

PJ2, FB...

I can say this, that after 911, there was a very serious effort in these regards.

With ADSB, there has been ADSB IN capability on many aircraft for quite some time now.

If the aircraft is on a coded procedure, where do the speed and altitude commands originate?

(thats enough at this point, I dont want the black SUV's showing up)

[nombody]

The actual presentation deck from the conference is here if you want to read the actual presentation itself instead of relying on second-hand news articles.

http://conference.hitb.org/hitbsecconf2013ams/materials/D1T1%20-%20Hugo%20Teso%20-%20Aircraft%20Hacking%20-%20Practical%20Aero%20Series.pdf (http://conference.hitb.org/hitbsecconf2013ams/materials/D1T1%20-%20Hugo%20Teso%20-%20Aircraft%20Hacking%20-%20Practical%20Aero%20Series.pdf)

[PJ2]

F.OBN;

Thanks for your response.

I realize that the issue has a security element to it but the point needs to be emphasized that ACARS & ADS systems cannot take over the flight controls of an aircraft, and that isn't a security issue, that is a design feature, knowledge of which is available to anyone. For heaven's sake, no "black SUVs" are going to show up for discussing such an issue!

I'm not disputing claims of interference through vulnerabilities, I am disputing the claim that such vulnerabilities represent a threat to the physical control of airliners beyond the ability of flight crews to counter. Let us not conflate the issue such that all manner of rumour be taken at face value for fact.

In general, let us not raise and embrace the possibility, then refuse to discuss it out of some concern for secrecy or security. If the threat is real, demonstrate how it is thus using commonly available knowledge and information. I have made some points regarding why I think this is nonsense but claim no expertise in any area other than flying these cable-pulley, hydraulic and fbw transports. Tell me as a pilot why such concerns should be taken seriously when there is a flight crew on board that can manually fly the airplane.

When someone here who both embraces these claims (that airliners can be "taken over" by ACARS or ADS commands through the FMS directly controlling the flight and engine controls, autoflight on or off), and can describe the method or process by which this is made possible and cannot be defeated by the cockpit crew, then perhaps we can take this threat seriously.

I would think that the risks are far higher in terms of corporate espionage for data that airlines are always desperate to gather on their competitors. But that kind of hacking is not new and it doesn't threaten flight safety.

nombody, thanks for the link. The preso reminds me of something Von Daniken or Velikovsky would put out.

PJ2

[lederhosen]

This reminds me of the hype with computers leading up to the year 2000. People made a lot of money claiming disaster was around the corner and carrying out expensive audits. It is (just) conceivable that you could screw up the flight management system. But then what? after all that is what the pilots are there for....to fly the plane. If the system fails we revert to?....manual flight....big deal!

[surfman96]

FYI

There is a lively thread over at Hacker News. Several of the developers claim to have experience with avionics software programming.

https://news.ycombinator.com/item?id=5531679

p.s. also a humorous sub-thread about possible TSA responses: ban Android Phones; seal them in one quart ziplock baggie; wrap them aluminum; put Hugo Teso on the no-fly list; etc..

[FlightPathOBN]

PJ2,

Understand your response.

that airliners can be "taken over" by ACARS or ADS commands through the FMS directly controlling the flight and engine controls, autoflight on or off)

If this was possible, would post how to do it in an online public forum?

Think about your autopilot controls, there is a button on the yoke, and several other ways to control the autopilot. Can the autopilot disengage itself?

[FullWings]

I read the presentation and I think this is a serious problem.

What the security researcher is talking about is using unsecured communication channels (ADS, ACARS) to identify then attack an aircraft, compromising the FMS and possibly other systems.

From what he was saying it appears that there are ''zero-day exploits'' available for some FMCs, through normal data channels. Once in there, the attacker could do pretty much anything. :eek:

We tend to think of aircraft nav/data systems as being made up of isolated units but if there are communications between them, then they are vulnerable. You can do a fair bit with most FMCs: tune navaids, select navigation sources and even use them as backup dials and switches for when these fail. On the 777 you can be ''pushed'' route updates by ATC (or whoever is pretending to be ATC...) Once compromised, you could display to the pilot(s) ''situation normal'' but in fact be taking the aircraft off-route...

[areobat]

No one thought that it was possible to remotely make 30 non-externally networked ultra high speed centrifuges located inside a super secret, hardened nuclear processing facility operated by country no one can get into quietly spin their bearings to destruction.

But it happened.

I'm not concerned about a flight becoming someone's jumbo size Parrot AR Drone, but I would be concerned that system interruptions or system manipulation could be used to provoke a mishap.

[FlightPathOBN]

From what he was saying it appears that there are ''zero-day exploits'' available for some FMCs, through normal data channels. Once in there, the attacker could do pretty much anything.

All this, and TESO was not an avionics expert...

[mixture]

No one thought that it was possible to remotely make 30 non-externally networked ultra high speed centrifuges located inside a super secret, hardened nuclear processing facility operated by country no one can get into quietly spin their bearings to destruction.

But it happened.

I think you know you are talking chalk and cheese here !

You know very well that particular network was most likely targeted by well funded, well connected entities possibly linked to one or two governments with a vested interest.

[areobat]

. . need a suicidal passenger on the aircraft carrying a radio transmitter powerful enough to override the ground transmitters.I think a well placed, high power ground transmitter could easily overcome a more distant "legitimate" transmitters.

Even though this discussion has been focused on the ground/air links, I would be willing to wager that the back-end ground link portions of these systems are almost as vulnerable. Why spend money on a transmitter when you don't have to.

. . well funded, well connected entities . . Never underestimate the power of money or determination. :)

[PJ2]

F.OBN;

Again, thank you for engaging the question. I think discussion of this matter is important so that the salient issues can be discerned against a substantial background noise.

The salient issue is, as stated, that there are certain vulnerabilities to ACARS, ADS, (and also to GPS/SatCom, but that too, is old news; we've known about Satellite / GPS jammers for years). To me, the widespread (and growing) use of iPads for critical flight planning, weight-balance, enroute and approach-plate work represent a far, far greater security risk in terms of hackability with clear and safety-related results, than the present matter under discussion, but we'll stay on-topic.

The background noise is the inability of those proposing the notion that this is a serious problem, to articulate the means by which this is more than just an ACARS / ADS vulnerability issue which is, like the issues mentioned above, probably well known.

The presentation works because it implies much but says very little. We'll see where this all is in a week or so.

PJ2

[Intruder]

How did this guy supposedly get around the requirements to ACCEPT, LOAD, and EXECUTE a flight plan change; and override the altitude locked in via the MCP?

Sounds like a lot of sensationalism, or some ACARS and ADS/CPDLC implementations are a LOT different than the ones on the 744 and 748...

[FlightPathOBN]

PJ2,

Thanks for the response. As you have noted, it is a very complicated issue. It isnt about GPS jammers, or high powered signals from the ground, these are at best, an annoyance.
This about getting to some of the core processes.
Like a thief, you check all of the ways into the building, and the first thing you is when you get to the 32 floor, you lock down the elevator behind you.

How did this guy supposedly get around the requirements to ACCEPT, LOAD, and EXECUTE a flight plan change; and override the altitude locked in via the MCP?

How are these commands entered?

(in the 744, there are, from what I remember, 4 places where you can command disengage to the autopilot system, and the system can disengage itself?)

edit: this is just f'n great...this made Yahoo news... How a single Android smartphone can crash an airplane (http://news.yahoo.com/single-android-smartphone-crash-airplane-185500619.html))

[Ian W]

How did this guy supposedly get around the requirements to ACCEPT, LOAD, and EXECUTE a flight plan change; and override the altitude locked in via the MCP?

Sounds like a lot of sensationalism, or some ACARS and ADS/CPDLC implementations are a LOT different than the ones on the 744 and 748...


I think you and PJ2 may be confusing what the FMC/FMS allows the flight-crew to do (often a company decision limiting training requirements) and what the FMC/FMS software can actually do. Just because they have not put the menu items, buttons and switches on the outside doesn't mean that the software capabilities are not there. Indeed, I would be surprised if there were not several undocumented capabilities put into the software and passed through certification, so that they could be 'delivered' rapidly as upgrades just by allowing the function.
Like many control systems (such as power control systems, communication switchgear, flood gates etc) the firmware and software may have been written without any attempt at defensive coding. There are often hidden codes left over from testing that due to certification issues are not taken out - as nobody would send that code over ACARS would they? Well seems that it is possible. I would be more interested in how he accessed the ACARS frequencies and spoofed the log in from a standard Galaxy phone. But once into ACARS I have no doubt this is possible.

[FakePilot]

I've seen many hacks that simply use amount and repetition to cause a failure in the code somewhere. The basics are:
1. Analyze code in the target computer.
2. Find some code that will break when presented with a contrived data input.
Note this input can be huge and even presented over time with careful timing.
3. Imbed code in your input that does what you want.
4. Hit the target with this input.
5. When the code breaks the computer blithly keeps on running - right into your code.
6. Computer is now running your code with whatever permissions the broken code had or possibly more or even maybe ALL permission (depends on design, cpu etc etc)

Anyway, the quick version. Years ago I remember being amazed at how the memory allocation from repeated calls was tricked into providing unzeroed memory to the process. Guess what? The process assumed the memory would have all zeros. Bham!

[areobat]

One of the basic problems with code written these days is variable range checking. It takes coding time to write the code, CPU time to execute it, and engineering time to validate it. As code becomes increasingly complex, the penalties expand exponentially, so it is often skipped. This, in combination with "vestigial" code, or deliberately added "undocumented function calls" create an enormous opportunity for exploitation.

It looks to me like these systems were designed under the security through obscurity mantra (after all, who would mess with our little corner of the world?). This, of course, never works, especially today's connected world where nothing is "obscure".

I read the following list of "features" that were demonstrated to work against the simulators by Teso's Android App

Please go here: A way of interacting with the plane where the user can dynamically tap locations on the map and change the plane’s course.
Define area: Set detailed filters related to the airplane, for example activate something when a plane is in the area of X kilometers or when it starts flying on a predefined altitude.
Visit ground: Crash the airplane.
Kiss off: Remove itself from the system.
Be punckish: A theatrical way of alerting the pilots that something is seriously wrong – lights start flashing and alarms start buzzing.

Seems like the real deal to me. The paranoid in me would speculate that the powers that be have known about this vuln for a while and this is, in part, one of the reasons for the "no electrics" ban on takeoff/landing (the most vulnerable part of any flight). I can only hope things are patched soon to make tampering more difficult. A hardened fix may require a complete change in architecture.

[Ian W]

Areobat
I can only hope things are patched soon to make tampering more difficult. A hardened fix may require a complete change in architecture.

Not sure that would be necessary. All that would be required is a communications gate keeper in firmware that security checks the ACARS/ADS or any other inputs in the same way virus scanners work today. The speed of the scan compared to the lethargic ACARS or ADS would mean that it would not slow anything down.

All these issues will be revisited as the aviation world is dragged kicking and screaming into modern communications systems with Aircraft Access to SWIM (System Wide Information Management). Perversely, in the SWIM world things will be far more secure mainly because it is perceived as a less secure environment and therefore there is no false sense of security.

[Grenville Fortescue]

Is hacking into an aircraft's systems actually possible? :eek:

Please tell me no!

[roulishollandais]

Is hacking into an aircraft's systems actually possible?
Please tell me no!
Please reread the 29 posts!:}

[Sciolistes]

Please tell me no!
You're in luck. No.

I would imagine there are security concerns with regards to the ease that information on flights is available. But that is just information.

Actually hacking an aircraft systems, I don't really know what this guy is getting at. ACARS is a character based protocol, it just sends and receives text documents, not commands, just messages. Suggesting otherwise is like saying you can automatically make my phone dial a number by sending me an SMS. Not physically possible.

Fake ADSB targets is possibly a concern, as I think it is just data. I'm not sure, but I don't believe TCAS can be fooled as the range and bearing is internally computed by the interrogating aircraft, therefore only the altitude can be spoofed and the spoofer would need to be overflown by the aircraft to fool the aircraft into an RA.

[areobat]

Suggesting otherwise is like saying you can automatically make my phone dial a number by sending me an SMS. Not physically possible.It is indeed, totally possible! The SMS protocol was adapted so that people could send point to point text messages, but was originally designed into cell phones as a control protocol, a function it still also serves today. Most people don't know that things like your voice mail message indicator status or caller ID are carried as control messages via the same SMS protocol as text messages. They are just processed by the phone so you don't actually see them. Flaws in cell phone firmware have led to some exploits in the past, most notably, the iPhone: How To Hijack 'Every iPhone In The World' - Forbes.com (http://www.forbes.com/2009/07/28/hackers-iphone-apple-technology-security-hackers.html) These attacks were carried out by sending maliciously formatted SMS messages which the phone failed to reject (Apple was a bit of Newbie in the phone world at the time). It's the same situation here.
(http://www.forbes.com/2009/07/28/hackers-iphone-apple-technology-security-hackers.html)

[Sciolistes]

I wondered if that would come back an bite me :ouch:

After a bit of digging, this iPhone hack is not what is seems. It is basically a code injection exploit and requires the user to install an app. The security issue was that Apple allowed the app into the App Store without noticing the app's ability to receive and execute code that could possibly take control of your phone. The main stream news articles seem to be suggesting that it is possible to just send an SMS in the standard way, which is not the case.

Likewise, the reporting of this issue. This code injection isn't physically possible with ACARS and certainly is not the method talked about in that presentation anyway. That bloke is suggesting that you can generate false alerts, steer the aircraft and even turn it into a lawn dart with ACARS as it is, unmodified and using off the shelf gear. It isn't clear exactly how he demonstrated the vulnerabilities. Whatever, suggesting that he can remotely control the aircraft with ACARS or ADS-B is just looney tunes.

[Ian W]

If you look at the pdf presentation he is saying that there are multiple ways to access ACARS on an aircraft if you know its address, ARINC and SITA make this a selling point. So getting ACARS messages up to the aircraft is simple.

He then uses standard hacking techniques like malformed messages, for esample an ACARS message that should have a character count instead provides a negative number or a ginormous number, he can do this because he is not trying to send ACARS messages he is trying to break the receiving software and he is not using an ACARS friendly transmission system. The computer that is running the ACARS software is _also_ the one in which a whole pile of other things run including the FMC, display processing, MCDU etc etc. So if he can make it run some exploit code by sending it a broken message that then allows him to upload some more code running at high authority, he has broken into the computer that is running around "80 - 100" of the major control applications of the aircraft.

Its all on the pdf slides.

[PJ2]

Re Forbes' article, "How to Hijack 'Every iPhone iIn The World' ", here is Forbes' take on the present issue under discussion: Researcher Says He's Found Hackable Flaws In Airplanes' Navigation Systems (Update: The FAA Disagrees) - Forbes (http://www.forbes.com/sites/andygreenberg/2013/04/10/researcher-says-hes-found-hackable-flaws-in-airplanes-navigation-systems/)

The claim has been made that the author of this presentation could send radio signals to aircraft such that aircraft so hacked could be commanded to change direction, altitude and speed.

So far, no one has even outlined the steps and process let alone detailed the unbroken chain of technical events which would lead to an Android phone taking control of an aircraft beyond the crew's awareness or ability to counter the hack.

For the reasons I have posted above and in subsequent posts I suggest that the challenges are almost insurmountable when it comes to actually manipulating the flight controls as claimed by Mr. Teso.

That ACARS, ADS and CPDLC are potentially hackable is not in dispute. It is the extent of the threat that requires delineation, and I propose that such threats do not encompass actual control of the aircraft.

Hacking instrument displays such as Primary Flight Displays and Nav Data Displays with examples such as TCAS & GPWS indications still require assessment, resolution and action by crew members, and are not automatic responses by the autoflight systems. The implementation of providing uploaded data to make such a system "think" there is either an intruder (TCAS) or a legitimate EGPWS warning, is a herculian undertaking which would yield very little cockpit effect and zero aircraft effect. The "return" on the "investment" required just isn't there.

Route changes require manual executions using the FMS keyboard interface; no autoflight system changes altitude without manual input by the flight crew; speed changes are an autothrust function but inputs are reasonableness-checked by the FMS.

PJ2

[noughtsnones]

There's a risk that the following quotations were reported in (InformationWeek | Business Technology News, Reviews and Blogs (http://www.informationweek.co.uk) and Information for the World's Business Leaders - Forbes.com (http://www.forbes.com)) incorrectly or may become superseded, the overall message though is quite clear; Honeywell, Rockwell-Collins, EAS and FAA aren't presently worried.

Honeywell spokesman Scott Sayres via phone
“If we talk very generically -- not just about Honeywell software -- PC FMS software is normally available as an online pilot training aid”
“In other words, what Teso did was hack a PC-based training version of FMS that's used to simulate the flight environment, not the actual certified flight software installed on an aircraft.”

Rockwell Collins
“Today’s certified avionics systems are designed and built with high levels of redundancy and security. The research by Hugo Teso involves testing with virtual aircraft in a lab environment, which is not analogous to certified aircraft and systems operating in regulated airspace.”

EASA spokesman Jeremie Teahan via email
“This presentation was based on a PC training simulator and did not reveal potential vulnerabilities on actual flying systems"
“There are major differences between PC-based training FMS software and embedded FMS software. In particular, the FMS simulation software does not have the same overwriting protection and redundancies that is included in the certified flight software”
“For more than 30 years now, the development of certifiable embedded software has been following strict guidance and best practices that include in particular robustness that is not present on ground-based simulation software”

FAA
“The FAA is aware that a German information technology consultant has alleged he has detected a security issue with the Honeywell NZ-2000 Flight Management System (FMS) using only a desktop computer. The FAA has determined that the hacking technique described during a recent computer security conference does not pose a flight safety concern because it does not work on certified flight hardware. The described technique cannot engage or control the aircraft’s autopilot system using the FMS or prevent a pilot from overriding the autopilot. Therefore, a hacker cannot obtain “full control of an aircraft” as the technology consultant has claimed.”

In my experience, simulations are the basis of extremely powerful techniques towards understanding the normal (expected) and emergent behaviour of any complex system, but it is usual to increase the throughput of test data by removing something. Once a cut-down simulation of a system has been produced, there is the need for extreme care in the usage of test results, as they can produce misleading positive and negative views of the real thing.

IMO PJ2, in particular, has correctly highlighted the irresponsibility of the presentation and subsequent re-broadcast of the work. In other fields, we know that, such presentation would not occur without peer review. It's actually a great shame that further output from the individual and their organisation may be devalued to some extent, as a consequence of this publicity.

I'm happy to fly alongside an Android and I'm happy to participate in a simulation, provided that it stays in the laboratory.

00, 01, 10 n 11

[Ian W]

PJ2
Route changes require manual executions using the FMS keyboard interface; no autoflight system changes altitude without manual input by the flight crew; speed changes are an autothrust function but inputs are reasonableness-checked by the FMS.

If I have exploit code inside the Common Core System, then I put the characters I want into the FMS keyboard buffer storage area in the CCS followed by a return and it executes just as if the crew had entered it. Nothing would appear on the CDU. The slide he shows also indicates that the display outputs come via the CCS - so the displays could be made to show something entirely different to what the aircraft is actually doing. A hacker could reallocate all the crew accessible keys in the translate tables so that the crew would be unable to use the CDU or perhaps even on/off switches if they are actually 'software configured'.

[Grenville Fortescue]

Please forgive my ignorance but I thought aviation systems were among the most protected If not the most protected) on the planet!

Don't national aviation authorities insist on an aircraft's software systems impenetrable when they certify a new aircraft and then require it to continue being impenetrable?

[PJ2]

Ian W, thanks for a detailed response. I can appreciate the potential vulnerabilities a bit more clearly. We'll let this "bake" for a while and see what next week brings. - PJ2

[Ian W]

Please forgive my ignorance but I thought aviation systems were among the most protected If not the most protected) on the planet!

Don't national aviation authorities insist on an aircraft's software systems impenetrable when they certify a new aircraft and then require it to continue being impenetrable?

They run a whole battery [cough] of certification tests. The problem is building the test scripts and if nobody thought something was possible then - their will be no test for it. This takes us into the realm of positive and negative testing. Positive testing is making sure that the system does everything it is meant to. This is pretty tedious stuff - go through the functional requirement and check everything works as advertised be clever with values on the line above and below etc.

Negative testing is everything else. That is a LOT and very expensive to test. So someone has to scope the testing. Obviously, nobody thought that people would be trying to 'get into' the system over the comms links. So nobody specified any defensive code or testing of defensive code so none was written.

Many systems end up fortified in an area where people are sure things could be mishandled - say flight crew mistypes. But no cross checking on ACARS inputs or perhaps SATCOM communications. When these things were developed back in the 70's they were very esoteric and hacking was something you wore a jacket for. Now these links look really primitive and simple to break into. Worse, the hardware and software architecture inside the aircraft seems to have been built for cost and weight saving and not security. Like other things recently we may see the equivalent of armored boxes appear in software. But don't expect much to be publicized.

[FlightPathOBN]

We were doing flight vals with ADSB IN, working with self regulation of aircraft.

There were many unintended consequences.

[PJ2]

Interesting....TESO - Wikipedia, the free encyclopedia (http://en.wikipedia.org/wiki/TESO)

[Vortex what...ouch!]

With the right equipment it is possible to take control of any electronic device, I won't tell you how for obvious reasons. Just because it it is in a jet doesn't make it immune. This is nothing new. And I don't expect criminals to launch a series of hi-jackings any time soon. You guys are intelligent and could probably figure out how to do it, but at the end of the day thats why two of you are sat up front and can turn off the auto pilot and fly the aircraft. It could happen but not if real people are the fail safe. :ok:

[Vortex what...ouch!]

Looks more like a group that would hack bitcoins or Justin Bieber e-mails.

Don't underestimate the intelligence, or bloody mindedness of some of the kids of today.

With the correct know how, it is not much more difficult than programing your TV. :mad:

[woodja51]

Apart from the intellectual value in taking control of an aircraft , if indeed it was possible in theory, from a smart phone, if any hijackers were interested in actually accomplishing an end result of physical control, just go to the link below for a far more reliable method.

I see several pages of posts on the theoretical aspects of ACARS control etc but not much with respect to this below,

See if this is a more practical and possible eventuality.

WJA

http://youtube/mlmzvF2qkDY

[Vortex what...ouch!]

01001001 00100000 01100100 01101111 01101110 00100111 01110100 00100000 01110101 01101110 01100100 01100101 01110010 01100101 01110011 01110100 01101001 01101101 01100001 01110100 01100101 00100000 01100001 01101110 01111001 01100010 01101111 01100100 01111001 00101110 00100000 01001001 00100000 01101000 01100001 01100100 00100000 01110100 01110111 01101111 00100000 01101011 01101001 01100100 01110011 00100000 01101111 01100110 00100000 01101101 01111001 00100000 01101111 01110111 01101110 00101110

Kids not with standing, this is not rocket science, it is easily done. But well done :D

[Vortex what...ouch!]

WJA

http://youtube/mlmzvF2qkDY

That link is not working mate. :confused:

[737Jock]

010101000110100001100101011100100110010100100000011000010111 001001100101001000000110111101101110011011000111100100100000 001100010011000000100000011101000111100101110000011001010111 001100100000011011110110011000100000011100000110010101101111 011100000110110001100101001000000110100101101110001000000111 010001101000011001010010000001110111011011110111001001101100 011001000011101000100000011101000110100001101111011100110110 010100100000011101110110100001101111001000000111010101101110 011001000110010101110010011100110111010001100001011011100110 010000100000011000100110100101101110011000010111001001111001 001000000110000101101110011001000010000001110100011010000110 111101110011011001010010000001110111011010000110111100100000 011001000110111101101110001001110111010000101110000011010000 101001101000011101000111010001110000001110100010111100101111 011101110111011101110111001011100111001001101111011101010110 001001100001011010010111100001101001011011100111010001100101 011100100110000101100011011101000110100101110110011001010010 111001100011011011110110110100101111010100000110110001100001 011110010100011101110010011011110111010101101110011001000010 111101000010011010010110111001100001011100100111100101011111 010000110110111101101110011101100110010101110010011100110110 100101101111011011100010111101000010011010010110111001100001 011100100111100101011111010101000110111101011111010101000110 0101011110000111010000101110011000010111001101110000

There are only 10 types of people in the world: those who understand binary and those who don't.
Binary to Text (ASCII) Conversion (http://www.roubaixinteractive.com/PlayGround/Binary_Conversion/Binary_To_Text.asp)

Not as impressive as it seems....

[yssy.ymel]

There is an interesting tidbit of information that does make for interesting reading:

"In addition to detecting events on the aircraft and sending messages automatically to the ground, initial systems were expanded to support new interfaces with other on-board avionics. During the late 1980s and early 1990s, a datalink interface between the ACARS MUs and Flight Management Systems (FMS) was introduced. This interface enabled flight plans and weather information to be sent from the ground to the ACARS MU, which would then be forwarded to the FMS. This feature gave the airline the capability to update FMSs while in flight, and allowed the flight crew to evaluate new weather conditions, or alternative flight plans."

ARINC 619 details the protocols that are used to send data to other avionics packs on the plane, however that does not necessarily mean that a message could be sent to EXECUTE a command on the FMC.

What this means is the assertions that ACARS does not in any way interface with other avionics on board (which is what I always believed to be true) is not the case.

Where there is a datalink or common bus between two systems, there is a vector...

Food for thought.

[JRBarrett]

The computer that is running the ACARS software is _also_ the one in which a whole pile of other things run including the FMC, display processing, MCDU etc etc. So if he can make it run some exploit code by sending it a broken message that then allows him to upload some more code running at high authority, he has broken into the computer that is running around "80 - 100" of the major control applications of the aircraft.
.

Uh... no. I am an avionics maintenance engineer of almost 40 years experience and I can assure you that the scenario you describe above is absolutely NOT how the integrated avionics system on a modern aircraft is implemented. There is no "common core" computer on which all of these various functions run. Each of the various sub systems that make up the complete avionics suite run on stand-alone, purpose-built discrete "black boxes". Until the last decade or so, the individual components of a complete aircraft avionics system literally were contained in rack-mounted boxes. In more modern systems, like the Rockwell-Collins Proline 21, the "boxes" have been replaced by plug-in circuit boards with edge-mount connectors, but the overall design of having functionality performed by discrete and specialized sub-systems remains the same.

ACARS is processed by a purpose-built, stand-alone AFIS computer. That is all it does. It is made to do one thing, and one thing only.

The FMS functionality resides on a purpose-built, stand-alone discrete navigation computer. It may do many things, but all of its funtionality resides within that computer, and though it may communicate with other onboard systems through a variety of data bus protocols, its internal workings are effectively walled off from other devices and systems in the aircraft.

Likewise the displays are driven by symbol generators. These again, are purpose-built, stand-alone, discrete units which are designed to do one specific thing - generate the grapics which appear on the cockpit displays.

The same holds true for the Flight Guidance Computer, the Performance Computer etc etc.

The "hacking" presentation made by Mr. Teso is based on PC-based emulations of various aircraft systems used for flight crew training, and though those emulations may exactly duplicate the look, feel and funtionality of the actual aircraft systems, their internal workings are COMPLETELY different.

The actual "black boxes" in a real aircraft contain embedded CPUs, data processors and software running on highly proprietary real-time operating systems which bear no realtionship in ANY way to the OS functions on a PC. For a hacker to use buffer overruns or the like to seize control of the processes of one of these units would require knowlege of the internal architecture of the hardware and software in the "black box" that no hacker (no matter how talented) could possibly have. If such knowlege IS "out there" in the hacker community, it would mean that manufacturers like Honeywell, Rockwell-Collins, Thales, L3 et al have all been victims of industrial espionage on a massive scale - which I very much doubt. Having worked closely with all of these manufacturers over the last 3+ decades, I can say that they all guard their trade secrets with bulldog tenacity.

That said, I certainly agree that open protocols like ACARS, ADS-B and the like are undoubtedly vulnerable. One scenario that comes to mind would be if a hacker gained access to an airline dispatch communications system - he could then cause a falsified flight plan routing to be uplinked to an aircraft when its crew requested the FP through ACARS. That could certainly have serious real-world consequences.... likewise if an ACARS exploit allowed a hacker to uplink completey false aircraft load manifest data to a crew before departure, and crew made takeoff performance calculations using that false data, again, the outcome could be very serious.

But these scenarios mainly highlight vulnerabilities in the external data support infrastructure of the airline industry... not glaring security holes within the various components that make up an aircraft's onboard avionics suite. While Mr. Teso's presentation makes some valid points, most of his claims regarding the supposed ease with which a hacker could seize control of an aircraft's systems with a smartphone are a complete load of codswallop.

[woodja51]

Try inserting it into a you tube search function ...I think that works ..

[Intruder]

That said, I certainly agree that open protocols like ACARS, ADS-B and the like are undoubtedly vulnerable. One scenario that comes to mind would be if a hacker gained access to an airline dispatch communications system - he could then cause a falsified flight plan routing to be uplinked to an aircraft when its crew requested the FP through ACARS. That could certainly have serious real-world consequences.... likewise if an ACARS exploit allowed a hacker to uplink completey false aircraft load manifest data to a crew before departure, and crew made takeoff performance calculations using that false data, again, the outcome could be very serious.
While a false flight plan or load data might be uploaded, it is unlikely that a significantly different version would bypass all the manual checks & balances in the cockpit.

As someone else pointed out, I suspect it is relatively easy to uplink something from an invalid source, but the chance that it could actually do anything malicious is remote at best.

[FREDAcheck]

A few points about security in general (about which I know something), not specifically about aviation:


Security systems get broken even when the designers and other experts swear it just physically can't happen. I'm not suggesting other posters are wrong to say aircraft control systems can't be hacked, I'm just saying sometimes "impossible" hacks happen.
As Bruce Schneier put it (he's one of the leading industry experts on security): "Any security expert can devise a security system so secure that he or she can't conceive of any way of breaking it". But other people will.
For this reason, the best security systems are not secret: the details of architecture, design and procedures are open and subject to scrutiny. That way it's more likely that the good guys find the problems before the bad guys do. Because, assuredly the bad guys WILL find the problems, and it's much worse if they find them before you do. The security should rely on secrecy of keys and passwords (which can be changed), not on secrecy of design (which can't easily be changed).
This is one of consequences of the Digital Millenium Copyright Act (DMCA). It criminalises attempting to hack or even investigate commercial cryptography systems. Of course, it does nothing to stop the bad guys (it doesn't even slow them down), but makes it much less likely that security vulnerabilities will be found by anyone else (and fixed).
A number of security systems in widespread use today were hacked very quickly, and arguably with more public scrutiny early on they might have been enhanced and corrected before launch. Two examples are the CSS encryption system used on DVDs and the Mifare contactless card used in numerous public transport systems (such as the London Oyster card).

As I understand it, most avionic systems and interfaces are open and public. From a security point of view, that's good, not bad. If people are worrying publicly about ACARS and ADS-B, it's much more likely any problems get found and fixed, e.g. by manual checks and balances in the cockpit.

[Sciolistes]

IanW,
If I have exploit code inside the Common Core System, then I put the characters I want into the FMS keyboard buffer storage area in the CCS followed by a return and it executes just as if the crew had entered it.
But surely these systems are fundamentally embedded and the requirements static. By that I mean the instruction pointers do not reference working memory and there is no need for dynamic memory allocation.

In addition, I would have thought the operating system at the hardware level would not permit any code to be executed that has not been verified or validated through some kind of checksum to guard against memory corruption (for whatever reason). Never mind the basic issue of illegal memory address access.

Basic input validation? Just assuming by some staggering improbability that somebody didn't think of this during the design, implementation and test stages of development, whatever clever stuff one can think of to screw the receiving software over, getting foreign instructions to execute just is not going to be possible by any measure, never mind ACARS access.

Even disregarding all that, the whole fundamental basis for Teso's assertions, as he states in the slide pack, is the ability to audit the code to look for vulnerabilities, and I can't see how he or anyone else without a role directly related to development of the relevant elements of the source code, would ever get access to the source.

Like the Apple hack (it wasn't even a hack) mentioned earlier, just flimflam. I find it incredibly frustrating how the media choose to frame these stories.

[roulishollandais]

AF447 ACARS report shows the connexion between ACARS and flight systems. AF ground knew in real time what was happening. Should the right person have been before the screen, they had three minutes to call the crew : "Hey, Guys, you have an UAS, Do Nothing, Oh you are already stalled ! : PUSH ! "

Using both binary and human procedures is the key to better safety (IBM always taught that, Hugo lecture is a confirmation).;)

[Ian W]

Sciolistes (http://www.pprune.org/members/271494-sciolistes)

You are making a series of assumptions of the design of the CCS. Unfortunately, from what TESO said the designers made the assumption that no bad guys would have access. So all the normal protections that the average paranoid designer would put in may not have been put in. Remember every single line of code put into a system being certified is a huge cost in testing so why put hacker defensive code into a system or more complex design 'when it is unnecessary"?

"In addition, I would have thought the operating system at the hardware level would not permit any code to be executed that has not been verified or validated through some kind of checksum to guard against memory corruption (for whatever reason). Never mind the basic issue of illegal memory address access."

The CCS would appear to be a single computer that allows the programs to play in the one big sand-box. This is not a dedicated firmware system on a VME board.

"Even disregarding all that, the whole fundamental basis for Teso's assertions, as he states in the slide pack, is the ability to audit the code to look for vulnerabilities, and I can't see how he or anyone else without a role directly related to development of the relevant elements of the source code, would ever get access to the source."

He actually bought the systems on Ebay. The systems he bought included the FMS, simulation systems and simulators of ACARS message generators. In other words all the bits he needed were available for pennies on line. The code was the same as the operational code. At one stage I used to work on system maintenance starting at the machine code level and work up through assembler to the high(er) level code. So you have all the bits all you need is the patience to see what ACARS hack works. Then repeat that on another FMS type and so on see if you can find a common exploit. If I can not only get in but get in as a 'super' user or maintenance level then I can start convincing the software in the aircraft that is really software running in a simulator so take these inputs not those. Or put out these ADS values instead.

The best way out as I said earlier is to have some gatekeeper firmware watching over the comms links and bouncing and reporting any broken messages before they get to the normal too-trusting avionics. My worry would now be that someone before Tesa could have been in and 'done a malicious update' of the FMS code. And that malicious code is now just waiting for a specific legal message or a particular date - in other words a standard trojan timebomb. So perhaps airlines should think about doing a complete clean software reload just in case I don't know what the normal maintenance cycle is for CCS software. Now the exploit idea is publicized there will be those trying their hand at it and there are several things that could be easily done that could cause chaos. I would write more but I don't want to provide hints to the 'black hats'

[Grenville Fortescue]

Ian W - thank you for your response.

I am now more concerned than ever! :sad:

[Sciolistes]

Ian W,
The CCS would appear to be a single computer that allows the programs to play in the one big sand-box. This is not a dedicated firmware system on a VME board.
Wow, that would surprise me, I thought CCS was a low level communications architecture of software and hardware components (fibre, busses, routers and endpoint hardware) implementing the base network protocols and higher level transport functions. I didn't think CCS was a sandbox system and certainly not a single computer.

[PJ2]

Sciolistes;

Not sure as I have no experience in this but it might be worth looking at ARINC 653 (http://en.wikipedia.org/wiki/ARINC_653) for some notions of required robustness and 'security'.

The more I consider all this the more I believe that present aircraft are, by virtue of a lot of what has been said particularly in the discussions between JRBarrett and Ian W, "safe" from hacking, (you can't "get" to the flight controls through ACARS or an FMS). But I remain agnostic about developing architectures, for example the mentioned-CCS in the B787 design.

In an early post I used the term "corpus callosum" more to conjure a simplistic image of "everything together, cross-pollinating/cross-computing/cross-informing"...a very rough metaphor which will likely send software engineers into fits of eyebrow-raising, as a way of thinking about "centralized computing". I'm trying to think of these systems as they have evolved; the B787 is substantially different than the Airbus architecture I believe and it is future developments that may need closer examination. I can say one thing...after having spent some time googling "CCS" and variously-related topics and examining manufacturers' comments, there is nothing stated in the online "brochures" about security concerning the current themes - it's just all positive, sales-related talk and so there is no information regarding how these systems have been protected. To be fair, many of these sites were dealing with the "B7E7", so we know that hacking (in 2002 - 2005) was not a serious threat or primary threat.

That said, the threats are more serious for developing systems. I raised the notion earlier about the importance of peer-reviewed papers on these topics, this one in particular and, you know, there are almost none to be found.

I'm sure in unsung corners of this burgeoning field of the software engineering of historical "cartesian controls" (cables-and-pulleys to bits-and-bytes, and as a pilot I say this with admiration and acceptance, not scepticism!), there exists such studies and research but as we have seen in other areas in which technologies must function reliably without single-point-failure in high-risk applications, the robust risk analyses, (thinking possibilistically . . . (http://leeclarke.com/docs/clarke%20thinking%20possibilistically%20-%20Significance.pdf)) we'd expect are not widely apparent. Why?

PJ2

[FlightPathOBN]

PJ2,

One doesnt need to get directly to the FCC. Besides, it is always helpful to know where the bus switches are to kill the autopilot :mad:

http://operationsbasednavigation.com/wordpress/wp-content/uploads/2013/04/TM-1-1510-224-10_135_1-e1365878588109.jpg

Bet carnivore is online.

[PJ2]

F.OBN, I'm familiar with these and other, similiar schematics, (eg., Airbus). I see standard, independent peripherals in a typical flight control system with EFIS, and with the FCC in the center. You can't hack this system because there is no "receiver", so to speak, no entry point.

There are no 'bus switches' to 'kill' the autopilot in any airplane I've ever flown, but there are standard autopilot disconnect switches/buttons etc. And if the airplane isn't doing what the PF wants then the crew deals with it as they would any abnormal -take control, ensure aircraft stability, (heading, altitude, and if climbing or descending then level off to troubleshoot), communicate the problem first to one another then to ATC then assess severity, determine and execute a response, secure the airplane, decide next action, advise ATC and request an appropriate ATC clearance.

From what I've seen so far, there is a great deal about transport aircraft in this present thread which is either not being expressed (it ain't a secret) or just isn't understood. It's not that these things are too complicated, it's that there is no way in because the parts are independent of one another, require crew input to function, or don't exist. My point above is to call for some thought on how the B787 may respond because I think it is a different architecture. Until some careful thought is put into this question, no one can make assured pronouncements on that system's security either.

PJ2

[FlightPathOBN]

PJ,

The autopilot circuit breaker(s).

It doesnt have to be about brute force taking control of the aircraft, but getting the aircraft go where you want it to.

Not to dance around the subject, but there are many receiver points in the system, there may only be certain direct ones, but many indirect ones.

Self Separation (http://en.wikipedia.org/wiki/Self-separation)

[JRBarrett]

PJ2,

One doesnt need to get directly to the FCC. Besides, it is always helpful to know where the bus switches are to kill the autopilot :mad:

Bet carnivore is online.

This is an early 1980s -vintage Honeywell Primus system... and interestingly (in light of the thread topic) one which doesn't even HAVE an FMS. No IRU's either - it's using old school mechanical C14 and VG14 remote directional and vertical gyros - which are not even digital - they use analog Sine/Cosine AC signals to provide heading and attitude reference to the symbol generators.

There is NO point of entry in this system for outside control - none whatsoever.

[FlightPathOBN]

JR,

What are you talking about? If it is the diagram, well, that is not really relevant other than to show the myriad of systems which provide data.

Did you read the self separation trials?

Answer this, if there are no points of entry into the system, how does one get the aircraft to self-regulate while on autopilot?

[PJ2]

F.OBN;

The Airbus doesn't have "Autopilot circuit breakers". It has no CBs in the cockpit, (the A320 has a few on the aft overhead, but none for the "autopilot".

"Self-separation" (as described in the link provided) does not provide a pathway to any systems which will operate the flight controls. The question asked, (how does one get the aircraft to self-regulate while on autopilot?), is moot; it doesn't apply.

As Mr. Teso himself in his presentation shows, TCAS responses are not done by autoflight systems.

To make this point abundantly clear, no transport aircraft autoflight sytem extant will alter course, altitude or speed in an auto-programmed, autopilot response to TCAS, GPWS or ADS signals. For the record, the ACARS case has been exhausted.

As shown in his presentation, (at least this part is true), the autopilot is disconnected and any manoeuvers, (TCAS, GPWS, etc) are manually flown.

The crew makes the determination of response and action using standard operating procedures.

There are no "ways in", in any of the descriptions you have thus far provided.

PJ2

[Ian W]

As shown in his presentation, (at least this part is true), the autopilot is disconnected and any manoeuvers, (TCAS, GPWS, etc) are manually flown.

So you receive a TCAS RA

Absolutely it is you on the controls

You cannot see the other aircraft - you are trusting the software has not been hacked and the 'CLIMB CLIMB' has not been swapped with a 'DESCEND DESCEND'

Or perhaps the EGPWS alert is routed to the 'bit bucket' so you hear nothing despite the terrain that you are close to because the FMC has carried out a completely invalid QFF correction.

This exploit should not be underestimated.

[PJ2]

Ian W;

As emphasized I'm not a software or any kind of engineer but I flew these aircraft for over three decades, so I wade into such discussions with trepidation with what little I comprehend regarding specifics in terms of software, inter-relatedness, architectures and switching.

This ack'd, I doubt very much whether it is that simple or direct. In fact, I consult routinely with several AMMs and know that it isn't that direct. Neither is it conclusively impossible for two reasons: a) proving a negative is not conclusive and, b) even AMMs are limited to NTK.

Rather than go another round I will let this rest and see what others have to contribute and how this unfolds. Many thanks once again per your exchanges.

PJ2

[ph-ndr]

I have followed this topic for some days now and was hoping it would show up here. The one angle that seems to be lost on many IT bodies, and too many flying staff focusing on technical details, is this: it isn't all about what you can make the various systems do or not do.

The easiest interface to "use" is the angle of denying the people in 0A and 0B of trust in the system.

It will in all likelyhood turn out to be simpler to find ways of making the various components act in undefined, unexplicable and incoherent ways, rather than trying to make the system automate and perform certain task on their own.

Once you erode trust enough in the electronics of the airplane, then the conservative nature of the airline industry will kick in: head for a suitable airfield and figure out what's going on.

What you have here is the basic ingredients for DoS/DDoS attacks.

The one thing the industry in general wants to do is to retain trust in the safety provided (not actual security, that's a whole different discussion and done to death already).

-A

[Ian W]

People have to realize that this is already happening. see

GPS Jammers Threaten Air Traffic Navigation: Video - Bloomberg (http://www.bloomberg.com/video/88574724-gps-jammers-threaten-air-traffic-navigation.html)

http://www.gps.gov/multimedia/presentations/2012/03/WSTS/merrill.pdf

GPS jammers and spoofers threaten infrastructure, say researchers | Ars Technica (http://arstechnica.com/business/2012/02/uk-research-measures-growing-gps-jamming-threat/)

These jammers have a range of 5 - 10 miles dependent on manufacture and power - that is a hemisphere of 5 - 10 miles so above the jammer at FL410 an aircraft ADS-B may be reporting a totally incorrect position based on jammed GPS. (See figure 8 of this paper looking at the effect on ships and the difference between eLORAN position and GPS position when there is jamming
http://www.navnin.nl/NIN/Downloads/GLAs%20-%20GPS%20Jamming%20and%20the%20Impact%20on%20Maritime%20Navi gation.pdf )

Given jamming like that the FMC (and crew) thinking it is well off track will try to navigate back to 'where it should be' and in reality fly the aircraft well off track all the while broadcasting its incorrect position on ADS. Imagine the effect in a high traffic area with all the aircraft giving false positions.

It was the managed version of this jamming that was demonstrated by some Universities in 'taking control' of an unmanned aircraft and possibly the way the Iranians brought down a reconnaissance UA.

This is an area that the proponents of moving everything to GNSS based systems need to analyze, and then they will need to mitigate all the potential risks before closing the radars down and removing all the NDB/VORs.

The only backup system with sufficient coverage and more security is eLORAN, and there is a battle over whether to fund it. .

[FlightPathOBN]

Ian,

GPS jamming is only marginally effective, and is only effective in blocking the signal, not manipulating the signal. It take a great deal of power to block the signal in an area, and even greater amount to block it through the flightpath for any distance. I know of several areas, where the military actively jams large areas, but again, this take a great deal of power.

On really interesting 'unintended consequence' was formation flying.

Here is possibly a different approach to the issue that may help in the understanding.

Assume that you have permission to do this.

[Ian W]

GPS jamming is only marginally effective, and is only effective in blocking the signal, not manipulating the signal. It take a great deal of power to block the signal in an area, and even greater amount to block it through the flightpath for any distance. I know of several areas, where the military actively jams large areas, but again, this take a great deal of power.

I have given you the references.

[FlightPathOBN]

Jamming doesnt make it appear in a different location, it just blocks the signal. The aircraft IRU would keep the aircraft on track, with a drift rate. Drift rates are measured in nm/hour.

Aircraft traveling in certain areas of the world frequently lose SAT GPS coverage, or dont have enough SAT's available for horizontal and vertical location...there is the RAIM prediction for this.

On an aircraft, there are usually at least 3 GPS ant, located as far away from each other as possible. If you had a jammer on board the ac, it would still be difficult to block all of the antennae, and even if you did, the IRU would take over and provide aircraft position.

[FullWings]

I think Ian W is being quite conservative in his scenarios.

There is a lot of "it couldn't happen" and "the manufacturer says it's impossible". Historically, many of these kind of statements have been made after a successful hack, though some sense of affront but also as a smokescreen. I bet there is some serious code reviewing going on behind the scenes at Honeywell et al. Given the option of a) running pre-existing code on a simulator or b) spending lots of money to write new code / make new hardware with identical functionality, I wonder what they did? :rolleyes:

I think it is naive at best to assume that because a system was designed for a specific purpose it can't be coerced into doing other things. As pointed out previously in this thread, it's difficult enough (some would say impossible, given the time/energy requirements for computation with a complex system) to make sure that things do what they should let alone what they shouldn't.

Considering the hardware alone, do FMS manufacturers make their own chips or do they integrate other people's designs? I would think the latter. There are lots of hacks, undocumented features and failure modes in common units even when the silicon comes from well-respected designers/manufacturers.

Saying "these devices are only connected by communications links" is pretty hubristic. The Internet is only a communication link and look what happens if you plug an unprotected computer into it for a few seconds.

I was witness to a double FMC failure in a 777 brought on by nothing more than a specific bit of wind/temperature data (which could have come from the uplink). The A/P, A/T, LNAV, VNAV, performance data and the navigation database dropped out one after the other and left us with a with a solitary white triangle in the middle of a blank screen. We were somewhat concerned as we were just heading out across the Atlantic... Whether this could have been used as a vector for an exploit I have no idea but it does show that there was a QA hole in there and it is exceedingly unlikely that it was the only one. :ooh:

Jamming doesnt make it appear in a different location, it just blocks the signal. The aircraft IRU would keep the aircraft on track, with a drift rate. Drift rates are measured in nm/hour.
GPS "spoofing" does exactly the above. Considering the relative distances between the two transmitters and the receiver, it doesn't need that much power from the rogue transmitter to overwhelm the genuine signal at the aircraft end. Granted, most modern nav kit uses blended positions from GPS, IRS, DME, VOR, etc. so would pick up on a gross error or at least show you that something untoward was happening.

I flew into Seoul yesterday and the brief had a note on it that NK had been doing some GPS spoofing of their own and to check the aircraft position using raw data. Given that the approach plate has "DO NOT ENTER THIS AIRSPACE AS YOU WILL BE FIRED UPON WITHOUT WARNING" printed on it, I thought this advice well worth heeding!

[FlightPathOBN]

FW,

That is exactly the airspace I was referencing. Designed the RNP corridors with airspace/direction sep through that area...

As I stated at the beginning of this thread, this has been done sucessfully on a few variants, not to hack, but in the name of automated ATC and self-regulation of aircraft.