Poryhack

Ports are always possible. In this case it would be relatively easy since Java and C# (which PKHeX is written in) are very similar. The hardest part will be adapting the UI into something that makes sense on a phone.

You reset 23,000 times? Props for dedication I guess. The chances could be determined by stepping through the game in a debugger although I don't know if there is a such thing for the 3ds.

Nice work on figuring these out and presenting your findings.

Cool, I was under the impression Gateway would only play valid signed ROMs.

I'm a bit out of the loop: Is it possible to play an edited ROM?

I'm not sure where to ask this but. Do you know where I can get a used japan x or y that FOR SURE has the pokedex already? And I have pokemon x so does it matter what version I get in Japanese? Also so for this question I don't know where to go.

Getting one that for sure has the pokedex probably isn't gonna happen. Kaphotics has said that he will be updating PKHeX to allow for pokedex editing so that should probably solve your problem (you can edit the Japanese save file without having to know any Japanese).

It doesn't matter whether you get X or Y if you're intending to use Bank.

Does CyberGadget use the same technique as Datel for editing saves?

Can we get some more details on the circuit you built?

Do not ask how to use the Code Generator -- it requires a hacked 3DS with custom firmware and the interpreter is not finished.

It seems to me that you could've saved yourself a lot of stupid questions by keeping this out of any public releases until the infrastructure (interpreter, etc) is ready and available.

We already can modify the client. "We" being the select few people that have setups enabling them to run unsigned code. Those people could technically document the protocol now and allow us to develop fake clients. You're right about a TLS exploit not really being needed, but it's a potential vector for somebody who wants to document the protocol and write up a fake client (which would work for everyone).

I am a little late with this, but Red Hat has an online tool (I've seen a couple other downloadable ones) to check for the presence of this vulnerability on the server side (the vulnerability needs to exist on client and server for a successful exploit) located here. Interestingly, all the Nintendo domains not hosted on Amazon EC2 (there are a few, mostly for 2nd/3rd party stuff like Pokemon) are affected. This also confirms that Nintendo is using OpenSSL on their servers. Still no confirmation of OpenSSL on the client side, but it could be useful to know for sure that their servers are running OpenSSL in case of future exploits.

I will stay on the lookout for a way to test for this vulnerability on the client aka (3)DS side. The information is out there for people a little more inclined than I am, so I expect one will pop up soon.

Fake clients aren't technically MITM. You don't even really need a MITM exploit to develop them. In an ideal situation Nintendo's servers would just see the fake client as a regular 3DS.

If unsigned code execution continues to be a privilege limited to a select few then we could see fake clients pop up, assuming those select few are willing to do some research into the protocol. If it goes widespread however that that will obviously be the preferred way to do things. Although IMO there is something kinda elegant about just "trading" your pokemon away to a Pokecheck type website, editing it via your web browser, and returning it the same way. No fiddling with save files or clunky windows forms apps...

I was thinking more about fake clients than fake servers. If we can decrypt the traffic and reverse-engineer the protocol we could write a client that would allow for exporting and importing PKMs via trade or whatever.

I'm not certain that the actual implementation of TLS on the (3)DS uses OpenSSL, but like I mentioned in my opening post, the DSi and 3DS manuals include OpenSSL's copyright notice (as well a 2 other crypto products).

Yet another OpenSSL bug was announced today. This one is MITM only unlike heartbleed. Some relevant links:

https://www.openssl.org/news/secadv_20140605.txt

http://ccsinjection.lepidum.co.jp/

https://www.imperialviolet.org/2014/06/05/earlyccs.html

I doubt it.. But, honestly I mainly use dolphin 64 bits now anyways, so... I wouldn't exactly shed a tear if it was the case.. Less work for me!

I looked it up. They are. (More or less.)

Aren't 32bit versions of Dolphin discontinued now?

I'm not sure who responded that way, but for what it's worth, as a dev-type person I think this is pretty rad.

Didn't mean to say that anybody responded in the negative, just that nobody responded at all (when I said it).

Yeah that's the right attitude. You could also try /r/pokemon (and maybe search for some emulation-related subreddits?).

This is really impressive. I only played with it briefly but I can definitely see how it would be cool for a "Twitch Plays Pokemon" scenario. Bummer that you missed the hype train on that or this could have really exploded. Have you posted this anywhere else? I'm a little bummed out for you that you've gotten such a lukewarm response here; don't take it to heart. Most of the dev-types around here are focused on X/Y at the moment.

I apologize in advance if this sounds really obvious (or stupid), but will we still be able to trade between two games if we have two devices? :grog:

Local trades will work fine. Trades over the internet won't work without some kind of hack.

It depends. Most, but not all, of the ways to defeat TLS that have been described in this thread would affect the 3DS/DS as a whole and not just specific games. For the 3DS at least, Nintendo probably would patch out anything that affected the platform as a whole. The cool part about breaking TLS though is that you could potentially build up your own online infrastructure and simply never upgrade your firmware. I don't know if that's very realistic but it is an option.

I will admit that discretion would probably be optimal if a hole is found.

Most of this is easy enough to test. Gens 4 and 5 store Nintendo CA's public key directly in the ROM. You can generate your own key pair with OpenSSL and replace the public key in the ROM with your own. From there you can generate and sign your own certificates with whatever algorithm and subject field you'd like.

The factoring thing is a longshot but maybe worth pursuing. Once you have a collection of public keys from Nintendo CA and the certificates it has signed you can check out the EFF SSL Observatory or something similar to comb through a large number of certificates for common factors. For what it's worth, Nintendo uses OpenSSL to create/sign certificates.

Question: Does the DS accept X.509 certificates using signing algorithms other than SHA1-RSA? Like perhaps MD5?

I'm not sure. I've seen the 3DS accept SHA256-RSA. My best guess is that the DS does accept MD5.

Also, does it care what's contained in the subject or just that it's signed by Nintendo CA?

Again, not sure. I can difinitively say from my own testing though that 3DS titles do care about the subject field and not just being signed by the correct CA.

Edit: Found this in a Google search for "factoring RSA":

http://windowsontheory.org/2012/05/15/979/

Basically, if either Nintendo CA's public key or that of any of the certificates they've signed share a common factor with any random public key we can find on the internet, it can be broken in a reasonable time if enough people have bitcoin mining clusters they're willing to lend.

I don't see any mention of Bitcoin in that article, where are you getting that part?

Update: GenV support added, and it's live for testing. It's such a beta I make no promises it will do anything sane with your pokemon.

http://foundations-gts.cloudapp.net/

Haven't tested it, but congrats on the progress. I'm sure you'll get lots of attention after the shutdown!

AFAIK his work still requires a ROM hack to strip the SSL. I'd love to hear from him anyhow.

That's correct. Good news nonetheless.