Peek Into The Compiler’s Code — Lots Of Compilers

We don’t know what normal people argue about, but we know we spend a lot of time arguing about the best microcontroller, which editor is the best, and what language or compiler does the best job. The problem with all those compilers is getting them loaded and digging into the generated code. If you too spend your time thinking about those things, you ought to have a look at [Matt Godbolt’s] Compiler Explorer. We know that hosting an IDE-like web page and compiling code is old hat — although [Matt’s] site has been around quite some time. But [Matt’s] doing it differently. The code you build on the left hand pane shows up as assembly language on the right hand side.

There are plenty of options, too. For example, here’s a bit of C code from the site’s example:

int square(int num) {
   return num * num;
}

Here’s the corresponding assembly from gcc 9.2 for x86-64:

square:
  push rbp
  mov rbp, rsp
  mov DWORD PTR [rbp-4], edi
  mov eax, DWORD PTR [rbp-4]
  imul eax, eax
  pop rbp
  ret

Continue reading “Peek Into The Compiler’s Code — Lots Of Compilers”

Hail To The King, Baby: Reverse Engineering Duke

If you’re a fan of DOS games from the 1990s, you’ve almost certainly used DOSBox to replay them on a modern computer. It allows you to run software in a virtual environment that replicates an era-appropriate computer. That’s great for historical accuracy, but doesn’t do you much good if you’re trying to leverage modern computing power to breathe some new life into those classic titles. For that, you need to dig in a little deeper.

For the last two and a half years, [Nikolai Wuttke] has been doing exactly that for 1993’s Duke Nukem II. The end result is RigelEngine, an open source drop-in replacement for the original game binary that not only runs on a modern Windows, Linux, or Mac OS machine, but manages to improve on the original in a number of ways. An accomplishment made even more impressive once you learn that the original source code for the game has been lost to time, and that he had to do everything blind.

In a blog post chronicling his progress so far, [Nikolai] explains the arduous process he used to make sure his re-implementation was as accurate as possible to the original game. He spent untold hours studying the original game’s disassembled code in Ida Pro, handwriting out pages of notes and pseudocode as he tried to understand what was happening behind the scenes. Once a particular enemy or element of the game was implemented in RigelEngine, he’d record the gameplay from his version and compare it to the original frame by frame so he could fine tune the experience.

So what’s the end result of more than two years of work and over 25K lines of code? Thanks to the incredible advancements in computing power since the game’s release nearly 30 years ago, [Nikolai] has managed to remove the need for loading screens. His engine is also capable of displaying an unlimited number of particle effects on the screen at once, and multiple sound effects can now be played simultaneously. In the future he’s looking to implement smooth character movement (in the original game, movement was in 8 pixel increments) and adaptive volume for sound effects based on their distance from Duke. Ultimately, RigelEngine should be able to replace the original graphics with new high resolution textures once some issues with the rendering buffer gets sorted out.

It’s hard to overstate how important some of these classic games are to those who grew up playing them. With John Romero still releasing DLC for the original DOOM and hackers disassembling nearly 40 year old games to fix bugs, it doesn’t seem like they’re in any danger of being forgotten.

Continue reading “Hail To The King, Baby: Reverse Engineering Duke”

Learn To Reverse Engineer X86_64 Binaries

Opening up things, see how they work, and make them do what you want are just the basic needs of the average hacker. In some cases, a screwdriver and multimeter will do the job, but in other cases a binary blob of random software is all we have to work with. Trying to understand an unknown binary executable is an exciting way to discover a system’s internal functionality.

While the basic principles of software reverse engineering are universal across most platforms, the details can naturally vary for different architectures. In the case of the x86 architecture, [Leo Tindall] felt that most tutorials on the subject focus mostly on 32-bit and not so much on the 64-bit specifics. Determined to change that, [Leo] ended up with an extensive introduction tutorial for reverse engineering x86_64 binaries starting at the very basics, then gradually moving forward using crackme examples. Covering simple string analysis and digging through disassembled binaries to circumvent fictional security, the tutorial later introduces the Radare2 framework.

All example source code is provided in the accompanying GitHub repository, although it is advised to avoid looking at them to keep it more interesting and challenging. And in case you are looking for more challenges later on, or generally prefer a closer connection to the hardware, these MSP430 based capture the flag online challenges might be worth to look at next.

Reverse Engineering Guitar Hero

What do you do when a ten-year-old video game has a bug in it? If you are [ExileLord] you fix it, even if you don’t have the source code. Want to know how? Luckily, he produced a video showing all the details of how he tracked the bug down and fixed it. You can see the video below. You may or may not care about Guitar Hero, but the exercise of reverse engineering and patching the game is a great example of the tools and logic required to reverse engineer any binary software, especially a Windows binary.

The tool of choice is IDA, an interactive debugger and disassembler. The crash thows an exception and since [ExileLord] has done some work on the game before, he was able to find a function that was creating a screen element that eventually led to the crash.

Continue reading “Reverse Engineering Guitar Hero”

Completely Owning The Dreamcast Add-on You Never Had

If you’ve got a SEGA Dreamcast kicking around in a closet somewhere, and you still have the underutilized add-on Visual Memory Unit (VMU), you’re in for a treat today. If not, but you enjoy incredibly detailed hacks into the depths of slightly aged silicon, you’ll be even more excited. Because [Dmitry Grinberg] has a VMU hack that will awe you with its completeness. With all the bits in place, the hacking tally is a new MAME emulator, an IDA plugin, a never-before ROM dump, and an emulator for an ARM chip that doesn’t exist, running Flappy Bird. All in a month’s work!

The VMU was a Dreamcast add-on that primarily stored game data in its flash memory, but it also had a small LCD display, a D-pad, and inter-VMU communications functions. It also had room for a standalone game which could interact with the main Dreamcast games in limited ways. [Dmitry] wanted to see what else he could do with it. Basically everything.

We can’t do this hack justice in a short write-up, but the outline is that he starts out with the datasheet for the VMU’s CPU, and goes looking for interesting instructions. Then he started reverse engineering the ROM that comes with the SDK, which was only trivially obfuscated. Along the way, he wrote his own IDA plugin for the chip. Discovery of two ROP gadgets allowed him to dump the ROM to flash, where it could be easily read out. Those of you in the VMU community will appreciate the first-ever ROM dump.

On to doing something useful with the device! [Dmitry]’s definition of useful is to have it emulate a modern CPU so that it’s a lot easier to program for. Of course, nobody writes an emulator for modern hardware directly on obsolete hardware — you emulate the obsolete hardware on your laptop to get a debug environment first. So [Dmitry] ported the emulator for the VMU’s CPU that he found in MAME from C++ to C (for reasons that we understand) and customized it for the VMU’s hardware.

Within the emulated VMU, [Dmitry] then wrote the ARM Cortex emulator that it would soon run. But what ARM Cortex to emulate? The Cortex-M0 would have been good enough, but it lacked some instructions that [Dmitry] liked, so he ended up writing an emulator of the not-available-in-silicon Cortex-M23, which had the features he wanted. Load up the Cortex emulator in the VMU, and you can write games for it in C. [Dmitry] provides two demos, naturally: a Mandlebrot set grapher, and Flappy Bird.

Amazed? Yeah, we were as well. But then this is the same guy emulated an ARM chip on the AVR architecture, just to run Linux on an ATMega1284p.

Seeking Treachery In A Questionably Sourced Phone

Have you ever considered sourcing an off-brand phone from the China markets? Why, or what stopped you? The answer is data and identity. You are trusting both when you decide to use a smartphone. Let’s face it, smartphones are a personality prosthesis in our society. They know your physical location, what your interests are, the people you hang out with, and how you spend your money. The keys to the castle are shared with these devices and you shouldn’t grant that kind of trust without knowing your phone is worthy of it.

But… what if that phone has amazing features at an equally amazing price? [ijsf] bought the phone and then made it earn the proper level of trust. The model in question is a Blackview BV6000s — pictured above in a tub of soapy water proving it’s IP68 claim. This thing has flagship specs but not a flagship name so [ijsf] took [Dave Jones’] advice and took it apart instead of turning it on. In this case, it is a complete ROM dump and disassembly.

The goals was to find malware — anything that is potentially leaking data. Nothing was found, which we think is because this phone isn’t nearly shady enough. We’d expect the bargain basement models (like this $3 wonder vaporware) to be more in line. That one actually has a carrier behind it which means they plan to recoup on usage charges. But suspiciously cheap phones may be using a business model that makes it back by stealing a chunk of your identity.

Two good things come out of [ijsf’s] writeup. First, it’s a decent guide to dumping and snooping in a ROM. Second, in addition to the fruitless search for thieving apps, the annoying bloatware was removed for a cleaner ‘stock’ image.

D-Link Fails At Strings

Small Office and Home Office (SOHO) wireless routers have terrible security. That’s nothing new. But it is somewhat sad that manufacturers just keep repurposing the same broken firmware. Case in point: D-Link’s new DIR-890L, which looks like a turtled hexapod. [Craig] looked behind the odd case and grabbed the latest firmware for this device from D-Link’s website. Then he found a serious vulnerability.

D-Link's DIR-890 Router

The usual process was applied to the firmware image. Extract it, run binwalk to find the various contents of the firmware image, and then extract the root filesystem. This contains all the code that runs the router’s various services.

The CGI scripts are an obvious place to poke for issues. [Colin] disassembled the single executable that handles all CGI requests and started looking at the code that handles Home Network Administration Protocol (HNAP) requests. The first find was that system commands were being built using HNAP data. The data wasn’t being sanitized, so all that was needed was a way to bypass authentication.

This is where D-Link made a major error. They wanted to allow one specific URL to not require authentication. Seems simple, compare string A to string B and ensure they match. But they used the strstr function. This will return true if string A contains string B. Oops.

So authentication can be bypassed, telnetd can be started, and voila: a root shell on D-Link’s most pyramid-shaped router. Oh, and you can’t disable HNAP. May we suggest OpenWrt or dd-wrt?