3

Context:

I want to reverse engineer a protocol in place for the Nintendo 3DS. The implementation however, uses TLS, which makes it difficult to reverse engineer. I'm currently able to sniff packets to/from my 3DS because I have a spare router being used for a "testing wifi" that runs through my desktop's ethernet, and then through my desktops wireless card to the actual internet.

What I've investigated:

  • MITM
  • Proxies

Roadblocks:

  • I can't force the 3DS to accept a questionable certificate.
  • I can't forge the certificate.
  • I won't attempt thieving the actual private key ( I have little interest for it once I know the protocol ).
  • I'm unable to read the session key from my console's RAM, due to lack of hardware.

Potential solution:

  • I'm almost 100% positive that the protocol is some form of HTTP ( Probably through headers, mostly ). So if the encryption is XOR based, I may be able to get part of the key, at least? I don't know a lot about cryptography.
  • I've thought about setting up a proxy, a CA server instance [ and pointing my desktop's host file to this server instance ], installing Nintendo's certificate and then overwriting their public key with my own private key, and then using my 3DS's certificate on the proxy to communicate with Nintendo. I'm not for certain that this will work as I honestly don't have a complete grasp on how TSL works beyond that it's not something you can break easily.
  • Is brute-strength a viable option if I am able to generate more encrypted data?

tl;dr- Is there a way for me to decrypt this data without the server's private key, or cracking into the RAM to find the session key? I do have the server's certificate as well as my 3DS's client certificate.

Community
  • 1
Full Metal
  • 55
  • 1
  • 5

2 Answers2

3

Can you install a CA certificate on the 3DS? In that case, this might work:

If the device implements Pinning then this still won't work. In that case your project might be kinda doomed.

If it turns out not to be HTTP, you can try a full MiTM attack, which involves setting up a fake CA, using mitmproxy and routing all traffic from the 3ds through it.

TildalWave
  • 10,801
  • 11
  • 45
  • 84
NSSec
  • 459
  • 2
  • 5
  • Do you think that by using the web browser to connect to OWASP would allow me to permanently install this certificate, or just use it once? And is the full MiTM attack what I had described in my second potential solution, or is there more to it than I outlined? – Full Metal Oct 29 '14 at 14:10
3

If Nintendo did not botch things, then you won't succeed. The TLS protocol is meant precisely to prevent inspection and alteration from the outside.

If you want to know more on TLS (also known as SSL), read this answer as a walk-through. There are mostly four ways through which you might hope to reverse-engineer the protocol:

  1. Try to make the Nintendo 3DS accept a fake server certificate. This is the essence of @MrSec's answer: usually, TLS clients validate the server's certificate with regards to a set of "trusted CA" installed in the client. If you can add your own CA in that set, then you can create fake certificates that the client will accept.

  2. See if the Nintendo implementation would be susceptible to one of the known attacks on TLS. After all, console firmware updates tend to be rarer than fixes on general purpose computers, so some vulnerabilities may still lurk. On the bright side, you would learn a lot on cryptography if you choose that path and succeed.

  3. Maybe the console can be convinced to run the same protocol without TLS, in some "abnormal" situations. Many deployed software have a hidden debug mode that lingers around because the development teams forgot to remove it when doing the "production build".

  4. Do something else. For instance, the console connects to an external server; you might want to connect to that server from your PC, and work out the protocol details based on what the server answers, without implying the console at all.

Of course, accessing the RAM, or at least code executed by the console (the protocol implementation), would be a lot simpler. Note that there is not necessarily any "private key" to steal from the console. In TLS, the certificate and private key are normally on the server side.

Community
  • 1
Tom Leek
  • 168,808
  • 28
  • 337
  • 475
  • Well, hopefully Nintendo botch'd things, then, haha. I was hoping to circumvent installing the CA by doing a DNS hack. Are there mechanisms protecting against that? ( Does the CA have a private key, also? ). I'll have to look at the known attacks - the first one that stands out to me is the renegotiation. Maybe by blocking the https port, I can force the 3DS to "fall back" to http. – Full Metal Oct 29 '14 at 14:22
  • Also, I think I may need to install the 3DS's client certificate onto my browser, but I'm not entirely sure how to go about that. Will google. – Full Metal Oct 29 '14 at 14:39
  • If the client _also_ has a certificate, then in that case there is a private key on the 3DS, and chances are that the server uses it to know that it is talking to a genuine 3DS, in which case your chances of success drop down. – Tom Leek Oct 29 '14 at 14:51
  • @FullMetal Yes, the CA also has a private key. Also, DNS modifications are usually used to become a MITM in the first place, and not to break TLS, so its mostly unrelated. – user10008 Oct 29 '14 at 16:16
  • @user10008 I see. Perhaps this is hopeless after all, then. – Full Metal Oct 29 '14 at 16:54