▲ 148 points
back
50 comments
A sign of the times: the use of the term "cloud gaming" to describe what would once be called "network play".
The emulator will firstly break at the ROM entry point 0x0100 in debug mode, which is the entry point of the game program.
That start address is the same as in CP/M, and subsequently DOS 16-bit COM-format binaries. I wonder if Nintendo was inspired by that.
The DMG boot ROM fits into the top 0x100 bytes. To protect it from being snooped, the last instruction shuts off the boot ROM by flipping a register that can’t be flipped back, mapping the top 0x100 back to the cartridge (and allowing the cartridges interrupt vectors to be installed.) So, there is no jump to 0x100 at any point; they just fit the DMG boots ROM perfectly into 0x100 bytes and control flow leaves bootstrap right as PC hits 0x100.
This simple security mechanism was extremely effective, and lead to the DMG BIOS being undumped until relatively recently, when it was dumped by imaging the ROM directly and via fault injection to skip the last instruction.
The fact that it was undumped until recently makes me want to understand this more. Can you ELI5?
In only 0x100 bytes of ROM that is so simple, there’s unlikely to be too many software bugs that allow dumping. Decapping a chip and imaging it isn’t cheap either. The hardware mechanism for locking the boot ROM may be hard to figure out without having the boot ROM already. And given how simple and effective the hardware mechanism is, it, too, is unlikely to have any obvious flaws to exploit.
So they didn’t exploit flaws, they just tried to work around the protection.
Even though the Gameboy is relatively slow (~4.7 Mhz processor IIRC) it’s still not going to be easy to hit exactly at the right time to be able to perform your fault injection.
The protection is simple enough to be effective. If you did it with a modern manufacturing process it’d probably be quite difficult to be able to image the bits directly...
Nowadays, for say Nintendo Switch, you are more likely to see keys and firmware data dumped via early boot exploits or privilege escalation.
There's a description of the particular fault injection used for the Gameboy Color here: https://www.its.caltech.edu/~costis/sgb_hack/
Fault injection is a method to cause microprocessors to execute instructions "incorrectly" by manipulating external factors (clock frequency, input power, etc). Getting the CPU to fail to write to a memory address, or flipping the truth of a comparison instruction, and other "glitches" can influence execution of security-sensitive code and ultimately undermine security mechanisms.
The original Gameboy ROM was dumped by physically de-capping the chip and reading out the bits: https://dot-matrix-game.blogspot.com/2014/01/boot-roms.html
That was a super insightful read!
tl;dr For the SGB, they quadrupled the clock speed briefly to glitch over the one instruction responsible for mapping out the ROM.
For the CGB, they halted the clock, drained the voltage to randomize the instruction counter, then used a NOP slide that led to their payload.
In my mind, "network play" refers to playing multiplayer games over a network, which this isn't? This is about playing a Game Boy game on an emulator that is running on a server somewhere, which sounds very much like "Cloud gaming" to me.
I think "cloud gaming" was pretty accurate:
https://en.wikipedia.org/wiki/Cloud_gaming
... given the "client" in this case was just telnet and the game was "running" on another machine "in the cloud" [1]?
1. like literally on alibaba, amirite?!
Probably because the lower addresses are for the interrupt vector table.
No. Execution actually starts at 0x0 like most architectures, but the boot loader fits in the first 256 bytes, so after the last instruction executes, execution continues on at 0x100
Nice touch with the choice of the port number!
Now I only have to install telnet on my Mac to be happy! Thanks for the project!
I always like to have a look at what is being usurped, when choosing fun/apposite ports: -
% grep 1989 /etc/services
tr-rsrb-p3 1989/tcp # cisco RSRB Priority 3 port
tr-rsrb-p3 1989/udp # cisco RSRB Priority 3 port
#mshnet 1989/tcp # MHSnet system
#mshnet 1989/udp # MHSnet systemnetcat should work (only tried it in wsl, where the terminal wasn't sending the correct signals for arrows, though)
telnet is preinstalled.
Interestingly, not for the newer versions of OS X http://osxdaily.com/2018/07/18/get-telnet-macos/
Or even “newer” versions of Windows. I think they stopped including it in Windows 7.
Oh wow, that's terrible.
Why? The tiny % of people who need telnet are perfectly able to install it themself.
you can brew install it trivially, but yeah my 2018 MacBook Pro with macOS Mojave didn't have it preinstalled.
No (since High Sierra IIRC)
Wasn't for me
Myself curious to write a GB emulator... how do you get images? After a quick search I see a list of "homebrews" on a collection repo on GitHub [0]. Is there a particularly good place to find games?
Legally? I've been tracking down physical cartridges and using a ripping tool, which is basically a hardware slot for a gameboy cartridge that connects to a PC via USB. The one I own personally is this one, which can dump all the common cartridge types ("mappers") and their save data:
https://bennvenn.myshopify.com/products/reader-writer-gen2
The popular titles (especially Pokemon) can be hard to track down at a fair price, but lesser known gameboy games can be found easily on Amazon and from other used sellers for a few dollars each. Even stuff like Tetris is easy to get ahold of because so many copies were produced. Bad games still make great test cases. :D
If you're after homebrew there's a whole bunch of sites that host it. One site that I pulled my early test ROMs from was:
https://pdroms.de/news/gameboy
But there are of course countless others. The demo scene is quite lively, and once your emulator is working at a basic level, demos can be good test cases since they often use the hardware in surprising and unusual ways. Finally, once you're serious about accuracy, check out this list of test ROMs:
http://tasvideos.org/EmulatorResources/GBAccuracyTests.html
Especially the tests by blargg; these are designed with a simple pass/fail result but go seriously in depth checking out hardware edge cases, and the source code is available which makes debugging them a breeze. Finally passing his CPU test was a major milestone.
The rabbit hole is very deep, but it's a fun dive!
archive.org has an archive of various retro console roms in their "No-Intro Collection 2016-01-03 Fixed" collection.
Being copyrighted, it's not legal to redistribute them. You're favorite torrent search engine might be able to help, though. Or you can buy them off eBay and dump the image yourself. I'm not sure what the current state of dumping hardware is, but 10 years ago I hacked together one that used a PC parallel port.
I can highly recommend https://www.tindie.com/products/insidegadgets/gbxcart-rw-gam....
> Works with Windows XP or higher and Linux/Mac (console version). On Linux/Mac the speeds are much slower.
How come?
> You'll just need a Micro-USB or USB-C cable depending on the connector type you choose. Please note the USB-C connector only has the USB 2.0 lines attached so it may not work with devices expecting a USB-C capable device; you might need a USB-C to USB-A adapter and then a USB-A to USB-C cable.
Do you know if there are plans for a future revision of the hardware which will allow for the greater speed that USB-C can provide to be utilized?
>> Works with Windows XP or higher and Linux/Mac (console version). On Linux/Mac the speeds are much slower.
Not sure. It dumps the cart over serial and there were some problems with higher speeds at one point.
> Do you know if there are plans for a future revision of the hardware which will allow for the greater speed that USB-C can provide to be utilized?
I don't think the carts themselves are that fast, there wouldn't be a huge amount of benefit. At least when I tried it it wasn't even coming close to using full USB 2 speed.
Presumably Nintendo will shut this down shortly?
The emulator itself seems to be in the clear, however `gameboy.live` certainly is not. It's hosting quite a handful of copyrighted games, and that's likely to earn it a cease and desist if it gets popular. Of course, at the moment it is also being hugged to death; I was not able to start a session.
I can't imagine that telnet versions of gameboy games are really going to take off in any capacity. That said, if you do choose to self host, make sure you protect the access in some way, or only distribute freely licensed homebrew, etc etc.
Highly unlikely, given all the other GB emulators that already exist, some of which are far more famous.
Yeah, until you start hosting roms I don't think Nintendo cares (although possibly begrudgingly). Once you do though... bad times.
Nintendo has even used existing open source emulators themselves in commercial products.
> Nintendo has even used existing open source emulators themselves in commercial products.
Source? I'd love to read more about that.
Best example I know of is PocketNES, but that was used by Jaleco in a GBA port:
https://waxy.org/2004/07/jaleco_borrows/
Nintendo has written or contracted a lot of emulators themselves. The grandparent may be thinking of the pervasive use of the iNES header format, which originated with an unofficial (though not open source) emulator:
I could be wrong, but I believe they're using one in the NES Classic.
I believe the NES classic and Switch use open source emulators?
At uni, a large chunk of my final-year grade hinged on a large project, where we'd meet up with a supervisor, build a non-trivial application, and write a dissertation on it.
One of the best projects from recent years that was handed out as inspiration was someone that built a game boy emulator, with the ultimate aim of being able to run Pokemon Red.
This dissertation was public on the CS site for about 5 years, with source code to run it, and although this was pre-GitHub Nintendo were still very litigious back then. No ROM's were provided, so I assume Nintendo either missed it, or didn't care.
They care, they just have no legal reason to force it to be taken down.
Fork it while you can!
It is more important to clone it, so that you have a local copy on your PC
forking is just a gesture, especially for obviously hot repos. a takedown of 1 can takedown all the forks
Yes. I cannot understand the point of those people who kept "forking" repositories on GitHub, but don't do any development on them. They have a long list of untouched forked repositories, like Linux kernel, Apache, nginx, ..., and makes it particularly difficult for me to find the repos of their original works.
Even as a "backup", it's pointless, because it's all Copy-on-Write, there's no backup.
As if they never learned to use the "Star" button to bookmark...
Personally, I don't fork any repos unless I'm working on a derived program, or working for a patch, even so, I'll delete my forked repos as soon as the patches are accepted (if it's a one-time contribution), so these forked repos won't spam my own list.
I wish github had a bookmarks feature. Currently most people star when stars should be a "I used this and its good" rather than "Seems interesting, should take a look later"
I know it's an obvious suggestion, but 'GitHub' folder of browser bookmarks? Not clear to me what value it would add as a GH feature, just interface clutter IMO.
The Gameboy & in fact, all games consoles completely passed me by - my experience of hand-held gaming was Donkey Kong and TomyTronic. Now I'm going to have a chance to see what I missed out on - sort of :)
Here are some unprompted recommendations :)
If you like puzzle games, Tetris, if you like adventure games, Link’s Awakening. If you like platforming, I’d recommend any of the Super Mario Land or Donkey Kong Land games!
My DS came with Pokemon Yellow, F-ZERO, MarioKart SuperCircuit, Metroid Fusion and Fire Emblem. They are all among the greats on Gameboy.
In fact, I'd say one of the things that helped the Gameboy succeed was that it had so very many good games.
why did you use ascii art with braille instead of half width unicode?
This is unbelievably impressive, especially from a college sophomore! How does a 19 year old know how to do this / have the time to do this!?
What do you mean? 19 year olds have no responsibilities to speak of except "school". When I was 19 I was doing the same shit, loads ands loads of time.