> I managed to exploit the Nintendo DSi browser 15 years after it was released
I guess that was inevitable. So much exposed code over so much time.
I remember having a bunch of lunch/dinner discussions about this browser with the two developers actually doing that port in ~2005. It was a super secret and exciting project back then.
We worked in the same small Opera Software office of 30 people or so. They were really frustrated with the code footprint limitations of the DS.
The DSi Browser was an updated version of that original DS Browser. Don't know if it was based on the old port, or if it was redone. The DSi was more capable than the original DS, and the browser had to be redone because the old GBA-slot RAM cart was no longer supported. They switched the base to a considerably newer version of Opera. As a major advantage, the browser actually shipped with the DSi, making it much more useful than the two-cartridge getup necessary for the original DS (which, in the end, very few people ended up getting for that system).
The DSi browser was also actually good. I preferred it to the 3DS browser, by a huge margin.
I actually preferred the DSi's web browser to the browser on my iPod Touch, because the DSi's dual screens were utilized in a clever way that made it easier to view websites formatted for desktops. (Mobiile-optimized websites mostly weren't a thing yet.)
By contrast, the browser on the original DS was a barely usable nightmare. I'm sure the developers did what they could with the limited hardware available, but the result ran extremely slowly.
> They were really frustrated with the code footprint limitations of the DS.
As in the memory or the final binary size? I would have thought memory management was the tricky part -- even with the mandatory 8 MB expansion in the GBA slot -- but I suppose they would have been under even more pressure to fit it onto the smallest cart possible, with the cost of the expansion pack added for every unit
Now you're making me uncertain. I was pretty certain it was the code/binary footprint. I remember suggesting they look into using any MMU for doing code overlaying/swapping [and the DS doesn't appear to have one...].
The Opera code was very memory efficient after having gone through so many memory usage optimizations triggered by lots of mobile platform ports.
> E: I forgot about the mobile Opera ports, that also tracks - I'd love to read about the engineering that went into them!
Can't really meaningfully expand on that, most of that happened before I joined in 2004, but I can tell you that the fact that Opera was extremely memory efficient made Opera Mini (250M monthly uniques, 150k web page transcodes/s) economically possible starting 2005.
We needed to keep the browser/window state around for each user until they clicked the next link. If we threw it out, any javascript state would be lost.
Reading about Mini doing layout specifically for devices with <128px wide displays, I wonder how well today's responsive design frameworks would deal with that...
Mini did some tricks so the "display" was much wider than the device display but text columns were wrapped at device display width. So you you could zoom out and see the whole page but the text was readable when you zoomed in.
Hi! Do you remember what the limit was that prompted this costly measure? Addressable code space from the CPU? How could there be a limit in the megabytes, not gigabytes? I don't get it.
Was the DSi browser based on the same code as the DS browser?
The DS browser (which seems to be what you're talking about) was 2 physical cartridges, one that slotted into the regular DS game slot and an 8GB memory expansion cart that went in the GBA slot. The DSi's browser was built in, and the system didn't even have a GBA slot.
e: On a tangent, the Nintendo DS homebrew scene did end up with a standard (DLDI) for accessing flashcart storage, including the SD/CF slots on some GBA flashcarts -- so you would not have gotten 8 GB of RAM, but if you paid through the nose, you could potentially have made your DS swap out memory pages to an 8 GB memory card :V
This is a fascinating write-up. As somebody who's dabbled with homebrew a bunch over the years I've always wondered how one figures out exploits from scratch.
Nintendo is pretty litigious about this sort of stuff but I guess because this is such an old system they're able to get away with documenting exploit process like this.
Does anybody on HN know of other similar eng-focused guides for this sort of stuff out in the wild, or authors to follow?
The International Journal of Proof of Concept or GTFO (https://www.alchemistowl.org/pocorgtfo/) is a fun compilation of reverse-engineering efforts with a bent towards older systems - issue 0x2 has an article on getting RCE on a Tamagotchi :D
For those wondering about the hardware: 16MB of RAM, 133MHz ARM9, and 33MHz ARM7. 256MB of internal storage.
In other words, it's comparable to an early 90s PC. The fact that it can run a browser, complete with JS support, seems nearly unbelievable these days.
Keep in mind, it used Opera Mini, so no actual JS was run on the device. It was rendered server side and an "image" (draw instructions, really) was essentially sent as a response.
This is incorrect - you can run base64 bookmarklets without network. It is running a highly stripped down version of Presto. Opera Mini did use 'server side rendering' while this is handled on the device.
Twitter’s mobile site, for instance, is looking pretty good.
That surprised me as I wondered just how much JS capabilities the browser has; then I realised that article was written in 2013, when Twitter was still relatively sane and not the bloated SPA it is today (yet the actual content being displayed is not much different from 10 years ago.)
Not OP, but imo the game library on the DS was better (the 3ds also had plenty of great games, just not as many). You do have to sift through an unusually large amount of shovelware to find the good stuff though, similar to the Wii.
Of course you can play DS games on 3ds, but you have to choose between blurry non integer scaling to full screen or crisp native but small with black borders. The games look better running at native res on the big screen of the DSi XL.
DSi are quite cheap and available compared to the 3DS which is a lot pricier. And dsi is quite sleek and simple (like the old iPods) compared to the 3ds line which got quite large and heavy (which a lot of
People prefer)
In addition to the reasons others have stated, old games are designed with a D-pad in mind, not a circle pad/joystick, and the D-pad on the 3DS is in a slightly awkward position.
Personally the DS/i was just a bigger part of my life. The 3DS homebrew scene is a lot bigger but I still just love messing with the exact ds I used when I was in school.
Agreed. There's something very special about playing it all on Nintendo hardware. Unfortunately a couple of my favorite games have freezing issues when emulated on the DSi.
Has anyone tried developing for the Steam Deck? Yes "it's just a PC" but I mean making a game optimized for the Deck's screen size and controls, something that many devs get wrong on the Nintendo Switch where the text is too tiny in handheld mode and the UI is too cluttered.
Valve should let the Deck be targeted as a standalone platform in its own right, rather than a PC that just happens to be portable. Let there be a dedicated SDK and APIs that let us just optimize for the Deck without worrying about how a game might look or run on a proper desktop/laptop.
I guess that was inevitable. So much exposed code over so much time.
I remember having a bunch of lunch/dinner discussions about this browser with the two developers actually doing that port in ~2005. It was a super secret and exciting project back then.
We worked in the same small Opera Software office of 30 people or so. They were really frustrated with the code footprint limitations of the DS.