Starcraft reverse engineered to run on ARM | Hacker News Reader

Starcraft reverse engineered to run on ARM

boards.openpandora.org

237 pointsgalapago55 comments

That's, uh, really impressive. I'd like the author to write about it, because I'd like to understand how much extra work it took to get compiling from the C code once it was disassembled by the tools. It'd be interesting to understand what sort of pitfalls the tools produce, so that the tools can be more efficiently used to do more work like this.

It's well above my head, but it'd be a fascinating read!

I'm in touch with the author, but we'll see if he ends up writing about it or not... :)

By the way it's not the first time this is done, there were some other static recompilations (Xcom i think) done in the same way 3 years ago. But Starcraft was probably harder.

On a vaguely related note, it doesn't matter much for X-Com since there is a very, very complete open-source reimplementation: https://github.com/SupSuper/OpenXcom

Yeah, and it's also available on Pandora by the way. :)

The tools that he used to convert x86 to C can be found here:

https://github.com/notaz/ia32rtools

Video of the game running on an OpenPandora here:

http://www.youtube.com/watch?v=7vWnyDrNQO4.

Original Minimum Requirements (low-latency internet connection rated at 28.8 KBps+):

  - 90 MHz Pentium or equivalent
  - 16 MB RAM
  - SVGA video card
  - low-latency internet connection rated at 28.8 KBps+

I forgot how few resources this great game needed.

ps: the pandora specs http://openpandora.org/portal/index.php?option=com_content&v...

I used to play it on a 90MHz Pentium with 48MB of RAM, running Windows NT4, and let me tell you, it did not run well.

I remember there being this one mission where you have to survive for a fixed amount of time (10min? 15min?), and on this machine it lasted more like half an hour. Also reminds you how they accounted for time in those days.

Diablo (the first) with the Hellfire expansion ran smooth as butter on the same machine. I also remember trying to do Python and Java on that machine, didn't go over to well either, although Python wasn't too bad.

Keep in mind that the speed of Starcraft's ingame time does not necessarily match your wall clock. It can be faster or slower, depending on game speed setting.

NT never really felt comfortable on under 128MB from my memories.

Yeah I think I used a Pentium 233MMX at first. And single mode, online multilplayer massive maps would probably slow everything down. Gosh I wish I still had these machines to witness the differences before my eyes.

A bit unrelated, but this reminded me of when I did a full install (as opposed to a partial install and running the rest from the CD-ROM) of SC as a kid, which made my father extremely angry. "You used a whole 95 megabytes!"

I say this fully aware that the cycle will continue one day when I get angry at my future child for installing Flight Sim 27, taking up 1.5 terabytes of precious HD space. And of course, they will remember it one day and laugh because a 100PB SSD will be a $10 purchase at the gas station.

What I often forget is just how dated the graphics are. Which is no biggie or anything, but very much why you only need 16MB of RAM.

The bulk of the logic seems to be here:

https://github.com/notaz/ia32rtools/blob/master/tools/transl...

It looks like it's not a full decompiler, but just an instruction-level one - it doesn't attempt to recover any more high-level structure beyond if/goto and function boundaries with parameters. Look at lines 4500-4533 for an example. He also appears to be parsing disassembler output(!) for its input.

Is there an overview of how to use ia32rtools any place?

This kind of reverse engineering never fails to impress. If you asked me ahead of time, I'd probably have said "possible in theory, but there would be so many obstacles to overcome that no one will succeed in practice."

I thought it had been done for Android first, and apparently it was, with winulator:

docs.winulator.com/programs

Edit: more info on GsmArena

http://blog.gsmarena.com/you-can-now-play-starcraft-and-caes...

"The Winulator doesn’t work like an emulator. It just converts an x86 game executable to an ARM-friendly one. Here is what you need to do.

You’ll need three things – a computer with installed Winulator Converter Helper, the original DRM-free game installed on that computer and the Winulator Android app installed on your phone."

Yes I was a bit confused that this is supposed to be new information, I installed StarCraft on my android about a year ago using winulator.

It even supports a bluetooth mouse, (which I went and bought the same day I installed and got working). Works perfectly. like having a '96 gaming PC in your pocket(s)

I even changed the winulator icon to StarCraft icon then went to the pub and pulled the mouse out of my pocket, setup my android and made all my iphone-owning friends $#!^ bricks. Good times.

You only need this [0] and this [1] to run the game.

[0] https://play.google.com/store/apps/details?id=com.postram.wi...

[1] https://docs.google.com/a/shir-man.com/file/d/0B1bdCV3iqJ-MT...

I've kicked around the idea of translating machine code to LLVM assembly code specifically to do things like this.

I actually got as far as creating a GitHub repo to work on this <https://github.com/wtracy/recompile> but my code never got farther than some logic for parsing ELF headers.

I can't wait until I find such a project that is in a usable state! I've tried all of these (save dagger, no releases yet) and always hit some issue due to their immaturity.

https://github.com/libcpu/libcpu

http://dagger.repzret.org/

https://github.com/draperlaboratory/fracture

I think the most stable implementation in this space (if limited in scope) would be Apple's Rosetta. Sadly both closed-source and now abandoned; if it was opened up, it'd be great to base a more general A-to-B translator on.

Excuse my ignorance here; I wanted to get into LLVM more but never did. Don't you have: frontends which do Language => LLVM intermediate code and backends which do LLVM code => native ? So you were writing a frontend which could do x86 => LLVM code and then it can compile to ARM, x86, JS etc?

Sounds like a HUGE undertaking (esp for one person) but worth it; once you have that frontend (if my assumptions are correct), you would be able to have a lot of fun.

That's a pretty accurate description of what I was trying to do. You are correct that it's a huge undertaking. :-)

That said, even once you've got x86 -> LLVM translation working, there's a lot of code out there that makes x86-specific assumptions.

I once interviewed with a group that was trying to port a large codebase from PPC to x86, and even having the source code didn't help with the fact that their code assumed a big-endian architecture.

One approach to this is taken by RevGen [1], which uses QEMU to disassemble the target code and lift it to QEMU's intermediate representation (TCG). The TCG ops are then translated to LLVM.

It's definitely not perfect, but I suspect it will work much better than trying to do x86->LLVM from scratch. QEMU's IR is very likely much closer to correct than anything you'd come up with, since it is used for emulation, and the mapping from QEMU IR to LLVM is very straightforward (you can even run QEMU with LLVM as the backend, albeit with some performance penalty).

Two things to watch out for in this approach: helper functions (places where QEMU has decided to use a C function to implement some functionality rather than implementing it in TCG) and there may be some artifacts in the generated LLVM from things that are related to QEMU's system emulation rather than what the original code did.

[1] http://infoscience.epfl.ch/record/166081/files/revgen.pdf

Very cool--I'll look at this if I ever get back to this project. (Unlikely, given the changes in my priorities since I started it.)

At the time, my primary motivation was really to learn more about x86 machine code, which explains the brute-force approach. (Hey, Linux got started because Linus wanted to learn more about x86 memory management, so it's not a completely dumb approach.)

Yeah LLVM would be really cool like emscripten, but for x86.

I would like to see a performance comparison of this approach vs. running a full virtual machine since the x86 to arm conversion approach still requires a wine lib to execute all the windows APIs.

I love my open pandora, even though i haven't played much on it recently.

I'll probably also buy the follow up device.

It's still the only option for long flights if you don't have the $ to pay for business class (power sockets there); I have a Pandora with 2 batteries (which are quite small) which is over 20 hours of a system which actually lets you do your work. Wouldn't have survived my trip of 25 hours last week without it.

I love my Pandora too .. 10 hours on a single charge, you really can't beat that. Plus the fact that its a portable Linux workstation just makes it so damned valuable even when I'm not playing games on the thing ..

I've definitely signed up for the sequel! :)

We are almost there with other devices; a phone size tablet with a clamshell keyboard would do, especially if you can hook up a game keyboard, normal keyboard and mix. Problems are; 1) there are none which qualify, both tablets and keyboards; somehow clamshell, you know, the battle tested way of doing keyboards, is not something which caught on on tablets (except Clamcase I guess) :) And why can't I buy a phone sized tablet without the GSM crap in it; that would/should be tons cheaper than buying a phone 2) they are not open as the pandora. I don't really want to be stuck with Android, iOS or Win; some Linux with a complete desktop env please.

Lots of planes these days getting power sockets back in steerage class.

Hopefully that continues as I have been flying a lot all over the place the past month and none had it, not in the EU nor in the USA. Only in the top tier seatings. Maybe just bad luck...

Besides that ; I need devices with 'infinite-ish' battery life because battery life really really sucks.

I had various models of the GP2X and hacked together a game for it and really enjoyed the community around it. That said, I thought the Pandora project would either fail or units would only be available when better alternatives exist, or the unit price would be too high. I'm glad to see there is still some momentum.

I thought the same thing ; I didn't think I would like it that much as I do either. But there are really no alternatives; they are closed and just not the same. But the market is VERY limited to gaming coders basically. That's what it's great for...

Neat! As I'm not much of a gamer, I hadn't heard of this device before. But for under $600, you get a modest portable Linux box with 10-hour battery life.

http://ithic.com/newsite/index.php?id_product=9&controller=p...

I'm not quite sure what I'd use one for, but it's an interesting option.

Here's how people use it: http://pandoralive.info/?cat=15

If you're interested about the followup device: http://pyra-handheld.com/

Done by some of the founders of OpenPandora. Will probably be the only followup device. It has impressive specs, but is priced like a laptop (which it is tbh).

Awesome. I've been meaning to do the same thing for Final Fantasy VII PC.

While I'm never one to stand in the way of tinkering, I'm curious as to why you chose FF7?

There are many open source implementations of PS1 emulators, and the PC version of FF7 is notoriously bad. So from a gameplay perspective, the PS1 version of FF7 is far easier to run an any platform, and is superior in all respects.

Like I said, not discouraging it, just curious.

Starcraft was ported to ARM in 2010 to run on the Windows Mobile platform. Details are rather light, so I don't know if they used the same approach, but it's likely.

http://www.phonearena.com/news/StarCraft-arrives-for-Windows...

Funny, I actually started up my pandora the first time in two years, thinking I'd play pokemon. And then I see this on HN.

Video here: http://pandoralive.info/?p=2965

So if it's compiled for ARM now, any chance I could get it working on my Chromebook?

Now that you have the C source, release it and/or compile a tablet version.

The C source would be a derived work. They have no right to release it.

Isn't this the same thing then? You can release a recompiled ARM binary but not the source with which it was built? I think legally they are both derived works. I don't really care about that as I believe it should be allowed for software > 10 y/o, but isn't it technically the same thing and thus not allowed at all?

Ah, I didn't realize that binary builds were posted. That is definitely naughty.

I don't actually care.

In the US, does decompiling have ramifications in regards to the DMCA?

Probably, and copyright. Blizzard sued bnetd for reverse-engineering to make a compatible server. http://en.wikipedia.org/wiki/Bnetd

FD: I no longer play Blizzard games due to this action.

Any possibility that this could be ported to a Raspberry Pi?

I wish there were more static recompiling emulators.

Raspberry Pi port anyone?

Now how about an Intel Mac binary?

Reply on news.ycombinator.com