alt Hacker NewsNitpicking the shell history scene in 'Tron: Legacy'
Comments
One of my favorite details of this movie is that the semi-antagonistic ENCOM executive Dillinger uses emacs [0], while Flynn uses vi. Clearly, the VFX artist who made the film's UNIX shells had a preference!
(Dillinger is also shown running "ENCOM Linux" -- is the VFX artist a BSD user? As he cycles through his buffers, we see a split second of `hanoi-unix`; definitely not the type to pay attention during boring board meetings!)
> Killing some processes to free up memory
This section is disregarding a key lore element, the inhabitants of the grid are programs. Killing a process in this context more likely has an interpretation of an attempt to stop an individual such as the villain Clu. I would say an alternative explanation is is more story based, with Kevin Flynn trying to stop Clu from the outside world but being unable to and instead taking the last resort of entering the grid when he knows it would be dangerous.
As an aside the Daft Punk soundtrack that accompanies this film is an absolute masterpiece. I think it's their best work.
It's such a shame the film doesn't live up to it's own soundtrack.
I have such a soft spot for this scene. I saw this movie in theaters when I was a high schooler, and this exact scene with Sam entering in commands piqued my curiosity to learn if it was a real thing. I eventually discovered that OS X came shipped with a bash terminal, and that I could manipulate a computer in just the same way. It really made an impact on me, which I certainly wasn't expecting when buying tickets to this film I knew nothing about.
$ login -n root
Login incorrect
login: backdoor
No home directory specified in password file!
Logging in with home=/
#
Why is this guy so obsessed with the variable vs fixed-width font, you'd think he's the guy who wrote putty or something
I was luck to know Josh Nimoy who is responsible for a lot of this in the movie, who has since sadly passed away. Josh took great pride in the fact that he was able to put Emacs and a bunch of Unix commands in a major Hollywood blockbuster.ed
The author notes a possible error that the laser config file never seems to get copied to the location the laser software will actually run from, but it could have been done directly from vi.
:w
:w /path/to/actual/config.cfg
:qThe funny thing about all of this to me is that, compared to most 'hacking' scenes in movies, this bit is wildly realistic, almost too good. If they were like "run upload_me" we wouldn't even be talking about it.
$ login -n root
Login incorrect
login: backdoor
No home directory specified in password file!
Logging in with home=/
#
I like the fun in this article, but some nitpicks don't seem right to me. This kinda reminds me of cinemasins.
1) I would assume his dad talked about always having a backdoor as a kid, so that's why Sam tried backdoor as the second username
2) temp.cfg isn't an unreasonable config filename. We don't know what the source code is. My guess would be that he hardcoded temp.cfg in the source because something wasn't working, and continued working on the actual bug
3) Killing processes to free memory? He reached for a kill -9 and then a regular kill. That hints to me that he recognized those two processes and knew -9 was required only for the first. He probably checked to see if he had enough memory, saw that he did, and then started cleaning up the processes.
4) Linux and SolarOS? Couldn't the other terminal just have been sshed to another box? That seems most reasonable to me.
I for one, am absolutely fascinated with Tron Legacy. It was the first Tron movie I saw as a kid in middle school. In some ways, it's responsible for the trajectory of my career.
Apart from the obvious reasons about the DP soundtrack and the visuals, I love the theme of chasing perfection and the way it backfires.
Kevin Flynn says to CLU in the end "The thing about perfection, is that it's unknowable. You don't know that because I didn't know it when I created you" and I love the fact that it says how we can put our best and our worst into what we create. That we're not just responsible for lifeless machines, that it's more than that. And it's a hauntingly beautiful thought.
I doubt they put this much thought into it, but I'd say the backdoor is actually the "-n" flag and this is some modified version of login that just does setuid(0) for whatever you put after.
> and squeezed a lot more juice out of it than I’d realised was there to be squozen.
I barked out loud when I read this.
The style of the desktop in the screenshot looks a lot like the XWindow manager twm:
https://en.wikipedia.org/wiki/Twm
If you like that general esthetic, you can try that today in your GNU/Linux distro.
SunOS 4 did not have /proc, that was a BSD-based system.
Interesting indeed. The bit about Solaris -> Solar is nice/funny. I guess its an update to some system or kernel config file.
Or for super hacker points, edit appropriate binary using adb :)
This is something that really upset me going into Tron Ares. I had a blast rewatching Legacy beforehand and picking out somewhat realistic shell commands. Ares ditches a lot of these shell commands in favor of everything being a script. `./start_ares_program`, etc. IIRC, we still see a `systemctl` or two in the movie, but definitely less fun than Legacy.
I worked on this movie, mainly from a CentOS shell, and I approve this nitpick.
whenever I join a new firm (usually as a DevOps or SRE) I ask the Linux team which server in the firm has the longest uptime.
Invariably, I then send them this post where it shows the uptime from the host in the movie (I'll let the reader click through to see the time): https://scifi.stackexchange.com/questions/9041/whose-hardwar...
If you're curious, the longest uptime I've had someone report back was in excess of 4 years.
P.S. I also remember working at a big investment bank and the oldest Good Till Cancel order in the mainframe was a Buy CSCO @ $6 from the late 1990s (this was in 2010).
I always remember when, as a young geek writing games for my C64, I was thrilled when I saw the Terminator and a lot of the code scrolling past in its HUD was 6502 assembly code!
Now I'm watching this thread for the consultant hired by the film to show up and explain why each of those goofs was caused by the director explicitly asking for them...
Simon writes:
> To [switch users], /bin/login would need to be setuid, and it certainly isn’t on Linux... _Perhaps_ Solaris (or SolarOS) is different?
The login command is indeed setuid root on SunOS 4, to which the movie pays homage, as its documented behavior is "to [permanently] change from one userID to another". The su command explicitly means "temporarily switch to a new user ID".
Here are copies of the SunOS 4 manual pages, if you're curious:
http://www.typewritten.org/Manual/Sun/SunOS/4.0.2/man1/login...
http://www.typewritten.org/Manual/Sun/SunOS/4.0.2/man1/su.ht...
And here's a link to the relevant bits of the SunOS 4.1.3 source code:
https://github.com/Arquivotheca/SunOS-4.1.3/blob/2e8a93c3946...
this makes me remember Trinity doing the power plant escalation hack in the 2nd Matrix movie
the code apparently was legit, I think it was an SSH exploit
(btw that movie is TWENTY-SEVEN YEARS OLD)
lol. I remember seeing LLLSDL go by when I originally saw the movie. The funny but is I had just written the internet draft for LLSD, so I was wondering g if someone on the writing staff had been following our work at Linden Lab. More likely it was a coincidence and all the L's meant "Laser."
Very fun analysis!
The video tech one of my startups made was used to do "On-Set Video Playback" exactly like this for a bunch of movies and TV shows. We didn't make the product for that purpose and only learned this was a thing when a playback company contacted us asking for a change in the firmware to enable external synchronization to a 48fps source clock.
Since it wasn't a difficult change and the use case was neat, we made a custom version for them. That's how I got to know some of the people who do this work and even got to visit some movie and TV sets. So, based on that, here are some insights relating to TFA.
The first thing to know is on-set video playback for film and TV production is a specialized service because it can require arcane knowledge to properly interface various video displays with 24 fps film cameras. This used to involve a lot of custom modified displays, hand-built or modified interface boxes and various arcane cables/adapters but it's gotten somewhat easier with the advent of variable frame rate displays and GPUs.
Since time is money on-set, productions just hire this out on a project basis to one of a few specialized firms in Hollywood. As it's a niche thing, these firms are usually just a handful of knowledgeable A/V guys who've acquired a variety of customized interfacing gear over many projects along with different types of displays and have practical experience in making it work quickly and reliably with various cinema cameras.
There are two main parts to a project: 1) Making the screen look right on camera, and 2) Getting the right images on the screen at the right time.
1) Making it look right breaks down into three parts: A) Getting the source on the screen, B) Synchdronizing the source with the cinema camera so there's no screen flicker or rolling, and C) Adjusting the screen's brightness, contrast, gamma, saturation, etc to 'read' well on-camera along with minimizing any light glare and reflections. Depending on the ambient scene brightness and the camera's shutter speed, iris, etc these adjustments can sometimes be more extreme than the display's native adjustments allow. The playback team has tools for this including stand-alone signal processing boxes that range from simple knob adjustments all the way to 3D LUTs that can remap any pixel value to any other. They might also use old-school tricks like covering the screen with neutral density film similar to window tinting.
2) Getting the right images on the screen at the right time breaks into two parts. A) Creating the source imagery, and B) Triggering the playback on cue. For most projects the production will just have the playback team create the source imagery. The only exceptions tend to be shows where on-screen shots are frequent and integral to the story. In those cases, the on-screen content will usually be the responsibility of a designer working under the production's art director and the playback team's job will be getting it on the screen. The on-screen imagery for Tron: Legacy is pretty minimal and contained to a few scenes so it was probably designed and created by the playback team as a per-hour line item on their project bid.
In those cases, the playback team will receive the relevant script pages and a few storyboards. Based on those and perhaps a phone call with a line producer or AD, they'll make some comp stills and send them over for pre-approval. Once approved, they'll do the actual source content and send clips for approval. Depending on the production, this may just be signed off by the line-producer or an AD but, in other cases, the director will want to at least see it. If the playback team is providing the display they'll send over photos so the production designer and set dressers know what will be coming.
On the shoot day the team gets there early and coordinates with the set dressers to get the display in place, then electricians for power and finally the DP and camera crew to test sync, brightness, etc. The type of content going on-screen and how interactive it needs to be will determine if they've already pre-recorded the source and just play it back on-set, use an interactive video source to sequence or animate the content or actually use a "live" source. They tend to use whatever software can do the job, is easy, reliable and flexible. This can range from as basic as Powerpoint to more sophisticated presentation tools to scripting tools and, when necessary, even custom command line apps they've cobbled together over the years. For video clips, they'll record what they can and then modify or composite elements together with standard tools like Photoshop and AfterEffects.
In the case of Tron: Legacy, it's hard to tell if they pre-recorded the sequences from a Linux computer and triggered playback in steps on-set or used a live Linux computer since, done properly, they can look essentially identical. There's a strong preference to pre-record everything and sequence or animate it for playback but sometimes that's not possible due to keyboard/mouse activity. The reason is that any live computer might crash or respond at slightly different speeds from take to take complicating editing, especially when there's repeated re-takes or on-set heat from lights, etc. Power on set can also sometimes be from generators and very dirty, even on studio sound stages and back lots. Any delay due to playback not being ready, or worse killing a take, can have severe reputational consequences.
In cases where a live computer is unavoidable, the strong preference is for someone from the playback team to do all the operation off-camera while the actor uses a dummy keyboard and mouse. This usually works fine because there's rarely a need to hold on an all-in-one medium shot showing the screen and keyboard/mouse during actual interaction. On-screen interaction is almost always shown in an insert close-up of the just the screen and bezel. Either way, the sound of keypresses and clicks are dubbed in later by foley artists just like footsteps and doors closing, etc. The absolute nightmare scenario for any playback artist is when a live computer is required that an actor actually operates. It never goes well. Not because the actors are dummies but because they have to focus first on hitting their marks, saying their lines and actually, you know, acting. Under those conditions, typing the exact same techno-gibberish in exactly the same way, with the same timing, while repeating lines over 30 takes would likely give most of us trouble too.
Good luck finding his will in the home directory of the backdoor account.
Wonderful!
At the bottom he notes: "I’m sitting in the UK as I write this. Under UK law, I believe this should constitute fair dealing: the purpose is quotation for criticism and review, and this single screen capture is in no way an alternative to paying to see the original film. The film comes from the USA, and under USA law I think it similarly constitutes fair use: it’s for non-profit educational purposes, the amount of the full work used is extremely small, and the effect on the value of the full work negligible."
I took down my entire "Behind The Screens" YouTube channel and transferred it to my own site: https://behind-the-screens.tv because of copyright notices from YouTube that were heavily skewed towards the studios and I didn't have the energy to fight what was clearly fair use in my videos.