Mechanics of FLUXBABBITT.

The public discovery of FLUXBABBITT, a modestly-clever American spy gadget – that may or may not have been “fired in anger” yet – has provoked the usual flood of media garbage (“JTAG is a Chinese back door! Threat or menace?”) What follows is some basic investigation regarding the plausible workings of this device, based only on:

  • The leaked document itself.
  • A friend’s disassembled “Dell PowerEdge,” of several years’ vintage.
  • Intel’s published documentation for their “XDP” port.

Here is the port in question:

XDP socket in Dell PowerEdge - Depopulated.

XDP socket in Dell PowerEdge - Depopulated.

If you doubt your lying eyes, run – not walk – to your server closet and pop a Dell machine of recent manufacture. Remove the cooling duct cover. Look near the rear or front-most edge of the motherboard. You will find a similar picture.

But, threat or menace? Let’s find out; straight from the horse’s mouth:

3.10 Depopulating XDP for Production Units

At some point there may be a desire to remove the debug port from production units. It is recommended that the port real-estate and pads remain in place if they need to be populated for a future problem. Depopulate all physical devices (connector, termination resistors, jumpers) except: Termination of OBSFN_x[0:1] / BPM[4:5]# / PREQ#, PRDY#; Termination of TCK; Termination of TDI; Termination of TMS; Termination of TRSTn.

Intel Corp., “Debug Port Design Guide for UP/DP Systems.” p. 24.

Not exactly a bog-standard JTAG port (there is, in fact no particular standard for the socket, really; only for the bottom layer of the protocol) – from here you can access CPU registers, view and edit the contents of memory, issue bus read/write cycles, etc. AMD includes a similar (though incompatible) port in some of its products.

Presumably, FLUXBABBIT injects a little bit of nasty directly into RAM at boot time – quite like a traditional MBR infector. The somewhat-exotic delivery mechanism is there to counter a possible audit of the system firmware. (Why this audit would not be expected to include a basic physical inspection of the machine’s internals is a question that should be asked of our dear friends at Ft. Meade, not me.)

JTAG and other debug connectors are routinely found in mass-market products. The manufacturer often succumbs to the temptation of shaving a few pennies of unit cost by omitting the actual connector. This is what the leaked document refers to as “depopulated” (in fact, a standard term-of-art in electronics manufacture.)

The only thing even vaguely suspicious about Dell’s particular phantom debug port is: the pre-tinned solder pads. This could, however, be a mere artifact of the plating process undergone by the motherboard, rather than a deliberate helping hand for our favourite intelligence agency. (Attaching the missing connector would take all of five minutes for a fellow with a steady hand, a solder paste stencil, and a hot air machine – with or without pre-tinned pads.)

And regarding the doings of spies in general: there is really no limit as to what can be done to a physically-molested computer. Focusing on this particular feature is just the kind of tunnel-vision typical of the Computer Insecurity community.

If you’re wondering why there is no FLUXBABBIT in your own Dell, take comfort: the product is almost certainly obsolete. That is, rendered obsolete by “pwning” at design time. Physical molestation is reserved for archaic or otherwise uncooperative machinery.

This entry was written by Stanislav , posted on Tuesday January 07 2014 , filed under Cryptography, Distractions, Hardware, NonLoper, Photo, SoftwareArchaeology . Bookmark the permalink . Post a comment below or leave a trackback: Trackback URL.

11 Responses to “Mechanics of FLUXBABBITT.”

  • J.O. says:

    idk why people are so surprised.
    this kind of device looks like those modchips for old consoles
    they even have a similar purpose which is to subvert the security of the device

    • Stanislav says:

      Dear J.O.,

      Very similar. In exactly the same way that a surgeon is superficially similar to a maniac who cuts you open while you sleep.

      Yours,
      -Stanislav

    • Stanislav says:

      Dear lisposonx86,

      Reminiscent of “Movitz.”

      I took a similar approach myself, until I realized that poor bedrock abstractions (e.g. impedance mismatches) cannot be remedied by anything layered on top of them – regardless of how much you try.

      The “Lisp CPU” is actually the easiest part. Which is why everyone starts there. Now try adding networking, video, etc. device support without the Big Stupid creeping steadily back in.

      Yours,
      -Stanislav

  • lisposonx86 says:

    Ah, ok. :)

  • Jakub L says:

    Dear Stanislav,

    I’ve recently come across these two papers, and besides being fascinated,
    I couldn’t quite shake off the feeling of “Loper? Is that you?”

    Now, both papers hint at a necessity of a fairly sophisticated compilation step to implement their first-class
    environments efficiently, even on a dataflow machine, if I understand correctly. So, assuming that Loper has first-class environments (I assume it does, because a) fexprs and b) I believe you’d consider them the right thing), could you perhaps give a hint about how they are implemented (if you have a spare minute, that is)?

    All the best,
    Jakub

    P.S.: Sorry for the out-of-place comment.

    • Stanislav says:

      Dear Jakub L,

      Nope, wasn’t me.

      That being said, first-class environments aren’t the least bit new. And on the right kind of metal (e.g. SCHEME-79) you can get them ‘for free.’

      At the moment (and for the past year or so) I’m occupied with some of the lower-level aspects of the system – including, but not limited to the question of how to give the Von Neumann bottleneck a proper funeral. F-Exprs and other niceties must necessarily come later.

      Yours,
      -Stanislav

  • Yaroslav says:

    Dear Stanislav,

    Have you heard about Micron’s Automata Processor?

    http://www.micron.com/about/innovations/automata-processing

    Its description sounds quite alike to the dataflow architecture you were talking about. Micron presents it as the answer to the Von Neuman’s bottleneck. What do you think?

    Best regards,
    Yaroslav

    • Stanislav says:

      Dear Yaroslav,

      There have been plenty of people pushing something vaguely ‘dataflow-flavoured’, for quite some time. But there is a difference between selling a co-processing gadget with 65536 CPUs and making the jump to a complete abandonment of all existing von Neumann crud.

      As far as I know, all of the current players (e.g. Tilera) intend for their systems to be used as ‘number crunching’ co-processors with an otherwise bog-standard PC – similar to how GPU cards are used today; rather than as a total replacement for the von Neumann CPU. The latter would require a re-thinking of languages, compilers, OS, and virtually every other aspect of computing. Don’t look for the chip vendor willing to contemplate such a thing – there are none to be found.

      Yours,
      -Stanislav

  • Simon says:

    Hi Stanislav.

    Any comment on the Mt Gox meltdown, and what it means for bitcoin in general?

    • Stanislav says:

      Dear Simon,

      More or less: this.

      You can listen to Mr. P (who kindly shares some of the output of his elaborate private intelligence-gathering apparatus with the public, at no cost!) or you can listen to the unrepentant scammers, with their glossy magazines pushing ten thousand breeds of pyramid scheme.

      The folks who listened to Mr. P (whether or not they then chose to do business with his firm) still have their coin. As for the others…

      Yours,
      -Stanislav

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre lang="" line="" escaped="" highlight="">