Black Magic Probe: The Best ARM JTAG Debugger?

We don’t always JTAG, but when we do, we use a Black Magic Probe. It’s a completely open ARM-chip debugging powerhouse. If you program the small ARM chips and you don’t have a BMP, you need a BMP. Right now, one of the main producers of these little gems is running a Kickstarter where you can get your hands on a nicely made one and/or a 1Bitsy STM32F415-based development board.

Why is the BMP so great? First off, it’s got a JTAG and a UART serial port in one device. You can flash the target, run your code, use the serial port for printf debugging like you know you want to, and then fall back on full-fledged JTAG-plus-GDB when you need to, all in one dongle. It’s just very convenient.

But the BMP’s killer feature is that it runs a GDB server on the probe. It opens up a virtual serial port that you can connect to directly through GDB on your host computer. No need to hassle around with OpenOCD configurations, or to open up a second window to run [texane]’s marvelous st-util. Just run GDB, target extended-remote /dev/ttyACM0 and you’re debugging. As the links above demonstrate, there are many hardware/software pairs that’ll get you up and debugging. But by combining the debug server with the JTAG hardware, the BMP is by far the slickest.

Full disclosure: we use a BMP that we built ourselves, which is to say that we compiled and flashed the firmware into a $4 STLink clone programmer that we had on hand. Breaking the required signals out required a bit of ugly, fiddly soldering, but we enjoy that sort of thing. If you don’t, the early-bird Kickstarter (with cables) looks like a good deal to us.

uController Code Profiler Debugs Your Microcontroller

When working on digital circuits that operate at high frequencies it helps to have some special tools on hand. Things like oscilloscopes and logic analyzers are priceless when something isn’t working right. Another great tool would be this hardware-based profiler that [Mike] came up with while he was working on another project.

The profiler connects to USB and shows up as a serial port. Normally [Mike] used a set of LEDs to get information about how his microcontrollers work, but for this project that wasn’t enough. The uController Code Profiler can provide the main loop running time, time functions and sections of code, keep track of variables, and a few other tasks as well, all with nanosecond resolution.

The source code isn’t provided but a hex file is available, along with a schematic and an include file, if you want to try this one out on your next project. Like this homemade logic analyzer, this could be a powerful tool in your microcontroller arsenal. Simply include the file with various pieces of your code to get it up and running!

Breaking Dridex Malware with Excel Macro Password Exploit

[Ronnie] recently posted a new chapter in his adventures in malware deconstruction. This time the culprit was an infected Excel spreadsheet file. The .xls file was attached to a phishing email claiming to be related to a tax rebate. With tax season in full swing, this type of phishing message would be likely to be opened by an inexperienced user.

[Ronnie] saved the file to a virtual machine to prevent his real workstation from getting infected. He then opened it up in Excel and noticed that it immediately attempted to run macros. A macro is essentially visual basic scripting that runs inside of the spreadsheet file. You can use it for simple automation, cell formatting, or do even more complicated tasks like reach out to external websites and pull information. This malware focused on the latter.

[Ronnie] used the alt + F11 shortcut to view the macros. Unfortunately the attackers had password protected them. [Ronnie] wouldn’t be able to view the macro code without knowing the password. Luckily, he learned of a surprisingly simple trick to completely bypass the macro password. He opened up the .xls file in Notepad++ and located three keys; CMG, DPB, and G. [Ronnie] then created and saved a new blank .xls document and password protected the macros with his own password. He opened up this new file in Notepad++ as well, and located those same three keys. He copied the keys from the new file into the old one, and saved the old file. This effectively changed the password of the malware file to the new one he had set for his new file. This is a nifty trick that apparently only works on the older .xls formats, not the newer .xlsx format.

After loading the macros, [Ronnie] quickly noticed that most of the code was obfuscated to make it difficult to analyze. There were, however, three named modules that reference possible sandbox evasion techniques. The malware first invokes these functions to detect the presence of a virtual machine or other type of sandbox. If it detects nothing, then the rest of the malware program is decoded and executed. [Ronnie] removed these checks and then executed the macro to verify that his change had worked.

The next step was to try to view the decoded instructions. The decoded gibberish was saved to a variable. The simplest way for [Ronnie] to view the contents of the variable was to have the program create a pop-up box that displayed the contents of that variable. After making this change and running the program again, he was able to see exactly what the malware was doing. The code actually invoked Powershell, downloaded a file from the Internet, and then extracted and executed that file. In the full write-up, [Ronnie] goes even further by downloading and analyzing the executable.

Debugging MSP430 using Eclipse

[Springuin] just posted a tutorial about debugging MSP430 projects using Eclipse. He read our feature about debugging under IAR, a proprietary IDE which TI offers as a code-limited freebie with the TI Launchpad. In that writeup we wondered if anyone would put together a tutorial using open source tools like DDD and GDB to make debugging easier for those that choose to use operating systems other than Windows. Even though he didn’t directly use those particular packages, this should work just as well.

Eclipse is a popular IDE for many different languages like C, C++, Java, and others. We’ve already seen it used to develop for the TI Evalbot on Linux systems. [Springuin] is using the Java-based IDE on a Windows system, and this is the first time we recall seeing directions on using an open-source alternative for programming with the TI Launchpad under Windows. That being said, the only real Windows specific parts are the steps necessary for communicating with the programmer. Since this method uses MSP-GCC and msp430-gdbproxy, it should be easy to do this under Linux as well. Use our tutorial to set up those tools if you haven’t already, then follow this one for a setting up and debugging in the Eclipse environment.

Debug mode lurking inside AMD chips

Looks like some hardware enthusiasts have worked out a method to enable debug mode within AMD processors. The original site isn’t loading for us, but the text has been mirrored in this comment. Getting the chip into debug mode requires access passwords on four control registers. We’ve read through the writeup and it means very little to us but we didn’t pull out a datasheet to help make sense of the registers being manipulated. It shouldn’t be hard to find an old AMD system to try this out on. We’d love to hear about anything you do with this debug system.

[via Slashdot]

Update: more pink wireless-terminal hacking

[Dave] poked around inside of an IM-ME wireless toy and compiled his findings. He read about the device when we covered it in November and picked up a couple to see what he could do. He patched into the debug port in the CC1110 processor and enabled it by performing a chip erase. He then began mapping out how the processor connects and communicates with the qwerty keyboard, the wireless radio, and the LCD screen. The board is full of test points which make the hardware easy to access. [Dave’s] experiments show that this hackable device is full of potential so let’s see what you can do!

Hacking ZigBee chips: CC2430

[Travis Goodspeed] took an in-depth look at the debugging protocols for some ZigBee chips and posted his findings. In particular he’s looking at the CC2430 System-on-chip. These chips have a debugging protocol that is not hard to implement if you know what you’re doing. Certainly his tips make it easier for the rest of us. Don’t miss the info about reading from, writing to, and overcoming security of this hardware.