Tim Schuerewegen Interview
DS Update recently caught up with Tim Schuerewegen for an interview as he is a prominant homebrew developer for the DS. Tim has also recently developed a new driver and we decided to ask him what this means for homebrewers everywhere and regular gamers. See the interview below.
DS Update: Now can you tell us exactly what you have been recently working on and what it does?
Tim Schuerewegen: I wrote a Windows 2000/XP driver for the RT2560 chipset and an application that uses this driver to communicate with a DS to perform so-called "wireless multiboot".
DSU: And this driver does what exactly?
TS: This driver allows me to send and receive raw 802.11 frames. I had to write my own driver because of the 802.3 encapsulation layer that is hardcoded in every Windows NDIS driver for 802.11 hardware. On Linux this is not a problem, because there the drivers export 802.11 functionality, not 802.3. So what I did in the last few weeks was writing a Windows driver for my RT2560 based card. This was relatively easy because of the examples in the DDK and the source code from the official RT2560 linux driver.
DSU: And what does your application do?
TS: The wireless multiboot application that uses my driver uploads game code to the slave DS. However, it can not upload homebrew code because of the RSA signature. If the slave DS checks the signature and it does not match, it will hang during the Nintendo logo fadeout. That is why I am restricted to uploading existing multiboot binaries with matching signature such as the ones from Super Mario 64 DS, Zoo Keeper, Yoshi Touch and Go, etc. However, the ARM7 and ARM9 execution addresses that are sent to the slave DS are not checked in any way. This means that I can have the slave DS execute *other*
code than what was uploaded. The only place where such other code can be put is on a GBA cart. A similar method is used by PassMe devices, where the game header is patched in realtime so that it will run code off the GBA cart instead. The RSA signature is 1048-bit, which means that brute-force breaking it is not an option. Even having the code that verifies the signature on the slave DS won't help us create signatures for our homebrew code. However, it might be possible to update the DS firmware with a patched version so that this signature check is removed and homebrew code can actually be uploaded and executed without the need for a GBA cart.
DSU: Now for the everyday DS user, what does your software mean?
TS: If they happen to have a RT2560 based wireless card and a GBA cart, then they can execute homebrew code on their DS without the need for a PassMe. In my opinion a PassMe is better than the wireless multiboot hack in terms of
speed. The actual upload on my PC takes 15 seconds or so, which is way longer than what it takes to run homebrew code with a PassMe.
DSU: Is all this that you are talking about easily accessible to people who know nothing about it to run such homebrews?
TS: You must have some knowledge of Windows 2000/XP in order to replace the official driver with my version. Other than that you simply run my application, accept the download on the DS and wait until it is complete and starts the homebrew code from the GBA cart/slot.
DSU: Now will all this be open to people with other OS than Windows?
TS: No. There already is a much more complete driver for Linux and the actual application that performs the multiboot was written in two days or so. If anyone wants to perform wireless multiboot using other platforms, they should write their own software. It is not that hard given the right skills and a lot of free time.
DSU: I'm on an , but anyways what does this all mean in terms of DS tunneling? I know there are many rumours flying at this time so could we please clear all of them up.
TS: There was a time when I was interested in tunneling. Not so much for the ability to actually play against other people across the globe, but rather for studying the various aspects of the wireless multiboot protocol. Now that I know how to perform wireless multiboot I am no longer interested in DS tunneling. However, people are free to try to write their own tunneling software using my driver. It has a very simple interface. The only problem with tunneling will be the latency. If you do not respond in a timely fashion the slave/master DS will de-authenticate you and the fun is over. If you even get past authentication/association that is. Last time I checked team Nitro was still trying to tunnel the DS, but I doubt that they will
have any success whatsoever.
DSU: I can't say that i disagree with you there, but do you think that the DS will ever be tunneled?
TS: Maybe. If you can find someone that is stupid enough to waste a lot of time. I actually still have my old tunneling test application from some time ago when I was working with the ZyDAS ZD1211 USB stick. It would only take me 30 mins max to update it to use my RT2560 driver and see if it does anything. The lack of interest keeps me from trying that though :)
DSU: Anyways, do you think that this new software will have a great impact on anything in the current gaming community?
TS: No. The wireless multiboot "passme" hack is useless to most people. Only worth using if you are waiting for your PassMe to arrive and want to run some homebrew demos on your DS, like me. If you want to do DS homebrew, buy a PassMe. If you don't want to do DS homebrew, buy nothing. The wireless multiboot method is only useful for people without PassMe that want to run homebrew code on their DS. And in that case, they are better off with a PassMe. So pretty much useless... until the DS firmware is modified. Even then, only useful to homebrew developers, not the gaming community. Two different worlds. They (gaming) are interested in playing and tunneling commercial games. We (homebrew) are interested in running our own code.
DSU: Fair enough.
TS: Oh, and because the wireless method needs to upload game code from a commercial game with matching signature, it is not quite as legal as a PassMe.
DSU: It's only illegal if you get caught.
TS: Nintendo's own fault that I need to upload commercial code, they shouldn't have added the signature. So in this case, they support/encourage the piracy.
DSU: That's an interesting way of looking at it.
TS: There's one other thing that some people in the gaming community are assuming. It is *not* possible to stream commercial games with my software. It might be possible to upload and play a standalone multiboot game if such thing exists. All of the multiboot games I have seen so far require connection with the master DS for loading additional game data. And again, I am not interested in that. I do not care about the gaming community.
DSU: And when do you plan to release this software?
TS: Haven't made any plans for a release. Some people already have my driver/software because they asked nicely :)
DSU: Any thing else you would like to say?
TS: No.
DSU: Thank-you for your time.
Click Here to download Tim's latest software.
DS Update: Now can you tell us exactly what you have been recently working on and what it does?
Tim Schuerewegen: I wrote a Windows 2000/XP driver for the RT2560 chipset and an application that uses this driver to communicate with a DS to perform so-called "wireless multiboot".
DSU: And this driver does what exactly?
TS: This driver allows me to send and receive raw 802.11 frames. I had to write my own driver because of the 802.3 encapsulation layer that is hardcoded in every Windows NDIS driver for 802.11 hardware. On Linux this is not a problem, because there the drivers export 802.11 functionality, not 802.3. So what I did in the last few weeks was writing a Windows driver for my RT2560 based card. This was relatively easy because of the examples in the DDK and the source code from the official RT2560 linux driver.
DSU: And what does your application do?
TS: The wireless multiboot application that uses my driver uploads game code to the slave DS. However, it can not upload homebrew code because of the RSA signature. If the slave DS checks the signature and it does not match, it will hang during the Nintendo logo fadeout. That is why I am restricted to uploading existing multiboot binaries with matching signature such as the ones from Super Mario 64 DS, Zoo Keeper, Yoshi Touch and Go, etc. However, the ARM7 and ARM9 execution addresses that are sent to the slave DS are not checked in any way. This means that I can have the slave DS execute *other*
code than what was uploaded. The only place where such other code can be put is on a GBA cart. A similar method is used by PassMe devices, where the game header is patched in realtime so that it will run code off the GBA cart instead. The RSA signature is 1048-bit, which means that brute-force breaking it is not an option. Even having the code that verifies the signature on the slave DS won't help us create signatures for our homebrew code. However, it might be possible to update the DS firmware with a patched version so that this signature check is removed and homebrew code can actually be uploaded and executed without the need for a GBA cart.
DSU: Now for the everyday DS user, what does your software mean?
TS: If they happen to have a RT2560 based wireless card and a GBA cart, then they can execute homebrew code on their DS without the need for a PassMe. In my opinion a PassMe is better than the wireless multiboot hack in terms of
speed. The actual upload on my PC takes 15 seconds or so, which is way longer than what it takes to run homebrew code with a PassMe.
DSU: Is all this that you are talking about easily accessible to people who know nothing about it to run such homebrews?
TS: You must have some knowledge of Windows 2000/XP in order to replace the official driver with my version. Other than that you simply run my application, accept the download on the DS and wait until it is complete and starts the homebrew code from the GBA cart/slot.
DSU: Now will all this be open to people with other OS than Windows?
TS: No. There already is a much more complete driver for Linux and the actual application that performs the multiboot was written in two days or so. If anyone wants to perform wireless multiboot using other platforms, they should write their own software. It is not that hard given the right skills and a lot of free time.
DSU: I'm on an , but anyways what does this all mean in terms of DS tunneling? I know there are many rumours flying at this time so could we please clear all of them up.
TS: There was a time when I was interested in tunneling. Not so much for the ability to actually play against other people across the globe, but rather for studying the various aspects of the wireless multiboot protocol. Now that I know how to perform wireless multiboot I am no longer interested in DS tunneling. However, people are free to try to write their own tunneling software using my driver. It has a very simple interface. The only problem with tunneling will be the latency. If you do not respond in a timely fashion the slave/master DS will de-authenticate you and the fun is over. If you even get past authentication/association that is. Last time I checked team Nitro was still trying to tunnel the DS, but I doubt that they will
have any success whatsoever.
DSU: I can't say that i disagree with you there, but do you think that the DS will ever be tunneled?
TS: Maybe. If you can find someone that is stupid enough to waste a lot of time. I actually still have my old tunneling test application from some time ago when I was working with the ZyDAS ZD1211 USB stick. It would only take me 30 mins max to update it to use my RT2560 driver and see if it does anything. The lack of interest keeps me from trying that though :)
DSU: Anyways, do you think that this new software will have a great impact on anything in the current gaming community?
TS: No. The wireless multiboot "passme" hack is useless to most people. Only worth using if you are waiting for your PassMe to arrive and want to run some homebrew demos on your DS, like me. If you want to do DS homebrew, buy a PassMe. If you don't want to do DS homebrew, buy nothing. The wireless multiboot method is only useful for people without PassMe that want to run homebrew code on their DS. And in that case, they are better off with a PassMe. So pretty much useless... until the DS firmware is modified. Even then, only useful to homebrew developers, not the gaming community. Two different worlds. They (gaming) are interested in playing and tunneling commercial games. We (homebrew) are interested in running our own code.
DSU: Fair enough.
TS: Oh, and because the wireless method needs to upload game code from a commercial game with matching signature, it is not quite as legal as a PassMe.
DSU: It's only illegal if you get caught.
TS: Nintendo's own fault that I need to upload commercial code, they shouldn't have added the signature. So in this case, they support/encourage the piracy.
DSU: That's an interesting way of looking at it.
TS: There's one other thing that some people in the gaming community are assuming. It is *not* possible to stream commercial games with my software. It might be possible to upload and play a standalone multiboot game if such thing exists. All of the multiboot games I have seen so far require connection with the master DS for loading additional game data. And again, I am not interested in that. I do not care about the gaming community.
DSU: And when do you plan to release this software?
TS: Haven't made any plans for a release. Some people already have my driver/software because they asked nicely :)
DSU: Any thing else you would like to say?
TS: No.
DSU: Thank-you for your time.
Click Here to download Tim's latest software.
1 Comments:
Interesting.
Tell him to get polarium, thats got a completely standalone game-share download.
Also, legal or not, I would have thought Nintendo would like game-demo downloads. (and when your limited to ram, its not going to be anything more then a demo).
Im also interested why so dissmissive about tunnelingly..lag is an issue i can understand...but not wanting to at least test it in principle is odd.
Especialy with a few people saying "its impossible" (which normaly is incentive enough for the really smart people to prove them wrong)
Post a Comment
<< Home