PretendoNetwork / Inkay

Wii U Pretendo Network patches (Aroma)
GNU General Public License v3.0
159 stars 41 forks source link

[Feature]: Ability to load certificate from a file #40

Open Milk-Cool opened 3 months ago

Milk-Cool commented 3 months ago

Checked Existing

What feature do you want to see added?

Basically what the title said. Aroma modules have settings that can be opened with L+DOWN+(-). My suggestion is that it should be possible to add custom servers or enter a custom address in these settings so that it's easier for developers to... well... develop.

Why do you want to have this feature?

I want to contribute to pretendo but there's no easy way to switch between pretendo and my official servers.

Any other details to share? (OPTIONAL)

No response

Cart1416 commented 3 months ago

I can't even figure out how to compile

Milk-Cool commented 3 months ago

@Cart1416 just use docker with the included dockerfile

Cart1416 commented 3 months ago

@Milk-Cool the docker thing complained about a main function missing for the linker so I added a dummy function and got a 50kb wps that didnt work

Milk-Cool commented 3 months ago

@Cart1416 right... it does miss an instruction, but not the linking instruction. delete dockerfile, git pull and then add this line:

COPY . /app

before WORKDIR.

Milk-Cool commented 3 months ago

then you can cp build files from container. gl!

redmine4404 commented 3 months ago

It would be geat, but Inkay also provide the wii U the certificate needed to allow the console to connect to the pretendo proxy. And that certificate is generate with mitm. So to implement that, a back end service that will recover the certificate and send it to every console that asking for it will be needed and a script who would automatically download the certificate will need to be implemented to Inkay. That sound like a lot of work for just to save just a couples of minutes.

jonbarrow commented 3 months ago

I'm not sure this is something within Inkay's scope. Inkay is not a development tool, it's our production patches for standard users. If someone wants to use a different address, they can just compile their own version. Adding direct compilation instructions is already added to our TODO list via https://github.com/PretendoNetwork/Inkay/issues/39

If the goal is development use, generally it's recommended to have a proxy server set up to aid in debugging. Every major proxy server out there supports some form of automatic request modification (Charles having this in the UI, Fiddler (Classic) having FiddlerScript, mitmproxy having Python plugins, etc.), which can be trivially used to direct requests to a different server. Some proxies, like Charles, even have this as a built in feature (through the "Rewrites" feature)

We even have a custom mitmproxy setup designed for proxying Nintendo traffic and redirecting it to our servers https://github.com/PretendoNetwork/mitmproxy-nintendo. This can easily be modified to point to your own servers during development

This is how we all generally do things anyway. I use Charles with a Rewrite rule setup to point all https://account.nintendo.net requests to http://account.pretendo.cc, and then modify my hosts file to point account.pretendo.cc to my local servers. You can easily do the same thing but changing https://account.nintendo.net to https://account.pretendo.cc and http://account.pretendo.cc to something like http://account.pretendo.local or whatever (just so that the initial CONNECT request passes for the live server)

Setting your own server addresses in Inkay isn’t super useful even for development use since again you really want a proxy server regardless just to make sure things are going as expected, and at that point just use the proxy server to direct back to your local servers

MatthewL246 commented 3 months ago

In addition, the servers currently use subdomains to route requests. Setting a custom address like 192.168.1.2 for the patches wouldn't work because requests to account.pretendo.cc, nasc.pretendo.cc, and conntest.pretendo.cc (all of which are handled by the account server) would look the same if they were all sent directly to 192.168.1.2.

Making the servers work correctly requires the console to send requests to an actual domain with a subdomain, which requires either an MITM-ing proxy, DNS spoofing, or purchasing a real domain. All of these require additional setup beyond just setting a custom address in Inkay, and the first two methods don't require changing anything in the Inkay code.

Something that would be convenient for development is allowing Inkay to load the Juxt certificate off the SD card like the 3DS patches do, which would remove the need to recompile Inkay when using a MITM-ing proxy. But that's a separate issue.

Milk-Cool commented 3 months ago

Hello! I kind of forgot about this issue, however since i have created it, I have actually learnt about how the proxy is usually used. And I do think this is a better solution. However, replacing the whole plugin is still unnecessary in my opinion, as loading the certificate from a file is possible. I am not sure whether this is a good solution, but here's what I'm proposing now:

  1. If the certificate file does not exist at a specific path, Inkay should use the one bundled with it.
  2. If it does exist, Inkay should replace the certificate with the certificate from that file before applying the patches.
jonbarrow commented 3 months ago

I agree that loading the certificate from a file, when present, is something good to have. We may need to update our certificates at some point and issuing an entire plugin update for this is unnecessary