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...5878588109.jpg

Bet carnivore is online.

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

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

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.

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?

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

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.

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

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

People have to realize that this is already happening. see

GPS Jammers Threaten Air Traffic Navigation: Video - Bloomberg

http://www.gps.gov/multimedia/presen...TS/merrill.pdf

GPS jammers and spoofers threaten infrastructure, say researchers | Ars Technica

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/G...Navigation.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. .

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.

I have given you the references.

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.

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:

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!

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.