You are not logged in.

Read the FAQ and Knowledge Base before posting.
We won't make a 3DS/2DS emulator.



#1 2010-01-18 22:21:58

Luigi__
Member
From: Peach__'s castle
Registered: 2009-05-29
Posts: 18
Website

The WFC discussion thread

So yeah. The question is: are we allowing WFC connections from DeSmuME? Let's discuss this matter.

First of all, no comments like "plz make wfc work i rly want to play pokemon over wfc i rly want wfc blah blah".
If you know nothing about the technical part of the thing and just want to play pokemon over WFC, you will not be able to contribute to this discussion.

WFC currently doesn't work.

Let's assume it works.
- The default MAC address used by DeSmuME is always the same (00:09:BF:12:34:56). If Nintendo sees like 500 users with the same MAC address, it'll look suspicious.
--- We can force users to have a firmware dump.
----- But it wouldn't solve anything. People would all follow the illegal path and download the same firmware image with the same MAC address.
--- We can just take the MAC address of the user's computer.
----- But it could mess up his network.
--- We can generate a MAC address randomly from the computer's MAC address.
----- Maybe the WFC servers deny any connection from a device that doesn't have a DS-like MAC address.
--- We can make a random DS-like MAC address.
----- But chances are that it'll collide with existing MAC addresses.
--- But does the WFC protocol transfer MAC addresses at all?

- Maybe the WFC protocol relies on a precise timing.
--- It'd be a bad idea from Nintendo. Timings are unpredictable, mainly due to the fact the data has to go through your network, then the internet, before reaching the WFC servers.

- What if DeSmuME crashes/hangs/whatever during a WFC game?
--- Dunno. Maybe it'll crash the WFC game, maybe it'll crash the WFC servers (really, really unwanted), maybe it'll not affect the game apart from excluding the player who crashed.
--- I think it's more like "What if player X turns his DS off during a WFC game?". Aka, shouldn't cause big trouble.

- What if DeSmuME happens to send incorrect data to the WFC servers?
--- At worst, the DeSmuME user would get thrown out of the WFC game with a big "Communication error #12345" message, I think.
--- Unless the data is REALLY incorrect and the WFC servers' software is as badly coded as, say, the WiiOS (BannerBomb and other exploits come to mind). In this case it could crash the servers and even lead to hacking attempts from malicious users (really, really, really, really unwanted).

- What if hackers use DeSmuME to hack the WFC servers?
--- That's an interesting point. We'll make DeSmuME so they can't do it without modifying the source code, of course.
--- But what if they modify the source code?
----- We can just tell we aren't responsible for anything done with unofficial/modified builds, are we? We don't support those builds anyway.
--- After all, why would people want to hack the WFC servers? WFC doesn't transmit critical data anyway.
--- Assuming they really want to hack those servers after all. They'd rather use real hacking software, not DeSmuME, wouldn't they?
--- If someone hacked the WFC servers, I think Nintendo would look for their IP and report them to their ISP, rather than trying to shutdown emulators that are perfectly legal in themselves.



Feel free to discuss those points or other points I could have missed, and/or to prove me wrong.

Remember: no 'plz make wfc work i rly want to play pokemon with wfc plz'!!!

Last edited by Luigi__ (2010-01-18 22:23:13)


Kuribo64 - If you're wondering where Mario__ is, he's currently saving Peach__ once again.

Offline

#2 2010-01-18 23:01:41

zeromus
Radical Ninja
Registered: 2009-01-05
Posts: 6,169

Re: The WFC discussion thread

That is a pretty good overview. I think you entirely left off the question of "What if hackers use desmume to CHEAT on the WFC servers?" We should find out the state of the art of WFC cheating via cheat codes, etc., to consider how much we would change that. There is an entire class of cheating which should be nearly undetectable, which would be done by lua scripts to create flawless (and sometimes prescient) playing. I guarantee you nintendo and other developers are nowhere near as ready to deal with cheaters as PC game developers are. But then again, how bad is it already?

Maybe WFC is mostly used for casual playing with friends and it doesnt matter if it is totally cheated. Unlike many PC games, WFC is usually an add-on to a primarily single player game.

The significance of this question is mostly that it is a new way for the emulation world to touch the legit console games world, by emulator users getting on their servers. There may be a necessary philosophical response to this, quite apart from the practical concerns.

There shouldn't really be any way to maliciously "hack" the WFC servers or else it would have been done already by analyzing the protocol, and that isn't our problem at all. I'm not sure what that means anyway; one must state a purpose when discussing hacks. Hack to cheat? Hack to DDoS?

Offline

#3 2010-01-19 03:24:32

yonizaf
Member
Registered: 2009-12-22
Posts: 179

Re: The WFC discussion thread

well, Nintendo shouldn't know what MAC you use, because it's only used on the local network. unless they include it in the packet's data for some reason (unlikely), but then you could send them whatever else you want, and still use what you use on the real network.

however, the way things are now (same MAC for everyone) there's another problem: what if 2 or more people on the same network are using desmume (and wifi)? the MACs will collide, not good (I think). anyway, it should be better to randomize the MAC.

and, I was able to connect to freenode with ClIRC, though it seemed to work only after I ping'd desmume. wonder why.

Offline

#4 2010-01-19 18:06:40

Luigi__
Member
From: Peach__'s castle
Registered: 2009-05-29
Posts: 18
Website

Re: The WFC discussion thread

zeromus wrote:

That is a pretty good overview. I think you entirely left off the question of "What if hackers use desmume to CHEAT on the WFC servers?" We should find out the state of the art of WFC cheating via cheat codes, etc., to consider how much we would change that. There is an entire class of cheating which should be nearly undetectable, which would be done by lua scripts to create flawless (and sometimes prescient) playing. I guarantee you nintendo and other developers are nowhere near as ready to deal with cheaters as PC game developers are. But then again, how bad is it already?

I see. You mean if they use LUA scripts, or ARDS/whatever cheat codes while WFC-playing. Interesting point.
My answer: we should detect when the game tries to connect to the WFC servers (by looking for particular data in the packets being sent, I guess) and, when it's doing, block LUA/ARDS cheats.

And for what's hacking the WFC servers, I can't really find a purpose to it. Because I meant 'real' hacking, aka trying to get the servers down or to retrieve sensitive data from them (I don't think there's any in WFC though).
If it's hacking for cheating, well, interesting... depending on how much the user is cheating, it may or may not be noticeable by Nintendo. If it is, it is really bad for us. We should just block any cheats when WFC'ing. But this point may need more thinking and discussion.

But it is already possible to use an ARDS when WFC'ing, I think. And it hasn't been reported as crashing the WFC servers or whatever. So ARDS should be okay. The real problem is LUA.


yonizaf wrote:

well, Nintendo shouldn't know what MAC you use, because it's only used on the local network. unless they include it in the packet's data for some reason (unlikely), but then you could send them whatever else you want, and still use what you use on the real network.

however, the way things are now (same MAC for everyone) there's another problem: what if 2 or more people on the same network are using desmume (and wifi)? the MACs will collide, not good (I think). anyway, it should be better to randomize the MAC.

and, I was able to connect to freenode with ClIRC, though it seemed to work only after I ping'd desmume. wonder why.

The best way to know that is to record the packets being sent and look for the MAC address in them. There we have our answer.

Also, if you set DeSmuME to load a firmware dump, you'll be using the MAC address stored in your dump. But I agree, we should make DeSmuME generate different MAC addresses for each computer. Probably a MAC address like 00:09:BF:xx:xx:xx (where xx:xx:xx are the last three numbers of your computer's MAC address) would do it.

And about ClIRC. ATM, it works, but the connection is wonky. I'm looking for what could cause that. Maybe just your router having trouble acknowledging the presence of the DeSmuME "device". Mine had trouble too. But the connection is still wonky. I could connect to EFNet and talk on #dolphin-emu, but the connection timed out after a while.
The problem may be that SoftAP's current receiver can only read one packet every millisecond. There's high chance that packets are being missed.
I'm going to rewrite the receiving code so it can handle more packets per millisecond and also make it operate in nonblocking mode.

Last edited by Luigi__ (2010-01-19 18:58:27)


Kuribo64 - If you're wondering where Mario__ is, he's currently saving Peach__ once again.

Offline

#5 2010-01-19 20:55:06

shash
Administrator
Registered: 2007-03-17
Posts: 897

Re: The WFC discussion thread

Cheating in WFC is already possible using a DS, as no checks are done. About the Lua auto-playing scheme, I see it as an evolution of cheating. As far as I know, most of the people playing on WFC, play against trusted peers.

As for the MAC issues, remember that Desmume is open-source, and generating a variation that world do something else with the MAC sent would be rather easy, so just avoid putting too much effort on that.

On a general note, imho, just make and implementation that works, and remember, that Desmume being open-source, there's not much you can do to avoid people abusing WFC (neither you can with a DS + ARDS). The only thing that should really matter, is try to avoid f**** up with the service (sending bad data on a general basis, or whatever), as Nintendo could get pissed about that tongue

Any way, isn't implementing Adhoc version easier? Or is WFC better documented? (I thought that the documentation on the latter was sparse)

Offline

#6 2010-01-19 21:27:32

zeromus
Radical Ninja
Registered: 2009-01-05
Posts: 6,169

Re: The WFC discussion thread

I suspect WFC is easier to test and debug..

Offline

#7 2010-01-20 20:18:30

yonizaf
Member
Registered: 2009-12-22
Posts: 179

Re: The WFC discussion thread

Luigi__ wrote:

The problem may be that SoftAP's current receiver can only read one packet every millisecond. There's high chance that packets are being missed.

I highly doubt that's the problem. IRC is rather relaxed on packet sends, and though it pings you every minute or so, it only disconnects you if no response for over 10 minutes, something like that.

Last edited by yonizaf (2010-01-20 21:20:51)

Offline

#8 2010-04-18 11:12:03

Luigi__
Member
From: Peach__'s castle
Registered: 2009-05-29
Posts: 18
Website

Re: The WFC discussion thread

UPDATE

WFC now works (albeit unstably) since r3533.

From #desmume:
[13:02] <Manivo> Holy crap.
[13:06] <Manivo> So seeing as we're slowly progressing towards flooding big N's servers with pirate connections
[13:08] <Manivo> Here's an idea I had the other day. How about limiting wifi access for savefiles on which cheatcodes have been used?
[13:08] <Luigi__> that may be done
[13:08] <Manivo> Big N's fury might be sooner summoned if they had a flood of cheaters on their servers, rather than a flood of illegitimate players.
[13:08] <Luigi__> http://forums.desmume.org/viewtopic.php?id=2543 <- that has been discussed here
[13:08] <Luigi__> it is already possible to cheat on WFC using an ARDS
[13:09] <Luigi__> the real problem may be LUA
[13:09] <Manivo> I know, the difference however is that on an actual DS one needs to actually buy something, which limits the numbers of people who actually do that.
[13:09] <Luigi__> but seeing as it is enabled by a preproc definition, blocking wifi communications on LUA enabled builds shouldn't be hard
[13:09] <Manivo> Seeing as both desmume and AR codes are free..

What do you think?


Also, MKDS seems to be suffering from a timing problem as the WFC race starts. The bottom screen map becomes unstable and the 3D framerate drops to 25. I thought zeromus, our professional in timing problems, could perhaps look into that...

Last edited by Luigi__ (2010-04-18 13:57:03)


Kuribo64 - If you're wondering where Mario__ is, he's currently saving Peach__ once again.

Offline

#9 2010-04-19 10:48:56

Manivo
Awesome Possum
Registered: 2009-02-15
Posts: 655

Re: The WFC discussion thread

Back to the MAC discussion - AFAIK it has been established that the MAC address is not sent to big N in wifi connections. It isn't sent directly, in any case.
The friend code is hashed from the game ID and the DS's MAC address. The main problem with randomizing your MAC address is not whether it'll work with the WFC or whatever. The problem is the friend codes.

If big N were to tolerate rogue connections to the WFC as long as they didn't ruin legitimate users' experience, I'm assuming it would become pretty agitated at rogue users logging on with a random MAC that just happens to create a friend code for a legitimate user.

Offline

#10 2010-04-19 15:45:52

zeromus
Radical Ninja
Registered: 2009-01-05
Posts: 6,169

Re: The WFC discussion thread

How are the friend codes used? If it is really "hashed" then the size of the result would be somewhat reduced from the input, creating some possibility of collision anyway. This may be acceptable due to how the friend codes are used, or it may not. It would be difficult to exploit in the wild with hardware and a limited ability to set MAC. But a game code + MAC un-collapsed would not create an excessively long friend code.. can you say how long the friend codes are? I'm not sure. Anyway, this would be one example of the types of attacks we'll be facilitating.

Offline

#11 2010-04-22 02:00:15

Pokefan999
Member
Registered: 2009-05-24
Posts: 114

Re: The WFC discussion thread

It seems that user info is not stored on the DS card using emu which causes an update when a different emu session initiate connection to big N for the same game and a new code will be issued (seems to be incremental).  With the flood of emu users trying wifi connection (especially pokemon), the available codes will reach its threshold very soon and big N will be very pissed rather than cheating.

Offline

#12 2010-04-22 03:18:48

zeromus
Radical Ninja
Registered: 2009-01-05
Posts: 6,169

Re: The WFC discussion thread

I've been told that it is based on mac address, but it seems like that is fixed right now, so if new friend codes are being issued, then nintendo must be consuming them internally. We need to get this figured out asap

Offline

#13 2010-04-22 03:29:25

Pokefan999
Member
Registered: 2009-05-24
Posts: 114

Re: The WFC discussion thread

I am sure new codes are issued because I tried several times and each time it will wipe out all my registered friend codes and issued different ones.  I have several of them for the same game.

Offline

#14 2010-04-22 07:00:01

zeromus
Radical Ninja
Registered: 2009-01-05
Posts: 6,169

Re: The WFC discussion thread

New codes arent being issued if it is based on your mac and your mac is random.

Offline

#15 2010-04-22 07:05:41

Pokefan999
Member
Registered: 2009-05-24
Posts: 114

Re: The WFC discussion thread

if codes are issued based on mac alone, then it is not possible to have 2 desmume connecting to big N at the same time from the same pc and cannot trade with my own pokemon games or keep my evolved pokemon from trading.  sigh.

Offline

#16 2010-04-22 07:50:52

zeromus
Radical Ninja
Registered: 2009-01-05
Posts: 6,169

Re: The WFC discussion thread

sure it is. the mac is whatever desmume says it is. so you would just tell desmume instance A that its mac is A and desmume instance B that its mac is B

Offline

#17 2010-04-23 04:45:23

Pokefan999
Member
Registered: 2009-05-24
Posts: 114

Re: The WFC discussion thread

I don't quite understand your response - you mean to say the code is now fixed and will not changed because it is fixed.  I use r3576 and it is still updating my code with new ones.
I managed to enter Wifi Club using SoulSilver and Platinum - enter friend code in each other PAL PAD.
When I start single battle or trade, the other one is seen and can apply but stuck at communicating with the other party until it sort of timed-out.
It would be great if it works.

Offline

#18 2010-04-23 05:21:04

zeromus
Radical Ninja
Registered: 2009-01-05
Posts: 6,169

Re: The WFC discussion thread

did you tell desmume what fixed mac to use? no? then it may be entirely random, for all you know, and the friend codes may be entirely random. or, the friend codes may be entirely random no matter what. we don't know which is the case yet. IF the friend codes are not always random and IF you fixed desmume to a constant mac address THEN your friend code will be stable. I am not saying anything but a bunch of IFs since I have conflicting information and I dont know the answer yet.

Offline

#19 2010-04-23 07:01:48

zeromus
Radical Ninja
Registered: 2009-01-05
Posts: 6,169

Re: The WFC discussion thread

Well it seems that WFC games write to the firmware. I think the WFC initializes some unique ID in the firmware, using random data, and it isn't going to be there in subsequent boots of the emulator. We'd need to save this firmware file back out. Alternatively we could do something hacky, suppose that we understand exactly what must be done--no more and no less--and drop these blocks of data (they are some small dozens of bytes) into the INI file / commandline config. I sort of like that idea better since it doesn't require the firmware.

We could play it a little safer and drop every byte modified into a firmware patch file which would load up after desmume establishes its fake firmware..

An external patch file would be easiest for users to track. it would be called WFC.DAT or something, and perhaps you could specify that instead of the individual bytes in ini/commandline. So, desmume would dump the wfc.dat as soon as it was created, if one wasn't specified already. Then it would be easy to swap them in and out to pretend you're operating several different devices.

Offline

#20 2010-04-23 08:25:23

Pokefan999
Member
Registered: 2009-05-24
Posts: 114

Re: The WFC discussion thread

It seems the MAC is always the same for the same game even when you boot the emu.  The Wi-Fi Connection ID(from last successful connection) is wiped out when you restart emu which forces an update when you try to connect again and a new code issued.

Offline

#21 2010-04-23 16:01:29

zeromus
Radical Ninja
Registered: 2009-01-05
Posts: 6,169

Re: The WFC discussion thread

Yeah the mac is fixed, its the unique ID in the firmware that is random. That unique ID is generated without contacting nintendo, within the first few frames of the game.

Offline

#22 2010-04-23 17:15:56

Manivo
Awesome Possum
Registered: 2009-02-15
Posts: 655

Re: The WFC discussion thread

Something which may be an issue is the way in which a new friend code is given. In the numerous games I tried playing on wifi that require you to receive a new friend code it takes around half a minute for a new friend code to be set. One would think that if the friend code is set locally by the game's unique ID and the firmware's MAC address the process would take no more than a second, however the long process (and the fact that the wifi signal strength indicator appears on the screen) could imply that the friend code is also registered via the WFC server. That in turn could imply that we really are gobbling through available friend codes on big N's server.

If only they'd publicly release the specifications this would be so much easier for all parties involved. Hint hint. I know you're reading this, Satoru Iwata.

Offline

#23 2010-04-23 18:45:57

zeromus
Radical Ninja
Registered: 2009-01-05
Posts: 6,169

Re: The WFC discussion thread

The friend code comes from nintendo. But it is based on this firmware unique ID, not the MAC. We're only gobbling through them because every time the emulator boots a new unique ID gets made and so it looks like a unique DS unit to nintendo.

The patch file i proposed would sort of be like the unique hardware tag for an emulated DS. I suppose it could contain the MAC address also. Anything that would ordinarily go in the firmware, except that we didn't want to require the use of firmware. Basically we would have our own emulated "firmware" and this file are the instructions for how to populate the data in it.

As a downside, this would interfere with our ability to 100% correctly emulate the firmware writing. It would take two code paths.

Offline

#24 2010-04-28 20:54:40

Pokefan999
Member
Registered: 2009-05-24
Posts: 114

Re: The WFC discussion thread

I can start 2 emu using Mortal Kombat and battle each other using WFC but screen display is slow although fps shows 40+ to 60.  It is especially slow during menu selection while it is a bit faster during actual fight.
For Pokemon Wi-Fi, I can contact the other game on the same pc for trade or battle and it will acknowledge contact and then wait for a while before it says the other party fails to respond.  I think it sort of timed-out after waiting for too long but at least I am no longer getting WFC error codes.
Any way to improve the network delay / response ?

Offline

#25 2010-04-28 20:58:30

zeromus
Radical Ninja
Registered: 2009-01-05
Posts: 6,169

Re: The WFC discussion thread

Yes--wait until the code is finished and bug-free and optimized. This isnt a simple feature that is implemented yes/no and the checkbox by [yes] was just filled in. It just barely started working and there is a ways to go still. I dont want to tell you to quit testing things, but don't expect anything to work and dont assume youre doing anything wrong.

Offline

Board footer

Powered by FluxBB