Boeing 787 In Flight Entertainment System Security fun | Hacker News Reader

Boeing 787 In Flight Entertainment System Security fun

btr.pm

173 pointsrbanffy142 comments

I wish people wouldn't do shit like this on live systems like this one. Even the port scan could have had bad consequences (especially since this person did -A). By all means explore the interesting JSON object that was downloaded and yeah I'd worry about installing random stuff on my machine.

I'm not talking about crashing the plane; I'm talking about crashing the IFE and me then having to sit through 10 hours of people who didn't bring a book.

Thank you for this comment. I for one would be pretty pissed if a "hacker" decided to crash my/or my kids entertainment on a long flight. There is definitely a need for this type of work, but doing so in a 50,000 lb brick floating a few miles above the ground isn't an atmosphere I am comfortable with, especially if I am present...

Oh, I agree. There's definitely a need for this type of thing. The work of white hats is essential.

If anything were to happen, it definitely shouldn't affect the avionics, not even remotely, or the plane would not have had a chance of certification. Data to the less secure IFE had better flow through a unidirectional network ("data diode"), and/or use a separate set of sensors.

Even if it brought down the server, it's still nothing that the flight attendants can't solve by "turning it off and back on". This kind of fault happens all the time.

More interesting to me is the level of isolation of the network. Could someone exploit my phone through the in-flight WiFi, for example?

Accidents happen. Commenter below referenced Swiss Air 111: https://en.m.wikipedia.org/wiki/Swissair_Flight_111

They cite inadequate safety standards and an overheating entertainment system.

It's easy to assume that government or the airlines wouldn't allow a faulty system to fly, but just like software it's those extreme edge cases that cause problems. Somehow I doubt hacking the entertainment system is comprehensively covered in the manufacturers safety check. It's probably a remote chance something bad would happen, but we can't say it's 0.

This keeps getting cited on this thread. The IFE didn't simply "overheat". It had faulty wiring. The coffee maker could just as easily have caused that accident.

Lots of things have faulty wiring, but they keep working as long as their power draw is under some limit. Drawing excess power is a common result of software going into an infinite loop, which is a possible outcome of security probes.

Half the bugs I notice in Chrome, I notice because my laptop fan starts running.

A CPU overheating is still completely different from the wiring or other components heating up. It is entirely monitored, can throttle itself or shut down through OOB controls.

It's more likely for your plane to be hit by a falling unicorn than you being able to burn something up just by the power of `while (1)`.

This genuinely made me laugh out loud.

Sure. Hair dryers draw excess power when you drop them in a bathtub. Ground-fault protection outlets are supposed to prevent that. If they don't, the outlet is faulty.

The origin of Murphy's Law was in a rocket sled project. This guy was strapped onto a rocket sled, fired down a track, and then subjected to strong braking forces. "If anything can go wrong, it will go wrong" didn't just mean "stuff happens". It meant, "you have to either make it impossible for it to go wrong, or you have to find a way that, even if it does go wrong, this guy doesn't die". You can't just ignore the problem as unlikely. It will happen sooner or later.

You don't get to say "lots of things have faulty wiring". Things that can kill you had better not have faulty wiring, or had better be able to survive it if they do.

"More than 21-percent of GFCI circuit breakers and 19-percent of GFCI Receptacles tested did not provide ground fault protection. The failure rate in areas of high-lightening strike was as high as 57 percent ... when a GFCI device fails, it continues to pass electric current but no longer protects the unsuspecting homeowner from ground fault conditions." (From http://www.experts123.com/a/the-national-electrical-code-gro...)

And read this before dropping your hair dryer in the bathtub: https://iaeimagazine.org/magazine/2010/01/16/the-illusion-of...

Yeah, but that's sort of the rub, isn't it? It's faulty wiring that won't, in practice, overheat unless you overload the server with (say) a port scan.

So yes, the aircraft is supposed to be robust against any trickery with the entertainment system. And indeed, it's 100% their fault for installing the wiring in a way that would overhead under load.

It's still pretty irresponsible to risk taking down the aircraft like that to check for a vulnerability!

If a port scan can overload a server, it could also be a bug in the JavaScript code that runs on the clients. Too many AJAX requests and the plane goes down? I sure hope not...

I agree that, in theory, at least the avionics shouldn't be accessible from the IFE. I am sure there is a rigorous protocol for making sure this is properly secured and certification for airworthiness. I think the parent comment was more making the point that we don't need a flight full of people scanning ports for fun and profit, and the consequences of doing so are unknown and could lead to things like no wifi or IFE on the flight you're on and hopefully not worse

This is obscurantism. Port-scanning a networked system, even aggressively, must be considered typical environmental hazards that any network-attached system must be able to weather (preferably with no degradation in service).

The point is not that the system is fine, the point is that the method used to identify the flaw is dangerous. This needs to be fixed but the ends do not justify the means.

> I am sure there is a rigorous protocol

The "rigorous protocol" is one-way hardware diodes. The telemetry simply cannot physically travel the other way.

Now, of course, there can always be mistakes. Certification is supposed to catch that, but of course, that isn't fool proof either.

> If anything were to happen, it definitely shouldn't affect the avionics, not even remotely, or the plane would not have had a chance of certification.

Is that based on expectation, hope, or knowledge?

In-flight entertainment would be categorized as DO-178B Level E software and DO-254 Level E hardware:

https://en.wikipedia.org/wiki/DO-178B#Software_level

https://en.wikipedia.org/wiki/DO-254

By definition, it should have no impact on "safety, aircraft operation, or crew workload".

Mistakes can happen, but this is what is aimed for.

> definitely shouldn't affect the avionics

No, and the flaw you're busy exploiting also definitely shouldn't be there.

(Yes, the IFE is probably airgapped. Probably.)

Since when are web servers DO-178 certified?

Wild guess: Roughly about the time they began being used in IFE systems?

Not at levels A-D, which are the ones where the faults "should not be there" (citing the parent comment).

At level E you only have to prove that there's no effects of faults on safety-critical systems, so it's more about the surrounding architecture than the software itself.

What flaw? He was merely querying a public http API and scanning for ports.

The only way to know that you won't crash a critical system is to try it. You're right you shouldn't be able to but that doesn't mean it can't be done. Doing this in flight is still dangerous.

500k lb, at the very least :)

Swissair flight 111 crashed because of a fire that started in in flight entertainment system. Although isolated it still caused a fire that caused the highest death toll for the MD11 which was considered a very safe aircraft.

https://en.m.wikipedia.org/wiki/Swissair_Flight_111

It crashed due to faulty wiring in the IFE, which started an electrical fire. It could just as easily have been the coffee maker.

Well, imagine a fire due to faulty wiring that is accidentally triggered by some hack. Maybe absurd but not impossible. Why mess with any in-flight system?

Why do you assume that it is more likely the hack causes a fire instead of preventing a fire? I mean, I would think that the most likely individual outcome of a hack would be shutdown of the system, which should reduce the likelyhood of weird things happening.

The MD-11 is considered a safe aircraft, because almost all airliners are very very safe. comparatively to the Airbus and Boeign equivalent, it is not viewed as a particularly safe aircraft, as it was derived from the DC-10 (which had a epically bad reputation). while a lot of the issues with the DC-10 were fixed, there longer length of the plane caused issue.s

Actually, it was not that safe. To reduce fuel consumption, Douglas used a quite small tail for an aircraft that size.

Consequently the MD-11 has to land at high speed which makes it prone to catastrophic bounced landing like the 2 Fedex crashes.

Also, it was not produced for very long (compared to other aircrafts from Boeing or Airbus) and the fleet was either retired or converted to freighters quickly by airlines.

Maybe he did it as the plane was coming in to land? When else do you think he might have access to such a system?

He did it during the cruise, according to the flight status JSON he got. Also, takeoff and landing are the most dangerous periods for air travel.

Out of curiosity, when else would you suggest they do this? Other than "not at all", of course, which is not going to happen.

During a pentest?

What about this write-up leads you to believe that a pentest ever has (or will (on purpose)) happened??

If there was a penetration test, do you think Boeing would publish unpatched vulnerabilities in their own product?

As someone who used to work in the IFE software field, I can assure you these systems are perfectly capable of crashing themselves in endless loops without any outside help from the likes of us, thank you very much. ;)

If your software can't handle nmap it has no business being on any network anywhere ever.

This mentality is where a lot of our current security problems come from, from IoT to critical infrastructure to ATMs, etc. Developers can't imagine someone would ever do anything nefarious on their "closed" network, so they don't bother doing more than cursory security. Then the internet shames anyone who tries to demonstrate how bad things really are.

That doesn't justify putting other people's lives at risk. Testing on a live system without permission is still irresponsible.

"lives at risk" is a bit of a stretch. They might take down the IFE and people might be bored, but they won't take the plane down. The telemetry data is read-only (the hardware is physically isolated and transmission one way -- systems that need write access are isolated from the ones that only need read access, and have to go through a slew of certification processes).

(I work on IFE and avionics)

Is this still true with 787? [1] indicates that it uses virtual links that are not physically separated.

[1] - https://en.m.wikipedia.org/wiki/ARINC_429

The protection lies between that bus and the TCP/IP stack of the IFE. Data can go one way, and several feet of certification documents are there to ensure that.

A stack of paper on the ground is of little comfort to me in the sky. If there is a physical (TCP/IP!) connection between two systems there is a potential for communication between them. No amount of certification will ever make that as secure as an air gap.

There are hardware diodes.

There is no physical way to write through those.

As parent said, communication on the avionics side happens on a specialized bus, to which the entertainment side has read access only, enforced either through hardware or through highly-certified software (Common Criteria EAL6 or even EAL7) on the secure side.

It's really quite useful. I changed my zsh prompt a while back to show me the status of the internet connection on board, remaining time, flight number and from where to where the plane is going.

https://twitter.com/mitsuhiko/status/867043286128656384

That's absolutely awesome.

Very cool. I saw that you handle Lufthansa as well, now.

Tiny nitpick:

In my understanding, ETA denotes a point in time, e.g. 22:50h, that is the estimated time at which you arrive. (Absolute)

If you want to specify a duration in this context, i.e. how much longer until arrival, e.g. 0:53h for another 53 minutes until arrival, you'd speak of the ETE (estimated time enroute). (Relative)

See (in German) e.g. https://de.wikipedia.org/wiki/Estimated_time_of_arrival

tl;dr: use "ete" instead of "eta"

There's a lot of posts mentioning that a scan shouldn't cause any trouble, however there's no way of knowing how the services are configured on the other end, or how they are set up to respond to certain packet types, or how the server will respond to certain data within those packets if said data does not conform to expected lengths etc. A lot of assumptions are made that non-conforming data will be ignored in a closed proprietary system, and that the system will handle all packets across all protocols gracefully. Anyone who says sending packets to a port running an unknown service (or implementation of said service) can't cause any issues with the service is throwing quite a wide net. Running a port scan or trying to interface with any of the systems on an aircraft while it's in flight without knowing how the systems operate or interact with each other is incredibly irresponsible, if not downright stupid.

I remember about 20 years ago, you could crash any Windows computer you had the IP address of by sending a particularly crafted package to a certain port. Oh, those were the days.

Port 139, maybe?

http://insecure.org/sploits/windows.OOB.DOS.html

Also, ping of death:

http://insecure.org/sploits/ping-o-death.html

Ah, SQL Slammer... Those were the days indeed! :-)

https://en.m.wikipedia.org/wiki/SQL_Slammer

I think you're reading that incorrectly. The way I have interpreted those posts (including my own) is to say that if nmap can crash your software you should a) know that and b) not release it.

In 2017, you absolutely have a reasonable expectation that network systems are safe to nmap. You might be wrong, but that's a completely reasonable assumption.

I agree with you, that the expectation is reasonable, however in the real world this is not always the case. I totally agree that the systems should be tested for this, and if not they shouldn't be in a live environment.

However I draw the line when an unauthorized actor accesses a live system to prove a point, rather than going through proper procedures with absolutely no knowledge of the potential outcomes of his or her actions. This isn't white hat by any stretch of the imagination, and is incredibly reckless.

Irresponsible and stupid perhaps, but a lot of exaggeration here too.

I'd say the absolute worst case scenario is that the IFE crashes and must be restarted. Not a great result but not a plane crash and not a 10h flight without IFE either.

I'm not sure that there's any exaggeration in my post - I didn't mention any overblown outcomes that could result from these sort of actions, purely the considerations that weren't taken into account before the action was taken. I may not be seeing the wood for the trees though - it's been one of those days at work today! :)

Oh I didn't mean your post in particular containing exaggerations, more that there is generally a lot of talk here insinuating plane crashes or other catastrophic side effects coming from port scans.

The other almost-catastrophic outcome is apparently that the IFE system would not just crash, but be bricked in a state where it couldn't be restarted. Not impossible, but not likely either.

People switch seats in planes without asking the staff. That's also irresponsible and dangerous, and the worst case scenario is a crash. This is about the same level of risk if you ask me.

> I did a port scan on the System Control Unit

Is that still white hat? Did they also check to see if the cockpit door is locked?

Scanning should be fine; trying to access them becomes dubious; bruteforcing the login could lead to arrest.

I had a projector firmware freeze up hard on me during a port scan. There is some risk there.

So what does that say about the wisdom of port scanning a machine your life is currently depending on?

He probably should've done his port scan once the plane was on the ground. Though I'd be REALLY worried if there was even the slightest risk of network access to the IFE causing a flight control device of any kind to seize up, and would hope that someone at Boeing made sure that was not possible.

If that plane ever plans to enter US or EU airspace, there is a literal air-gap between the IFE and the flight systems.

Then how is it showing the flight metrics?

I wouldn’t guess they would add double sensors for all that information.

Or did you mean well protected, instead of literal air gap?

One way connection of some kind? Its not an air gap but may functionally work the same way.

Optoisolators are a prolific and an extremely cheap electrical component that performs the "air-gap" functionality.

No, that's not airgapping.

Electrical safety airgapping and information security airgapping are different, and entirely unrelated. If data can pass from one side to the other it's not airgapped (from an infosec perspective).

Fiber needs transmitter and receiver transducers. If each side has only one of those, data can literally flow only in one direction. So it's still infosec-airgapped in the other.

No, data diodes are a different (but related) concept. An airgap implies no information transfer, either in or out. Use an airgap when information leakage must be stopped (as well as remote attacks), use a data diode when information can be released but you need to stop remote attacks.

Fiber optic connections aren't required, anything with separate transmit and receive lines can be turned into a data diode (as long as the protocols used permit it). RS232 null modem cables with the RX lines disconnected are a classic.

I don't know enough about airplanes to know if it would be unencrypted but they radio all of that same data to the ground in some way, could the IFE system just passively listen to that broadcast?

GPS + external sensors for pressure, wheels, …

I am not a Boeing engineer, but I do have some experience in avionics design.

The flight critical systems would be isolated from in-flight entertainment system (IFE). The IFE probably has a listen-only tap to flight metric info on an ARINC databus from the flight computer. I did a quick search and looks like 787 uses ARINC 667, a fiber optic interconnect.

The Federal Aviation Administration has issued special conditions for the certification of the 787 to deal with the fact that there is no "literal airgap" in recent airliners even though that was initially mandated by the airworthiness standards:

> These special conditions are issued for the Boeing Model 787-8 airplane. This airplane will have novel or unusual design features when compared to the state of technology envisioned in the airworthiness standards for transport category airplanes. The architecture of the Boeing Model 787-8 computer systems and networks may allow access to external systems and networks

[1] https://www.federalregister.gov/documents/2007/12/28/E7-2507...

Do you honestly believe your life depends on the stability of an in flight entertainment computer?

If your fellow passengers found out who killed the movies in the middle of a long flight... in this particular case, yes, it might.

It would probably not harm the aircraft but would be bad enough if it freezes the entertainment system for all passengers. If the ~300 other people on board find out that you're the one responsible for their boredom on a 10 hour flight, you won't have a great time.

Has anyone taken a 10h flight where the IFE was not rebooted due to some problem?

Agree the IFE could crash, but can't see how there is even a remote risk to critical systems, or any risk to the IFE that isn't solved by (yet another) reboot of it.

I used to work at a university, and would routinely (with authorisation) nmap the entire /16. I discovered this would freeze the TCP/IP stack on a bunch of VMS boxes on campus - luckily on VMS that was restartable without bouncing the box :-)

Scanning can lead to arrest in some places.

In the UK for example, the computer misuse act says that using any tool with the intent of accessing a system (without actually doing so, let alone doing so successfully) is an offence.

It could easily be interpreted as a CFAA violation in the US as well. I'm a professional pen tester, and there's no chance I'd port-scan any system on an aircraft without permission.

It's almost like theres a reason every computer security class and every scanning software written has a disclaimer saying "NEVER SCAN A SYSTEM WITHOUT AUTHORIZATION".

At one of the companies I worked at, years ago, a service discovery system I wrote did a very light scan of every listening port bound on every system. One thing it did was an HTTP GET.

One of the core apps had a control port that implemented HTTP. Unfortunately, my GET hit a route that didn't exist, and that caused a small memory leak every time.

Nothing too bad happened; the leak was slow, and even though the app stayed up many months at a time, we did notice the leak and figured out what was causing it.

As others have stated elsewhere, I've seen completely 'easy going' TCP connections to embedded devices cause immediate crashes.

I wondered the same. Right or wrong some equipment does not respond well (lockup, reset...) to port scanning.

It's borderline; if something bad happens (and bad things definitely can happen from portscanning, especially embedded systems), you'll be on the hook for it.

"you'll be on the hook for it."

Particularly if something goes terribly wrong and you're on the plane.

Nothing you do to the IFE is going to take down the plane.

In theory the IFE and avionics are separated by firewalls. Some things like the PA system are often on the IFE side, and hacks for panasonic IFE have included impersonating the pilot announcements and stuff.

In practice I wouldn't expect the firewalls to be particularly well tested or complete or configured correctly, and it may be possible for an attacker to DOS the firewall and impact the other systems, and possible for the attacker to penetrate the firewall and so on.

I find this hard to believe. I always thought that IFE and avionics are on separate machines and run over different internal networks and wires. But I'm also not a Boeing engineer.

Can someone confirm the above post?

You or I would have completely different sets of wires.

Sadly, it seems they usually share wires and are separated by firewalls.

There's been lots of CCC and defcon talks about hacking in-flight systems. Googling "panasonic ife hack" gets plenty of hits, as does "Chris Roberts" who is a hacker who has made some pretty big claims about actually really hacking planes in flight and other stupid things. And there are articles like this https://www.wired.com/2015/04/hackers-commandeer-new-planes-... that talk about how the systems share wires.

I don't know anyone who believes those claims, which have become a kind of shared joke in the software security community.

Roberts? Yes.

Shared wires? That's fact, right?

I'm simply commenting on the notion that any packet he sent an IFE caused the plane to literally, perceptibly move. I don't need or want to derive the probability of that having occurred from first principles.

Nobody in the office here (I work on IFE & avionics software) believes those claims either.

Do you have source on panasonic IFE hacks? Sounds interesting.

(Its mentioned in the opening paragraph of the article ;) Its been a big thing for a long time and there are lots of articles you can google too.)

Doh! Thank you.

Not really familiar with the Boeing architecture, but having worked on similar systems for other commercial aircraft, "firewall" is an understatement for the systems that act as gateways between the aircraft network domains with different criticality levels.

The IFE is in the Passenger Information and Entertainment Services Domain (as defined by the standard ARINC664 Aircraft Data Networks). A basic assumption regarding the connectivity to more sensitive domains is that PIESD is totally insecure and anything can happen.

Finally to people wondering why aircraft designers would physically connect networks with vastly different security requirements: it's for making it possible to share aircraft/ground communication means (satcom...)

I only have experience with smaller, general aviation aircraft (Turboprop, 8 seats) but the IFE is indeed connected to the same box that handles maintenance tools. The ipad we use to troubleshoot the engines is on the same wifi network that we use to watch videos.

229 dead from an overheated entertainment system: https://en.wikipedia.org/wiki/Swissair_Flight_111

Nothing you do to the IFE is going to take down the plane.

So we're supposed to just take your word for it, in the face of contradictory evidence?

You don't have to go any further than the Wikipedia article the previous commenter provided to see that no evidence has been provided for how sending packets to an IFE could take down a plane.

Fair enough, but lack of evidence in this one case is not evidence that IFE systems are invincible. That's quite an extraordinary claim.

I agree it's not likely, but there can be some rare cascading scenarios. Like pilots may update electronic flight bag data via an onboard network which is separate from the entertainment network...but shares bandwidth with the same satellite transciever/antenna. Your port scan hogs the bandwidth somehow, resulting in somewhat less fresh data for tarmac conditions, etc. It's not likely, but it's possible.

And it doesn't have to be a dramatic life threatening situation to incur a boatload of financial liability. See this for example: http://nypost.com/2017/08/30/unruly-passenger-ordered-to-pay...

The other reply regarding the overheated IFE is another unlikely, but possible, scenario.

faulty wiring in the cockpit after the entertainment system started to overheat. electronic device don't start to do arc wiring with a portscan. Stop spreading bad info.

Even if in any other dimension it can be possible, it's the responsability of who design the system for protect against this.

Agree with the last line 100% - although the same argument can just as easily be applied to any and all systems in any and all arenas. The fact that the potential exists leaves a margin for error, and a window for trouble, which is what the post is about. If the potential for failure in a system is there, it needs to be addressed and the effects nullified or mitigated.

It shouldn't.

Hyperbole like this always makes me nervous. The probability is obviously not zero, politely suggesting the question: "what has been missed in this analysis?"

This isn't a publicly accessible system like a webserver. This is an entertainment device on a plane.

It's not your intuition about the IFE hardware that's problematic; it's your intuition about the "publicly accessible system like a webserver".

I meant from a legal standpoint. Accessing an IFE from a personal device you take on an airplane will be viewed differently in court than running nmap on your laptop against a webserver hosted on AWS.

Is that still white hat?

I think if you are not specifically asked to do it, it isn't white hat, and I think (but am not 100% sure) the law is like that. I don't know what hat it is, but white it isn't.

Irresponsibility is not solely the domain of Black Hats...

The decompression flag is interesting, I would've poked around the Javascript to see if that flag is ever read. If they were thorough, the web frontend would show a red screen with words like "Decompression! Put on your oxygen mask!"

Otherwise, passengers could be so distracted with the electronic entertainment that they might not notice that it got very breezy all of a sudden...

This is actually a good idea. Or at least activate the PA system and stop videos. Not sure how easy it is to notice masks falling down if you wear noise cancelling headphones and look down on your tablet.

I imagine it would tangle onto your hair or you'd notice the confusion around you ?

Looks like decompression is checked for in a function that catches behavior for DECOMPRESSION, PA, and WEIGHT ON WHEELS (no entertainment on ground when heavy devices should be stored):

https://github.com/x8BitRain/InFlightEntertainment-Scoot787/...

which then weaves through various functions similar to the above states. So I think your guess is on track!

Were the in flight entertainment touchscreens really capactive? I've found that such designs have almost exclusively been resistive. The resistive designs are cheaper, but also tend to be designed with a high threshold. The two put together makes a lot of resistive touchscreens feel sluggish. You feel like you have to mash the heck out of them to get them to act sometimes. On the upside they don't require human capacitance to work, just screen pressure.

I imagine they meant resistive, however newer planes do have capacitive screens now.

I've often thought the genius who thought it was a good idea to put a crappy low sensitivity touchscreen directly behind my head needs to be kicked squarely in the nuts, repeatedly.

Newer planes have capacitative touch now. They even rolled their own implementation of Apple cover flow.

The guy probably has the terms mixed up.

Oh man, I was on a recent Austrian 767 trans-atlantic flight where they use a touchscreen (capacitive, I suppose) for the seat controls. Where did they put it? Right under where your forearm would go. There was no visual confirmation for hitting the buttons, which mean it was virtually impossible to tell if your seat was doing what you wanted it to do when you 'pressed' the buttons, but then it would randomly do stuff you DIDN'T want it to do just while you're sitting there.

I took to leaving my phone on top of the seat controls, but even then seemed to have weird gremlins.

I'm not sure who designed that, but it was.. not smart. Poor design, poor implementation.

All fun and games until someone remembers that there is no air gap on Boeing's in-flight network

> There are places where the networks are not touching, and there are places where they are

Boeing's Lori Gunter

https://www.wired.com/2015/04/hackers-commandeer-new-planes-...

Not a pilot, but Regarding flight phrase, actually airplane can detect FLARE easily (Airbus even has a FLARE flight law governing the aircraft during flare).

Typically FLARE would be RA (Radio Altimeter) < 50ft, flaps/slats extended, speedbrake armed, and weight on wheel = 0 or something along this line.

Reading through the post it didn't seem like he found any security issues. Their map has javascript variables which isn't a security issue. It doesn't seem like SCU had many open ports. It was running a relatively new version of Linux.

Didn't find anything of interest at all + did a foolish, possibly illegal thing.

Why is this blog post being upvoted?

> I did a port scan on the System Control Unit

Scanning during flight is not really responsible at all.

Awesomely entertaining (hah!) read. Very interesting, thanks. Also, welcome to every no-fly list on the planet. If you are going to find that you are increasingly seeing more scrutiny, this is why.

Beside a scan is good or bad, how would they go about finding the source? There wont be an IT officr at landing collecting logs/mac address from any wireless card. I've scanned those systems many times and nothing ever happened - i am just pointing out to the issue that catching a real attacker it is hard not just technically but in practice

Also, don't use a typical *nix terminal that looks all hackerish (black background, green font, something like that). Someone non technical is bound to notice that, even if out of the corner of their eye.

Actually my experience is that fellow passengers were often intrigued by all the colors on the screen (from your usual syntax highlighting) rather than worried by the dark background!

Unfortunately nowadays "Arabic" is what worries people, even if that turns out to mathematical notation. [1]

[1] https://www.theguardian.com/us-news/2016/may/07/professor-fl...

I'm not too keen on the idea that I'm now supposed to watch on a laptop. If I wanted to go to that kind of trouble I wouldn't be confining myself to whatever crap was on the in-flight entertainment system in the first place.

I'm not too keen on having a screen I don't control ( and never use anyway) in front of me for an entire flight. I hate being shown ads, and the only place I still regularly encounter them are airplane IFE systems I can't turn off during certain phases of the flight, and poorly chosen gas stations. Interestingly neither of those used to be significant sources of advertising.

I've never seen one that couldn't be turned off.

>td_id_decompression:"0"

Well that's just...awesome..

Welcome to the no fly list, sir!

Some domestic Chinese airlines I have flown sidestep most IFE problems completely. As you enter the plane, you are issued a sturdy, fully charged Android tablet computer that is fully loaded with entertainment content. You return the tablet as you exit the aircraft. If something is going wrong with your tablet they give you a fresh one.

So many good things with this approach: cost, easy upgrades, no complicated certification or hardening needed.

I have no idea why no other airlines use this method, it seems so much easier to me.

Reply on news.ycombinator.com