Recherche avancée

Sur d’autres sites (5141)

• Alias Artifacts

  26 avril 2013, par Multimedia Mike — General

  Throughout my own life, I have often observed that my own sense of nostalgia has a window that stretches about 10-15 years past from the current moment. Earlier this year, I discovered the show “Alias” and watched through the entire series thanks to Amazon Prime Instant Video (to be fair, I sort of skimmed the fifth and final season which I found to be horribly dull, or maybe franchise fatigue had set in). The show originally aired from 2001-2006 so I found that it fit well within the aforementioned nostalgia window.

  
  
  

  But what was it, exactly, about the show that triggered nostalgia ? The computers, of course ! The show revolved around spies and espionage and cutting-edge technology necessarily played a role. The production designer for the series must have decided that Unix/Linux == awesome hacking and so many screenshots featured Linux.

  Since this is still nominally a multimedia blog, I’ll start of the screenshot recon with an old multimedia player. Here is a vintage Mac OS desktop running an ancient web browser (probably Netscape) that’s playing a full-window video (probably QuickTime embedded directly into the browser).

  
  

  

  Click for larger image

  
  

  Let’s jump right into the Linux side of things. This screenshot makes me particularly sentimental since this is exactly what a stock Linux/KDE desktop looked like circa 2001-2003 and is more or less what I would have worked with on my home computer at the time :

  
  

  

  Click for larger image

  
  

  Studying that screenshot, we see that the user logs in as root, even to the desktop environment. Poor security practice ; I would expect better from a bunch of spooks.

  Echelon
  Look at the terminal output in the above screenshot– it’s building a program named Echelon, an omniscient spy tool inspired by a real-world surveillance network of the same name. In the show, Echelon is used to supply plot-convenient intelligence. At one point, some antagonists get their hands on the Echelon source code and seek to compile it. When they do, they will have access to the vast surveillance network. If you know anything about how computers work, don’t think about that too hard.

  Anyway, it’s interesting to note that Echelon is a properly autotool’d program– when the bad guys finally got Echelon, installation was just a ‘make install’ command away. The compilation was very user-friendly, though, as it would pop up a nice dialog box showing build progress :

  
  

  

  Click for larger image

  
  

  Examining the build lines in both that screenshot and the following lines, we can see that Echelon cares about files such as common/db_err.c and bt_curadj.c :

  
  

  

  Click for larger image

  
  

  A little googling reveals that these files both belong to the Berkeley DB library. That works ; I can imagine a program like this leveraging various database packages.

  Computer Languages
  The Echelon source code stuff comes from episode 2.11 : “A Higher Echelon”. While one faction had gotten a hold of the actual Echelon source code, a rival faction had abducted the show’s resident uber-nerd and, learning that they didn’t actually receive the Echelon code, force the nerd to re-write Echelon from scratch. Which he then proceeds to do…

  
  

  

  Click for larger image

  
  

  The code he’s examining there appears to be C code that has something to do with joystick programming (JS_X_0, JS_Y_1, etc.). An eagle-eyed IMDb user contributed the trivia that he is looking at the file /usr/include/Linux/joystick.h.

  Getting back to the plot, how could the bad buys possibly expect him to re-write a hugely complex piece of software from scratch ? You might think this is the height of absurdity for a computer-oriented story. You’ll be pleased to know that the writers agreed with that assessment since, when the program was actually executed, it claimed to be Echelon, but that broke into a game of Pong (or some simple game). Suddenly, it makes perfect sense why the guy was looking at the joystick header file.

  This is the first bit of computer-oriented fun that I captured when I was watching the series :

  
  

  

  Click for larger image

  
  

  This printout purports to be a “mainframe log summary”. After some plot-advancing text about a security issue, it proceeds to dump out some Java source code.

  SSH
  Secure Shell (SSH) frequently showed up. Here’s a screenshot in which a verbose ‘ssh -v’ connection has just been closed, while a telnet command has apparently just been launched (evidenced by “Escape character is ‘^]’.”) :

  
  

  

  Click for larger image

  
  

  This is followed by some good old Hollywood Hacking in which a free-form database command is entered through any available command line interface :

  
  

  

  Click for larger image

  
  

  I don’t remember the episode details, but I’m pretty sure the output made perfect sense to the character typing the command. Here’s another screenshot where the SSH client pops up an extra-large GUI dialog element to notify the user that it’s currently negotiating with the host :

  
  

  

  Click for larger image

  
  

  Now that I look at that screenshot a little more closely, it appears to be a Win95/98 program. I wonder if there was an SSH client that actually popped up that gaudy dialog.

  There’s a lot of gibberish in this screenshot and I wish I had written down some details about what it represented according to the episode’s plot :

  
  

  

  Click for larger image

  
  

  It almost sounds like they were trying to break into a network computer. Analyzing MD5 structure… public key synthesized. To me, the funniest feature is the 7-digit public key. I’m a bit rusty on the math of the RSA cryptosystem, but intuitively, it seems that the public and private keys need to be of roughly equal lengths. I.e., the private key in this scenario would also be 7 digits long.

  Gadgets
  Various devices and gadgets were seen at various junctures in the show. Here’s a tablet computer from back when tablet computers seemed like fantastical (albeit stylus-requiring) devices– the Fujitsu Stylistic 2300 :

  
  

  

  Click for larger image

  
  

  Here’s a videophone from an episode that aired in 2005. The specific model is the Packet8 DV326 (MSRP of US$500). As you can see from the screenshot, it can do 384 kbps both down and up.

  
  

  

  Click for larger image

  
  

  I really regret not writing down the episode details surrounding this gadget. I just know that it was critical that the good guys get it and keep from falling into the hands of the bad guys.

  
  

  

  Click for larger image

  
  

  As you can see, the (presumably) deadly device contains a Samsung chip and a Lexar chip. I have to wonder what device the production crew salvaged this from (probably just an old cell phone).

  Other Programs

  The GIMP photo editor makes an appearance while scrubbing security camera footage, and serves as the magical Enhance Button (at least they slung around the term “gamma”) :

  
  

  

  Click for larger image

  
  

  I have no idea what MacOS-based audio editing program this is. Any ideas ?

  
  

  

  Click for larger image

  
  

  FTP shows up in episode 2.12, “The Getaway”. It’s described as a “secure channel” for communication, which is quite humorous to anyone versed in internet technology.

  
  

  

  Click for larger image

  
  

• Investigating Steam for Linux

  1er mars 2013, par Multimedia Mike — Game Hacking

  Valve recently released the final, public version of their Steam client for Linux, and the Linux world rejoiced. At least, it probably did. The announcement was 2 weeks ago on Valentine’s Day and I had other things on my mind, so I missed any fanfare. When framed in this manner, the announcement timing becomes suspect– it’s as though Linux enthusiasts would have plenty of time that day or something.

  
  
  

  Taming the Frontier
  Speculation about a Linux Steam client had been kicking around for nearly as long as Steam has existed. However, sometime last year, the rumors became more substantive.

  I naturally wondered how to port something like Steam to Linux. I have some experience with trying to make a necessarily binary-only program that runs on Linux. I’m fairly well-versed in the assorted technical challenges that one might face when attempting such a feat. Because of this, whenever I hear rumors that a company might be entertaining the notion of porting a major piece of proprietary software to Linux, my instinctive reflex is, “What ?! Why, you fools ?! Save yourselves !”

  At least, that’s how it used to be. The proposal of developing a proprietary binary for Linux has been rendered considerably less insane by a few developments, for example :

  1. The rise of Ubuntu Linux as a quasi de facto standard for desktop Linux computing
  2. The increasing homogeneity in personal desktop computing technology

  What I would like to know is how the Steam client runs on Linux. Does it rely on any libraries being present on the system ? Or does it bring its own ? The latter is a trick that proprietary programs can use– transport all of the shared libraries that the main program binary depends upon, install them someplace out of the way on the filesystem, probably in /opt, and then make the main program a shell script which sets a preload path to rely on the known quantity libraries instead of the copies already on the system.

  Downloading and Installing the Client
  For this exercise, I installed x86_64 desktop Ubuntu 12.04 Linux on a l33t gaming rig that was totally top of the line about 5 years ago, and that someone didn’t want anymore and handed down to me recently. So it should be ideal for this project.

  At first, I was blown away– the Linux client is in a .deb package that is less than 2 MB large. I unpacked the steam.deb file and found a bunch of support libraries — mostly X11 and standard C/C++ runtimes. Just as I suspected. Still, I can’t believe how small the thing is. However, my amazement quickly abated when I actually ran Steam and saw this :

  
  
  

  So it turns out steam.db is just the installer program which immediately proceeds to download an additional 160+ MB of data. So there’s actually a lot more information to possibly sift through.
  
  Another component of the installation is to basically run a big ‘apt-get install’ command to make sure a bunch of required packages are installed :

  
  
  

  After all these installation steps, the client was ready to run. However, whenever I tried to do so, I got this dialog which would cause Steam to close when the dialog was dismissed.

  
  
  

  Not a huge deal ; later NVIDIA drivers are fairly straightforward to install on Ubuntu Linux. After a few minutes of downloading, installing and restarting X, Steam ran with minimal complaint (it still had some issue regarding the video drivers but didn’t seem to consider it a deal-breaker).

  Using Steam on Linux

  So here’s Steam running on Linux :

  
  
  

  If you have experience with using Steam on Windows or Mac, you might observe that it looks exactly the same. I don’t have a very expansive library of games (I only started using Steam because purchasing a few computer components a few years ago entitled me to some free Steam downloads of some of the games on the list in the screenshot). I didn’t really expect any of the games to have Linux versions yet, but it turns out that the indie darling FTL : Faster Than Light has been ported to Linux. FTL was a much-heralded Kickstarter success story and sounded like something I wanted to support. I purchased this from Steam shortly after its release last year and was able to download the Linux version at no additional cost with a single click.

  It runs natively on Linux (note the Ubuntu desktop window decorations) :

  
  
  

  You might notice from the main Steam client that, despite purchasing FTL about a 1/2 year ago and starting it up at least a 1/2 dozen times, I haven’t really invested a whole lot of time into it. I only managed to get about 2 minutes further this time :

  
  
  

  What can I say ? This game just bores me to tears. It’s frustrating because I know that this is one of the cool games that all real gamers are supposed to like, but I practically catch myself nodding off every time I try to run through the tutorial. It’s strange to think that I’ve invested far more time into games that offer considerably less stimulation. That’s probably because I had far more free time compared to gaming options during those times.

  But that’s neither here nor there. We’ll file this under “games that aren’t for me.” I’m glad that people like FTL and a little indie underdog has met with such success. And I’m pleased that Steam on Linux works. It’s native and the games are also native, which is all quite laudable (there was speculation that everything would just be running on top of a Wine layer).

  Deeper Analysis
  So I set out wondering how Steam was able to create a proprietary program that would satisfy a large enough cross-section of Linux users (i.e., on different platforms and distros). Answer : well, they didn’t, per the stated requirements. The installation is only tuned to work on Ubuntu 12.04. However, it works on both 32- and 64-bit platforms, the only 2 desktop CPU platforms that matter these days (unless ARM somehow makes inroads on the desktop). The Steam client is quite clearly an x86_32 binary– look at the terminal screenshot above and observe that it’s downloading all :i386 support libraries.

  The file /usr/bin/steam isn’t a binary but a launcher shell script (something you’ll also see if you investigate /usr/bin/firefox on a Linux system). Here’s an interesting tidbit :

  function detect_platform()
  
    # Maybe be smarter someday
    # Right now this is the only platform we have a bootstrap for, so hard-code it.
    echo ubuntu12_32
  
  

  I wager that it’s possible to get Steam running on other distributions, it probably just takes a little more effort (assuming that Steam doesn’t put too much effort into thwarting such attempts).

  As for the FTL game, it comes with binaries and libraries for both x86_32 and x86_64. So, good work to the dev team for creating and testing both versions. FTL also distributes versions of the libraries it expects to work with.

  I suspect that the Steam client overall is largely a WWW rendering engine underneath the covers. That would help explain how Valve is able to achieve such a consistent look and feel, not only across OS platforms, but also through a web browser. When I browse the Steam store through Google Chrome, it looks and feels exactly like the native desktop client. When I first thought of how someone could port Steam to Linux, I immediately wondered about how they would do the UI.

  A little Googling for “steam uses webkit” (just a hunch) confirms my hypothesis.

• How to link static library with xcode ?

  31 janvier 2013, par why

  I have built ffmpeg and link it to my project :

  

  But when I include libavformat.h , it game me error :

  

  I want to know what's the settings I am missing ?