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.

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

There were many unintended consequences.

Interesting....TESO - Wikipedia, the free encyclopedia

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:

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:

Why bother?
 

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

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

That link is not working mate. :confused:

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

Not as impressive as it seems....

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.

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.

Link
 

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

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.

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.

IanW,
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.

Binary and Human marriage is the key to increase safety
 

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).;)

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'

Ian W - thank you for your response.

I am now more concerned than ever! :sad:

Ian W,
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.

Sciolistes;

Not sure as I have no experience in this but it might be worth looking at 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 . . .) we'd expect are not widely apparent. Why?

PJ2

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.