Before I start, I should address the inevitable “what about OAuth2″ comments. Yes, OAuth2 is the new hotness for Facebook authentication, but the Facebook Connect iPhone SDK isn’t going to get broken (intentionally!) any time soon. (I have that on authority from a friend inside Facebook, BTW.) If you’ve got the time to replicate the functionality of FBConnect for the new world order I salute you, but otherwise this code may come in handy and will continue to function until a full-featured replacement for FBConnect arrives.

With a session proxy (say at http://your-server.example.com/fbproxy), this is how the client establishes a session:

• Phone:
  – GET http://your-server.example.com/fbproxy?auth_token=A_TOKEN&…
• To respond, your server relays the results of this POST:
  – POST: http://api.facebook/com/restserver.php
  – POST body: auth_token=A_TOKEN&sig=A_SIGNATURE&…

A_SIGNATURE is generated using your FB app secret, so Facebook knows the request is legit. Facebook returns a session key & secret that can be used to make Facebook API calls from the phone. If you’re wondering (like I did) how this is any more secure than shipping your app secret directly, you should understand that a session key is much less powerful than an app secret. The app secret is basically the root password for your app, while a session key gets you an unprivileged user account.

With HexaLex I’ve used Google App Engine to host most of the backend service, so I ended up adapting some sample code I found online to do the job. (minifb is particularly readable.) I didn’t want to pull in a bunch of other dependencies, so this code is self-sufficient. I’m using Google’s webapp framework so that’s what’s used in the code, but it should be easy to adapt to whatever framework you favor. Without further ado, here’s the code:

"""
To use this, write in your Facebook API key and secret below and then
add FacebookSessionProxy to your list of url handlers:
    application = webapp.WSGIApplication(
        [('/fbproxy', FacebookSessionProxy),
         ...])
 
Then in your iPhone code use something like
session = [FBSession sessionForApplication:myApiKey 
             getSessionProxy:@"http://yourApp.appspot.com/fbproxy"
             delegate:self];
"""
import hashlib
import httplib
import urllib
from google.appengine.ext import webapp
 
# This lambda prevents the secret from appearing in cgitb backtraces
FB_API_SECRET = lambda:"YOUR_API_SECRET"
FB_API_KEY = "YOUR_API_KEY"
 
FB_API_HOST="api.facebook.com"
FB_API_PATH="/restserver.php"
 
def facebook_signature(paramsDict):
    """Compute the signature of a Facebook request"""
    sorted = paramsDict.items()
    sorted.sort()
 
    trace = ''.join(["%s=%s" % x for x in sorted])
    trace += FB_API_SECRET()
 
    md5 = hashlib.md5()
    md5.update(trace)
    return md5.hexdigest()
 
def get_fb_session(auth_token):
    """Request a Facebook session using the given auth_token"""
    params={
            "api_key":FB_API_KEY,
            "v":"1.0",
            "auth_token":auth_token,
            "generate_session_secret":"1",
            "method":"auth.getSession",
    }
    params["sig"] = facebook_signature(params)
 
    encoded_params = urllib.urlencode(params)
    headers = {
            "Content-type":"application/x-www-form-urlencoded",
    }
 
    conn = httplib.HTTPConnection(FB_API_HOST)
    conn.request("POST", FB_API_PATH, encoded_params, headers)
    return conn.getresponse()
 
class FacebookSessionProxy(webapp.RequestHandler):
    def get(self):
        response = self.response
        auth_token = self.request.get('auth_token')
        if len(auth_token) == 0:
            response.set_status(httplib.BAD_REQUEST)
            response.out.write("Facebook login error: no auth_token given.")
            return
        fbResponse = get_fb_session(auth_token)
        response.out.write(fbResponse.read())
        response.set_status(fbResponse.status, fbResponse.reason)
        response.headers['Content-Type'] = fbResponse.getheader('content-type')
 
# The End

Update: I fixed a bug in the call to get_fb_session. Thanks to Justin Williams for reporting it.

• User: root, Password: aardvark. (Repeat with various well-known usernames and every word in the English dictionary)
• User: abe, Password: abe. (Repeat with all common first/last names)

It’s not hard to think of simple methods to cut off these attacks without altering or otherwise restricting one’s ssh service (by, say, running sshd on a non-standard port):

• Throttle login attempts on a per-host basis. i.e. if a host tries and fails to log in N times in M seconds then start making it wait longer and longer between successive logins (or even blacklist the host entirely).
• Throttle login attempts on a per-account basis. i.e. if user bob gets N failed login attempts within M seconds then throttle or blacklist future login attempts on that account.
• Auto-blacklist hosts that attempt to log in to accounts that should never be logged in to. e.g. if somebody tries to ssh in as user “games” they’re toast.

Indeed, there are any number of programs out there that aim to provide exactly these capabilities.¹ What these techniques have in common is the need to measure the number of failed login attempts associated with a host and/or account over a period of time. So how do the existing programs do it? Sadly, a large number do it by scanning log files. In other words, a scanner will look for a certain pattern (typically using regular expressions) in the logging output for your system and assume that it indicates a failed login attempt. This is not a great idea.

What’s wrong with log file scanning, anyway? The first (and least important, IMHO) mark against it is performance. A typical system has dozens or hundreds of processes running at any time, each generating log output to some degree. Well-written programs generate a trickle, but it’s not unusual for a program to accidentally ship (or be misconfigured) with debug-level logging enabled and thus generate a torrent of debug output. By running a log file scanner you’ve now got a program that has to sift through every byte of that output looking for just one type of event! This is certainly not the most efficient way to find out about login attempts.

Another bad aspect of log file scanning is that it relies on the specific formatting of log messages from specific programs. If you replace OpenSSH with BogoSSH and BogoSSH uses a slightly different log output format then your scanner breaks. Similarly, if the OpenSSH people ever decide to change their logging format (not that this is likely) then your scanner breaks. If you install some new service that the scanner doesn’t know about it’s probably going to be totally unprotected unless it happens to format its log messages just like some other service the scanner understands.

But the worst thing about log file scanning is that sloppy implementations can actually open your system up to denial of service attacks! I recently came across this article by Daniel B. Cid that describes vulnerabilities in several popular log scanners that allow remote attackers to cause your machine to falsely blacklist any other machine of their choosing. Even worse, one scanner allowed attackers to cut a machine off from the network entirely! I refer you to the article for details, but the root causes of this problem are easy to describe:

• Regular expression matching is error-prone. People aren’t terribly good at understanding the full class of strings that a given R.E. will match. I’ve been doing complicated R.E. stuff for years now and I still have a terribly hard time writing bug-free regular expressions.
• Log files are chock full of strings that come from insecure sources, like, say, random users on your machine and script kiddies all across the internet who want to crack your machine. You do not want to be taking action automatically based on the contents of such an untrusted data source. The article doesn’t even begin to mention what an attacker with local access could do by writing and executing a program that mimics sshd’s log output.

So how should this problem be solved? By going straight to the horse’s mouth. If you want to know about authentication attempts, talk to the authentication system. Every modern *NIX system supports PAM, the Pluggable Authentication Module system. With a PAM module you can perform an action on any failed login attempt from any PAM-enabled service. This allows you to create a concise, trustworthy authentication log file with a consistent format, which can then be monitored by a very simple (and thus secure) scanner.

One project that takes the PAM approach is pam_abl (auto-blacklist). While it doesn’t use the specific strategy I described above (it builds a database rather than producing an authentication log file) it does get its info from the right source and is thus immune to these bogus log message attacks. Unfortunately pam_abl is a bit inflexible and limited in its capabilities. It doesn’t provide any way to blacklist a host if it tries to log in to a bogus account like ‘games’. It doesn’t provide a way to throttle rather than blacklist. And although it effectively ensures that an attacker will never have a chance to guess your account passwords it doesn’t provide a way of firewalling off a malicious host entirely. Even worse, the maintainer of pam_abl doesn’t seem to have time to work on it any longer. Hopefully somebody else will step up and turn this into the tool for stopping dictionary attacks dead in their tracks.

¹ Here are a handful:

• denyhosts
• fail2ban
• blockhosts
• blocsshd
• crackblock
• shellter
• sshdfilter
• sshit
• sshutout

Updated: Removed ssh-faker from the footnote since it effectively alters the sshd service.

Well, it turns out to be trivially easy to do a QL plugin that renders HTML. Mix in Pygments, the very capable syntax highlighting engine that can output HTML, and you’ve got a syntax highlighting QL plugin in under 100 lines of code!

Rather than host this project myself I’ve decided to try making a Google Code project. You can find it here:

http://code.google.com/p/qlcolorcode/

Enjoy!

If you do need access to a machine where you don’t have an ssh account there’s also FTPFS and others. There are a ton of FUSE filesystems and it’s now become a pretty simple task to port them to OS X. In the easiest cases it’s just a recompile.

Anyhow, big props to Amit Singh for doing a great service to the Mac community. Get MacFuse here.

I’m not going to cover setting up LIRC or choosing an IR transceiver, since those topics are covered in detail on the LIRC website. Let’s just say that there are many options available to you at pretty cheap prices, and if you’ve got any skill at all with a soldering iron you can build an IR transceiver for pocket change.

Discrete codes are almost always distributed in Philips Pronto format. It’s sort of the lingua franca of remote controls. What we really want is a nice little utility that reads a pronto code and spits out a LIRC config file. There’s lots of info out there on the pronto format and IR codes in general, but, sadly, no such utility exists, so we have to do things the hard way.

First, an overview of our strategy. When you push a button on a remote control it transmits a number to the device it controls. There are a variety of techniques manufacturers use for encoding numbers as IR pulses, but in the end it’s all about getting one number (or “code”) to that device. As you’ll see, it’s not too hard to get that code out of a pronto code, but it can be tricky to translate the encoding information to LIRC. What we’re going to do is let LIRC worry about all the encoding details by either using a pre-existing config file for the device or learning one from its remote. Once we have that config it’s trivial to insert the new discrete codes.

To start with, we need a LIRC config file for the device in question. I’m going to use the Roku Soundbridge as an example device here. If you’re lucky there’s a ready-made config file on the LIRC website for your device. If you’re really lucky it already has the discrete codes and you’re finished! For the Soundbridge I’m not so lucky¹. Thankfully we have the original remote, so we can use LIRC to build a config file. We fire up irrecord and follow the instructions (no need to actually record all the remote’s buttons), and pretty soon we have something like this:

begin remote

  name  soundbridge
  bits           16
  [snip]
  pre_data_bits   16
  pre_data       0xF609
  [snip]
      begin codes
          power                    0x6897
          menu                     0xE817
          [snip]
      end codes
end remote

There’s no need to understand everything in the file, so I’ve snipped out everything but the interesting parts. What do we see here? It looks like the Soundbridge remote sends 32-bit codes (a 16-bit header and a 16-bit code). The code for toggling power is 0xF6096897 and the code for the menu button is 0xF609E817. All the codes start with the same prefix (0xF609) so it’s only written once.

Now all we need is are the discrete power codes (we’ll call them power_on and power_off). These are normally provided in one of two ways — as pronto codes or .ccf files. We can use either one, but for now let’s assume you have a .ccf file. In fact, Roku Labs provides a .ccf file for the Soundbridge on their website. We’re going to use Tonto, the open-source ccf editor, to examine the contents of the .ccf file. I’m not going to talk about installing Tonto, just suffice to say that it’s much the same as setting up any other Java program.

So now we do the following steps (here’s a screenshot you can follow if you get lost):

1. Start Tonto
2. Load Soundbridge.ccf
3. Use the tree view on the left side to navigate to devices/soundbridge/extras
4. Double-click “extras” to open a view of the extras panel. The “power on” and “power off” buttons here are the discrete controls we’re looking for!
5. Double-click the “power on” button to examine its properties
6. Double-click the “[IR] Power On” line to see the details of the IR signal
7. Click the “Expert” button to see the “expert” details.

Bingo! In the expert details view there’s a HexValue field that reads f609c23d. Remember how our other codes started with F609? So all we need to do is add a line to the codes section of the LIRC config file:

      begin codes
          power                    0x6897
          menu                     0xE817
          power_on                 0xC23D
      end codes
end remote

Save this file in the appropriate place, point your IR transmitter at the Soundbridge (or whatever your device is), restart lircd, and try irsend SEND_ONCE soundbridge power_on. The power should turn on. Try it again and it should stay on. Yay! Now you can teach the code to your remote or use it with LIRC. Repeat with the rest of the codes you want to use and write macros that Just Work™.

One last detail. If you don’t have a full ccf file and just have the pronto code (a very long string of hex digits) for a command, you can still extract the code. In the first (non-expert) IR Signal dialog we saw in Tonto, the text field contains the pronto code for the button. If you paste in a different pronto code and then click “expert” you’ll see the hex code for that code. So just use any old ccf file you can find, any device, any button, and paste in the code you need. This is how I got the discrete power codes for my JVC TV.

[1] If you have a Soundbridge your luck should be much better now. I’ve sent in the Soundbridge config file to the LIRC developers so it should be in their database soon.

It took an expert like Mark, who's the coauthor of Windows Internals, quite a while to get to the bottom of this. Now imagine this was happening on a “Trusted” platform where even power-users like Mark would be powerless to undo the damage, and maybe you can see just how bad the situation can get. Media corporations have shown time and time again that they are not just disrespectful of customer rights but downright contemptuous of them. Any scheme like Treacherous Computing that involves trusting them to do the right thing is practically a guarantee of abuse.]]> http://www.n8gray.org/blog/2005/11/01/rootkit-brought-to-you-by-sony/feed/ 0 http://www.n8gray.org/blog/2005/10/24/hardware-links/ http://www.n8gray.org/blog/2005/10/24/hardware-links/#comments Tue, 25 Oct 2005 05:42:00 +0000 n8 http://www.n8gray.org/sandbox/wordpress/?p=51 Ever wanted to know the pinout of a PlayStation controller connector? How about how to build a null-modem cable? Who among us hasn't, at some point, wanted to build their own PS/2 to Serial Mouse adapter? Thanks to the folks at the Hardware Book, you can get all this information and more!

Once you've figured out the pinout of that Amiga Video connector and want to build a custom circuit, it's good to know how to make your own iron-on PCB masks using a laser printer and photo paper. Here's another site with lots of info.

Of course, you'll actually need to know a little bit about electronics to use this knowledge. These guys have some tutorials, and these guys have cool ideas.]]> http://www.n8gray.org/blog/2005/10/24/hardware-links/feed/ 1 http://www.n8gray.org/blog/2005/10/11/aux-in-hack-for-200506-subaru-legacyoutback-with-6-cd-changer/ http://www.n8gray.org/blog/2005/10/11/aux-in-hack-for-200506-subaru-legacyoutback-with-6-cd-changer/#comments Tue, 11 Oct 2005 14:42:00 +0000 n8 http://www.n8gray.org/sandbox/wordpress/?p=54 About a year ago I bought a 2005 Subaru Legacy wagon with an in-dash 6-CD changer. It's proven to be an excellent car, but it has one nagging flaw: there's no way to connect an iPod to the stereo. The usual way this is done for factory stereos without aux-in jacks is to use a kit to convert the CD changer input to an aux-in, but with the changer integrated into the stereo that's not an option. Another option would be to replace the whole stereo with a 3'rd party unit, but the Subie's stereo is integrated with the heating and AC controls

When all else fails, there's the option of using an FM modulator connected directly to the antenna input for the stereo. Amazingly enough, Subaru made even this option painful by using a non-standard antenna cable! Metra now sells the cable you need to make this work, but the sound quality for FM modulators is only marginally acceptable. Oh, and don't even mention those FM transmitters you find at Target–those just sound awful!

However, thanks to a couple of enterprising hardware hackers at legacygt.com my problem has been solved. A fine gentleman known as centerpunch made the whole thing possible, and another called jazzymt made it easy. The install requires you to dismantle the stereo and connect a circuit with an aux-in between the CD changer and the main stereo circuit board. I did the install myself this afternoon and thought I'd share some tips for anybody who wants to try it themselves. But first, the standard disclaimer. These tips are based on my experience with my car. I'm not an expert, and I don't know your car. Maybe they'll work for you, maybe they won't, but don't blame me if you break something trying to follow what I've written here.

There are three pieces of trim that will make your life difficult.

• The emergency-brake cover. This is the first thing you're asked to remove, and unfortunately it can be really tough to get out. It's hard to get a hold of because the driver's seat obstructs it. (It helps to lower the driver's seat completely if you have power seats.) The cover is held on by two clips, one at the front and one at the rear. If you're clever maybe you can figure out how to unclip them. If you're like me, on the other hand, you just have to grab the edge and pull straight up, really hard.
  
• The Silver ring around the shifter. (I have the automatic transmission, and this might not be a problem if you have the manual.) Prying that thing out was quite frightening. There it is, right in the middle of the cabin, all shiny, just waiting to be scratched, bent, or otherwise befouled. The trim underneath it gives a little too easily as you try to pry the ring up. It's scary stuff. To defeat it, here's what you need to know:
  • To pry up the ring, use a well-padded flat head screwdriver, and twist. To pad mine, I used the felt pad from the armrest cubby underneath the screwdriver and two playing cards on top of it.
  • The clips holding the ring in are on the sides, at the top and bottom. The one on the lower right is not quite at the bottom, but about an inch from the bottom. Dont pry anywhere else or you might bend the ring! Be as gentle as possible, and work each clip a little bit at a time.
  
  
• The arm rest console. This damned thing was the bane of my existence the first time I removed the stereo. There are two bolts inside the console that are easy enough to remove, but the two clips up near the shifter would not let go without a serious struggle! I was very concerned that I was going to break the console if I pulled with the amount of force required to detach those clips. I thought about drilling out the clip that's visible, but that wouldn't have helped with the hidden right-hand one. In the end, once again, brute force did the trick and nothing broke. Just pull straight up, really hard, and don't blame me if it breaks for you.

Here are some pictures that I took the first time I took apart the stereo, back in January. I've always found it helps to know the locations of the clips holding the trim in when I'm trying to take something out.]]> http://www.n8gray.org/blog/2005/10/11/aux-in-hack-for-200506-subaru-legacyoutback-with-6-cd-changer/feed/ 1 http://www.n8gray.org/blog/2004/07/27/gcc-preprocessor-defines/ http://www.n8gray.org/blog/2004/07/27/gcc-preprocessor-defines/#comments Tue, 27 Jul 2004 07:14:00 +0000 n8 http://www.n8gray.org/sandbox/wordpress/?p=74 Here's a useful tidbit that I thought I would share. If you want to find out all of the built-in #define's that GCC gives you, try this:

On recent versions of GCC this will give you a list of all the predefined macros. On older systems (I don't know how far back) you can try this:

It's harder to read, but many of the platform-specific macros are in there.]]> http://www.n8gray.org/blog/2004/07/27/gcc-preprocessor-defines/feed/ 2 http://www.n8gray.org/blog/2004/07/23/tag-generators-for-ocaml/ http://www.n8gray.org/blog/2004/07/23/tag-generators-for-ocaml/#comments Fri, 23 Jul 2004 07:37:00 +0000 n8 http://www.n8gray.org/sandbox/wordpress/?p=75 Throughout my programming career, I've found tags to be incredibly useful, so
when I started working in OCaml one of the
first things I sought out was a tag generator. (For those of you who don't
know, tags are essentially cross-references that allow you to find the
definition of any identifier in a program.) There are a handful of OCaml tag
generators out there, including:

• ocamltags: This is included with OCaml and appears to be Emacs-based. I've never figured out how to make it work.
  
  
• otags: Written by Cuihtlauac Alvarado and Jean-Francois Monin. This is based on a
  camlp4 parser, which suggests that it should be quite accurate. It also
  seems that you can use additional parsers with the -pa option. I've had a
  lot of success with this tagger, but as of this
  writing it hasn't been updated for OCaml 3.08. (older versions) (alternate
  link)
  
  
• taglet: Written by Issac Trotts. It's regex-based, so it won't work with custom camlp4
  preprocessor macros. The idea behind taglet is to
  only make tags for modules. The author belives that this ends up being
  easier to deal with than having tags for every identifier.
  I'm not so sure myself.

Leave a comment if you know of any other tag generators for OCaml!]]> http://www.n8gray.org/blog/2004/07/23/tag-generators-for-ocaml/feed/ 1