The Smell of Molten Projects in the Morning

Ed Nisley's Blog: Shop notes, electronics, firmware, machinery, 3D printing, laser cuttery, and curiosities. Contents: 100% human thinking, 0% AI slop.

Category: Software

General-purpose computers doing something specific

  • Arduino: Using Ancient Litronix DL-1414 LED Displays

    Tek 492 Memory Board Reader
    Tek 492 Memory Board Reader

    While I was putting together the Tek 492 memory board reader, I though it’d be a nice idea to add a small display. While the Arduino has USB serial I/O, the update rate is fairly pokey and an on-board display can provide more-or-less real time status.

    Given that the reader was built for an early-80s memory board, I just had to use a pair of Litronix DL-1414 4-character LED displays from my parts heap. The DL-1414 datasheet [Update: link rot? try that] proudly proclaims:

    The 0.112″ high characters of the DL1414T gives readability up to eight feet. The user can build a display that enhances readability over this distance by proper filter selection.

    I think that distance is exceedingly optimistic.

    DL-1414 LED display schematic
    DL-1414 LED display schematic

    However, I needed to see only a few feet to the benchtop. Even better, adding the displays required no additional hardware: the SPI-driven shift registers on the board already had address and data lines, plus a pair of unused bits for the write strobes. What’s not to like?

    This schematic connects to the one you just clicked on; the two big blue bus lines are the same bus as in that schematic.

    If you don’t have anything else riding the data bus, adding a pullup on the D7 bit that isn’t used by these displays will make all the bits float high; the DL-1414s seem to pull their inputs upward. That came in handy when I was debugging the EPROM-burning code, because reading data without an EPROM in the socket produced 0xff, just like an erased EPROM byte.

    The two displays are the dark-red rectangle in the lower-right of the first picture, covered with a snippet of the Primary Red filter described there.

    These closeups, without and with the filter, demonstrate why you really, really need a filter of some sort.

    DL1414 Unfiltered
    DL1414 Unfiltered
    DL1414 Filtered
    DL1414 Filtered

    Using the displays is straightforward, given the hardware-assisted SPI code from there. You could actually do it with just the I/O pins on an Arduino board, but you wouldn’t be able to do anything else. If you don’t have any other SPI registers, you could get away with a pair of HC595 outputs:  7 data + 2 address + 2 strobes + 5 outputs left over for something else.

    A few constants set the display size and a global buffer holds the characters:

    #define LED_SIZE            4            // chars per LED
    #define LED_DISPLAYS        2            // number of displays
    #define LED_CHARS           (LED_DISPLAYS * LED_SIZE)
    
    char LEDCharBuffer[LED_CHARS + 1];       // raw char buffer, can be used as a string
    

    A routine to exercise the LEDs by scrolling all 64 characters they can display goes a little something like this:

    Serial.println("Exercising LED display ...");
    
     Outbound.Controls |= CB_N_WRLED1_MASK | CB_N_WRLED0_MASK;        // set write strobes high
     digitalWrite(PIN_DISABLE_DO,LOW);                                // enable data outputs
    
     while (digitalRead(PIN_PB)) {
    
      digitalWrite(PIN_HEARTBEAT,HIGH);
    
      byte Character, Index;
    
      for (Character = 0x20; Character < 0x60; ++Character) {
       for (Index = 0; Index < LED_CHARS; ++Index) {
        LEDCharBuffer[Index] = Character + Index;
       }
       UpdateLEDs(LEDCharBuffer);
       delay(500);
    
       if (!digitalRead(PIN_PB)) {
        break;
       }
      }
    
      digitalWrite(PIN_HEARTBEAT,LOW);
     }
    
     WaitButtonUp();
    

    A routine to plop a string (up to 8 characters!) on the LEDs looks like this:

    void UpdateLEDs(char *pString) {
    byte Index = 0;
    
     while (*pString && (Index < LED_CHARS)) {
    
      Outbound.DataOut = *pString;           // low 6 bits used by displays
      Outbound.Address = ~Index;             // low 2 bits used by displays, invert direction
      Outbound.Controls &= ~(Index < LED_SIZE ? CB_N_WRLED1_MASK : CB_N_WRLED0_MASK);
    
      RunShiftRegister();
    
      digitalWrite(PIN_DISABLE_DO,LOW);      // show the data!
    
      Outbound.Controls |= CB_N_WRLED1_MASK | CB_N_WRLED0_MASK;
      RunShiftRegister();
    
      digitalWrite(PIN_DISABLE_DO,HIGH);     // release the buffers
    
      ++pString;
      ++Index;
     }
    
    

    You can use sprintf() to put whatever you like in that string:

    void ShowStatus(word Address,byte Data) {
    
     sprintf(LEDCharBuffer,"%04X  %02X",Address,Data);
     UpdateLEDs(LEDCharBuffer);
    
    }
    

    Not, of course, that anybody would actually use DL-1414 displays in this day & age, but the general idea might come in handy for something more, mmmm, elegant…

  • Tektronix 492 Spectrum Analyzer ROM and EPROM HEX Files

    Tek 492 Memory Board
    Tek 492 Memory Board

    Having gotten my buddy Eks back on the air with new EPROMs for his Tek 492 spectrum analyzer, here are the Tek 492 ROM Images (← that’s the link to the file!) you’ll need to fix yours.

    [Update: the comments for that post have pointers to other images and a clever hack to use a standard EPROM. If you’re not a stickler for perfection, that’s the way to go.]

    They’re taken from a “known good” Tek 492, so they should work fine: the firmware verifies the checksum in each chip as part of the startup tests; if it’s happy, we’re happy.

    Because WordPress doesn’t allow ZIP files, I tucked the HEX files into an OpenDocument file that also contains the pinouts and some interposer wiring hints & tips.

    If you’re using the OpenOffice.org word processor, you’re good to go. Open the document and get all the instructions you need to extract the files and put them to good use.

    If you’re not using OOo, then choose one of:

    • Install OpenOffice.org (it’s free software, so kwitcher bitchin’)
    • Futz with whatever Microsoft claims will import ODT files (if it doesn’t work, don’t blame me)
    • Just extract the HEX files and do whatever you want (if you know what you want)

    The trick, explained in the document itself, is that ODT files are just ZIP files with a different file extension, so any unzip program will unpack them. You won’t see the HEX files in the document, you must apply unzip to the ODT file itself.

    After unzipping, you’ll find three HEX files in the directory that originally held the ODT file, along with the collection of files that make up the OpenDocument document.

    The only files you care about:

    U1012 – 160-0886-04.hex
    U2023 – 160-0838-00.hex
    U2028 – 160-0839-00.hex

    Use ’em in good health…

    Oh, if you haven’t already figured it out, the DIP switch on your board is also bad. Saw the damn thing apart with a Dremel tool, pry off the debris, unsolder the pins, and install a new one. Just Do It.

  • Tree Frog: The Video

    Frog walking on tent
    Frog walking on tent

    Watching the tree frogs crawl up the tent from inside let us see how they move: hand-over-hand up the fabric. A dozen of them crawling along was spooky…

    I took a movie with my pocket camera that turned into an 8 MB AVI, which I can’t upload here. Most of it isn’t all that interesting, anyway, an observation which hasn’t stopped YouTube dead in its tracks yet, but we can do better than that.

    A pair of Free Software programs extracts the interesting part and produces a (somewhat) smaller animated GIF that works with WordPress.

    First, shatter the AVI into separate JPG images:

    mkdir frames
    ffmpeg -i cimg3781.avi -sameq frames/frame-%03d.jpg

    A bit of browsing showed that I wanted frames 227 through 265 and that the frog was pretty much in the upper-middle of the image. So, crop a 320×240 image around the frog from those 640×480 frames:

    cd frames
    mkdir stills
    for f in `seq 227 265` ; do convert frame-$f.jpg -crop 320x240+160+60 stills/still-$f.jpg ; done

    Then convert them into an animated GIF with a 500-ms frame rate (the -delay ticker is 10 ms):

    cd stills
    convert -delay 50 still-2* frogwalk.gif

    It’s a 1.6 MB wad, but gets the message across: frogs keep three paws stuck to the floor.

    Remember, that little guy is moving at glacial speed in the GIF: those 40 frames of video last just over a second in real time.

    Memo to self: MPEG-1 and MPEG-2 only support video-style frame rates around 30 fps.

    Update: Regular reader Przemek Klosowski showed me how to generate those numeric sequences on the fly, without using a for loop:

    There's this neat Bash construct {1..10} that you can use directly after ffmpeg:
    convert -delay 50 still-{227..430}* result.gif
    
    You can even skip every nth frame:
    convert -delay 50 still-{227..430..5}* result.gif
    

    Thanks!

  • Useful Hex and Binary File Utilities

    I’m doing some work with a one-off ROM reader & EPROM programmer, so it’s once again time to mess around with Intel HEX files, raw binary images, and the like.

    The key routine (which runs on an Arduino Decimila) to dump a ROM in HEX format goes like this, with all the constants & variables & functions doing the obvious things:

    void DumpHC641(void) {
    
    word Address,Offset;
    byte DataRd,Checksum;
    
     for (Address = 0; Address < ROM_SIZE; Address += IHEX_BYTES) {
      sprintf(PrintBuffer,":%02X%04X00",IHEX_BYTES,(word)Address);           // emit line header
      Serial.print(PrintBuffer);
      Checksum = IHEX_BYTES + lowByte(Address) + highByte(Address) + 0x00;   // record type 0x00
      for (Offset = 0; Offset < IHEX_BYTES; ++Offset) {
       digitalWrite(PIN_HEARTBEAT,HIGH);
       DataRd = ReadHC641(Address + Offset);
       digitalWrite(PIN_HEARTBEAT,LOW);
       Checksum += DataRd;
       sprintf(PrintBuffer,"%02X",DataRd);                                   // data byte
       Serial.print(PrintBuffer);
      }
      Checksum = -Checksum;                                                  // two's complement
      sprintf(PrintBuffer,"%02X",Checksum);
      Serial.println(PrintBuffer);
     }
     Serial.println(":00000001FF");                                          // emit end-of-file line
    }
    

    So getting an Intel HEX file is just a matter of capturing the serial output, whacking off any debris on either side of the main event, and saving it.

    The srec_cat program handles conversions among a myriad formats, most of which I can’t even pronounce. The few I use go a little something like this:

    srec_cat mumble.hex -intel -o mumble.bin -binary
    srec_cat mumble.bin -binary -o mumble.hex -intel
    srec_cat mumble.bin -binary -o mumble.txt -hex_dump
    srec_cat -generate 0x0000 0x2000 -constant 0x00 -o mumble.txt -intel
    

    It’s sometimes handy to apply srec_cat to a group of similarly suffixed files, in which case some Bash string chopping comes in handy. For example, to convert some hex files into binary:

    for f in 27HC641*hex ; do echo ${f%%hex} ; srec_cat "$f"  -intel -o "${f%%hex}"bin -binary ; done
    

    Good old diff works fine on text files, but in this case it’s better to see which bytes have changed, rather than which lines (which don’t apply in the context of a binary file). The vbindiff program looks great on a portrait-mode display.

    I don’t do much binary editing, but tweak serves my simple needs. Confusingly, members of this class of program are called “hex editors”, but they really work on binary files.

    There’s also diff3, for those rare cases where you must mutually compare three text files. Makes my head spin every time…

    All those programs are likely packages in your favorite Linux distro.

  • Arduino Hardware-assisted SPI: Synchronous Serial Data I/O

    Many interesting projects require more digital output bits than the Arduino hardware can support. You then use 74HC595 serial-in/parallel-out chips and that tutorial pretty well explains how it works. The shiftOut() library function squirts a byte out through an arbitrary pin, leading with either the high or low bit.

    Software SPI: Clock and Data
    Software SPI: Clock and Data

    Just drop one byte into shiftOut() for each ‘595 lined up on your board. Remember to latch the bits (LOW-to-HIGH on RCK @ pin 12 of the ‘595) and enable the output drivers (LOW on -G @ pin 13, similarly) when you’re done sending everything. You can have separate latches-and-enables for each ‘595 if that suits your needs, although then you once again run out of Arduino bits pretty quickly. It’s entirely possible to devote a ‘595 to latches-and-enables for the rest of the chain, but that gets weird in short order.

    The scope shot shows that shiftOut() ticks along at 15 µs per bit (clock in the upper trace, data in the lower trace). For back-of-the-envelope purposes, call it 8 kB/s, which is probably less than you expected. If you have a string of 5 external bytes, as I did on a recent project, that’s only 1600 updates / second. It was part of a memory board reader & EPROM programmer: reading an 8 kB ROM chip requires two shift-register runs (one to set the address & data, one to read in the chip output), so the overall rate was on the order of 10 seconds per pass and much worse for programming. You can optimize the number of bits by not shifting out all the bytes, but that’s the general idea.

    Because ‘595 chips are output-only, in order to get 8 bits of data into the Arduino board, add a 74HC166 parallel-in/serial-out chip to the string. Alas, shiftOut() doesn’t know about input bits, so you’re on your own.

    Hardware SPI: Clock and Data
    Hardware SPI: Clock and Data

    If you’re going to have to write some code to get input bits anyway, you may as well use the ATmega168 (and its ilk) hardware SPI as it was intended to be used: for high-speed synchronous serial I/O. This scope shot shows the SPI clock (in the top trace again) ticking along at 1 µs per bit, which is 1/16 the Diecimila’s oscillator frequency. You can pick any power of two between 1/2 and 1/128; I used 1/16 because it’s fast enough to make the rest of the software the limiting factor, while slow enough to not require much attention to layout & so forth.

    Start by Reading The Fine Manual section about the ATmega168’s SPI hardware, starting at page 162.

    The pin definitions, being lashed to internal hardware, are not optional. Note that SCK is also the standard Arduino LED, which won’t be a problem unless you need a tremendous amount of drive for a zillion ‘595s. I stuck an additional LED on Arduino digital pin 2.

    #define PIN_HEARTBEAT     2             // added LED
    #define PIN_SCK          13             // SPI clock (also Arduino LED!)
    #define PIN_MISO         12             // SPI data input
    #define PIN_MOSI         11             // SPI data output
    

    Initial hardware setup goes in the usual setup() function:

    pinMode(PIN_SCK,OUTPUT);       // set up for "manual" SPI directions
    digitalWrite(PIN_SCK,LOW);
    pinMode(PIN_MOSI,OUTPUT);
    digitalWrite(PIN_MOSI,LOW);
    
    pinMode(PIN_MISO,INPUT);       // configure inputs
    digitalWrite(PIN_MISO,HIGH);
    
    SPCR = B01110001;              // Auto SPI: no int, enable, LSB first, master, + edge, leading, f/16
    SPSR = B00000000;              // not double data rate
    

    Basically, the “manual” setup allows you to wiggle the bits by hand with the hardware SPI control disabled.

    Arduino Hardware SPI Schematic
    Arduino Hardware SPI Schematic

    Here’s a chunk of the schematic so you can see how the bits rattle around. You’ll surely want to click it to get the details…

    I put the data in a structure that matches the shift register layout, with the first byte (Controls) connected to the ATmega’s MOSI pin and the last byte (DataIn) connected to MISO. The SCK pin drives all of the serial clock pins on the ‘595 and ‘166 chips in parallel. Your structure will certainly be different; this was intended to suck data from a Tek 492 Spectrum Analyzer memory board.

    typedef struct {      // external hardware shift register layout
     byte Controls;       // assorted control bits
     word Address;        // address value
     byte DataOut;        // output to external devices
     byte DataIn;         // input from external devices
    } SHIFTREG;
    
    SHIFTREG Outbound;    // bits to be shifted out
    SHIFTREG Inbound;     // bits as shifted back in
    

    The functions that make it happen are straightforward:

    void TogglePin(char bitpin) {
     digitalWrite(bitpin,!digitalRead(bitpin));
    }
    void PulsePin(char bitpin) {
     TogglePin(bitpin);
     TogglePin(bitpin);
    }
    
    void EnableSPI(void) {
     SPCR |= 1 << SPE;
    }
    
    void DisableSPI(void) {
     SPCR &= ~(1 << SPE);
    }
    
    void WaitSPIF(void) {
     while (! (SPSR & (1 << SPIF))) {
    //        TogglePin(PIN_HEARTBEAT);       // use these for debugging!
    //        TogglePin(PIN_HEARTBEAT);
     continue;
     }
    }
    
    byte SendRecSPI(byte Dbyte) {             // send one byte, get another in exchange
     SPDR = Dbyte;
     WaitSPIF();
     return SPDR;                             // SPIF will be cleared
    }
    
    void CaptureDataIn(void) {                // does not run the shift register!
     digitalWrite(PIN_ENABLE_SHIFT_DI,LOW);   // allow DI bit capture
     PulsePin(PIN_SCK);                       // latch parallel DI inputs
     digitalWrite(PIN_ENABLE_SHIFT_DI,HIGH);  // allow DI bit shifting
    }
    
    void RunShiftRegister(void) {
     EnableSPI();                             // turn on the SPI hardware
    
     Inbound.DataIn  = SendRecSPI(Outbound.DataIn);
     Inbound.DataOut = SendRecSPI(Outbound.DataOut);
    
     Inbound.Address  =         SendRecSPI(lowByte(Outbound.Address));
     Inbound.Address |= ((word) SendRecSPI(highByte(Outbound.Address))) << 8;
    
     Inbound.Controls = SendRecSPI(Outbound.Controls);
    
     PulsePin(PIN_LATCH_DO);                   // make new shift reg contents visible
     PulsePin(PIN_LATCH_ADDRESS);
     PulsePin(PIN_LATCH_CONTROLS);
    
     DisableSPI();                             // return to manual control
    }
    

    Actually using the thing is also straightforward. Basically, you put the data-to-be-sent in the Outbound variables and call RunShiftRegister(), which drops output bytes into SPDR and yanks incoming bytes out, then stuffing them in the Inbound variables. I have separate latch controls for the Controls, Address, and Data chips, although I don’t use them separately here.

    You must wiggle the parallel latch enable line on the 74HC166 chip before shifting to capture the data, as shown in CaptureDataIn(). That chip also requires a separate pulse on its serial clock line to latch the data, which you do manually with the hardware SPI disabled. If you’re paying attention, you’ll wonder if that clock pulse also screws up the data in the rest of the chips: yes, it does. If this is a problem, you must add some external clock-gating circuitry, disable the ‘595s, or pick a different input shift register chip; it wasn’t a problem for what I was doing.

    Here’s a function that reads data from a RAM chip on the Tek memory board, so it must write the address and read the RAM chip’s output. The PIN_DISABLE_DO bit controls the output buffers on the ‘595 that drives the RAM’s data pins; they must be disabled to read data back from the RAM. Don’t worry about the other undefined bits & suchlike; just assume everything does what the comments would have you believe.

    byte ReadRAM(word Address) {
     digitalWrite(PIN_DISABLE_DO,HIGH);            // turn off data latch output
     digitalWrite(PIN_BUS_READ,HIGH);              // allow RAM read access
    
     Outbound.Controls |=  CB_BUS_CLKPH2_MASK;     // set up RAM -CS gate
     Outbound.Address = Address;
     Outbound.DataOut = 0x55;                      // should not be visible
     RunShiftRegister();
    
     digitalWrite(PIN_BUS_N_SYSRAM,LOW);           // activate RAM -CS
     CaptureDataIn();                              // latch RAM data
     digitalWrite(PIN_BUS_N_SYSRAM,HIGH);          //  ... and turn -CS off
    
     Outbound.Controls &= ~CB_BUS_CLKPH2_MASK;     // disable -CS gate
     RunShiftRegister();                           // tell the board and get data
    
     return Inbound.DataIn;
    }
    
    Hardware SPI - Detail of clock and data timing
    Hardware SPI – Detail of clock and data timing

    Here’s a detailed shot of the outbound bit timing. Notice that the upward clock transitions shift bits into the ‘595 and ‘166 chips, while the SPI output data changes on the downward transitions. You can tweak that to match your hardware if you’re using different shift register chips, by messing with the SPCR settings.

    Bottom line: using the ATmega168 hardware SPI provided a factor-of-15 speedup and serial digital input, too.

  • Displaying Variables in Gnuplot

    Sample plot with regression line & variables
    Sample plot with curve-fit line & variables

    Gnuplot can do curve fitting (of all kinds) and parks the coefficients in variables. In general, you’d like to display those values on the final plot for later reference…

    The trick is using the sprintf() function, which behaves largely like the C version, to insert the variable into a formatted string for use in the label command.

    I drive Gnuplot with shell scripts, which simplifies introducing parameters & suchlike. That’s conspicuous by its absence here, but when you need it, you need it bad.

    The script to generate that plot looks like this, with some key points in the highlighted lines:

    #!/bin/sh
    export GDFONTPATH="/usr/share/fonts/truetype/msttcorefonts/"
    gnuplot << EOF
    set term png font "arialbd.ttf" 18 size 950,600
    set output "Calibration Curve - Full.png"
    set title "Calibration Curve - Full"
    set key noautotitles
    unset mouse
    set bmargin 4
    set grid xtics ytics
    set xlabel "10^5/ADC"
    set format x "%3.0f"
    set ylabel "Resistance - Ohm"
    set format y "%3.0f"
    set yrange [0:100]
    set datafile separator "\t"
    f(x) = m*x + c
    fit f(x) "Measurements/Calibration.csv" using 3:1 via m,c
    set label 1 sprintf("m = %3.4f",m) at 510,75 font "arialbd,18"
    set label 2 sprintf("c = %3.4f",c) at 510,70 font "arialbd,18"
    plot    \
     "Measurements/Calibration.csv" \
     using 3:1 with linespoints lt 3 lw 3 pt 3 , \
    f(x) lt 4 lw 2 
    EOF
    

    The dataset for that plot is tucked into the obvious file and looks like this, with tabs between the columns:

    # ESR Calibration Curve
    # Resistance    ADC Decimal    Reciprocal
    0.0    492    203
    0.1    489    204
    1.0    461    217
    1.2    456    219
    1.5    447    224
    1.8    440    227
    2.0    432    231
    2.3    428    234
    2.4    423    236
    2.7    414    242
    3.3    400    250
    3.8    387    258
    4.3    378    265
    4.7    367    272
    5.0    360    278
    5.5    350    286
    6.3    332    301
    6.7    329    304
    8.1    306    327
    9.1    293    341
    9.9    284    352
    21.0    182    549
    33.0    126    794
    47.0    90    1111
    67.0    60    1667
    73.0    54    1852
    83.0    47    2128
    92.0    41    2439

    There is no denying that a straight line is not the best fit to that dataset, but that’s not the point.

    Memo to Self: the set label commands go between the fit and the plot. Remember to add the f(x) to the plot function…

  • Why Friends Don’t Let Friends Use Windows: Torpig

    For those of you still using Windows, here’s a sobering look at why you shouldn’t: an analysis of the Torpig botnet by an academic group that managed to take over its command & control structure for a few days.

    The report is tech-heavy, but well worth the effort to plow through.

    Here are some of the high points…

    Why do the bad guys do this? It’s all about the money, honey:

    In ten days, Torpig obtained the credentials of 8,310 accounts at 410 different institutions.

    … we extracted 1,660 unique credit and debit card numbers from our
    collected data.

    Does an antivirus program help?

    Torpig has been distributed to its victims as part of Mebroot. Mebroot is a rootkit that takes control of a machine by replacing the system’s Master Boot Record (MBR). This allows Mebroot to be executed at boot time, before the operating system is loaded, and to remain undetected by most anti-virus tools

    In these attacks, web pages on legitimate but vulnerable web sites are modified with the inclusion of HTML tags that cause the victim’s browser to request JavaScript code from a[nother] web site under control of the attackers. This JavaScript code launches a number of exploits against the browser or some of its components, such as ActiveX controls and plugins. If any exploit is successful, an executable is downloaded from the drive-by-download server to the victim machine, and it is executed.

    What happens next?

    Mebroot injects these modules […] into a number of applications. These applications include the Service Control Manager (services.exe), the file manager, and 29 other popular applications, such as web browsers (e.g., Internet Explorer, Firefox, Opera), FTP clients (Leech-FTP, CuteFTP), email clients (e.g., Thunderbird, Outlook, Eudora), instant messengers (e.g., Skype, ICQ), and system programs (e.g., the command line interpreter cmd.exe). After the injection, Torpig can inspect all the data handled by these programs and identify and store interesting pieces of information, such as credentials for online accounts and stored passwords.

    If you think hiding behind a firewall router will save you, you’re wrong:

    By looking at the IP addresses in the Torpig headers we are able to determine that 144,236 (78.9%) of the infected machines were behind a NAT, VPN, proxy, or firewall.

    If you think you’ve got a secure password, you’re wrong:

    Torpig bots stole 297,962 unique credentials (i.e., username and password pairs), sent by 52,540 different Torpig-infected machines over the ten days we controlled the botnet

    If you think a separate password manager will save you, you’re wrong.

    It is also interesting to observe that 38% of the credentials stolen by Torpig were obtained from the password manager of browsers, rather than by intercepting an actual login session.

    Somewhat more info on Mebroot from F-Secure.

    Remember, the virus / worm / Trojan / botnet attacks you read about all the time only affect Windows machines. Linux isn’t invulnerable, but it’s certainly safer right now. If you’re running Windows, it’s only a matter of time until your PC is not your own, no matter how smart you think you are.

    If you have one or two must-gotta-use Windows programs, set up a dedicated Token Windows Box and use it only for those programs. Network it (behind a firewall) if you like, but don’t do any email / Web browsing / messaging / VOIP on it. Just Say No!

    For everything else, run some version of Linux. It’ll do what you need to get done with less hassle and far less risk. It’s free for the download, free for the installation, and includes all the functions you’re used to paying money for. Just Do It!

    If you think using Linux is too much of a hassle, imagine what putting your finances back together will be like. Remember, the bad guys will steal everything you’ve ever put on your PC, destroy your identity, and never get caught.

    Now you know… why are you still stalling?