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