Solder Time! FaceDancer11 and GoodFET41 Assembly

By Brad Antoniewicz and Tushar Dalvi.

At Recon 2012 Travis Goodspeed and Sergey Bratus released the Facedancer, an extremely flexible piece of hardware for emulating and tinkering with USB devices. Although the Facedancer is very much it's own device, it evolved from another one of Travis Goodspeed's projects, the GoodFET, which is his own customized Flash Emulation Tool debugger for the MSP430 microcontroller.

The PCBs for each device can be ordered online however, the devices are not currently available pre-assembled. So if you want to play with them, you'll need to learn how to solder! Although some may see this as a pain, I personally love it and hope assembled boards are never released - it forces people to learn the fundamentals of what they're doing.

I've done almost no surface mount soldering before and have always wanted to play with USB so the Facedancer was a perfect project for me. Although I don't have much use for the GoodFET, two were generously included within my shipment, so I ordered the spare components and built them too.

Components

Both the Facedancer and GoodFET include a parts list on their description pages but when you go to order them from any supplier, you'll quickly realize there are a seemingly endless combination of options to choose from. After spending some time putting together an actual order, I jumped on #goodfet and asked for a little help. Luckily the channel is populated with hardware rock stars like Michael Ossmann and dragorn who were kind enough to help redefine my order, pointing out corrections to the online parts list that weren't published yet and alternate crystal options. Throughout the entire assembly process, these two defied standard irc help channel etiquette by offering extremely useful tips and troubleshooting suggestions - These guys ROCK!

In the end, here's the detailed part list I used. Everything was ordered from DigiKey, since that's were I bought my first 6.5535MHz crystal. I made a reddit post, just in case you want to add any updates.

• http://www.reddit.com/r/netsec/comments/10g7f0/goodfetfacedancer_parts_list/

Package	Pg. Description	DigiKey Part	DigiKey Description
SSOP28	FT232RL	768-1007-1-ND	IC USB FS SERIAL UART 28-SSOP
QFP64	MSP430F2618TPM	MSP430F2618TPM	IC MCU 16BIT 116K FLASH 64-LQFP
LQFP32	MAX3420E	MAX3420EECJ+-ND	IC USB PERIPH CONTROLLER 32TQFP
0603	1.0µF Capacitors	587-1242-1-ND	CAP CER 1UF 10V 10% X7R 0603
0603	0.1µF Decoupling Capacitors	490-1532-1-ND	CAP CER 0.1UF 16V 10% X7R 0603
0603	18pF Capacitors	445-1272-1-ND	CAP CER 18PF 50V 5% NP0 0603 (see note)
0603	27pF Capacitors	490-1413-1-ND	CAP CER 27PF 50V 5% NP0 0603
HC49/UP**	12MHz SMD Crystal, 18pF	535-10218-1-ND	CRYSTAL 12.000 MHZ 18PF SMD
0603	0603 LED	754-1121-1-ND	LED 1.6X0.8MM 568NM GRN CLR SMD
0603	330R LED Series Resistors	RMCF0603JT330RCT-ND	RES 330 OHM 1/10W 5% 0603 SMD
0603	33R USB Series Resistors	RMCF0603JT33R0CT-ND	RES 33 OHM 1/10W 5% 0603 SMD
N/A	USB Mini Receptacle UX60-MB-5ST	ED2992CT-ND	CONN USB MINI B R/A SMD

Note: Although the 18pF capacitor might be a good capacitor, it is not ideal for the chosen crystal so the 27pF cap was chosen

Tools

Here's a list of tools I used to put it all together. Hopefully you have most of these already:

Soldering Iron. One of the biggest things is to get a good soldering iron - leave the crappy radio shack one on the shelf and get one with temperature control and a fine tip. I went for the Weller WES51.
Flux! You won't understand how amazing this is until you use it. Then you'll question what the heck you were doing without out. I used the RadioShack stuff. Its messy, dragorn recommended ChipQuik No Clean Flux.
Head mounted magnifier - There's probably a more official name for this :) It was extremely useful to have a head mounted magnifier over those stupid helping hands. I bought this one.
Tweezers - Impossible to place surface mount capacitors without these guys. I used the Wiha 7a SA-ESD, which I think these are close to.
Tip Cleaner. This helps keep the tip clean and help with spreading the solder when its dirty and needs to be tinned. This is the Hakko 599B.
Multimeter - Extremely important for any electronics project. This is the Extech 430
Desoldering Braid - Helps when you mess up. So much easier to when you use a little flux with it. I used the RadioShack stuff.
Solder - I used the RadioShack's 0.022" solder, that they don't have on their site.
Hot Plate - When I started this project out, I was really excited to do some hot plate reflow. Before you buy anything, read the rest of this article :) This is the Brentwood TS-337
Soldering Paste - For hotplate reflow. I used the No Clean Zeph Paste. They didn't ship me the fine tips I ordered and haven't responded to any of my emails. :/
Infrared Thermometer - Needed for the hot plate reflow, this is the Kintrex IRT0421

Hot Plate Reflow

I wanted to try out the hot plate reflow technique because it looked really easy and seemed like a fun way to get everything done quickly. I also came across another great blog post showing how someone else used it for an earlier GoodFET, which helped me make my decision.

Here's a quick video I put together showing the process:



Overall, I feel like hotplate reflow is cool but I don't know that it was really needed. I sort of cheated by running a super thin line of paste down across all of the pads on the PCB rather then being more precise with a toothpick. Since the paste didn't flow smoothly out of the syringe, I ended up getting uneven globs which eventually turned into bridges once the reflow completed. To fix the bridges, I ended up drag soldering (which is one of the most popular ways to hand solder surface mount components) so I could have probably just skipped the hotplate entirely. Also, the hotplate temperature is pretty hard to control, after completing the first board it took a long time for the plate to decrease in temperature, I got impatient and threw on the next board which put me pretty close to frying everything.

Drag Soldering

For future projects, I'll be drag soldering my surface mount components. It's just plain easy. Turn your soldering iron to about 725F, place the component, apply a generous amount of flux, tack down one pin to hold everything in place then semi-slowly drag the iron over multiple pins. The solder will hop from pin to pin leaving just enough to hold the part in place. This is an awesome video by Curious Inventor demonstrating the method:

Troubleshooting

Once I had everything assembled, I connected it to my system and discovered the FT232R chip was not being recognized. I used the audible continuity tester on my multimeter to debug the issue. Starting from the host side USB connector, I tested the paths between the connector and the FTDI input pins which quickly revealed I had a small solder bridge. I used a some flux with the desoldering braid to clean it up and then drag soldered it a little more to make sure I had a good joint.

After that I gave everything a close inspection under magnification again and noticed a couple more tiny bridges. As I removed them, I accidentally broke one of the pins off of the MSP430. Normally this would be an issue, but since the pin wasn't used, it was ok to leave it alone. I reconnected the Facedancer to my computer and it worked!

Software

Once everything is assembled on the Facedancer, connect the host side to your system. dmesg should show a similar set of logs:

 root@bt:~# dmesg
[7097779.953802] ftdi_sio 5-1:1.0: FTDI USB Serial Device converter detected
[7097779.953882] usb 5-1: Detected FT232RL
[7097779.953889] usb 5-1: Number of endpoints 2
[7097779.953896] usb 5-1: Endpoint 1 MaxPacketSize 64
[7097779.953903] usb 5-1: Endpoint 2 MaxPacketSize 64
[7097779.953909] usb 5-1: Setting MaxPacketSize 64
[7097779.955746] usb 5-1: FTDI USB Serial Device converter now attached to ttyUSB0

And you'll also see a FTDI entry using lsusb

 root@bt:~# lsusb
Bus 005 Device 045: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC

Next you'll need to install the prerequisites, download all of the supporting code from the SVN server, and build the client

 root@bt:~# apt-get install python-sqlite python-serial
 root@bt:~# svn co https://goodfet.svn.sourceforge.net/svnroot/goodfet
 root@bt:~# cd goodfet/trunk/client
 root@bt:goodfet/trunk/client# make link

You can define the board you're using via the board environment variable. I tend to use different boards so I'll specify it on the command line. It's recommended that you first backup the info flash (be sure to store it in info.txt) from the board before installing the firmware, to do so:

 root@bt:goodfet/trunk/client# board=facedancer11 goodfet.bsl --dumpinfo > info.txt

Now we can install the firmware:

 root@bt:goodfet/trunk/client# board=facedancer11 goodfet.bsl --fromweb

This may or may not work for you. As of 11/26, you'll get this error:

 The --fromweb feature is temporarily disabled, pending a rewrite.
 Please grab a copy of the appropriate .hex from
 http://goodfet.sf.net/dist/ and flash it like so:

 goodfet.bsl -e -p foo.hex

So let's manually download and install:

 root@bt:goodfet/trunk/client# wget http://goodfet.sourceforge.net/dist/facedancer11.hex
 root@bt:goodfet/trunk/client# board=facedancer11 goodfet.bsl -e -p facedancer11.hex
 MSP430 Bootstrap Loader Version: 1.39-goodfet-8
 Mass Erase...
 Transmit default password ...
 Invoking BSL...
 Transmit default password ...
 Current bootstrap loader version: 2.13 (Device ID: f26f)
 Program ...
 4932 bytes programmed.

Once everything has completed, just run a quick test to make sure nothing is broken!

 root@bt:goodfet/trunk/client# bboard=facedancer11 goodfet.monitor test
 Performing monitor self-test.
 Self-test complete.

Looks like everything is working. Now you'll need to dig throw a lot of python, the USB specifications and blog posts to do some awesome USB hacks. This is a great place to start:

• http://travisgoodspeed.blogspot.com/2012/07/emulating-usb-devices-with-python.html

Enjoy!

Dumping iClass Keys

By Brad Antoniewicz.

iClass, arguably the second most widely deployed technology in proximity card access systems (the first being the ProxCard II), is a proprietary RFID communications standard and card type. It provides an enhanced level of security over the ProxCard as it encrypts the data stored on the card and leverages a challenge/response form of authentication between the card and the reader. At the 27th Chaos Communication Congress (27C3) Henryk Plötz and Milosch Meriac took a look at iClass systems. They ingeniously dissected the RW400 iClass reader and released a method to dumping it's firmware via the exposed In Circuit Serial Programming (ICSP) interface of reader's PIC18F452 microcontroller. Within the firmware were the keys used as part of the iClass card to reader authentication making it possible for anyone with the appropriate skill to read and clone these cards. It was an awesome moment for RFID and hardware hacking geeks everywhere!

The Downside

But... there was a slight downside - the method of dumping the firmware was a arguably brutish. You have to actually overwrite a portion of the reader's firmware with "dumper code" that reads and then dumps the remaining portions of it's own firmware. To obtain a complete firmware image, you have to have access to two readers. This isn't that big of a deal when targeting "Standard Security" iClass implementations because you can just buy two RW400s, get their keys, and be forever happy since the keys are static across all cards/readers. But when it comes to "High Security" implementations, you have to physically remove a reader from the wall within your target's facilities, dump a portion of the firmware, then using another reader, dump the portion of the firmware you overwrote with the dumper code on the first reader. I should say that in theory you could just write the dumper code, dump the area of the firmware that contains the keys, and then just leave the reader in a inoperable state - but a good hacker wouldn't be a jerk and just leave a broken reader laying around so lets just forget about that option.

Another Method

Those interested in RFID hacking have probably stumbled upon http://www.proxclone.com/ at least once. It's a humble site in which the author takes on various RFID related hacking projects. One of the projects was to emulate the iClass work presented at 27C3. The author successfully re-enacted the method on a RW300 reader using the same general idea, but with the author's own code and different tools. Well done. Even more interesting though was that during the re-enactment, the author discovered a new method to gain access to the reader's keys - one that only required access to a single reader, didn't involve overwriting the firmware, and even yielded the last read card value stored by the reader!

Another Downside

There is also slight downside with this as well - the author described how to perform the attack, but implemented in a hardware prototype without releasing any code or schematics. This made it a little challenging for someone like me, who wanted to reproduce his work. Here's the hardware device he created, this image is straight from the whitepaper:

Using the Old with the New

Henryk Plötz and Milosch Meriac leveraged the FTDI TTL-232R-5V-WE to interact with the reader's microcontroller. It's a simple and elegant solution and I really wanted to use it to implement the proxclone method.

Hardware

The TTL-232R-5V-WE's true power is shown through its "bit bang" mode that allows its pins to be individually controlled. This makes it possible to emulate the PIC programming hardware without the restrictions imposed by more traditional PIC programmers. It costs around $20USD. The only additional hardware requirement is a power source to bring the PIC into High Voltage programming mode. I used a 9V battery power supply enclosure that included a switch so I can enable/disable it as needed. So all in all, we're looking at about a $25USD investment!

The exposed 6 pin ICSP interface on RW300s/RW400s is usually under a piece of electrical tape on the back of the reader. It differs slightly from the standard ICSP interface but not by much. Connect the ground on your 9V power to the FTDI ground (Black) and the VCC to PIN 3 on the reader. The pinouts are as follows:

9V Power	FTDI	Reader PIN	ICSP
Black (GND)	Black	1	VSS
N/A	Red	2	VDD
Red	N/A	3	VPP
N/A	Green	4	PGD
N/A	Orange	5	PGC
N/A	Brown	6	PGM

The green FTDI wire looks very much Blue in this picture, my guess its just iPhone camera funky-ness:

Software

On the software side, I used much of the code from the PIC18F ICSP programmer to implement the read instructions used in the proxclone paper. The instructions seemed simple enough:

The code can be found on our github repo here:

• https://github.com/OpenSecurityResearch/iclass_dump

We'll also need to install the D2XX drivers from FTDI. You can get away with using the standard libFTDI that's included with most Linux distributions (you'll just need to change some function names and add some #define's) but I choose the D2XX drivers. To install:

 root@bt:~# wget http://www.ftdichip.com/Drivers/D2XX/Linux/libftd2xx1.1.12.tar.gz
 root@bt:~# tar -zxvf libftd2xx1.1.12.tar.gz
 root@bt:~# cd release/build/i386
 root@bt:~/release/build/i386# sudo cp lib* /usr/local/lib
 root@bt:~/release/build/i386# sudo chmod 0755 /usr/local/lib/libftd2xx.so.1.1.12
 root@bt:~/release/build/i386# sudo ln -sf /usr/local/lib/libftd2xx.so.1.1.12 /usr/local/lib/libftd2xx.so

I choose this method because its easy and I'm working on non-persistent BT5R3, alternate installation methods are detailed in the ReadMe.txt included within the archive.

Dumping Keys

Once the hardware is all set up, connect the FTDI adapter to your Linux box. You may have to rmmod the ftdi_sio and usbserial modules so that the D2XX drivers can work.

 root@bt:~# rmmod ftdi_sio usbserial

Next clone the github repo and compile:

 root@bt:~# git clone https://github.com/OpenSecurityResearch/iclass_dump.git
 root@bt:~# cd iclass_dump/
 root@bt:~/iclass_dump# gcc -lftd2xx -o iclass_eeprom_dump-d2xx iclass_eeprom_dump-d2xx.c

Apply power to the reader (I just used a spliced Enercel 12V adapter I picked up at a nearby RadioShack), read a card, then run:

 root@bt:~/iclass_dump# ./iclass_eeprom_dump-d2xx -v 

iclass_eeprom_dump-d2xx will give you 20 seconds to connect the FTDI cable and apply the VPP programming voltage.

The program will continue and start dumping. About 10 seconds later, you'll have the full memory dump. Note that I'm not disclosing the offsets for any keys, so you'll have to figure them out yourself. iclass_eeprom_dump-d2xx automatically provides the key permutations so you don't have to worry about running them through permute.php.

 root@bt:~#  ./iclass_eeprom_dump-d2xx -v
iClass EEPROM Dumper
brad.antoniewicz@foundstone.com
------------------------------------------------
Connecting to FTDI TTL-232R-5V-WE...Connected!!
Checking bitmode...Success! - 0xf0

Make sure at least one card has been read by the reader, then
connect your FTDI TTL-232R-5V-WE to the reader's ICSP port
and introduce the VPP power

Sleeping for 1 Seconds while you do so....

Starting EEPROM Dump
        MOVLW       - Writing PGM_CORE_INST 0x0E00
        MOVWF FSR0H       - Writing PGM_CORE_INST 0x6EEA
        MOVLW       - Writing PGM_CORE_INST 0x0E00
        MOVWF FSR0L       - Writing PGM_CORE_INST 0x6EE9

Dumping (takes ~10 seconds)..
Dump Complete!

Full EEPROM Dump:
-------------------------------------------------------

                [ REMOVED ]

-------------------------------------------------------

Parsed Keys:
        HID Master:
                [ REMOVED ] (parsed)
                [ REMOVED ] (rev. permutated)
                [ REMOVED ] (shaved)
        TDES K1:
                [ REMOVED ] (parsed)
                [ REMOVED ] (rev. permutated)
                [ REMOVED ] (shaved)
        TDES K2:
                [ REMOVED ] (parsed)
                [ REMOVED ] (rev. permutated)
                [ REMOVED ] (shaved)
Parsed Last Read Card:
        Wiegand:        [ REMOVED ]
        First 4 of CSN: [ REMOVED ]
        Full CSN:       [ REMOVED ] (not always right)


All Done!  - Closing the adapter
Dont forget to disconnect the FTDI from the reader's ICSP

Enjoy!

Hacking Through Language Barriers

By Tony Lee and Chris Lee.

When assessing a global corporation's external network, a security consultant may not immediately realize geographically where in the world they may end up. We are often given large IP blocks that contain hosts around the world. As you interact with these systems, you may discover that the tools/applications you regularly use do not support the language of your target! This article will help provide a few ideas on determining where in the world you end up and how to continue the hack—even if you cannot natively read what you are doing.

I’m in! Now what?

Inevitably you'll discover a misconfiguration or some other vulnerability that will yield you access to something on the target's external network. Sometimes you might not even be sure what the system is (e.g. access obtained via a weak password). We've seen tons of stuff fall into this category - from VOIP gateways and VPN appliances to SCADA sensors and controllers (ironically, we find the most unique equipment is usually available over dial-up --yeah War Games!).

Nonetheless, here we are again, we have access to some unidentified host - but now what? Since we don’t manage the device and may not immediately know what it is, we look for some sign of a manufacturer or version in the banner. If it lacks a banner, we try to activate the help menu. This is all well and good, however what if the help menu or the banner show up as non-printable characters?

What the hex?

On a recent engagement, we ran into just this problem. The password prompt and a very lengthy copyright banner were legible, however all of the help functionality displayed as non-printable characters as shown in the example below:

Since it is impossible to know every device out there the help menu can be crucial to navigating the device and turning low hanging fruit into further access or substantial impact. So, how do we interpret the menu when it looks like that?

The first thing we have to assume is that the device and our client application do not speak the same language. This could be protocol or natural language. In the screenshot above, we see that the protocol is most likely not the culprit because we can read some of the menu—thus we have to assume this is a natural language issue. But what language is this?

Location clues

In order to pick the right language, it may help to figure out the geographic location of the device. Again, even though this may be a company that is headquartered in the US or elsewhere, it does not mean that the device is located in that country or even configured to be in that language since it is often local employees that have to manage the device.

To help discover the location, we will use the following clues:

• Manufacturer
• Login banners
• Hostname or DNS name
• GeoIP Data

Manufacturer

The manufacturer can sometimes be an indicator of the language, but this is not always the case due to global manufacturing and distribution of equipment, however there are countries that tend to purchase and support their own local products more often than they purchase foreign equipment. With that said, this is probably the least accurate clue, but worth noting. In the case above, Yamaha (a Japanese company) makes the device to which we have gained access. Additionally, it looks like the Tokyo Institute of Technology and the Japan Advanced Institute of Science and Technology also have copyrights on this device. Let’s see if this holds any weight as we move along.

Login banners

Warning and consent to monitoring banners will often have the company name and possibly location of the device. If listed, this information is usually more accurate than extrapolating the device location from the manufacturer’s origin.

Fictitious example:

It is the policy of the law firm of the Smith group to monitor the Internet 
access of its employees to ensure compliance with law firm policies.  
Accordingly, your use of the Internet may be monitored.  The firm reserves 
the right to disclose the fruits of any monitoring to law enforcement if it 
deems such disclosure to be appropriate.

Smith1 – Memphis

Username: 

Many security industry experts advise against this disclosure as it makes it very easy for the attackers to find and validate their targets—however it is still prevalent. The client’s argument is that it is very useful for administrators to also know the location and ownership of the device. In this situation, there was no consent to monitoring or other warning banner to clue us into the location.

Hostname or DNS name

Another tip-off can be the hostname or DNS Fully Qualified Domain Name (FQDN). Companies will often put geographical location info either in the hostname or as part of the FQDN.

Examples of this would be:

• VAWin2k8Server
• UKc2600
• Sharepoint.company.co.jp

Looking at the examples above, one could probably infer that the first example is in VA, in the US, the second example is located in the UK, and the last example is in Japan.

A real-world example can be seen when doing a traceroute to a device that is relatively far away:

 traceroute to nyu.edu (128.122.119.209), 30 hops max, 60 byte packets
 1  56-92-10-6.static.twtelecom.net (56.92.10.6)  1.058 ms  1.307 ms  1.662 ms
 2  20-34-18-25.static.twtelecom.net (20.34.18.25)  4.991 ms  5.194 ms  5.196 ms
 3  lax2-pr2-xe-0-3-0-0.us.twtelecom.net (66.192.253.170)  6.109 ms  6.106 ms  6.239 ms
 4  xe-7-1-0.edge2.LosAngeles9.Level3.net (4.53.230.61)  6.438 ms  6.412 ms  6.423 ms
 5  vlan70.csw2.LosAngeles1.Level3.net (4.69.144.126)  7.172 ms vlan90.csw4.LosAngeles1.Level3.net (4.69.144.254)  13.436 ms vlan70.csw2.LosAngeles1.Level3.net (4.69.144.126)  7.302 ms
 6  ae-93-93.ebr3.LosAngeles1.Level3.net (4.69.137.45)  7.863 ms  8.785 ms ae-73-73.ebr3.LosAngeles1.Level3.net (4.69.137.37)  8.067 ms
 7  ae-3-3.ebr1.SanJose1.Level3.net (4.69.132.9)  15.933 ms  15.797 ms  17.652 ms
 8  ae-2-2.ebr2.NewYork1.Level3.net (4.69.135.186)  83.898 ms  84.117 ms  83.987 ms
 9  ae-82-82.csw3.NewYork1.Level3.net (4.69.148.42)  84.614 ms ae-72-72.csw2.NewYork1.Level3.net (4.69.148.38)  84.346 ms ae-92-92.csw4.NewYork1.Level3.net (4.69.148.46)  85.171 ms
10  ae-1-60.edge4.NewYork1.Level3.net (4.69.155.20)  84.339 ms ae-3-80.edge4.NewYork1.Level3.net (4.69.155.146)  84.582 ms  84.581 ms
11  NEW-YORK-UN.edge4.NewYork1.Level3.net (4.28.130.118)  85.143 ms  85.140 ms  85.119 ms

It is interesting to see the physical path that packets take over long distance journeys.

Unfortunately, in our case, this did not help us as we were working off of IP address only and the hostname was not displayed in the banner or resolvable via a reverse DNS lookup.

GeoIP Data

The last tactic you can use is a GeoIP location search engine and database. This is a mapping of real world physical locations to Internet Protocol addresses. I recommend using a couple of them to validate each other’s results. Sometimes you may get one that is pretty far off in accuracy.

Some potential sites to use are:

• http://www.geoiptool.com
• http://www.geobytes.com
• http://freegeoip.net/

In our case, we included the result from geobytes below. This confirmed our suspicion from earlier that it may be Japanese.

Overall, these tools are fairly accurate, sometimes even down to the city, and will almost always get you in the right country.

Encoding/language support

Now that we know the language we want to try, the first attempt at making it readable was to try another program. Unfortunately, Putty was no help in this instance. None of the language settings under Putty Configuration then Translation seemed to match a Japanese character encoding.

It turns out that you need to download a separate version of Putty called Puttyjp. Since we did not want to install a special version of Putty for this, we looked through the character encoding in gnome-terminal . There are a few Japanese encodings, so we tried Japanese ISO-2022-JP as shown in the screenshot below:

No dice!

Let’s try another character encoding set, Japanese (SHIFTJIS)… Voila! We have something that is legible! Sorta… If you read Japanese you are in good shape. For the rest of us, we can either make a friend who reads the language or there is Google Translator.

Google translator to the rescue

The detect language feature in Google Translate guessed incorrectly, but it can be overridden. When in a pinch, this is not a bad option. The Ping help menu even makes sense when you read the English version—or at least enough to understand the command and how to use it. This was the same for the rest of the help menus which provided enough information to properly leverage the device.

Conclusion

Even though you may be assessing devices and networks around the world, it is not impossible to hit a home run on a device that you cannot even natively read. With enough patience and careful fiddling, a foreign device can be utilized as if it were a native device.

For those of you that were wondering what the mystery device was… It was a VPN concentrator designed for small/medium size businesses. One clue, intentionally not disclosed earlier, was the very subtle model number in the banner: RT107e.

Have you ever run into a language issue before? If so, what clues did you use to figure out the language of the device? What tools did you have to use to correctly render the text? What did you use to translate it once it was properly rendered?