gbadev.org forum archive

This may just be a small step to getting the wireless cracked, but someone on the Warp Pipe forums (http://forums.warppipe.com/viewtopic.php?t=12945) has picked up the DS with Network Stumbler:

[Images not permitted - Click here to view it]

The MAC address shown at the top is that of the DS, as is shown by this manufacturer id lookup:

http://standards.ieee.org/cgi-bin/ouisearch?0009bf

Quote:

00-09-BF (hex) Nintendo Co.,Ltd.
0009BF (base 16) Nintendo Co.,Ltd.
11-1 HOKOTATE-CHO
KAMITOBA, MINAMI-KU
KYOTO 601-8501
JAPAN

The guy picked up that MAC address while playing around with PictoChat. Notice that the speed is 2Mbps, obviously 802.11b.

Since it's using WiFi, I guess it can be tunneled. What about Super Mario 64 DS?
_________________
Little kids and Playstation 2's don't mix. :(

The problem is the multi-boot wireless protocaul is different. That's just the 802.11 portion of the DSes wireless capabilities.

So, how long until we have a TCP/IP stack running on this WiFi adapter?
(And a BSD-like API.)

BSD-like APIs are inefficient.
I prefer no-copy APIs for embedded systems.

So, where do we go dumpster-diving to find come DS docs?

How you been ampz?

I've been waiting for the Motorola Zigbee chips, to build an
802.15.4 interface for the SP...

Not any more! All I need now is the API.

cesium

Can some try this out: http://forums.warppipe.com/viewtopic.php?t=12954&start=15

It's the paragraph with specific instructions in it.
_________________
Little kids and Playstation 2's don't mix. :(

I've been asking myself how I could help contribute to the DS, WiFi dev effort.

Should I just sit on my arse and read gbadev every hour until
someone else "learns" the WiFi programming methods...

How would this 802.11 packet dump help us?

Sure, I'd learn new stuff, but ultimately if we just want to move data packets in and out of the WiFi port do we need to sniff at this level?

Does knowledge at the physical later of the ISO stack really help us
learn about the application layer API?

Should I just shut up and have fun over the long weekend setting this up?

cesium

MAC addresses are characteristic of 802.11b Ethernet, which is layer 2 of the Nintendo DS wireless comms protocol stack. Even without access to OSI layers 3 on up, I'm guessing that a bridge that works at layer 2 could still tunnel traffic.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

I grabbed a couple of DSes on the way home from work.

Maybe it's the low batteries from their "fresh out the box" state,
but the range of Picochat sucks! It doesn't work 20 feet!

Maybe it's my wireless video distribution system interfering...
Or the heavy traffic on my 802.11b net interfering...
Or my 802.11b camera interfering...

Hmmm, I'll have to lug em around after charging.
See if it improves when I get out the house.

Regardless, when we have the DS by the horns, it's gonna be
a fun ride! This unit gets major points for style.

cesium

this is neat. i just downloaded the app, and turned on the two DS's, and BAM! they where just... there...
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

Darkain wrote:

this is neat. i just downloaded the app, and turned on the two DS's, and BAM! they where just... there...

You sure they weren't just connecting directly?

Abscissa wrote:

You sure they weren't just connecting directly?

"they", as in the DS to the laptop, or the DS to the DS.... because either way, the laptop is intercepting the MAC packets.
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

So, what are you waiting for?? dump some packets for us!
Perferably packets with known contents, like pictochat text communication.

ampz wrote:

So, what are you waiting for?? dump some packets for us!
Perferably packets with known contents, like pictochat text communication.

heh, i'm working on it. the DS pumps out 500+ packets a second while idling in pictochat... this is a real pain to sort out. im trying to get a way to seperate messages that are "hey, im a host, look at me, and here are the addys of the other units" from "oh hey, im a picture, look at me!" :)

plus with it being 3am in the morning, my brain isnt being 100% functional, and im trying to get some other software downloaded to help this process out. i'll prob just have to sleep on it... heh (gotta keep ya all waiting. ;)
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

Cool!
I didn't try the suggested program because my WiFi card doesn't have the proper chipset they mention. Do you know of another capture program I could try?

cesium

http://www.livejournal.com/community/nintendo_ds/48965.html

i just posted my findings from this morning there. quite interesting, and raw binary data for those that are interested! :D
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

This is really great news! (The fact that pictochat data is sent as uncompressed, unencrypted 4bit per pixel bitmaps)
Should be fairly straightforward to write a pictochat client for PC.
This PC client could then easily be extended to a pictochat<->IRC gateway.
Imagine the possibilities, chatting in #dsdev or #gbadev wireless on a DS :-)

And this can be done NOW, no need to wait for DS flash cards.

You could even write a simple game that uses pictochat as input and output, but in reality runs on the PC.
Not very useful, but it would kind-of be the first homebrewed DS game :)

the thing is for an IRC or other relay for pictochat, is that its RAW BITMAPS... NOT text... meaning, you would need OCR to translate the information being sent across.
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

Darkain wrote:

the thing is for an IRC or other relay for pictochat, is that its RAW BITMAPS... NOT text... meaning, you would need OCR to translate the information being sent across.

Nah, OCR is only required for scanned text where the text is not perfect.
Pictochat text is entered on a virtual keyboard, right? So pictochat text will be perfect.

It is very easy to recognize perfect letters with a known font. You just look at a bunch of "key pixels". A certain combination of thoose pixels will only happen for a specific letter, so you just create a reverse-lookup table where you can get the ascii code given a specific combination of key pixels.
Or, you can make a copy of the entire pictochat font, and compare the text to each of the letters in the pictochat font. Only one letter in the font will match perfectly.
The second option is not as efficient as the first, but perhaps it is a little easier to understand and implement. (no need to find a set of key pixels)

there is also the thing of drawing on the screen tho.

but ya, a font matching would work best, key pixels wouldnt work too well. remember, there are 7 unique font sets in pictochat. (upper, lower, accented, hiragana, katakana, characters, and symbols), and the fact you could draw. key pixels would have a large chance of failure because of that.

but first, before we even get into that, its a matter of finding the byte order of the data. gotta convert 11 sets of 128 bytes into a visual bitmap pattern.
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

Well, I've taken a little look at the packets and so far have managed to gather this somewhat useless data :).

// Packet desc:
// First 4 bytes - Header ID?
// Next 2 - Unit ID?
// Next 4: total number of bytes sent in this message?
// 160 bytes, payload
// next 2, sequence number

Now, given 160 bytes x 11 data packets, that gives us 1,760 bytes, or 3,520 pixels. Going off a screen capture from pictochat the closest approximation to that I can find is 220x16 pixels per line. However, it does not appear to be stored in linear fashion (horizontal or vertical). Decoding vertically does give better results than horizontally though. Anyhow, I'll keep working on it unless someone beats me to the punch :).

actually, about an hour or two ago, i managed to decode it. there is only 128 bytes of data per packet. it is sent in 8x8 blocks, exactly the same fashon used in GBA VRAM for tiles.

tile 0
bytes 0-3 are row 0 pixels 0-7
bytes 4-7 are row 1 pixels 0-7
bytes 8-11 are row 2 pixels 0-7
bytes 12-15 are row 2 pixels 0-7
bytes 16-19 are row 2 pixels 0-7
bytes 20-13 are row 2 pixels 0-7
bytes 24-17 are row 2 pixels 0-7
bytes 28-31 are row 2 pixels 0-7

and then it moves to tile 1 row 0 and repeates
bytes 32-35 are row 0 pixels 0-7
...
and so on from there.

there is some problems ive ran across working on the second row of tiles tho, so there may be a little buffer range somewhere that i might be missing later on. i'll continue to work on it.
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

Heh, I just got to that point, however my results are pretty screwed up. Also, the size is off somewhat, so I don't think it can be 8x8 tiles (or my 220x16 theory is wrong as 220 % 8 != 0). Something is a bit fubared. I'm sure it'll work itself out in a bit though :).

That's what my hello decode looks like right now:
http://members.fortunecity.com/infinityhq/dsdev/dsdev.html

gladius wrote:

Heh, I just got to that point, however my results are pretty screwed up. Also, the size is off somewhat, so I don't think it can be 8x8 tiles (or my 220x16 theory is wrong as 220 % 8 != 0). Something is a bit fubared. I'm sure it'll work itself out in a bit though :).

That's what my hello decode looks like right now:
http://members.fortunecity.com/infinityhq/dsdev/dsdev.html

remember, the binary information i posted was just for the first row of text, as pictochat truncates its... and the first row is shorter then the rest, and the data being sent does adhear correctly to the smaller bitmap area size.

so, if you take away the amount of space that the name area takes up... how many pixels is left over? possibly aprox 176? 176/8=22. 22=11*2. (number of packets * 2), and then there is 2 tile rows per line... and a total of 4 blocks per packet... getting all this? each packet holds 4 block * 11 packets = 44 blocks. /2 cause there are 2 rows, and its 22.

so, out of 11 data packets, the first 5.5 is the first row of tiles, and the second 5.5 is the second row of tiles.

i think my prob w/ rendering the second row of tiles is that i was trying to align it to either the 5th or 6th packet, when in fact, it is half way inbetween.
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

Ah, I didn't realize it was for the shortened first line. That explains quite a bit. However, there is still 3,520 pixels being sent across the wire (well, across the air here ;). If we assume that the line is 176 pixels long, there will be 22 * 8 * 8 pixels per line = 1,408 * 2 = 2,816 pixels. So there are a bunch of extras floating around somewhere. Maybe control information, or palette stuff?

Would it possible to capture some drawings on the second (full width) line so we could get a better idea of horizontal size?

Just noticed, my first scanline is messed up on hello and full. Does this happen with yours as well? Or just a stupid bug on my part.

gladius wrote:

Just noticed, my first scanline is messed up on hello and full. Does this happen with yours as well? Or just a stupid bug on my part.

2 things: 1, look at the "full" binary file... each packet has only 128bits of picture data in them. therefor the calculation is 100% right on. there is some extra room in the headers that is just 0's

2) yus, im having the scan line issue as well, and im still not even sure how to re-create the second row of tiles... maybe my math is off in my app, i dunno... it just isnt working for me like i had hoped it would.
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

128 bits? I'm not sure how you are getting that figure. That extra room is sometimes 1's as well. For example, in packet 4 of full, there are the full 160 0x11's. A question though, how full was full? You mentioned there were a few pixels missing on the bottom, but there are quite a few 0x00's floating around in there. I'm not really any further on the bottom half either, trying to figure out just what is happening on the top scanline.

gladius wrote:

128 bits? I'm not sure how you are getting that figure. That extra room is sometimes 1's as well. For example, in packet 4 of full, there are the full 160 0x11's. A question though, how full was full? You mentioned there were a few pixels missing on the bottom, but there are quite a few 0x00's floating around in there. I'm not really any further on the bottom half either, trying to figure out just what is happening on the top scanline.

everything but the button 1-3 scan lines was completely full.

hmm, looking at full again, packet 4... correct... it *does* appear to be 160 bytes per packet.

and the thing is w/ adding a second line, is that its going to be hard to tell where the first line ends, and the second one begins, because all the the data is just thrown together in a long string.. maybe a bit later tonight, i'll try to capture some more stuff.
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

Hm.. Might have figured out the first scanline problem. It seems as though they use a 4x8 tile to start off the scanline. That fixes the problem with the first scanline, but the top half and bottom half are still wildly different.

This also causes further problems elsewhere, so I'm still unsure. My current full, line and hello are posted on my site.

[Edit: Ok. Now I'm pretty sure this is not the case, as full starts off with an 8x8 block with all the right hand pixels set to 1 in the first 8x8 block]

gladius wrote:

Hm.. Might have figured out the first scanline problem. It seems as though they use a 4x8 tile to start off the scanline. That fixes the problem with the first scanline, but the top half and bottom half are still wildly different.

This also causes further problems elsewhere, so I'm still unsure. My current full, line and hello are posted on my site.

[Edit: Ok. Now I'm pretty sure this is not the case, as full starts off with an 8x8 block with all the right hand pixels set to 1 in the first 8x8 block]

well, i switched over to 160 bytes of data and 10 bytes of header instead of 128 bytes of data and 42 bytes of data... and without fixing the first scanline issue, this is what i got (i truncated the extra stuff to the right that is just all 0's):

Code:

00000000000000000000100010100010100100100010000
00000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000
00000000000010000000000010010000000000000000000
00000000000010000000000010010000000000000000000
00000000000010000000000010010000000000000000000
00000000000011110001110010010001110000000000000
00000000000000000000000000000000000000000000000
00000000000010001011111010010010001000000000000
00000000000010001010000010010010001000000000000
00000000000010001010000010010010001000000000000
00000000000010001001111001001001110000000000000
00000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000

_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

ok, so... there are 5 tiles per packet. the last 4 and 3/5ths packets are for the bottom row. the top row starts at the begining of packet 3. there appears to be a buffer of 7 pixels on the left set of tiles. 7*16=122 unused pixels. not sure about right or bottom yet.

i'm gonna look into why "full" had more buffer before the first pixel then the others.... possibly an error on my part when snooping? i dunno..
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

Nice work guys. So basically even the text you type into pictochat is transferred as part of the bitmap? This seems to make sense since after you've sent even just one line of text and then "download" it back to re-edit it, the editor won't let you modify the text proper. All text you type in just overlays on top of the grabbed image. This is too bad as the idea for hooking into IRC won't work. Looks like it would still be trivial to set up a client listening on the PC side though to display and send bitmaps back to a DS.

darkain great stuff!
I'm looking at both your hello and full binaries. A few questions...

According to what you've said, your "full" picture that you logged basically had almost all lines filled except the last? Here is how I've interpreted it:

Just like you said, the first two mac bursts are pretty much blank, then about 15% into the third burst appears to start the bitmap data. For the next 4.5 chunks it appears to be basically filled in. Then I see almost two bursts of blank data, and then more fill continues.

So I guess my question is this: when you sent that data, did you send two seperate messages or just one?

flip_fl0p wrote:

So I guess my question is this: when you sent that data, did you send two seperate messages or just one?

are what two seperate messages? the "hello" "full" and "line" where all sent at seperate times.
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

I know, but did you send the full twice. Only asking because the data seems to have a hole of zeros right in the middle

flip_fl0p wrote:

I know, but did you send the full twice. Only asking because the data seems to have a hole of zeros right in the middle

no, that is a buffer range im guessing..

any time you send a message on a single line, it is a total of 13 packets always. but, 13 packets holds more information than what can be displayed. my estimate right now is that there are 7 pixels of buffer on the left margin, not sure about right and botttom margins. there doesnt appear to be any margin on the top.
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

When the DS wireless is figured out, will I need a wireless NIC to do online gaming with games made for P2P gaming only? And I'll assume the answer is "No", but in your opinions was it pointless for me to invest in a wireless router just for my DS? By that I guess what I'm asking is if the DS will use a wireless router in the future for online games.

mymateo wrote:

When the DS wireless is figured out, will I need a wireless NIC to do online gaming with games made for P2P gaming only? And I'll assume the answer is "No", but in your opinions was it pointless for me to invest in a wireless router just for my DS? By that I guess what I'm asking is if the DS will use a wireless router in the future for online games.

the DS using a wireless router is game specific... it is up to the developers... pictochat is about the only 802.11 thing we have to work off of right now, and it registers its own access point, and wont connect to anything other then its own custom AP. from what i can tell, mario and metroid both use the proprietary protocol of the DS for wireless communication, so we cant even see that with the laptop setups we are running off of (unless someone else has managed to figure it out in the past 24 hours w/0 telling me of such)
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

Just curious Darkain,

I'm guessing you sent these in the following order, correct if wrong:

Full, hello, line

flip_fl0p wrote:

Just curious Darkain,

I'm guessing you sent these in the following order, correct if wrong:

Full, hello, line

i cant recall... i got maybe 4 hours sleep last night, and that was either the last thing i did before i went to sleep, or the first thing i did when i woke up... i dont even think they came from the same game session.

oh, and on another note: it looks like tile row 1 has 32 tiles, and tile row 2 has 28 tiles. (wich explains the un-evenness)
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

right on, I'm sure you noticed that the first byte of the headers appear to increment by one bit per burst. I was taking a dive off the deep end by guessing the order in which you sent these because the counter information was as follows:

full's first packet header's counter started at 11h
hello's first packet header's counter started at 1Fh
line's first packet header's counter started at EDh

of course, the counter could possibly only be one byte in length, and reset itself after FFh. There fore it would make total sense if you actually sent line first.

Again, I don't have 2 DS's, just one and no logging software. I'm using your binaries, but they are definetly good logs. I commend you!

flip_fl0p wrote:

Again, I don't have 2 DS's, just one and no logging software. I'm using your binaries, but they are definetly good logs. I commend you!

:) thanx!

i'm working on more right now... a larger text test, and then im gonna delve into multiple text lines.

it takes me about 5-10 min to dump a line, cause i gotta copy-paste the data from one appliation to another to save the binaries, or else we get the additional headers that specific application provides, wich just gets in the way. the "This is a larget test" should be ready in about 5 min
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

http://ds.darkain.com/x.bin
http://ds.darkain.com/test.bin

"X" is a series of X's in a row, and test is the message "This is a larger test" with some symbols and scribbles after it.
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

good work going on there on figuring out the data formats.

we still need to figure out the pictochat communication protocol before we can actually create a software that can communicate with the pictochat application in the DS.

but anyways, a little progress is still prgress keep it up! :)

Thanks,

So what values are you using for the bitmap matrix?

How many bytes across until it wraps?

flip_fl0p wrote:

Thanks,

So what values are you using for the bitmap matrix?

How many bytes across until it wraps?

its a tile map, not a bitmap... as so it seems.

tiles are 4 bytes by 8 bytes. 2 pixels per byte. 5 tiles per packet. 32 tiles on the first row, 28 tile on the second row.
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

Ok ty for clearing that up. I am seeing results now. Good GOD is it painful to cut and paste all this hehe.

nite man :) ZZZzzz

What I don't understand is why they used nibbles (4-bits) to transfer data when it's a monochrome image. They could have quite easily been 8-pixels to a byte. There is no colour right?

Krakken wrote:

What I don't understand is why they used nibbles (4-bits) to transfer data when it's a monochrome image. They could have quite easily been 8-pixels to a byte. There is no colour right?

hence why i mentioned the GBA style tilemap above. why bother converting a format, when the format is already native to your system? :)

it looks like it just uses the GBA's 16-bolour tile mode.
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

Darkain wrote:

Krakken wrote:

What I don't understand is why they used nibbles (4-bits) to transfer data when it's a monochrome image. They could have quite easily been 8-pixels to a byte. There is no colour right?

hence why i mentioned the GBA style tilemap above. why bother converting a format, when the format is already native to your system? :)

it looks like it just uses the GBA's 16-bolour tile mode.

It just seems like it would be worth it. It would make transfers almost 4x faster.

Krakken wrote:

It just seems like it would be worth it. It would make transfers almost 4x faster.

with the current menthod, its aprox 3kb of information for 1 line... and at most 13kb for an entire screen.... and its transfering on a 2mbps network... so, about 100,000 bits out of 2,000,000 every second. that only limits you to streaming a 20fps movie like that. ;) i dont think chatting is that much of a problem.

also remember the overhead... there is a decent amount of overhead, so reducing the binary data is only marginally improving the over-all amount of data required to be send.

but then, you increase the encoding and decoding speeds by making the data compressed to its smallest form, and also prevent any sort of fordward compat w/ a possible *Pictochat COLOUR* ( unless they made that send out bolth a B/W and colour image, wich would then make it "slower" ;) )
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

Haha, I just thought if we figure out this protocol, we may be able to hack PictoChat to display 16-colour images! That is assuming that there is a default palette loaded into the system. If not the it would be marginly more difficult but still possible.

yeah, that depends on figuring out the pictochat communication protocol first.

Only after that we can experiment with sending different data bits and see what comes out in the pictochat window.

Krakken wrote:

It just seems like it would be worth it. It would make transfers almost 4x faster.

Eh, transfer speed doesn't seem that important to me, there's not much data getting sent and the network is ~11Mpbs (assuming it follows the 802.11b standard). Might be some lag at extreme ranges, though.
_________________
Rav (Win/Mac/Linux games for free)

i believe the DS is 1-2 Mbps.
Nice find. Can't wait to get my laptop back to start trying out some stuff.
_________________
~RiZeUp

RiZeUp wrote:

i believe the DS is 1-2 Mbps.
Nice find. Can't wait to get my laptop back to start trying out some stuff.

Hm, I'm pretty sure the standard is 11Mbps. Nintendo probably doesn't use the 802.11 standard for ad-hoc mode to save on batteries.
_________________
Rav (Win/Mac/Linux games for free)

Okay here is what I was able to decipher from the hello file. I implemented 4x8 byte tile structure. Still looks like I'm getting a little descrepency, well a lot. Also, the first 4 bytes of each tile might not actually be used as "tile-data" per say. There seems to be patterning on the top row of each tile. So is it possible for each tile to roll it's own ID tag or header?

Code:

0000000000000000000001000101000101100001 <-- header or boolean of some sort????
0000000000000000000000000000000000000000
0000000000000000000000000000000000000000
0000000000000000000000000000000000000000
0000000000000100000000000110000000000000
0000000000000100000000000110000000000000
0000000000000100000000000110000000000000
0000000000001111001011000110001011000000
0000000000000000000000000000000000000000 <-- Another header, or dead string conincidently 8 bytes later!
0000000000000000011111010110000100010000
0000000001000000010100000110000100010000
0000000001000000010100000110000100010000
0000000001000000011011011000011011000000
0000000001000000000000000000000000000000
0000000000000000000000000000000000000000
0000000000000000000000000000000000000000

ravuya wrote:

RiZeUp wrote:

i believe the DS is 1-2 Mbps.
Nice find. Can't wait to get my laptop back to start trying out some stuff.

Hm, I'm pretty sure the standard is 11Mbps. Nintendo probably doesn't use the 802.11 standard for ad-hoc mode to save on batteries.

The 802.11b standard allows for 1Mbps/2Mbps/5.5Mbps/11Mbps speeds. It is standard 802.11b, just slow standard 802.11b.

Also, Mario 64 DS appears to send out 802.11 beacon frames on channel 6 while waiting for a multiplayer game to start. I don't have another DS to see if there's any traffic while actually playing, but could this mean Mario 64 is using 802.11b somewhere? Or has someone with 2 DS noticed this already and not found any 802.11 traffic while the multiplayer game is in progress?

Okay, back into the fray :). What image width are you using to get the hello decoded like that Darkain?

I'm still way off on alignment with an image size of 216x16.

gladius wrote:

Okay, back into the fray :). What image width are you using to get the hello decoded like that Darkain?

I'm still way off on alignment with an image size of 216x16.

the two rows arent event. row 1 = 32 tiles, row 2 = 28 tiles

32*8=256 (row 1)
28*8=224 (row 2)
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

flip_fl0p wrote:

Okay here is what I was able to decipher from the hello file. I implemented 4x8 byte tile structure. Still looks like I'm getting a little descrepency, well a lot. Also, the first 4 bytes of each tile might not actually be used as "tile-data" per say. There seems to be patterning on the top row of each tile. So is it possible for each tile to roll it's own ID tag or header?

Code:

0000000000000000000001000101000101100001 <-- header or boolean of some sort????
0000000000000000000000000000000000000000
0000000000000000000000000000000000000000
0000000000000000000000000000000000000000
0000000000000100000000000110000000000000
0000000000000100000000000110000000000000
0000000000000100000000000110000000000000
0000000000001111001011000110001011000000
0000000000000000000000000000000000000000 <-- Another header, or dead string conincidently 8 bytes later!
0000000000000000011111010110000100010000
0000000001000000010100000110000100010000
0000000001000000010100000110000100010000
0000000001000000011011011000011011000000
0000000001000000000000000000000000000000
0000000000000000000000000000000000000000
0000000000000000000000000000000000000000

no, that first row inst a header... move that row down by 8 and left by 8, and it matches into the whole perfectly
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

Darkain wrote:

gladius wrote:

Okay, back into the fray :). What image width are you using to get the hello decoded like that Darkain?

I'm still way off on alignment with an image size of 216x16.

the two rows arent event. row 1 = 32 tiles, row 2 = 28 tiles

32*8=256 (row 1)
28*8=224 (row 2)

Stupid question, but perhaps perhipherally related to this: Does the DS use square, or rectangular pixels? I've only ever seen a few computers that use rectangular pixels.
_________________
Rav (Win/Mac/Linux games for free)

Nice! Finally fixed the first line bug. It appears there is a 4 byte header in the data stream itself. Once I skip past that all the images decode perfectly! Still wondering why there are 256 pixels of information for the first row... Perhaps those are actually tiled onto the second row if used? As the width can't be much more than 220.

[Edit: Images are up at http://members.fortunecity.com/infinityhq/dsdev/dsdev.html]

Last edited by gladius on Fri Nov 26, 2004 9:21 pm; edited 1 time in total

ravuya wrote:

Does the DS use square, or rectangular pixels? I've only ever seen a few computers that use rectangular pixels.

From what I've played of Metroid Prime Hunters First Hunt in Wal-Mart, the Nintendo DS uses the same square pixel aspect ratio as the Game Boy, Game Boy Pocket, Game Boy Color, Game Boy Advance, and Game Boy Advance SP. The NES, Super NES, and Super Game Boy use rectangular pixels sized 40:33 (not 40:30 as PocketNES assumes), and the Sega Genesis and Apple II use rectangular pixels sized 10:11.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

gladius wrote:

Nice! Finally fixed the first line bug. It appears there is a 4 byte header in the data stream itself. Once I skip past that all the images decode perfectly! Still wondering why there are 256 pixels of information for the first row... Perhaps those are actually tiled onto the second row if used? As the width can't be much more than 220.

[Edit: Images are up at http://members.fortunecity.com/infinityhq/dsdev/dsdev.html]

sweet! all 5 look perfect!

on mine, i just kept in that extra header, and just moved the extra row of bytes down... i guess either way can work.

i think the next step is to get ahold of the source code of one of those sniffers, and do all of this in real-time.
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

First of all, Darkain and gladius, great work!

Darkain, what hardware and software did you use to capture the pictochat conversation?
_________________
Joat
http://www.bottledlight.com

Joat wrote:

First of all, Darkain and gladius, great work!

Darkain, what hardware and software did you use to capture the pictochat conversation?

laptop w/ realtek 802.11b wireless PCMCIA card and AiroPeek.
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

Is there a destination MAC adress in the packets?

ampz wrote:

Is there a destination MAC adress in the packets?

the information that ive ripped so far was just the "DATA" section of the MAC packets... the MAC header itself contains source/dest type information, but i didnt include that in the initial binary rips that i made, so this way people wouldnt get all confused trying to figure out the MAC headers.
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

I was just woundering if the destination MAC is broadcast address or not.
It should be a broadcast address...

A broadcast adress should make it a little easier to write a program that reads them... (no need to set the network driver to promiscious mode)

ampz wrote:

I was just woundering if the destination MAC is broadcast address or not.
It should be a broadcast address...

A broadcast adress should make it a little easier to write a program that reads them... (no need to set the network driver to promiscious mode)

i'll go and dump the MAC headers later...
a) i only have access to 1 DS at the moment (i usually only get the second at night time while family is asleep)
b) i got homework i gotta catch up on. ;)
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

This probably has nothing to do with what you guys
are doing but today i was meddeling around with pictochat
and bam somthing joined the room then left in like 1 sec
then my ds frozee up and my wifi network in my house went down
just thought that was weird.

penndragon wrote:

This probably has nothing to do with what you guys
are doing but today i was meddeling around with pictochat
and bam somthing joined the room then left in like 1 sec
then my ds frozee up and my wifi network in my house went down
just thought that was weird.

Yeah, there have been some people complaining that the DS takes out their wireless for some reason. What kind of router are you using? I'll bet that it's a D-Link.
_________________
Rav (Win/Mac/Linux games for free)

Exactly its a D-LINk 802.11g
but what im saying is the router was
connected with it for a few secs.
on another note why are we trying to
get pictochat online why not just come
up with some app that send a signal to
the ds throug the ds download play that
way we could come up with our own
chat prog

Because even if we do figure out how to send things to it, we then still need to figure out how to build the packages.

The first step to knowing how to send packages to the DS.. is to know how to send anything. And that's where the Pictochat dissection is coming in handy right now. We can get a big ol' codebase built up and work from there on more complicated projects. You have to walk before you can run.

By the way, D-Link makes crap that pretty much only plays nice with Windows-based computers. I've never seen their routers work 100% with anything else, even established standards like DHCP.
_________________
Rav (Win/Mac/Linux games for free)

I set my LinkSys router to a MAC address simular to my DS and it freaked out when I went to picto chat. Had to reset the router and change the mac address back.
_________________
DigiPen Graduate

DrEggman wrote:

I set my LinkSys router to a MAC address simular to my DS and it freaked out when I went to picto chat. Had to reset the router and change the mac address back.

So the deal with the routers probably is, the DS thinks it's another DS, starts spamming it with "HI! I'M A DS! WHAT'S YOUR NAME?" packets and the router gets confused, starts screaming inside, and locks up without a fight. Wonder if there will be firmware patches.
_________________
Rav (Win/Mac/Linux games for free)

penndragon wrote:

why not just come
up with some app that send a signal to
the ds throug the ds download play that
way we could come up with our own
chat prog

because the DS uses 2 protocols, not 1... and one of those two, we cannot access... and that one that we cannot access is the one that the multiboot download uses... if it DID use the 802.11 for multi-boot download, that would be my top priority, so that way we could all start on our 3rd party projects.
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

Darkain, did you check this out?

http://www.dual-scene.com/modules.php?op=modload&name=News&file=article&sid=7&mode=thread&order=0&thold=0

If the NiFi Standard was so different, then why can we see the DS in picto and mario 64? Also if the DS isnt detectable in multi boot mode, what are the chances that its simply listening and not broadcasting?
_________________
DigiPen Graduate

DrEggman wrote:

Darkain, did you check this out?

http://www.dual-scene.com/modules.php?op=modload&name=News&file=article&sid=7&mode=thread&order=0&thold=0

If the NiFi Standard was so different, then why can we see the DS in picto and mario 64? Also if the DS isnt detectable in multi boot mode, what are the chances that its simply listening and not broadcasting?

This is similar to what I was saying earlier, the DS may be effectively in promiscuous mode in multi boot mode, and it's simply waiting for a beacon to start talking with another DS. I'm going to try capturing some Mario 64 beacon frames and retransmitting them while the DS is in multi boot mode to see if it responds.

chizu wrote:

DrEggman wrote:

Darkain, did you check this out?

http://www.dual-scene.com/modules.php?op=modload&name=News&file=article&sid=7&mode=thread&order=0&thold=0

If the NiFi Standard was so different, then why can we see the DS in picto and mario 64? Also if the DS isnt detectable in multi boot mode, what are the chances that its simply listening and not broadcasting?

This is similar to what I was saying earlier, the DS may be effectively in promiscuous mode in multi boot mode, and it's simply waiting for a beacon to start talking with another DS. I'm going to try capturing some Mario 64 beacon frames and retransmitting them while the DS is in multi boot mode to see if it responds.

the thing is tho, i have 2 DSs, and i did a multiboot game, and got a total of 0 packets out of it... i'll try it agian tho w/ some other settings... i think i was only listening on channel 1 at the time.
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

Darkain wrote:

chizu wrote:

DrEggman wrote:

Darkain, did you check this out?

http://www.dual-scene.com/modules.php?op=modload&name=News&file=article&sid=7&mode=thread&order=0&thold=0

If the NiFi Standard was so different, then why can we see the DS in picto and mario 64? Also if the DS isnt detectable in multi boot mode, what are the chances that its simply listening and not broadcasting?

This is similar to what I was saying earlier, the DS may be effectively in promiscuous mode in multi boot mode, and it's simply waiting for a beacon to start talking with another DS. I'm going to try capturing some Mario 64 beacon frames and retransmitting them while the DS is in multi boot mode to see if it responds.

the thing is tho, i have 2 DSs, and i did a multiboot game, and got a total of 0 packets out of it... i'll try it agian tho w/ some other settings... i think i was only listening on channel 1 at the time.

Hmm, I hope you just missed it on other channels. Mario has always been on channel 6 for me, and just hosting a game outputs about 40 packets a minute sniffing with AirSnort. They all appear to be standard 802.11b access point beacon frames though, no data, but I'm thinking this is simply because I haven't been able to try it with another DS in range.

Just tried sniffing Metroid Hunters: First Hunt, it outputs 3000 packets a minute while waiting for people to join a game. I'm going to look into their contents, but that's a ton of stuff to look through. This is really making me think NiFi as it's been dubbed isn't anything more than 802.11b without the IP layer.

EDIT: http://www.spicious.com/downloads/metroid.pcap is a pcap format dump of what metroid put out in 10 seconds, ethereal or any libpcap compatible application to see it.

Last edited by chizu on Sat Nov 27, 2004 6:39 am; edited 2 times in total

chizu wrote:

Just tried sniffing Metroid Hunters: First Hunt, it outputs 3000 packets a minute while waiting for people to join a game. I'm going to look into their contents, but that's a ton of stuff to look through. This is really making me think NiFi as it's been dubbed isn't anything more than 802.11b without the IP layer.

Cool. If you guys can log more the binary packet data, that would be great. I don't have a WiFi router myself, so I can't analyze log the myself. I'm thinking of getting a WiFi router for just this reason now, though. :-P

chizu wrote:

Just tried sniffing Metroid Hunters: First Hunt, it outputs 3000 packets a minute while waiting for people to join a game. I'm going to look into their contents, but that's a ton of stuff to look through. This is really making me think NiFi as it's been dubbed isn't anything more than 802.11b without the IP layer.

i just got about 13,000 packets that where sent from one DS to another in a mario multi-boot wireless down.... those run on channel 13 (out of normal spec for the US, i think)

i'm gonna start at the source, by just getting the data that shows up on the DS that says "hey, there is a game here" cause it contains game name and that lil pic, and thatll be the first thing for downloading home-brew demos.
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

allenu wrote:

Cool. If you guys can log more the binary packet data, that would be great. I don't have a WiFi router myself, so I can't analyze log the myself. I'm thinking of getting a WiFi router for just this reason now, though. :-P

routers wont work
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

Darkain wrote:

allenu wrote:

Cool. If you guys can log more the binary packet data, that would be great. I don't have a WiFi router myself, so I can't analyze log the myself. I'm thinking of getting a WiFi router for just this reason now, though. :-P

routers wont work

Really? I thought like, a wired router with a wireless access point would work perfectly.

I was planning on buying this just for my DS -_-

Darkain wrote:

chizu wrote:

Just tried sniffing Metroid Hunters: First Hunt, it outputs 3000 packets a minute while waiting for people to join a game. I'm going to look into their contents, but that's a ton of stuff to look through. This is really making me think NiFi as it's been dubbed isn't anything more than 802.11b without the IP layer.

i just got about 13,000 packets that where sent from one DS to another in a mario multi-boot wireless down.... those run on channel 13 (out of normal spec for the US, i think)

i'm gonna start at the source, by just getting the data that shows up on the DS that says "hey, there is a game here" cause it contains game name and that lil pic, and thatll be the first thing for downloading home-brew demos.

Yeah, channel 13 isn't licensed to the public in the United States. It is, however, licensed to the public in France, some other EU countries, and coincidentally Japan.

Allenu/Seiru, if you want to mess with this stuff pick up a prism2 chipset wireless card for your PC (pcmcia, pci, sometimes even usb will work). A wireless router should work with the DS, but only for games desiged to use a wireless router. A PC with direct access to a wireless nic is needed to access the lower level stuff that the games that are not designed to work with standard 802.11b hardware use to communicate.

chizu wrote:

Allenu/Seiru, if you want to mess with this stuff pick up a prism2 chipset wireless card for your PC (pcmcia, pci, sometimes even usb will work). A wireless router should work with the DS, but only for games desiged to use a wireless router. A PC with direct access to a wireless nic is needed to access the lower level stuff that the games that are not designed to work with standard 802.11b hardware use to communicate.

Ah, okay, I'll look for a wireless card then. Thanks.

Quote:

Allenu/Seiru, if you want to mess with this stuff pick up a prism2 chipset wireless card for your PC (pcmcia, pci, sometimes even usb will work). A wireless router should work with the DS, but only for games desiged to use a wireless router. A PC with direct access to a wireless nic is needed to access the lower level stuff that the games that are not designed to work with standard 802.11b hardware use to communicate.

Hmmm. But, in the future when there are WiFi games out for the DS, would I be able to use a prism2 card to access the net from my DS?

Seiru wrote:

Quote:

Allenu/Seiru, if you want to mess with this stuff pick up a prism2 chipset wireless card for your PC (pcmcia, pci, sometimes even usb will work). A wireless router should work with the DS, but only for games desiged to use a wireless router. A PC with direct access to a wireless nic is needed to access the lower level stuff that the games that are not designed to work with standard 802.11b hardware use to communicate.

Hmmm. But, in the future when there are WiFi games out for the DS, would I be able to use a prism2 card to access the net from my DS?

once games are designed to specifically use a standard AP, anything that acts as an AP should work.
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

Would this work?

http://www.compusa.com/products/product_info.asp?product_code=307007&pfp=BROWSE

Sorry for threadjacking here, but I've been given bad advice it seems by other forums, and you guys seem to know what you're talking about....

Seiru wrote:

Would this work?

http://www.compusa.com/products/product_info.asp?product_code=307007&pfp=BROWSE

Sorry for threadjacking here, but I've been given bad advice it seems by other forums, and you guys seem to know what you're talking about....

depends... what chipset does it use? outside of my realtek card, i dont know what else works. all i know is my 802.11g card does *not* work
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

Darkain wrote:

Seiru wrote:

Would this work?

http://www.compusa.com/products/product_info.asp?product_code=307007&pfp=BROWSE

Sorry for threadjacking here, but I've been given bad advice it seems by other forums, and you guys seem to know what you're talking about....

depends... what chipset does it use? outside of my realtek card, i dont know what else works. all i know is my 802.11g card does *not* work

Hmm...Prism 2.5.

Or ADM8211 depending on the revision ?_?

the DS apparently is using short preamble, wich is an optional feature of 802.11b, but required on 802.11g... this could explain why some 802.11b cards will fail.
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

another interesting find: trying to setup a multiplayer game on mario, while packet sniffing...

ive been trying this several times, sometimes it is on channel 5, or channel 7, or channel 9, or channel 13. i havnt seen any others for mario yet. i can see the large amount of packets being sent after i initiate the multiplayer game, but i cant see that initial sending of data that tells the client DS what games are available for download.

i'm gonna keep trying other things to see what i can come up with tho.
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

Darkain wrote:

but i cant see that initial sending of data that tells the client DS what games are available for download.

I am a real noob when it comes to wireless but I have been messing around also.
Could it be that the DS uses Nintendo own protocol to initiate the d/l then use WiFi to move the bigger part faster?

autobot wrote:

Darkain wrote:

but i cant see that initial sending of data that tells the client DS what games are available for download.

I am a real noob when it comes to wireless but I have been messing around also.
Could it be that the DS uses Nintendo own protocol to initiate the d/l then use WiFi to move the bigger part faster?

i've been considering this... but ive also been trying to figure out what this custom protocol is... my theory is that it still runs at the same freqs as 802.11b, but doesnt use MAC headers for its packets, hence why i cant see the messages. this is just a *theory* tho, considering that the becon packets are still being sent at the exact same time, so instead of adjusting the freq of the transmitter, it may be something as simple as sending a header that isnt a MAC packet... wich could also explain why some routers start to skrew up from the DS being around, as they may not probably hande non-mac-packets being received.
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

http://ds.darkain.com/mario%2064%20download.zip

inside that zip is the file saved by AiroPeek NX. that is the data that i believe to be the Mario 64 multi-boot version. maybe someone can peice together a binary file by stripping out all of the header information, and attempt to disassemble the code and data for the game?
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

sorry for asking such a dumb question but, why does it matter what chipset the adapter has? if its a 802.11g card what is the problem?
i only ask because my card that i already have uses the broadcom chipset. i cant really justify/afford to grab another one just for my DS...

thanks for being so patient

bveina wrote:

sorry for asking such a dumb question but, why does it matter what chipset the adapter has? if its a 802.11g card what is the problem?
i only ask because my card that i already have uses the broadcom chipset. i cant really justify/afford to grab another one just for my DS...

thanks for being so patient

as mentioned several times thru-out the thread... the software we are using to sniff the packets uses a special driver, and the driver is designed for *some* 802.11b cards. also, if you only have 1 DS unit, it doesnt help too much either, because all you will see is the beacon. there has to be at least 2 DSs for actual data to be transmitted. i am on a 802.11b realtek PCMCIA card and have 2 DSs to work with, as well as 2 copies of the mario game, metroid game, and 1 copy of feel the magic (which doesnt count since it is single player only)
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

Darkain wrote:

inside that zip is the file saved by AiroPeek NX. that is the data that i believe to be the Mario 64 multi-boot version. maybe someone can peice together a binary file by stripping out all of the header information, and attempt to disassemble the code and data for the game?

There is an unencrypted ds arm9 binary inside that 802.11 dump but some packets are missing which makes it impossible to extract a complete binary needed for emulation purposes. Maybe you could try capturing the same data again so that we can puzzle together a complete binary from both dumps?

hi all !

Quote:

There is an unencrypted ds arm9 binary inside that 802.11 dump but some packets are missing

Well something sounds strange to me. How are you sure of this ? Did you succeed in de-crypting data ? If yes, congratulations, and could you explain a bit more ?

If no, how do you know this is an arm9 binary inside the cypher text ???
_________________
Leonard

Hi everybody

I just want to congratulate everyone on all their great progress so far. What you've discovered is very promising! Keep up the good work.

http://ds.darkain.com/mario%2064%20download%202.zip (2.1mb)

here is a second packet dump file. this one is completely unfiltered, so it contains all of the beacon messages, and im guessing some of the other messages are "ok" replies and/oe request next packet.
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

if you load that file on vba you can see some commands not randomly:

mov r12, #0x8000000
ldrb lr, [r12,#0x9c]
cmps lr, #0xa5
bne $0000290

etc...

Darkain wrote:

here is a second packet dump file. this one is completely unfiltered, so it contains all of the beacon messages, and im guessing some of the other messages are "ok" replies and/oe request next packet.

Thanks, but I was actually referring to lost packets, not filtered ones. About 2% of your ds packets are not seen by your wireless adapter. Maybe you can improve the quality somehow? (move ds closer to pc/laptop, give more cpu% to AiroPeek, etc.)

Btw, I was able to extract a complete header, icon?, arm9 and arm7 binary by combining both dumps. Looks like I will be spending the weekend figuring out the wireless protocol while waiting for my ds to arrive :)

Don't know if it can help. Looking at Darkain uniltered log, I think that data are not encrypted. Look at packet number 19852 ( using AiroPeek), at offset $23e you can find string:

ma\0rio_head

the \0 in the string "mario_head" is strange, but maybe the data are packed with string dictionary technic such as LZSS. ( \0 should be a command byte, not a literal string/offset pair)

My guess is also that it's not encrypted, but is compressed. (Compression would make sense, for both transfer speed and cart space)

There's lots of incomplete text strings visible, or strings with unprintable chars (zeroes?) in just looking at it in Notepad. Try searching for 'FileID', 'Water', or 'Actor'

Interesting - looks like groups of 8 chars between the unprintable chars. At least in the area I looked at

I wonder if it uses the same LZ compression that the GBA uses (unpacking functions in the bios?)

arbitrary wrote:

My guess is also that it's not encrypted, but is compressed. (Compression would make sense, for both transfer speed and cart space)

There's lots of incomplete text strings visible, or strings with unprintable chars (zeroes?) in just looking at it in Notepad. Try searching for 'FileID', 'Water', or 'Actor'

Interesting - looks like groups of 8 chars between the unprintable chars. At least in the area I looked at

I wonder if it uses the same LZ compression that the GBA uses (unpacking functions in the bios?)

Indeed, it is not encrypted but mostly compressed. When running the arm9 binary on a DS emulator the code unpacks itself and all of the text becomes readable.

If not already the case, the FULL file should be a complete screen of ALL black pixels. Fill up every pixel of every line and it might be easier to seperate buffers headers and data.
Also for the first line, are you taking into account that you cannot draw or type over your user name? So the first line has less DATA space. And the reason for the larger size of the first line is for the color data and the name of the DS, as it highlights usernames in the color set.

Do you guys know how to read other users profiles in pictochat yet? I do not have two DS's but does it create tabs of other users names that you can click to type privately to them, and also read their profile? I have no clue. Would the profile data give us anymore info about direct DS to DS communication rather than full room communication, as reading someone elses profile would only be sent to your specific DS.

Ok, im sure i sound like a retard, but maybe i should crack open my second DS and go buy a wireless card (as my WRT54G i just bought isnt going to be much help ATM)

Peace

DynamicStability wrote:

Do you guys know how to read other users profiles in pictochat yet? I do not have two DS's but does it create tabs of other users names that you can click to type privately to them, and also read their profile? I have no clue. Would the profile data give us anymore info about direct DS to DS communication rather than full room communication, as reading someone elses profile would only be sent to your specific DS.

yus, there are tabs at the top of the screen where you can read others profiles. from what i can tell, i think the profile info is sent over the same time the "i've entered the chat room" message is sent over, and then stored on the local system. and no, you cannot have private conversations between 2 DSs. i would love to get a 3rd DS to try this sort of stuff out further, but that just isnt possible for me at this time.
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

Got a new network card so I can start working on the captures now. When the DS'es are setting up their connection, the parent unit just sends out beacons, then when I go into download games, the parent unit sends an Ack packet, then an Auth. Only then does the child unit start sending (according to AiroPeek). Then they go on to do Assoc Req's, and then just send keep-alives until I press okay to download the game on both units. So the bad news is there might be some non-standard comms happening to handshake the two units initially. Time to brush up on my 802.11 protocols :).

gladius wrote:

Got a new network card so I can start working on the captures now. When the DS'es are setting up their connection, the parent unit just sends out beacons, then when I go into download games, the parent unit sends an Ack packet, then an Auth. Only then does the child unit start sending (according to AiroPeek). Then they go on to do Assoc Req's, and then just send keep-alives until I press okay to download the game on both units. So the bad news is there might be some non-standard comms happening to handshake the two units initially. Time to brush up on my 802.11 protocols :).

great! and i just wanted to say thanx for all the help you have provided.

ive been sorting thru my mario dump 2 a bit... checking out packets 8370 and on... getting some interesting strings. it appears that the packets are 512 bytes in size, 14 bytes header, 498 data. byte 11 increments with each packet being sent. the maching reciving the data sends back an acknowledgement packet that is 10 bytes in size, with the 7th byte being the same incremented ID. in both examples, the following 3 bytes after the incremented ID are 0's, so its possible it may be a 16-bit or 32-bit number.

Code:

face_demo_wait_yoshi.bca
face_demo_wait_yoshi.btp
face_demo_yoshi.bca
face_demo_yoshi.bmd
face_demo_yoshi.btp
mdst_kira1_spa.bin
opening_star.bca
opening_star_short.bca
USA
texBank_U.bmd
bakubaku
basabasa
batta_block
battan
battan_king
big_snowman
birikyu
bombhei
bombking
book
boss_teresa
c_jugem
chair
choropu
donguru
donkaku
donketu
dossy
dosune
eyekun
gamaguchi
hanachan
hojiro
horuhei
huwahuwa
hyuhyu!
iwante"
jango#
jugem$
keronpa%
killer&

_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

Darkain wrote:

Code:

bakubaku

Nothing to do with the prequel to Super Puzzle Fighter II, I assume...
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

does the DS also continue to send out signals while in sleep mode, does it changed based on whether it is waiting or acting as a beacon. Also can DS auto-detect other Dss on that mode?

mikeandbandit wrote:

does the DS also continue to send out signals while in sleep mode, does it changed based on whether it is waiting or acting as a beacon. Also can DS auto-detect other Dss on that mode?

Pictochat does not emit anything while in sleep mode. Metroid emits the same thing awake or asleep on the server screen. Mario also emits the same thing awake or asleep.

Nothing is emitted by a client DS waiting for a server to show up as far as I can tell. I think it's merely listening for a probe from a server DS, and when it recieves that it starts negotiating with the server DS.

chizu wrote:

mikeandbandit wrote:

does the DS also continue to send out signals while in sleep mode, does it changed based on whether it is waiting or acting as a beacon. Also can DS auto-detect other Dss on that mode?

Pictochat does not emit anything while in sleep mode. Metroid emits the same thing awake or asleep on the server screen. Mario also emits the same thing awake or asleep.

Nothing is emitted by a client DS waiting for a server to show up as far as I can tell. I think it's merely listening for a probe from a server DS, and when it recieves that it starts negotiating with the server DS.

if two units are in pictochat, and the client goes into sleep mode, it sends out a MAC Deauth packet. it seems to have a friendly shutdown, not an instant cut off.

if the server goes into sleep mode, no packets are sent from it at all.

when you resume from sleep mode, no packets are sent at all until you select "yes" from resume communications prompt.
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

http://ds.darkain.com/metroid.zip

this dump contains me hosting a metroid game, and then having a second unit join in, and then a couple seconds of gameplay.

also, the info on how to do everyting is spread out across several forums, and peronsal IM conversations and other various places... i'm going to try to compile as much information on the wifi hacking as possible on my site:
http://www.darkain.com/portability.php?portid=1&page=8
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

so what your saying is that DS auto detection while in sleep mode is up to the program and the developer, which is what i had suspected. Is it then possible to download an app into the DSs memory which could alert you whenever any DS communication within range is active?

I have a network card now that works, but only one DS. Oh well.

Seiru wrote:

I have a network card now that works, but only one DS. Oh well.

sadly, about all you can get with 2 DSs is beacons... this is a problem for many around here that wanna get into this stuff.
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

Yeah, I'm having fun playing with the beacons :-P

mikeandbandit wrote:

so what your saying is that DS auto detection while in sleep mode is up to the program and the developer, which is what i had suspected. Is it then possible to download an app into the DSs memory which could alert you whenever any DS communication within range is active?

It should be possible to do such a thing.

Seiru wrote:

Yeah, I'm having fun playing with the beacons :-P

So am I :P
One thing you could look into with just the beacons is to see if there's a way to make a PC WiFi card look like another DS to a real DS. I've been trying to do this, but have made very little progress.

Ehh..my AiroPeek gives me an error when I try to re-send a DS beacon.

There is a bit of a fundamental problem that I'm running into for further investigations here. We need to send raw 802.11b packets. To do this you either need drivers that expose that functionality (i.e. the airopeek ones, too bad they aren't documented), or drivers you can modify (i.e. Linux).

The big problem with AiroPeek is that it can't/won't retransmit control or management messages, which is how you set up a 802.11b connection.

So, looks like I'm going to be setting up a Linux partition :P. The other crappy part about this is that it talking to the DS will be chipset specific probably.

q/ here if both the propretary and the standard wifi protocols are able to be picked up and used by routers, then why did nintendo include the standard 802.11 and not just go with the low power comsumption option solely, unless they essentially had to have both as the nintendo protocol is essentially a tweaked 802.11 right? anyway why include both if they are both capable of online play?

I'd say the quickest way to get this thing going is to first set up a proxy. Basically, figure out how to detect say.. Room B, then have one DS in Room A, the other in Room B. Then have a program on the PC that will connect to both rooms, and have it relay the messages back and forth to eachother, logging what activity occurs. At which point, you can then to a slight modification to the program to say inverse the colors, try different numbers to see of color messages can be sent, and then start sending various messages. Before long, one would learn the DS protocol and be able to make an application for it (this is pretty much the same way I learned the IRC protocol).

gladius wrote:

There is a bit of a fundamental problem that I'm running into for further investigations here. We need to send raw 802.11b packets. To do this you either need drivers that expose that functionality (i.e. the airopeek ones, too bad they aren't documented), or drivers you can modify (i.e. Linux).

The big problem with AiroPeek is that it can't/won't retransmit control or management messages, which is how you set up a 802.11b connection.

So, looks like I'm going to be setting up a Linux partition :P. The other crappy part about this is that it talking to the DS will be chipset specific probably.

Yeah, I've been wondering about how to send raw 802.11b packets. I'm already using Linux, the linux-wlan-ng drivers, and the hostap drivers, but I've yet to figure out how to transmit some raw packet data. I'm thinking that it might be possible to throw the hostap driver in Master mode and use it's libraries to generate DS-like packets?

I'm collecting a bunch of the information that's been discovered here on my website, there's a little bit of how to do this stuff on Linux there too.

chizu wrote:

Yeah, I've been wondering about how to send raw 802.11b packets. I'm already using Linux, the linux-wlan-ng drivers, and the hostap drivers, but I've yet to figure out how to transmit some raw packet data. I'm thinking that it might be possible to throw the hostap driver in Master mode and use it's libraries to generate DS-like packets?

I'm collecting a bunch of the information that's been discovered here on my website, there's a little bit of how to do this stuff on Linux there too.

That's a nice resource, thanks. And thanks also to Darkain for all the work on getting this stuff rolling, nice page there too :).

For sending raw 802.11b packets in Linux you can use AirJack, http://sourceforge.net/projects/airjack/ which is unfortunately only compatible with a few chipsets, prism2 mainly. Or, just hack the driver up to add a userland hook that accepts a raw packet and forwards it onto the hardware. It's non-trivial, that's for sure, unless someone discovers a different way :).

gladius wrote:

For sending raw 802.11b packets in Linux you can use AirJack, http://sourceforge.net/projects/airjack/ which is unfortunately only compatible with a few chipsets, prism2 mainly. Or, just hack the driver up to add a userland hook that accepts a raw packet and forwards it onto the hardware. It's non-trivial, that's for sure, unless someone discovers a different way :).

Hmm, I'm not really up on my kernel level C, so I'll give AirJack a try. I've alreadly got several prism2.5 cards since those used to be the only things that Linux worked well with.
Thanks for finding AirJack, I've been looking for something like that for a good chunk of today.

Any chance this stuff can work wth an at76c503 chipset? It's very popular with USB cards, and it took me forever to get drivers to work with Linux (source code doesn't play nice to me, binary files weren't available).

Zhila wrote:

Any chance this stuff can work wth an at76c503 chipset? It's very popular with USB cards, and it took me forever to get drivers to work with Linux (source code doesn't play nice to me, binary files weren't available).

Probably not, the driver for that chipset lacks promiscuous/monitor mode. You might be able to pick up some beacon frames addressed to the broadcast address but that's it.

Quote:

Probably not, the driver for that chipset lacks promiscuous/monitor mode. You might be able to pick up some beacon frames addressed to the broadcast address but that's it.

Is this a limitation of the software driver, or a limitation of the hardware itself?

Zhila wrote:

Quote:

Probably not, the driver for that chipset lacks promiscuous/monitor mode. You might be able to pick up some beacon frames addressed to the broadcast address but that's it.

Is this a limitation of the software driver, or a limitation of the hardware itself?

I think it is a limitation of the card's firmware.

Hmm.. from what I understand, the atmel-based cards do not have a firmware so to speak, rather, when the device is initilized, the driver sends the firmware image to the device, which is then stored on internal RAM, and when power is lost, so is the firmware, which must be updated with each cold boot of the device. So, then, in your opinion, is this still a software driver problem?

Zhila wrote:

Hmm.. from what I understand, the atmel-based cards do not have a firmware so to speak, rather, when the device is initilized, the driver sends the firmware image to the device, which is then stored on internal RAM, and when power is lost, so is the firmware, which must be updated with each cold boot of the device. So, then, in your opinion, is this still a software driver problem?

In a way, the linux driver does send the firmware image to the device at initilization but this firmware is just the Amtel coded firmware. So unless you can find/write firmware that supports Monitor or Promiscuous mode, capturing most DS packets won't be possible.

Hey there all! it's Dumpkain again!... i mean, Darkain. i got another dump for ya. 4 minutes long playing mario 64 2 player. played 2 games of running around getting the star... not to exciting gameplay, but exciting that we have more data to sort thru now!!

Mario 64 0 Dump 3 (1mb zip - 5.5mb unpacked)

also, you can get the latest on everything from a new section on my - Nintendo DualScreen - Wi-Fi Hacking
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

oh, i forgot to mention, i started this dump in the middle.. it doesnt have the initial handshake and wireless download isnt there, since i did all that ealier in a previous dump... just so you dont go and try lookin for that data in this dump. ;)
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

http://ds.darkain.com/mario%20beacon.bin

so, i was watching the mario 64 beacon data before starting a game up. it appears to be sending 10 consecutive packets in a row, with 40 byte headers and 96 bytes of data. byte 32 appears to be the incrementing counter byte, ranging from 0 to 9 in each packet.

in this dump, i've stripped out all of the MAC header information, so we can look directly at the DS info. the packets where all sent as beacon packets, and this is the data contained in the "WPA" section of the packets. if my memory serves me correctly, isnt WPA encryption... but the DS is using this part of the message as data... could *this* be how Ni-Fi defer from Wi-Fi?

if you look in the binary, you will see the strings for the game name, game description, and the host's DS's name. the name of the host for this game is "Darkain(tm)", with the (tm) being the actual TM character. the (tm) appears as "! or 0x22 0x21. i'm not too familiar w/ unicode or UTF-16, but i dont think this is either of those. the seperation between normal characters in the Nin format is a 0x00, and i dont think any PC standard text format uses those, do they?

anyways, hopefully this is good info for anyone that wants to try to re-create the process of downloading a ROM to their DS, as the first step would be broadcasting that a download server is available.

happy hacking! :)
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

Darkain: This looks like standard Unicode-16. Standard charaters are padded with zeros (for example A=0x0041) and the trademark character is 0x2122; take a look at http://www.unicode.org/charts/PDF/U2100.pdf. So, it seems to be following some standards :)

Two9A wrote:

Darkain: This looks like standard Unicode-16. Standard charaters are padded with zeros (for example A=0x0041) and the trademark character is 0x2122; take a look at http://www.unicode.org/charts/PDF/U2100.pdf. So, it seems to be following some standards :)

hey, thanx for the info, you are correct! :D that'll make things a bit easier knowing that it is a standard format like that.
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

Here's what I've seen while playing with Mario Beacon in Notepad:

Quote:

?
@ @ ?Up? @ C? b ?/E?{?ahr?f 6?!_2?B_S?g ? ? ? ???????,,??Â¸???????? ?
@ @ ?Up? @ ?n b ? ?? ??? ??,??y??? ? ?w paf f pf gq p? ?[UU ?
@ @ ?Up? @ ?? b w???ffffafff??????????lB?????????w???fv??jffwff?j?f??kh ? ? xg wg wg vf ff ?? ?
@ @ ?Up? @ ?? b ?? ?? q? ? j? `? ???????\??\???].??\????????5??U?Q???D???????af af ?
@ @ ?Up? @ ?? b ?? ?? ?? ??
??
?? f j ? ??jffff?w???????? ?? ??????? ?
@ @ ?Up? @ e? b ???? ??
?
D a r k a i n "! S u p e r M a r i ?
@ @ ?Up? @ ?? b o 6 4 D S S c r a m b l e t o ?
@ @ ?Up? @ ?? b g e t t h e S t a r s !
T h e c a p s w i l l h e l p y o u o u t . ?
@ @ ?Up? @ ?? H ?
@ @ ?Up? @ ??

^ Raw data

Quote:

D a r k a i n "! S u p e r M a r i ?
@ @ ?Up? @ ?? b o 6 4 D S S c r a m b l e t o ?
@ @ ?Up? @ ?? b g e t t h e S t a r s !
T h e c a p s w i l l h e l p y o u o u t .

^ Section of data

Quote:

D a r k a i n "! S u p e r M a r i
?
@ @ ?Up? @ ?? b
o 6 4 D S S c r a m b l e t o
?
@ @ ?Up? @ ?? b
g e t t h e S t a r s !
T h e c a p s w i l l h e l p y o u o u t .

As you can see above, this:

Quote:

?
@ @ ?Up? @ ?? b

Appears to be a separator in the data.

This is probably worthless information to the rest of ya, but I just thought I would submit it to make me feel special and like I'm part of this :)

Quote:

Appears to be a separator in the data.

ya, like i said, there is DS header information in there... that segment should appear 10 times (since there are 10 packets), and be slightly different each time.

if i remember correctly (i dont have the hex editor open right now), the first 6 bytes are the MAC address of the unit, and i havent have a chance to figure out the rest of the header other then the incremented id.
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

Darkain - here are some words I found in your Mario 64 Download 2 file, in order of when they appear in the file:

data
enemy
entry
normal_obj
vrbox
iron_ball
wanwan
iron_ball.bmd
chain.bmd
wanwan.bmd
wanwan_attack.bca
wanwan_wait.bca
e3_start_map_r00.bmd
coin
door
obj_kokuten
obj_pathlift
wanwan.bmd
wanwan_attack.bca
wanwan_wait.bca
e3_start_map_r00.bmd
coin
door
obj_kokuten
obj_pathlift

This was all near the end, I saw tons more object references etc throughout the file.

If we're seeing raw unicode in the multiboot data packets, am I correct in interpreting that means the DS multiboot does not use encryption?

We aren't sure yet. It's not been totally confirmed how the DS'es handshake. However, it's looking increasingly unlikely that encryption was used, as just about everything is in plaintext.

[pessimist]
But watch the packet checksums be RSA encrypted, essentially putting digital signature on everything sent over the air.
[/pessimist]
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

Mario 64 - From Japanese to English

this site lists the japanese names for in-game characters, and their english counterparts. it explains what some of the weird words we are seeing in the mario 64 dump are.... example: "Jugemu", which is "Lakitu" in the english version.
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

Darkain, did you find a nice way to save packets in raw format from Airopeek? I'm just working on the pictochat a little more, just getting the raw packet data seems to be a pain in the butt. Writing a parser for the text format won't be too bad though.

For online play I would be willing to bet if we could get some EoIP bridging software, we could make this happen. All I have found on the subject are routers made by www.mikrotik.com. I'm going to keep looking. It would be good if we find this software, if it would let you filter traffic based on MAC address and only allow DS MAC's pass. This would be all that would be necessary for online play, no matter what protocol because it would be layer 2 and I doubt Nintendo reinvented the wheel here.

tepples wrote:

[pessimist]
But watch the packet checksums be RSA encrypted, essentially putting digital signature on everything sent over the air.
[/pessimist]

Sounds pretty expensive computationally... but not outside the realm of possibility.
_________________
Rav (Win/Mac/Linux games for free)

eg.... I can't seem to get Airsnort with my Atmel Chipset nor Network Stumbler with my Prism chipset to pick up my DS in either Super Mario 64x4 nor Pictochat. I only have 1 DS, can't pick up packets, but at least I'd like to be able to see the fact that my DS exists.
_________________
Current high scores on Super Mario 64 DS:
Shell Smash - 50230
Wanted - 140

ravuya wrote:

tepples wrote:

[pessimist]
But watch the packet checksums be RSA encrypted, essentially putting digital signature on everything sent over the air.
[/pessimist]

Sounds pretty expensive computationally... but not outside the realm of possibility.

The checksums are only 32-bit though, aren't they? So wouldn't they be limited to 32-bit encryption max? And hence not all that difficult to crack?

I've made some new dumps of pictochat sending messages. Gotta run, or I'd post some more, but two are multi-line dumps and one is a completely full one line dump. We are close on the 2 line image using the current format, however the 5 line image is quite a bit off, something funky going on there. http://members.fortunecity.com/infinityhq/dsdev/dsdev.html for pics and source.

gladius wrote:

I've made some new dumps of pictochat sending messages. Gotta run, or I'd post some more, but two are multi-line dumps and one is a completely full one line dump. We are close on the 2 line image using the current format, however the 5 line image is quite a bit off, something funky going on there. http://members.fortunecity.com/infinityhq/dsdev/dsdev.html for pics and source.

kew kew. i just looked at your pics. nice work. ive also linked to your page from my ds wifi page.

i might look into multi-lined dumps a bit later, but right now, im playing around w/ some multi-boot dumps. i wanna be able to transmit code to the DS ASAP, this way we can start the home-brew dev scene. now, i dont want anyone to get their hopes up yet about this idea, im just mentioning to say that this is what i'm currently looking into, so i may not have any dumps again for a bit (unless someone specifically requests something they want)
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

gladius wrote:

I've made some new dumps of pictochat sending messages. Gotta run, or I'd post some more, but two are multi-line dumps and one is a completely full one line dump. We are close on the 2 line image using the current format, however the 5 line image is quite a bit off, something funky going on there. http://members.fortunecity.com/infinityhq/dsdev/dsdev.html for pics and source.

hey, wait a minutes... i was just looking at your images... remember, the first line of text (first 2 rows of tiles) are pushed over to the right to make room for the name... so just move the bitmap bits over to the right by 48 pixels for all tile rows, and add in blank space as a filler on the first line where the name would appear. this should fix up your alighment issue.
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

Here's my breakdown of Mario 64 probing with more dumps of the multiboot probes to play with.

1 packet is sent out when you start the probing. This contains a normal 80 byte long 802.11 management frame. The management frame tags each contain normal 802.11 data, except tag 221 which contains the information the DS is sending out. This first frame tag 221 consists of

Code:

00 09 bf 00 0a 00 00 00 01 00 00 00 11 00 40 00 28 f4 00 09 fe 01 08 00

and it's 802.11 sequence number is 0. I seem to be missing a lot of packets though, as I get sequence number 7 next, then 8, then 10, and it jumps around by 6 or so for most of the log. I'm in a really bad spot for low level wireless hacking, there's sometimes 6 or 7 wifi networks active here. My pcap files confirm what Darkain said about there being 10 192 byte packets.

I've put together a file containing the 221 tags from what I believe is one of each of the 10 packets.
http://projects.spicious.com/ds/downloads/10packets.txt

Here's the first pcap file that's from.
http://projects.spicious.com/ds/downloads/mario64probes.pcap
Here's the second pcap file, the 4th packet is the only one from this one.
http://projects.spicious.com/ds/downloads/mario64probes-4.pcap

Here's those 10 packets as a binary instead of the hex codes with 24 bytes of EFEFEF seperating them.
http://projects.spicious.com/ds/downloads/10packets.bin

My name is a little more difficult than Darkain's to find in the packets, as it's written in hiragana. ちず is 0x3061 0x305A.

I'm working on making AirJack work with a 2.6 linux kernel to rebroadcast these packets to see if the DS finds them. I still think it's possible to do without AirJack though, by finding a way to load up the 221 tag in the hostap drivers management frames.

Abscissa wrote:

ravuya wrote:

tepples wrote:

[pessimist]
But watch the packet checksums be RSA encrypted, essentially putting digital signature on everything sent over the air.
[/pessimist]

Sounds pretty expensive computationally... but not outside the realm of possibility.

The checksums are only 32-bit though, aren't they? So wouldn't they be limited to 32-bit encryption max? And hence not all that difficult to crack?

I was thinking about this in the shower today, actually (where everyone does their best thinking, duh). Because of the US export laws they can't possibly make a DS with any kind of crypto solution with > 64-bit keys, unless they were to ensure that the DS is never exported outside of the US; but this can't really be ensured thanks to sites like lik-sang and playasia.
_________________
Rav (Win/Mac/Linux games for free)

ravuya wrote:

I was thinking about this in the shower today, actually (where everyone does their best thinking, duh). Because of the US export laws they can't possibly make a DS with any kind of crypto solution with > 64-bit keys, unless they were to ensure that the DS is never exported outside of the US; but this can't really be ensured thanks to sites like lik-sang and playasia.

i've been thinking about the while "RSA Secured" thing too... my theory is that this is going to be an optional feature to developers to use in multi-player games, and the current launch titles mearly dont use it (thankfully).
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

I really have no idea why it's there. It could potentially be there for later use in case the whole internet access thing goes through and credit card payments or other secure data transfer is required.
_________________
Rav (Win/Mac/Linux games for free)

Warning.

Darkain, you just got slashdotted. http://games.slashdot.org/article.pl?sid=04/11/28/2042213&tid=222&tid=184&tid=10

Haha, awesome. I was wondering when this great work was gonna show up on slashdot.

localhost wrote:

Warning.

Darkain, you just got slashdotted. http://games.slashdot.org/article.pl?sid=04/11/28/2042213&tid=222&tid=184&tid=10

yus, i'm well aware of this... everyone has come to me all at the same time saying "SLASHDOTTED!!" and i just laugh! my page has been quite sluggish, but still loads, and all of the torrents on the site are killing my local bandwidth here at home.

i'm hoping this will interest more tallented developers that have access to the right hardware, so that they could help us out on decoding packets, and eventually writing software for the DS.
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

Darkain wrote:

i'm hoping this will interest more tallented developers that have access to the right hardware, so that they could help us out on decoding packets, and eventually writing software for the DS.

One can only hope, hehe.

Hey guys, I was doing some experiment on m64 too and I got the packets when m64 is searching for other dses and I was wondering what would happen if I would broadcast the same packets from my pc, (you know trying to make the ds think my pc is a ds) but I can't find any program to do this, I get some error on AiroPeek about it not being able to send the packets. Maybe someone can help?
At worse I could try to write a program to send the packets, I know some winsock stuff but i was wondering when creating the socket object should I create it with an ip of 255.255.255.255 for broadcast and it would work?

This is the problem I posted about before. The DS doesn't run an IP stack, so we have to send it raw 802.11b packets. Unfortunately nearly all drivers for Windows do not expose that kind of functionality. The ones that do are custom (see AiroPeek), but even they don't support sending control messages. This is the major stumbling block right now. Hence my foray into Linux which is slowly moving along :).

gladius wrote:

This is the problem I posted about before. The DS doesn't run an IP stack, so we have to send it raw 802.11b packets. Unfortunately nearly all drivers for Windows do not expose that kind of functionality. The ones that do are custom (see AiroPeek), but even they don't support sending control messages. This is the major stumbling block right now. Hence my foray into Linux which is slowly moving along :).

a friend of mine came up w/ the idea of possibly using the linksys router that has the open-source firmware, and thus had linux ported to it.

reasons?
1) it already runs linux
2) it is already designed to broadcast control messages

thing is, i dunno how hard it would be to code for the router, and constantly reflashing it would become tedious and annoying... so this may be a project saved for later after packet sending is perfected, and we want to setup a dedicated ds server... i dunno, i'm just rambling at this point. *goes back to decoding packets*
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

Besides the slashdotting, this thread and Darkains work have been getting ALOT of attention everywhere I look, even in the piracy channels on efnet :P
_________________
www.hungrydeveloper.com
Version 2.0 now up - guaranteed at least 100% more pleasing!

first of all - HELLO :)
I'm from /.

Darkain wrote:

a friend of mine came up w/ the idea of possibly using the linksys router that has the open-source firmware, and thus had linux ported to it.

Nope, Linksys WRT54G and the like use EVIL Broadcom chipsets - no source code, no real SDK, Not GPL compiliant. Those evil scumbags violate GPL and should be sued to death .. but there are no real GPL activists so its not gonna happen (Stallman is an Idiot btw).

BUT :) there is one other interesting hardware :
http://rtl8181.sourceforge.net/
We have a working OPEN SOURCED wifi driver that allows one to send and receive raw data. The boxes with realtek 8181 are sold for like 30$.

Other option would be APs based on Prism cards (2 2.5 3 GT and others) or Cisco (basically tuned up prism).

This non encrypted bootcode really excites me. Picochat looks cool too, but being able to boot your own code with say PIM capabilities would be great + there is a money contest for the first person booting Linux on DS :)

rasz wrote:

+ there is a money contest for the first person booting Linux on DS :)

$1,000 is what i've heard.. yes, i know. :)
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

MumblyJoe wrote:

Besides the slashdotting, this thread and Darkains work have been getting ALOT of attention everywhere I look, even in the piracy channels on efnet :P

That is starting to annoy me a little bit. Darkain is doing a lot here but there are also a few others who are working on this project to decode the protocol yet they recieve no credit.

Krakken wrote:

MumblyJoe wrote:

Besides the slashdotting, this thread and Darkains work have been getting ALOT of attention everywhere I look, even in the piracy channels on efnet :P

That is starting to annoy me a little bit. Darkain is doing a lot here but there are also a few others who are working on this project to decode the protocol yet they recieve no credit.

right. i think gladius has helped out greatly in decoding packets. and there are many others i am working with as well. who evers name appears isnt the important thing here tho, its the fact that we *NEED* to keep pushing forward.

because of the slashdotting, many developers have come forward to me with similar projects and vasts amounts of ideas. we have the pictochat image decoding going on here, we also have members here trying to decode the ARM9 binary code from the mario dump. outside of these forums, i know of at least 3 teams working on trying to tunnel the wireless multiplayer gameplay. and at this point, i'm focusing completely on wireless multi-boot download from a pc. there are countless amounts of other projects going on right now as well.

things are coming along smoothly at this point, much faster then anyone could even have imagined. we all have our own agenda, but we also have to try to keep this a team effort as much as possible. i, personally, have been trying my best to not hold anything back. the second i make a discovery, i post. yes, i have been wrong a few times because i have rushed information, but later corrected it.

i've been hearing a some teams talking about keeping information on the DS secret for the time being, and some have even requested that i do the same. i simply wont. i want information available to as many people as possible, this way, someone that has an idea or the knowledge for the task at hand can help out.
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

Darkain, if you died whilest working on this project, you would truly be a martyr. In other words, "Well put!"

Quote:

've been hearing a some teams talking about keeping information on the DS secret for the time being, and some have even requested that i do the same. i simply wont. i want information available to as many people as possible, this way, someone that has an idea or the knowledge for the task at hand can help out.

I think its great you've taken this attitude. This was discussed briefly on #dsdev on efnet last night. Unfortunately the one area I would like to have a hand in is pouring over the mariods mb rom, but to do that requires access to an arm9 emu, which apparently someone has written (anon) and has decided to keep private. Going through the mario mb rom will help to shed light on the issues being discussed in phantom-inker's thread on VIDEO and CPU/MEM masking.

its becoming apparent that while the homebrew hacking efforts are moving speedily, they are probably not moving as fast as they could and that is in large part due to the secrecy by those with the tools and hardware (and info).

So props for being so open about it. I am not sure what the motivation is behind keeping things secret, perhaps certain groups want to spring a significant ammount of progress on the scene and reap the credit and legacy. I have no time for that kind of stuff, I am purely interested in getting my code up and running on the DS.

Props to everyone here and elsewhere who have been working on seeing that through.

benjamin wrote:

I am not sure what the motivation is behind keeping things secret, perhaps certain groups want to spring a significant ammount of progress on the scene and reap the credit and legacy.

Maybe because all of this is not-so-legal and certain (wise) people don't want to get their hands burnt and/or go to jail?

The things I am referring to are not illegal to my knowledge, for instance writing and distributing an ARM9 emulator. Correct me if I'm wrong but the last time I checked emulators were not illegal.

Tim Schuerewegen wrote:

benjamin wrote:

I am not sure what the motivation is behind keeping things secret, perhaps certain groups want to spring a significant ammount of progress on the scene and reap the credit and legacy.

Maybe because all of this is not-so-legal and certain (wise) people don't want to get their hands burnt and/or go to jail?

I think the silence is mostly because the idiots who want a DS emulator the most are also the most incapable of delivering it; i.e. pirates.
_________________
Rav (Win/Mac/Linux games for free)

Good call. The reason people want it to be kept secret is like when release groups release roms, they like to pretend they have done something that anyone with just about any flash card hardware couldn't have done.

Having said that, the work you guys are doing (and sorry if I sounded like I was giving Darkain all the credit) is fantastic, and I am following your efforts very closely. Unfortunately while I understand the process (I have some CCNa etc training) I have nothing to offer except for support.
_________________
www.hungrydeveloper.com
Version 2.0 now up - guaranteed at least 100% more pleasing!

As it stands now, it seems like the next major obstacle is getting stuff sent to the DS. The popular WEP cracking programs AirSnort and AirCrack both use AiroPeek in their windows ports to do low level packet manipulation.

While investigating this, I noticed AiroPeek's API (Peek.dll) has the PeekPacketSend function exposed, which might do the trick. Has anyone tried using this to send data to the DS? I'd try this out myself, but for some odd reason AiroPeek won't work with my wireless card. I'd go out and buy a new one if I knew of a cheap brand that worked.

actually that would be some really useful information. i desperately want to get a look at the stuff the goes out of my DS but my card uses broadcom hence im skrewed. what is a cheap pci card i could go out and get.

mclysenk wrote:

While investigating this, I noticed AiroPeek's API (Peek.dll) has the PeekPacketSend function exposed, which might do the trick. Has anyone tried using this to send data to the DS? I'd try this out myself, but for some odd reason AiroPeek won't work with my wireless card. I'd go out and buy a new one if I knew of a cheap brand that worked.

wont work. it cannot send control signals, only data packets. from the looks of it right now, we are gonna need a linux box with the right wireless card to be able to transmit the needed packets to the DS. i've been in contact w/ some developers that are more familiar with linux than i, and we will probably be trying out some test enviornments in the next week or two.

my laptop lcd screen is dieing out on me (again), so i'm considering instead of taking it around with me everywhere i go, to hook up a monitor and turn it into a linux workstation specifically geared towards this project.
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

rasz wrote:

first of all - HELLO :)
I'm from /.

Darkain wrote:

a friend of mine came up w/ the idea of possibly using the linksys router that has the open-source firmware, and thus had linux ported to it.

Nope, Linksys WRT54G and the like use EVIL Broadcom chipsets - no source code, no real SDK, Not GPL compiliant. Those evil scumbags violate GPL and should be sued to death .. but there are no real GPL activists so its not gonna happen (Stallman is an Idiot btw).

Linksys' website has the firmware source code to all their linux-based products, and their firmware revisions. I'm not particularily sure what you're talking about there, other than plugging your project. Unless of course it isn't the real source, I've not really checked out the code yet, however I doubt that is true.

http://www.linksys.com/support/gpl.asp

Linux does sound like it may be the way to go on this for now, yay to open source software. And of course, yay to all of you working on this and keeping that work in the open.

Well, yes and no.

Linksys has been compliant to the GPL for some time now, releasing the source code of their Linux embedded products, nice and all. This, of course, has spurred development of interesting projects like OpenWRT.

However, the GPL'd parts of the source code currently don't include the binary-only drivers for the Broadcom chipsets. That means that, while the operating system can be tailored to do almost anything, the current wireless drivers impose a limit on how to use the hardware and this could severely affect the development of such a custom DS-compatible hotspot/router.

I'm not sure since I haven't read much on how exactly and to what extent is the hardware exposed by those drivers, but I've seen them causing bugs that were very hard to tackle because of their closed state.
_________________
Otaku no naka no otaku, Otaking da!!!

Darkain wrote:

wont work. it cannot send control signals, only data packets. from the looks of it right now, we are gonna need a linux box with the right wireless card to be able to transmit the needed packets to the DS.

Forgive my ignorance, but I'm still learning stuff about networking. What is the difference between a control signal and a data packet? I can't seem to find any good references.

mclysenk wrote:

Darkain wrote:

wont work. it cannot send control signals, only data packets. from the looks of it right now, we are gonna need a linux box with the right wireless card to be able to transmit the needed packets to the DS.

Forgive my ignorance, but I'm still learning stuff about networking. What is the difference between a control signal and a data packet? I can't seem to find any good references.

control packets, such as beacons, auth, deauth, ack... things like those. data packets would be like the ones that contain the pictochat images. the drivers and api for airopeek does *not* allow for sending of control packets. i think the api also prevents you from sending data packets w/ 0 bytes of data (in other words, just the MAC header). this too, is a problem, as the DS sends out a decent amount of emtpy data packets, i'm asuming so it can monitor signal strengths on those packets.

until we can get the auth handshaking working (which there isnt a sollution to in windows right now as far as i know), we cant do any other forms of communications.
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

Are control signals part of the 802.11b specification or the IP layer? Unless I'm way off the mark, the NDIS drivers used by AiroPeek bypass the IP layer, so you could send a fake auth/ack/whatever.

As for 0 length packets, it seems Peek.dll requires packets to be terminated with 4 zeroed bytes, so maybe you were having problems with that? I haven't quite finished reversing the api calls so I could be wrong.

mclysenk wrote:

Are control signals part of the 802.11b specification or the IP layer? Unless I'm way off the mark, the NDIS drivers used by AiroPeek bypass the IP layer, so you could send a fake auth/ack/whatever.

As for 0 length packets, it seems Peek.dll requires packets to be terminated with 4 zeroed bytes, so maybe you were having problems with that? I haven't quite finished reversing the api calls so I could be wrong.

everything is raw MAC packets. nothing on the DS uses an IP layer yet. if you could send me some API docs, i would be greatful. but like i said, everything i'm reading seems to point to a "no" on support for sending them using airopeek.
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

Darkain wrote:

everything is raw MAC packets. nothing on the DS uses an IP layer yet. if you could send me some API docs, i would be greatful. but like i said, everything i'm reading seems to point to a "no" on support for sending them using airopeek.

Thank you for the quick response. I don't have anything working yet since I can't test anything, but once I get a new network card I'll post some code, or at least be able to definitively say AiroPeek (and Windows) is a no-go.

I thought I would mention this first, but wouldn't the NIC have to have a Nintendo registered MAC address for the DS to even listen to it, or would a MAC cloning process be trivial, or is it dependant on the capability of the cards? Once things get rolling, I'd love to be able to test this stuff, but I'm not really in the position to get any new NICs. (I have a Linksys WC11 ver.3 (Prism2/NDIS) and a Belkin USB F5D6050 WLAN Adaptor (Atmel 76c503 RFMD))
_________________
Current high scores on Super Mario 64 DS:
Shell Smash - 50230
Wanted - 140

Zhila wrote:

I thought I would mention this first, but wouldn't the NIC have to have a Nintendo registered MAC address for the DS to even listen to it, or would a MAC cloning process be trivial, or is it dependant on the capability of the cards? Once things get rolling, I'd love to be able to test this stuff, but I'm not really in the position to get any new NICs. (I have a Linksys WC11 ver.3 (Prism2/NDIS) and a Belkin USB F5D6050 WLAN Adaptor (Atmel 76c503 RFMD))

MAC cloning is usually quite trivial. XP has an option to edit it built right in the OS, and most routers have the same capability. I'm pretty sure Linux and OS X do too, but I've never had a reason to try it out there.

(Nice Prism2, though. Should go great with Linux)
_________________
Rav (Win/Mac/Linux games for free)

Zhila wrote:

I thought I would mention this first, but wouldn't the NIC have to have a Nintendo registered MAC address for the DS to even listen to it, or would a MAC cloning process be trivial, or is it dependant on the capability of the cards? Once things get rolling, I'd love to be able to test this stuff, but I'm not really in the position to get any new NICs. (I have a Linksys WC11 ver.3 (Prism2/NDIS) and a Belkin USB F5D6050 WLAN Adaptor (Atmel 76c503 RFMD))

it is pretty common for devices today to have MAC address cloing, so this really isnt a problem.
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

just thought of this, how do we know when the DS is actaully listening, as it could be searching for a specific signal which only nintendo would know at this point in order for it to begin transmitting in a manner that can be easily used to connect online or just to a PC. Basically, im saying the DS amy not be listening to the PC because its waiting to recieve the Specific command to do so. Isn there a way to capture and emulate the signal a DS sends when its searching for clients in multiplayer?

mikeandbandit wrote:

just thought of this, how do we know when the DS is actaully listening, as it could be searching for a specific signal which only nintendo would know at this point in order for it to begin transmitting in a manner that can be easily used to connect online or just to a PC. Basically, im saying the DS amy not be listening to the PC because its waiting to recieve the Specific command to do so. Isn there a way to capture and emulate the signal a DS sends when its searching for clients in multiplayer?

my theory is this right now....

the DS is fully IEEE 802.11b compliant, running at 0.5, 1, 2mbps speeds. for things like wireless multiplayer download or pictochat, one unit acts as an access point, and sends out beacons, just like a PC AP would. the difference between WiFi and NiFi? none! WiFi (IEEE 802.11) uses radio waves to send binary data back and forth at a specific set of frequencies (identified by channels), and in this binary data, we have MAC (Media Access Control) packets.

http://www.uwsg.indiana.edu/usail/network/nfs/network_layers.html

the IEEE 802.11b standard does not require an IP layer to be present to be compliant. everyone asumes that because current DS software does not have an IP stack, and pull an IP addy from their router, that it therefor isnt IEEE 802.11b. this is un-true. it mearly means that it is exposing layers 3 thru 7 with a different protocol..... think of it this way: remember back in the days of NetBEUI, IPX/SPX, and AppleTalk networks? TCP/IP (IPv4 and IPv6) are the two most commonly used data communication protocols out there nowdays.

i believe that "NiFi" is mearly an alternative to TCP/IP for the DS. see, the TCP/IP protocol is actually a bit complex in terms of what all it can support, hence why it is used for general internet communcations. to create a more basic sollution, it appears as tho nintendo came up with their own alternative to TCP/IP. now, this doesnt mean that they wont use TCP/IP in future games (they already said there will eventually be internet based games, wich TCP/IP is a requirement for), but this is on a per-game basis, and nothing out there right now uses such a protocol yet.

the reason why we are able to capture packets from the DS right now is because we are doing this at Layer 2 (like a MAC dump), not Layer 3 (like a TCP dump). this bypasses any sort of protocol translations, and gives us raw binary data to work with.

-------------------------------------

so, in short, "NiFi" is an alternative to TCP (Layer 3), not an alternative to WiFi (802.11, Layer 2)
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

OK, I only have one DS but I setup madden 2005 to host a game and captured the packets using ethereal on linux. It sends out 2 alternating packet to the following MACs 03:09:bf:00:00:00 and 03:09:bf:00:00:00. I can't find any significant use for the destination macs. I don't know if maybe this is a multicast address or what. Will keep searching and give more info on what else I can find.

Also the packets to 00 are CLNP packets 30B in size
03 are LLC at 28B in size.

do we have any know executibles for the DS that will work in boot mode, (of course assuming will actually get to that point where the we can send data to the DS) i ask because it may be easier for the DS to put up signals in the download mode rather than pictochat as it may not be looking for any specific type of data, but rather an executable it is compatible with. Nintendo has said that it is possible for the kiosks to be built to allow DS demos when in range, so it may not be verifying the presence of a DS per se. if we could circumvent the entire handshake process that would be great. also could the two alternating signals be 1) a main madden server, and 2) a general mac address for all DSs?

Darkain, I'm really inclined to think that as well.

localhost wrote:

OK, I only have one DS but I setup madden 2005 to host a game and captured the packets using ethereal on linux. It sends out 2 alternating packet to the following MACs 03:09:bf:00:00:00 and 03:09:bf:00:00:00. I can't find any significant use for the destination macs. I don't know if maybe this is a multicast address or what. Will keep searching and give more info on what else I can find.

Also the packets to 00 are CLNP packets 30B in size
03 are LLC at 28B in size.

This is very, very similar to what Metroid does. I think those are a type of broadcast address, perhaps some sort of MAC subnetting? Anyone with more knowledge MAC address assignment than "first 6 bytes are the manufacturer, last 6 bytes are the individual device" know what that address is? Googleing has turned up very little.

Last edited by chizu on Tue Nov 30, 2004 5:41 am; edited 1 time in total

i couldnt trace the mac, but is it only for madden or do ther games use the same/similar mac address

gbadev.org forum archive

DS development > DS Wireless Cracking News

#29643 - PhoenixSoft - Tue Nov 23, 2004 3:11 am

#29647 - dagamer34 - Tue Nov 23, 2004 5:19 am

#29666 - Cupcakus - Tue Nov 23, 2004 4:22 pm

#29673 - cesium - Tue Nov 23, 2004 6:33 pm

#29718 - ampz - Wed Nov 24, 2004 7:45 am

#29742 - cesium - Wed Nov 24, 2004 6:02 pm

#29759 - dagamer34 - Wed Nov 24, 2004 7:32 pm

#29763 - cesium - Wed Nov 24, 2004 9:01 pm

#29772 - tepples - Wed Nov 24, 2004 11:01 pm

#29784 - cesium - Thu Nov 25, 2004 3:16 am

#29805 - Darkain - Thu Nov 25, 2004 9:24 am

#29807 - Abscissa - Thu Nov 25, 2004 9:56 am

#29808 - Darkain - Thu Nov 25, 2004 9:59 am

#29814 - ampz - Thu Nov 25, 2004 11:42 am

#29815 - Darkain - Thu Nov 25, 2004 11:54 am

#29821 - cesium - Thu Nov 25, 2004 3:44 pm

#29841 - Darkain - Thu Nov 25, 2004 8:41 pm

#29843 - ampz - Thu Nov 25, 2004 10:35 pm

#29845 - Darkain - Thu Nov 25, 2004 10:38 pm

#29846 - ampz - Thu Nov 25, 2004 10:48 pm

#29847 - Darkain - Thu Nov 25, 2004 10:54 pm

#29856 - gladius - Fri Nov 26, 2004 4:45 am

#29860 - Darkain - Fri Nov 26, 2004 5:17 am

#29861 - gladius - Fri Nov 26, 2004 5:37 am

#29862 - Darkain - Fri Nov 26, 2004 5:47 am

#29864 - gladius - Fri Nov 26, 2004 6:16 am

#29865 - gladius - Fri Nov 26, 2004 6:27 am

#29874 - Darkain - Fri Nov 26, 2004 6:53 am

#29875 - gladius - Fri Nov 26, 2004 7:13 am

#29877 - Darkain - Fri Nov 26, 2004 7:20 am

#29879 - gladius - Fri Nov 26, 2004 7:37 am

#29881 - Darkain - Fri Nov 26, 2004 7:58 am

#29882 - Darkain - Fri Nov 26, 2004 8:12 am

#29885 - allenu - Fri Nov 26, 2004 8:20 am

#29886 - flip_fl0p - Fri Nov 26, 2004 8:34 am

#29887 - Darkain - Fri Nov 26, 2004 8:37 am

#29888 - flip_fl0p - Fri Nov 26, 2004 8:39 am

#29889 - Darkain - Fri Nov 26, 2004 8:41 am

#29890 - mymateo - Fri Nov 26, 2004 8:45 am

#29891 - Darkain - Fri Nov 26, 2004 8:50 am

#29893 - flip_fl0p - Fri Nov 26, 2004 9:04 am

#29894 - Darkain - Fri Nov 26, 2004 9:08 am

#29895 - flip_fl0p - Fri Nov 26, 2004 9:18 am

#29896 - Darkain - Fri Nov 26, 2004 9:21 am

#29897 - Darkain - Fri Nov 26, 2004 9:29 am

#29898 - Marill - Fri Nov 26, 2004 9:34 am

#29899 - flip_fl0p - Fri Nov 26, 2004 9:46 am

#29900 - Darkain - Fri Nov 26, 2004 9:56 am

#29901 - flip_fl0p - Fri Nov 26, 2004 10:39 am

#29902 - Krakken - Fri Nov 26, 2004 10:51 am

#29903 - Darkain - Fri Nov 26, 2004 10:53 am

#29905 - Krakken - Fri Nov 26, 2004 11:01 am

#29906 - Darkain - Fri Nov 26, 2004 11:09 am

#29907 - Krakken - Fri Nov 26, 2004 11:13 am

#29908 - Marill - Fri Nov 26, 2004 11:27 am

#29917 - ravuya - Fri Nov 26, 2004 4:28 pm

#29918 - RiZeUp - Fri Nov 26, 2004 4:40 pm

#29919 - ravuya - Fri Nov 26, 2004 4:47 pm

#29920 - flip_fl0p - Fri Nov 26, 2004 5:55 pm

#29921 - chizu - Fri Nov 26, 2004 7:02 pm

#29922 - gladius - Fri Nov 26, 2004 8:53 pm

#29923 - Darkain - Fri Nov 26, 2004 8:57 pm

#29924 - Darkain - Fri Nov 26, 2004 8:58 pm

#29925 - ravuya - Fri Nov 26, 2004 8:59 pm

#29926 - gladius - Fri Nov 26, 2004 9:11 pm

#29927 - tepples - Fri Nov 26, 2004 9:13 pm

#29931 - Darkain - Fri Nov 26, 2004 9:50 pm

#29934 - Joat - Fri Nov 26, 2004 10:27 pm

#29935 - Darkain - Fri Nov 26, 2004 10:29 pm

#29936 - ampz - Fri Nov 26, 2004 10:53 pm

#29937 - Darkain - Fri Nov 26, 2004 10:55 pm

#29938 - ampz - Fri Nov 26, 2004 11:05 pm

#29939 - Darkain - Sat Nov 27, 2004 12:02 am

#29945 - penndragon - Sat Nov 27, 2004 1:27 am

#29951 - ravuya - Sat Nov 27, 2004 3:19 am

#29952 - penndragon - Sat Nov 27, 2004 3:49 am

#29962 - ravuya - Sat Nov 27, 2004 4:38 am

#29963 - DrEggman - Sat Nov 27, 2004 4:52 am