Reverse Engineering WFC

[AltF4]

Blah, midterms.

I can sniff Wifi packets. Anyone with an Atheros card can. (**** Broadcom) But the actual reverse engineering is the difficult part. You have to determine exactly how everything works. Piece by intricate piece.

You have to be scientific about it. Gather your data. As much as you can. Then correlate this data. Don't make assumptions. Or if you do, make them testable.

This is not a trivial project. Not the task of someone who isn't a professional network expert. I don't mean to dissuade anyone here, but this is going to take more of a concerted effort than "hey guys, let's make our own Wifi program". Then hope that someone just instantly makes it.

Things that are necessary for the organization and collection of this program:

1) A centralized leader who is qualified to be so.

2) A centralized location to publish results of reversing. (A Wiki would serve well)

3) A code repository. Maybe a subversion server, etc...

4) A collection and list of pledged responsibilities. (So people don't duplicate work)

5) Probably much much more.

And maybe someone should contact the Team Twiizers guys. They seem to be the main Wii hackers nowadays anywho. I bet their wisdom would be very helpful.

 

[Anth0ny]

Just call it "BRAWL ONLINE MINUS ALL THE CRAP THAT MAKES IT UNPLAYABLE"

That should capture the attention of everyone.

 

[BrutalBrutal]

I have a very solid grasp of C++ and I could help with programming the GUI using FLTK (portable GUI toolkit) or something similar. I have limited experience with networking, however, but I do have some experience with networking concepts and sockets. I would love to help out with this project in any way possbile.

 

[Buey]

Blah, midterms.

I can sniff Wifi packets. Anyone with an Atheros card can. (**** Broadcom) But the actual reverse engineering is the difficult part. You have to determine exactly how everything works. Piece by intricate piece.

You have to be scientific about it. Gather your data. As much as you can. Then correlate this data. Don't make assumptions. Or if you do, make them testable.

This is not a trivial project. Not the task of someone who isn't a professional network expert. I don't mean to dissuade anyone here, but this is going to take more of a concerted effort than "hey guys, let's make our own Wifi program". Then hope that someone just instantly makes it.

Things that are necessary for the organization and collection of this program:

1) A centralized leader who is qualified to be so.

2) A centralized location to publish results of reversing. (A Wiki would serve well)

3) A code repository. Maybe a subversion server, etc...

4) A collection and list of pledged responsibilities. (So people don't duplicate work)

5) Probably much much more.

And maybe someone should contact the Team Twiizers guys. They seem to be the main Wii hackers nowadays anywho. I bet their wisdom would be very helpful.

Well, we'll document the reverse engineering bit as much as we can, but I don't think we'll be creating an RFC for the full protocol or anything. Just find out the minimal set that's necessary and implement it.

I can host a Trac for organizing the project, but CVS/SVN would probably have to be on one of the big project hosting sites.

Since I mostly have Broadcom cards (or other cards that don't allow monitor mode), I can't sniff my Wii's packets at the moment...I have a netbook with Atheros 5007 but the 5007 isn't supported by OmniPeek, nor usable in BackTrack.

I have a very solid grasp of C++ and I could help with programming the GUI using FLTK (portable GUI toolkit) or something similar. I have limited experience with networking, however, but I do have some experience with networking concepts and sockets. I would love to help out with this project in any way possbile.

I would ideally want GUI dev in something like Flex, which is really easy and intuitive to use. Making windows with GLUT is a major pain.

 

[jodo]

I lack the technical skills to help out with something like this but I believe there was talk on the Dolphin forums about Kaillera / WiFi server support, so perhaps both dev teams could help each other with various bits of info they may stumble upon. [would love playing a lagless Brawl in HD :D]

 

[SCOTU]

might also have to write some ocarina codes. Brawl imposes an input delay that's much much much larger than the latency between the two wiis, so you might be able to just eliminate most of the input dealy by just writing an Ocarina code to be able to set it to whatever you want (2F-3F local, 5F cross country, 10F international; normal brawl seems to have a minimum of 10F).

 

[Buey]

Yeah, so this looks to be quite painful. When the user logs into WFC, the Wii hits 10 different servers or so on the nintendowifi.com domain with various requests, most using HTTPS. Then there's a mixture of HTTPS, raw TCP, and UDP flying around.

 

[BrutalBrutal]

I would ideally want GUI dev in something like Flex, which is really easy and intuitive to use. Making windows with GLUT is a major pain.

Why shouldn't the same program act as the GUI and intercept traffic in a Man-In-The-Middle attack? You want to create two programs when only one is needed? Making the daemon which does so in Java is counterproductive as well when there are C++ libraries (such as dsniff) which greatly simplify Man-in-the-Middle attacks of the nature you intend.

Programming a GUI really isn't that hard in C++, and you don't need anything flashy, just a clean and uncluttered interface. I don't know why you're fixated on FLEX unless you want to make the GUI yourself.

On another note, the description you posted on the first page about how you would go about doing it, it seems overly complicated. I thought that Brawl online worked P2P, so wouldn't you just need to find the format of the packet containing the information (from Nintendo) needed for the Wii to connect to another Wii, and create a packet containing information of your own, retrieved from the (non-nintendo) server, and then send it to the Wii?

Maybe we have different ideas about what the end-product would actually be. I would imagine it as a program you log on to, and it acts like a lobby such as the ones in most FPS games, ie with rooms which can be created by anyone, with the user being able to join a room that suits them. Nothing more complicated is needed. All you need to do is connect the Wiis to each other yourself.

 

[SCOTU]

lol at C++'s speed being a key point rofl. For something like this, you'd be fine using something as slow as java, since all the processing is easily less than a millisecond even in a slow language. As far as languages/ GUIs go, just use whatever the best/lead developer uses, since they're the one doing most the work

 

[BrutalBrutal]

Ok, you're right about the speed in retrospect . I guess I just want to help and I'd be about as useful using FLEX as anyone else who had never used it before, though it is apparently very intuitive.

 

[Ryusuta]

I just wish there was something I could do to help with this project. I am behind this 110%, but I feel like I'm just sitting on the sidelines as a cheerleader, since programming isn't my strong suit.

 

[Isatis]

I have a laptop with an Atheros card, and I have extensive knowledge in PHP, just tell me what to do

I just wish there was something I could do to help with this project. I am behind this 110%, but I feel like I'm just sitting on the sidelines as a cheerleader, since programming isn't my strong suit.

Beta testing, if we ever figure it out? :S

 

[HeKn_402]

this seems cool! I would like to be a beta tester also!!

 

[Ryusuta]

Sure, I'll Beta test for you. Before rushing to do so yourself, HeKn, remember that you're putting your system at risk if you agree to Beta test.

 

[shadowtroop]

LOL risk? I don't care, the Wii's as powerful as a 1997 PC anyways.

 

[Sails]

I'd love to ask a question; Why do you think that this will fix lag problems? If Brawl is P2P after connection, as stated here, then what are you hoping to accomplish? You would need to rewrite the actual netcode in the game to improve anything, correct?

 

[SCOTU]

LOL risk? I don't care, the Wii's as powerful as a 1997 PC anyways.

This is the most wrong thing i've read in several days. The wii is FAR more powerful than a '97 machine, and more powerful by far than most 2003 machines. You're probably just looking at some numbers and assuming you know what they mean, like CPU clockspeed, and making an invalid comparison against old computers.

I'd love to ask a question; Why do you think that this will fix lag problems? If Brawl is P2P after connection, as stated here, then what are you hoping to accomplish? You would need to rewrite the actual netcode in the game to improve anything, correct?

i don't actually think you need to rewrite the whole netcode. The latency in connection is significantly smaller than what the game implements an input delay for, so you could probably just make an ocarina code to change that default input delay.

 

[Ryusuta]

Just letting you know that I'm still willing t have my had on the chopping block for the testing process, even if it's probably quite some time away.

 

[KarateF22]

ill also beta test when the time comes. I understand the risk and blah blah blah...

 

[ShortFuse]

You don't need a WiFI sniffer. The Wii connects to the router. Your computer connects to the router. Do a network sniff or get a lan adapter and connect the wii to your pc and connect the pc to the internet via a second connection (router/direct).

I can code the GUI in C# 2.0 which is cross compatible with Linux and Mac via Mono

 

[SCOTU]

unless I'm mistaken, mono actually kinda sucks. I've got a friend who uses Linux, and I told him to get it cause C# is awesome. Apparently Mono has extremely limited compatibility.

 

[ShadowLink84]

I can beta test. I already have everything on my wii protected just in case something goes wrong.

 

[ShortFuse]

unless I'm mistaken, mono actually kinda sucks. I've got a friend who uses Linux, and I told him to get it cause C# is awesome. Apparently Mono has extremely limited compatibility.

News to me. BrawlPlusTweaker works fine in Mono. Even with my crappy friend finder which uses networking

 

[Buey]

Why shouldn't the same program act as the GUI and intercept traffic in a Man-In-The-Middle attack? You want to create two programs when only one is needed? Making the daemon which does so in Java is counterproductive as well when there are C++ libraries (such as dsniff) which greatly simplify Man-in-the-Middle attacks of the nature you intend.

Programming a GUI really isn't that hard in C++, and you don't need anything flashy, just a clean and uncluttered interface. I don't know why you're fixated on FLEX unless you want to make the GUI yourself.

On another note, the description you posted on the first page about how you would go about doing it, it seems overly complicated. I thought that Brawl online worked P2P, so wouldn't you just need to find the format of the packet containing the information (from Nintendo) needed for the Wii to connect to another Wii, and create a packet containing information of your own, retrieved from the (non-nintendo) server, and then send it to the Wii?

Maybe we have different ideas about what the end-product would actually be. I would imagine it as a program you log on to, and it acts like a lobby such as the ones in most FPS games, ie with rooms which can be created by anyone, with the user being able to join a room that suits them. Nothing more complicated is needed. All you need to do is connect the Wiis to each other yourself.

Java for simple portability. This should be easy to deploy for everyone. I am also not that comfortable with C/C++.

Programming in C++ is only not hard for those who are already familiar in C++, and it takes quite a bit of work to make anything that doesn't look horrifically ugly. I wanted to make the barriers toward contribution for this project as thin as possible. Flex is pretty easy to learn, looks very nice, and has a powerful IDE (FlexBuilder 3). Last year I found an interesting project that was written in Flex, looked at the code a bit, and got pretty functional with it within days.

You are correct in that the end product would just be a lobby, but consider the performance of Nintendo's own lobby servers. On busy nights you get upwards of a 5 minute refresh lag. If this project gains even a bit of popularity, it will suffer the same fate (moreso because we do not have the financial resources that Nintendo has). Thus, a scalable solution is needed, and a P2P overlay is the logical choice.

The main performance increase this project would supply over Nintendo's is in the performance of the servers (since Nintendo's are overloaded a lot). Clients can be optimized to reduce latency, but this would require Ocarina/HBC/etc., but I don't want to make that a prerequisite for using this system.

 

[Buey]

As for development, I haven't been able to do much more than capturing packets and taking a look at them. I have set up a MediaWiki (and also chosen a tentative name) at:

http://wiinet.randomsh*t.org (note that the URL does NOT have a *...i'm sure you can figure out what it's really supposed to be)

So, any updates (from myself or others) would probably be posted there.

If anyone has a good schema for capturing packets without an Atheros card or Wii Ethernet adaptor, please let me know. My schema is horrible:

PCs can't act as access points, only as ad-hoc nodes. Macs can act as APs, but I can't get Wireshark working on my MacBook Pro. So, I have the MacBook running as an AP for the Wii, and it's connect via a switch through Ethernet to my Windows laptop, which connects to the internet through my regular wireless network...rather convoluted. Also, because of NAT, all requests coming from the Wii look like they're coming from the MacBook, so I get random trash requests in the middle of the Wii traffic while I'm sniffing (requests that originate from the Mac).

 

[wiifanatic]

I can help code web interfaces (In php)

 

[BrutalBrutal]

Programming in C++ is only not hard for those who are already familiar in C++, and it takes quite a bit of work to make anything that doesn't look horrifically ugly. I wanted to make the barriers toward contribution for this project as thin as possible. Flex is pretty easy to learn, looks very nice, and has a powerful IDE (FlexBuilder 3). Last year I found an interesting project that was written in Flex, looked at the code a bit, and got pretty functional with it within days.

Fair enough. I might look into that then.

The main performance increase this project would supply over Nintendo's is in the performance of the servers (since Nintendo's are overloaded a lot). Clients can be optimized to reduce latency, but this would require Ocarina/HBC/etc., but I don't want to make that a prerequisite for using this system.

Not to mention any modifications would basically have to be written in Assembly.

PCs can't act as access points, only as ad-hoc nodes. Macs can act as APs, but I can't get Wireshark working on my MacBook Pro. So, I have the MacBook running as an AP for the Wii, and it's connect via a switch through Ethernet to my Windows laptop, which connects to the internet through my regular wireless network...rather convoluted. Also, because of NAT, all requests coming from the Wii look like they're coming from the MacBook, so I get random trash requests in the middle of the Wii traffic while I'm sniffing (requests that originate from the Mac).

That's actually an interesting question because it makes me wonder how the end product would work. I didn't know that PCs could only function as ad-hoc nodes. I will be using a wifi USB I got for about $AUD 50 on ebay, just as soon as I get my laptop working (because the drivers don't work with 64-bit Vista). That's always an option.

 

[Marufuji Ryo]

Good luck with this.

 

[Zolga Owns]

I can help design graphics if needed...
I don't know much about programming to help atm though I'm learning.

 

[samsonites101]

I would be happy to try and help, atleast with the parts that require java cause I know java pretty well. It sounds like a good idea. Also, nintendo cannot patch it because games can't get patched on wii. Everthing comes off the disc/ram once the game is loaded. There is no real wii os running underneath to hold the patches unless they are loaded directly onto ram, like the codes used here. I'd love to help. Send me an email if your interested in letting me help. My email is Samsonites101@gmail.com

 

[Ryusuta]

If we can set up a web page and/or usergroup specfically dedicated to this project, we could do a more efficient job of parsing out the tasks that are required. Like I said, I'm not much on C++/Java, but I can do most other things and am a willing bug tester, so that's a start. And I'm sure there are others that feel the same.

Perhaps we could set up a mini-board or xat or something.

 

[Zolga Owns]

@ 0rion
http://wiinet.randomsh*t.org/
(Remove the * and replace with an i)
Someone up there posted it

 

[Rikuzu]

is this project still going?

 

[Ryusuta]

@ 0rion
http://wiinet.randomsh*t.org/
(Remove the * and replace with an i)
Someone up there posted it

Glad the topic was bumped, because I didn't see this post. I'll check it out, now tha it's bookmarked.

 

[Oshtoby]

So, sorry to bump this topic, but is this going anywhere? It seems like a fantastic idea.

 

[Isatis]

So, sorry to bump this topic, but is this going anywhere? It seems like a fantastic idea.

Same question I'd like to ask.

 

[[TSON]]

Especially if we could use it as a replacement for Brawl+ Wifi to avoid being banned..

 

[Revven]

Especially if we could use it as a replacement for Brawl+ Wifi to avoid being banned..

You don't get banned in friends matches.

 

[[TSON]]

Oh, seriously?

Sweetness.

 

[GigaBowserXyZ]

o then i guess i don't have to worry about that anymore.