PSP Network Update Tricks
i am still really new at this, and i really dont know what i am doing, but here is my take of the situation..
oopo, seeing as you describe the system as accessing the MS and then the UMD then, maybe it is trying to essentially boot like a computer?? MS, then UMD (i.e. HD then CD??)
what if when you reflash your system with the code, since is obiviously doesnt install any real programs what if it only loads the most essential workings of the PSP, if so, if it could be broken into, i would give the most information? Maybe, since it is working in reduced funtionality mode, maybe it can only access a 32Mb MS which would contain all the data needed to run the CODE from the UMD to reflash the system? I agree with mc, the file would have to be totally unecrypted because the system ultimately wouldnt know how to use the encryption/decryption hardware on the board?
"arakon - every time someone makes something idiot-proof, nature comes up with a new idiot." - thats the coolest thing i have ever heard!!!
like i said, i am very new, but i am willing to learn, if anyone can point me in the right direction that would be awesome!
oopo, seeing as you describe the system as accessing the MS and then the UMD then, maybe it is trying to essentially boot like a computer?? MS, then UMD (i.e. HD then CD??)
what if when you reflash your system with the code, since is obiviously doesnt install any real programs what if it only loads the most essential workings of the PSP, if so, if it could be broken into, i would give the most information? Maybe, since it is working in reduced funtionality mode, maybe it can only access a 32Mb MS which would contain all the data needed to run the CODE from the UMD to reflash the system? I agree with mc, the file would have to be totally unecrypted because the system ultimately wouldnt know how to use the encryption/decryption hardware on the board?
"arakon - every time someone makes something idiot-proof, nature comes up with a new idiot." - thats the coolest thing i have ever heard!!!
like i said, i am very new, but i am willing to learn, if anyone can point me in the right direction that would be awesome!
-
Guest
Thanks for asking! Start by reading every forum post relating to PSP development here. :) It will give you the best background information for your next questions about what has been tried, and what is, may be, or isn't possible. ;)FNG wrote:like i said, i am very new, but i am willing to learn, if anyone can point me in the right direction that would be awesome!
From what I've read so far (quite a bit) and from my experience with other devices that use FLASH (i.e. linksys routers, embedded systems, etc)..
I would strongly believe that the PSP uses a bootstrap. The reason is as others have said, it makes it alot faster to program and re-program the device without having to open it up..
If you send your PSP to a place in California for them to fix it, and all they need to do is to hook up a cable and reflash the firmware.. That would take less time and cost less than having to manually open up each PSP.
I've also embedded serial port in a FPGA using VHDL. Most PC's (if not all) support 115200 baud as the max rate, but RS232 can go higher than 115200 baud. I've used 230400 baud (8 bits, 1 start bit, 1 stop bit) at the rate of 23,040 packets/sec (1 byte per packet) to send a picture from a computer usign an USB to serial converter (supported 230,400 baud) to the FPGA board that would then decrypt the serial data on the fly and send it to a LCD. The FPGA ran at 50 MHZ, and could support up to 460800 baud, but I couldnt get a USB-to-serial that supported that speed at the time.
Keep in mind that the PSP has a higher speed bus than what I used for my final project for class - so it could support 921600 baud or even 1036800 baud. At 1036800 baud, its sending ~103680 bytes/sec, or 6 MB in 60 seconds.
Another thing to think about, is that it took 3 minutes before the system information came up. What excactly is occuring during those 3 minutes? Others have said that its sending data.. But this is on a quality control line.. Perhaps the flash was uploaded in less than a minute, and the other 2 minutes were spent testing the RAM, graphics, etc?
Do we even know if the firmware was initially loaded? I.e. the bootstrap could have been notified to test the RAM, FLASH, etc before the ROM was even loaded. Thats the purpose of QC.
As for bootstrap code, it can be very small. The bootstrap on the routers I've worked with is really small, and offers alot of features. It doesnt take much code to test memory.
I decided to figure out what baud rate would be needed to send 32 MB in 3 minutes. 3 minutes = 180 seconds. 32 MB = 32,000,000 bytes. That divided by 180 seconds, 177,777.777778 bytes per second.
Baud = bits per second. 2 bits extra for header (start and stop bits)..
921,600 Baud = 92,160 bytes/sec..
1,843,200 Baud = 184,320 bytes/sec..
1,777,777 Baud = 177,777 bytes/sec..
But.. What if 2 minutes is spent on uploading the firmware and 1 minute is spent on tests?
Then.. 2,666,666 Baud is needed..
This is assuming that the flash is approximately 32 MB, which it may not be. This also assumes some other things, and its just to be an educational input on baud rates.
The best way to find out more about this way of flashing the ROM is to have people corrupt their PSP's on purpose and then hooking up the serial port to an oscilloscope and seeing if theres any activity whatsoever. Also, could do this without corrupting the firmware to see if, again, theres any activity. Also.. Where is the serial port connected to? I'll be researching this a bit myself.
The router that I've worked on, has an ARM cpu thats connected directly to the serial port. I havent seen any mention (so far) of a UART so I'd have to guess its an internal UART in one of the CPU's. The voltage levels support that guess (+2.5 V, 0V).
I looked at the pictures of the PSP at lik-sang.com and re-read some of the hardware information. From what I've seen so far, it appears that the "serial port" is on the same board as the ARM cpu (which is used for wlan). The processors run at a core voltage of ~1.6v, so it wouldnt make much sense to double to 2.5V for serial, and not 5V. However, the ARM cpu I've worked with in the router used 2.5V for serial because its core is 2.5V.
The pictures that sony released or was released by somebody else at extremetech.com doesnt mention the serial interface.. They do mention Mobile DDR I/F under I/O. The same page didnt mention the wireless either.
The I/O, Ext Bus, Security System, Timer/RTC, all are on the same bus as DMAC, which then interfaces into the main bus according to documents at extremetech.com.
The pictures at liksang, while offering alot of information, are also confusing because they dont show clearly which components connect to which. If the wireless board connects to the UMD and memory stick, I could put down a theory that the ARM processor may have a significant role in the security system, since the security system is on the "same" bus as the I/O.
But for now, I would theorize that the ARM processor plays a role. I'll be doing some other research into this :)
Updated: http://www.informit.com/content/images/ ... /fig06.jpg
The above link shows it better - you can see the RF board (bottom right) also contains the memory stick adapter. So far it looks like the adapter is connected to the connector and doesnt goto the ARM processor at all, but its hard to tell from the picture.
I also did some network sniffing. My PSP is already at version 1.5, so it didnt upgrade at all. However, I got captures of it looking for another PSP to play games with, and also connecting to check for an update.
One idea is to do something similiar to whats being done with the DS. Somebody figured out how the DS would load a game over its wireless and wrote code that the DS would then load and execute, over a wireless connection. It looks like the PSP can do the same. Perhaps a wireless bootloader that will then dump the memory to a computer thats running netcat on a specific port?
I would strongly believe that the PSP uses a bootstrap. The reason is as others have said, it makes it alot faster to program and re-program the device without having to open it up..
If you send your PSP to a place in California for them to fix it, and all they need to do is to hook up a cable and reflash the firmware.. That would take less time and cost less than having to manually open up each PSP.
I've also embedded serial port in a FPGA using VHDL. Most PC's (if not all) support 115200 baud as the max rate, but RS232 can go higher than 115200 baud. I've used 230400 baud (8 bits, 1 start bit, 1 stop bit) at the rate of 23,040 packets/sec (1 byte per packet) to send a picture from a computer usign an USB to serial converter (supported 230,400 baud) to the FPGA board that would then decrypt the serial data on the fly and send it to a LCD. The FPGA ran at 50 MHZ, and could support up to 460800 baud, but I couldnt get a USB-to-serial that supported that speed at the time.
Keep in mind that the PSP has a higher speed bus than what I used for my final project for class - so it could support 921600 baud or even 1036800 baud. At 1036800 baud, its sending ~103680 bytes/sec, or 6 MB in 60 seconds.
Another thing to think about, is that it took 3 minutes before the system information came up. What excactly is occuring during those 3 minutes? Others have said that its sending data.. But this is on a quality control line.. Perhaps the flash was uploaded in less than a minute, and the other 2 minutes were spent testing the RAM, graphics, etc?
Do we even know if the firmware was initially loaded? I.e. the bootstrap could have been notified to test the RAM, FLASH, etc before the ROM was even loaded. Thats the purpose of QC.
As for bootstrap code, it can be very small. The bootstrap on the routers I've worked with is really small, and offers alot of features. It doesnt take much code to test memory.
I decided to figure out what baud rate would be needed to send 32 MB in 3 minutes. 3 minutes = 180 seconds. 32 MB = 32,000,000 bytes. That divided by 180 seconds, 177,777.777778 bytes per second.
Baud = bits per second. 2 bits extra for header (start and stop bits)..
921,600 Baud = 92,160 bytes/sec..
1,843,200 Baud = 184,320 bytes/sec..
1,777,777 Baud = 177,777 bytes/sec..
But.. What if 2 minutes is spent on uploading the firmware and 1 minute is spent on tests?
Then.. 2,666,666 Baud is needed..
This is assuming that the flash is approximately 32 MB, which it may not be. This also assumes some other things, and its just to be an educational input on baud rates.
The best way to find out more about this way of flashing the ROM is to have people corrupt their PSP's on purpose and then hooking up the serial port to an oscilloscope and seeing if theres any activity whatsoever. Also, could do this without corrupting the firmware to see if, again, theres any activity. Also.. Where is the serial port connected to? I'll be researching this a bit myself.
The router that I've worked on, has an ARM cpu thats connected directly to the serial port. I havent seen any mention (so far) of a UART so I'd have to guess its an internal UART in one of the CPU's. The voltage levels support that guess (+2.5 V, 0V).
I looked at the pictures of the PSP at lik-sang.com and re-read some of the hardware information. From what I've seen so far, it appears that the "serial port" is on the same board as the ARM cpu (which is used for wlan). The processors run at a core voltage of ~1.6v, so it wouldnt make much sense to double to 2.5V for serial, and not 5V. However, the ARM cpu I've worked with in the router used 2.5V for serial because its core is 2.5V.
The pictures that sony released or was released by somebody else at extremetech.com doesnt mention the serial interface.. They do mention Mobile DDR I/F under I/O. The same page didnt mention the wireless either.
The I/O, Ext Bus, Security System, Timer/RTC, all are on the same bus as DMAC, which then interfaces into the main bus according to documents at extremetech.com.
The pictures at liksang, while offering alot of information, are also confusing because they dont show clearly which components connect to which. If the wireless board connects to the UMD and memory stick, I could put down a theory that the ARM processor may have a significant role in the security system, since the security system is on the "same" bus as the I/O.
But for now, I would theorize that the ARM processor plays a role. I'll be doing some other research into this :)
Updated: http://www.informit.com/content/images/ ... /fig06.jpg
The above link shows it better - you can see the RF board (bottom right) also contains the memory stick adapter. So far it looks like the adapter is connected to the connector and doesnt goto the ARM processor at all, but its hard to tell from the picture.
I also did some network sniffing. My PSP is already at version 1.5, so it didnt upgrade at all. However, I got captures of it looking for another PSP to play games with, and also connecting to check for an update.
One idea is to do something similiar to whats being done with the DS. Somebody figured out how the DS would load a game over its wireless and wrote code that the DS would then load and execute, over a wireless connection. It looks like the PSP can do the same. Perhaps a wireless bootloader that will then dump the memory to a computer thats running netcat on a specific port?
Why do you think that there should be any activity on the serial port? If it was designed to avoid reverse engineering, the serial port wouldn't send any data, until triggered from some external source, perhaps a hidden key combination or sending a secret message on the serial port. Perhaps the headphone connector is used for the serial port. If they want to flash the firmware on a corrupt PSP flash, the bootloader could check the serial port for the secret message, then a program could be uploaded (of course AES encrypted), which in turn could load a service UMD with utilities (or perhaps booting Linux :-) Would be nice to plug-in an USB keyboard and open a xterm on the PSP, like I've done with my iPAQ: http://groups.google.de/groups?selm=d46 ... cologne.de )fireether wrote:The best way to find out more about this way of flashing the ROM is to have people corrupt their PSP's on purpose and then hooking up the serial port to an oscilloscope and seeing if theres any activity whatsoever. Also, could do this without corrupting the firmware to see if, again, theres any activity. Also.. Where is the serial port connected to? I'll be researching this a bit myself.
I don't know the details of the DS hack, but if the games are crypted, there is no way to submit own code without knowing the key.fireether wrote: One idea is to do something similiar to whats being done with the DS. Somebody figured out how the DS would load a game over its wireless and wrote code that the DS would then load and execute, over a wireless connection. It looks like the PSP can do the same. Perhaps a wireless bootloader that will then dump the memory to a computer thats running netcat on a specific port?
you used the wrong url, using the one below it gives this :Synthaxx R-or wrote:pretty sure
http://v03.cdn.update.playstation.org/n ... /trial.txt
ust says "P" .. D:
Ok, I got a couple of captures. In order to aquire the captures, I did the following:
-Setted up a linux laptop with a D-Link 802.11g card, placed the card in monitor mode, setted up for channel 6 (same channel that I use for wireless network)
-Setted up the PSP's adhoc mode to use channel 6 - it gives you a choice, and I decided not to do auto. I can scan all channels with the wireless card, but I would miss some packets.
-Setted up the PSP's infrastructre mode to use my old wireless router. I use a DLink router that uses WPA-PSK, which the PSP doesnt support. So my old router (802.11b) was setted up. WEP 64 bit and 128 bit modes work, but I didnt use WEP for a short time because its encrypted and would show up as encrypted in ethereal.
-Started up ethereal on the laptop.
I captured the following:
-PSP checking for a new update (data is posted elsewhere, so I wont repeat what others have already found)
-PSP searching for any other games (via Game Sharing)
-Lumines 2P vs Mode - where it searches for other PSP's that are in range.
I did two captures of the Lumines 2P vs mode. This is because if a random number is picked for a hash or so, it would show up.
The reason why I picked to capture from the game is in case when the PSP is on "game sharing" mode, it may be listening for specific data, and in the game - it may be sending that data.
In each packet, the IEEE 802.11 header is valid. However, for most of the packets, the payload under the IEEE 802.11 header is not valid. It shows up (often) as IEEE 802.11 wireless LAN management frame, and ethereal indicates that the frame is corrupted (at the wireless LAN management header/payload).
Looking at the data, here is what ethereal thinks is a IEEE 802.11 wireless LAN management frame, although it may not be..
00 11 60 63 50 5f 51 55 5c 55 53 31 30 30 30 32 5f 4c 5f 01 04 82 84 8b 96 e5 18 bc c8
First packet, first attempt..
<null><0x11>PSP_AULUS10002_L_<0x01><0x04><0x82><0x84>
<0x8b><0x96><0xe5><0x18><0xbc><0xc8>
First packet, second attempt..
<null><0x11>PSP_AULUS10002_L_<0x01><0x04><0x82><0x84>
<0x8b><0x96><0x51><0x6e><0x13><0xfa>
Second packet, first attempt..
<null><0x11>PSP_AULUS10002_L_<0x01><0x04><0x82><0x84>
<0x8b><0x96><0xb0><0xb3><0xc8><0x96>
Second packet, second attempt..
<null><0x11>PSP_AULUS10002_L_<0x01><0x04><0x82><0x84>
<0x8b><0x96><0xd0><0x68><0x1b><0x24>
Third packet, first attempt...
<null><0x11>PSP_AULUS10002_L_<0x01><0x04><0x82><0x84>
<0x0b><0x16><0x03><0x01><0x06><0x06><0x02><0x00>
<0x00><0xa0><0x6a><0xc4><0x06>
Third packet, Second attempt...
<null><0x11>PSP_AULUS10002_L_<0x01><0x04><0x82><0x84>
<0x0b><0x16><0x03><0x01><0x06><0x06><0x02><0x00>
<0x00><0x5c><0x7c><0x96><0x44>
Notice that both packets are larger than the previous ones..
Also theres some similiarities between the first and second attempts.
Fourth packet, first attempt...
<null><0x11>PSP_AULUS10002_L_<0x01><0x04><0x82><0x84>
<0x0b><0x16><0x03><0x01><0x06><0x06><0x02><0x00>
<0x00><0x55><0x01><0xf2><0x14>
Fourth packet, Second attempt...
<null><0x11>PSP_AULUS10002_L_<0x01><0x04><0x82><0x84>
<0x0b><0x16><0x03><0x01><0x06><0x06><0x02><0x00>
<0x00><0x44><0x21><0x3a><0xfb>
Fifth packet, first attempt...
<null><0x11>PSP_AULUS10002_L_<0x01><0x04><0x82><0x84>
<0x0b><0x16><0x03><0x01><0x06><0x06><0x02><0x00>
<0x00><0x07><0xcd><0xe5><0x05>
Fifth packet, Second attempt...
<null><0x11>PSP_AULUS10002_L_<0x01><0x04><0x82><0x84>
<0x0b><0x16><0x03><0x01><0x06><0x06><0x02><0x00>
<0x00><0x9a><0x26><0x55><0x43>
And so forth.
It seems to broadcast the larger packets more often than the smaller ones.
Now, on to the game share packets. I only made one attempt.
They're similiar if not same as the above packets, in which it seems to be a corruption of the IEEE 802.11 wireless LAN management frame - i.e. ethereal says "Malformed Packet: IEEE 802.11". However, it could be their own (sony's) protocol thats being mistaken for IEEE 802.11 wireless LAN management frame data.
First packet:
<null><0x19>PSP_S000000001_L_GameShar<0x01><0x04><0x82>
<0x84><0x9b><0x96><0x2b><0xcf><0x7a><0xef>
Notice similarity with the above packets. 0x01, 0x04, 0x82, 0x84.
Second packet:
<null><0x19>PSP_S000000001_L_GameShar<0x01><0x04><0x82>
<0x84><0x9b><0x96><0x60><0x8b><0x80><0xa0>
Third packet:
<null><0x19>PSP_S000000001_L_GameShar<0x01><0x04><0x82>
<0x84><0x0b><0x16><0x03><0x01><0x06><0x06><0x02><0x00>
<0x00><0x49><0x70><0xdc><0x70>
Again, notice similarity with the "long" packets used by the game. I believe network processor is responsible for the physical layer and network layer - the application layer simply passes information to the network chip.. The name could be a string, with a max limit - thus why its gameshar and not gameshare. But thats just a theory. PSP_S000000001_L_GameShar is approx 25 characters.
Packet # Bytes
1 37
2 37
3 44
4 44
5 44
6 44
7 44
8 37
9 37
10 44
11 44
12 44
13 44
14 37
15 37
16 44
17 44
18 44
19 44
20 44
21 44
22 44
23 44
24 44
25 44
26 37
It seems to me that it switches between 44 and 37.. I looked at the IEEE 802.11 header..
When it does a Probe Request, its 37 bytes. When it does a beacon frame, tis 44 bytes. I have the PDF files (saved ethereal output as postscript then used ps2pdf to convert to PDF files for ease of reading.
All packets are sent to BSS Id: FF:FF:FF:FF:FF:FF which means broadcast.
I dont have a second PSP, but my room mate is planning to buy one soon. When she does, I'll sniff traffic between the two - which will be more valuable and informative than the above information. But for now, the above information is better than none. If anybody out there has two PSP's and can sniff between them - please post your findings.
I'm not supporting game copying, but if a game shares itself from one PSP to another so the second one can run the game, then by seeing how that is done - we can probably write a program that will allow us to probe the PSP. I.e. trick the PSP into thinking our laptop is another PSP thats trying to send a game.. Its alot faster to do it that way because the game should be in memory - and worst come to worst, the PSP can be rebooted. Its safer than playing with the OS file and risk making your PSP go bad.
Beside, theres another good reason to figure out the network protocol. A program could be made that will allow you to play against somebody else anywhere in the world.. By tunneling the PSP protocol through TCP/IP.
-Setted up a linux laptop with a D-Link 802.11g card, placed the card in monitor mode, setted up for channel 6 (same channel that I use for wireless network)
-Setted up the PSP's adhoc mode to use channel 6 - it gives you a choice, and I decided not to do auto. I can scan all channels with the wireless card, but I would miss some packets.
-Setted up the PSP's infrastructre mode to use my old wireless router. I use a DLink router that uses WPA-PSK, which the PSP doesnt support. So my old router (802.11b) was setted up. WEP 64 bit and 128 bit modes work, but I didnt use WEP for a short time because its encrypted and would show up as encrypted in ethereal.
-Started up ethereal on the laptop.
I captured the following:
-PSP checking for a new update (data is posted elsewhere, so I wont repeat what others have already found)
-PSP searching for any other games (via Game Sharing)
-Lumines 2P vs Mode - where it searches for other PSP's that are in range.
I did two captures of the Lumines 2P vs mode. This is because if a random number is picked for a hash or so, it would show up.
The reason why I picked to capture from the game is in case when the PSP is on "game sharing" mode, it may be listening for specific data, and in the game - it may be sending that data.
In each packet, the IEEE 802.11 header is valid. However, for most of the packets, the payload under the IEEE 802.11 header is not valid. It shows up (often) as IEEE 802.11 wireless LAN management frame, and ethereal indicates that the frame is corrupted (at the wireless LAN management header/payload).
Looking at the data, here is what ethereal thinks is a IEEE 802.11 wireless LAN management frame, although it may not be..
00 11 60 63 50 5f 51 55 5c 55 53 31 30 30 30 32 5f 4c 5f 01 04 82 84 8b 96 e5 18 bc c8
First packet, first attempt..
<null><0x11>PSP_AULUS10002_L_<0x01><0x04><0x82><0x84>
<0x8b><0x96><0xe5><0x18><0xbc><0xc8>
First packet, second attempt..
<null><0x11>PSP_AULUS10002_L_<0x01><0x04><0x82><0x84>
<0x8b><0x96><0x51><0x6e><0x13><0xfa>
Second packet, first attempt..
<null><0x11>PSP_AULUS10002_L_<0x01><0x04><0x82><0x84>
<0x8b><0x96><0xb0><0xb3><0xc8><0x96>
Second packet, second attempt..
<null><0x11>PSP_AULUS10002_L_<0x01><0x04><0x82><0x84>
<0x8b><0x96><0xd0><0x68><0x1b><0x24>
Third packet, first attempt...
<null><0x11>PSP_AULUS10002_L_<0x01><0x04><0x82><0x84>
<0x0b><0x16><0x03><0x01><0x06><0x06><0x02><0x00>
<0x00><0xa0><0x6a><0xc4><0x06>
Third packet, Second attempt...
<null><0x11>PSP_AULUS10002_L_<0x01><0x04><0x82><0x84>
<0x0b><0x16><0x03><0x01><0x06><0x06><0x02><0x00>
<0x00><0x5c><0x7c><0x96><0x44>
Notice that both packets are larger than the previous ones..
Also theres some similiarities between the first and second attempts.
Fourth packet, first attempt...
<null><0x11>PSP_AULUS10002_L_<0x01><0x04><0x82><0x84>
<0x0b><0x16><0x03><0x01><0x06><0x06><0x02><0x00>
<0x00><0x55><0x01><0xf2><0x14>
Fourth packet, Second attempt...
<null><0x11>PSP_AULUS10002_L_<0x01><0x04><0x82><0x84>
<0x0b><0x16><0x03><0x01><0x06><0x06><0x02><0x00>
<0x00><0x44><0x21><0x3a><0xfb>
Fifth packet, first attempt...
<null><0x11>PSP_AULUS10002_L_<0x01><0x04><0x82><0x84>
<0x0b><0x16><0x03><0x01><0x06><0x06><0x02><0x00>
<0x00><0x07><0xcd><0xe5><0x05>
Fifth packet, Second attempt...
<null><0x11>PSP_AULUS10002_L_<0x01><0x04><0x82><0x84>
<0x0b><0x16><0x03><0x01><0x06><0x06><0x02><0x00>
<0x00><0x9a><0x26><0x55><0x43>
And so forth.
It seems to broadcast the larger packets more often than the smaller ones.
Now, on to the game share packets. I only made one attempt.
They're similiar if not same as the above packets, in which it seems to be a corruption of the IEEE 802.11 wireless LAN management frame - i.e. ethereal says "Malformed Packet: IEEE 802.11". However, it could be their own (sony's) protocol thats being mistaken for IEEE 802.11 wireless LAN management frame data.
First packet:
<null><0x19>PSP_S000000001_L_GameShar<0x01><0x04><0x82>
<0x84><0x9b><0x96><0x2b><0xcf><0x7a><0xef>
Notice similarity with the above packets. 0x01, 0x04, 0x82, 0x84.
Second packet:
<null><0x19>PSP_S000000001_L_GameShar<0x01><0x04><0x82>
<0x84><0x9b><0x96><0x60><0x8b><0x80><0xa0>
Third packet:
<null><0x19>PSP_S000000001_L_GameShar<0x01><0x04><0x82>
<0x84><0x0b><0x16><0x03><0x01><0x06><0x06><0x02><0x00>
<0x00><0x49><0x70><0xdc><0x70>
Again, notice similarity with the "long" packets used by the game. I believe network processor is responsible for the physical layer and network layer - the application layer simply passes information to the network chip.. The name could be a string, with a max limit - thus why its gameshar and not gameshare. But thats just a theory. PSP_S000000001_L_GameShar is approx 25 characters.
Packet # Bytes
1 37
2 37
3 44
4 44
5 44
6 44
7 44
8 37
9 37
10 44
11 44
12 44
13 44
14 37
15 37
16 44
17 44
18 44
19 44
20 44
21 44
22 44
23 44
24 44
25 44
26 37
It seems to me that it switches between 44 and 37.. I looked at the IEEE 802.11 header..
When it does a Probe Request, its 37 bytes. When it does a beacon frame, tis 44 bytes. I have the PDF files (saved ethereal output as postscript then used ps2pdf to convert to PDF files for ease of reading.
All packets are sent to BSS Id: FF:FF:FF:FF:FF:FF which means broadcast.
I dont have a second PSP, but my room mate is planning to buy one soon. When she does, I'll sniff traffic between the two - which will be more valuable and informative than the above information. But for now, the above information is better than none. If anybody out there has two PSP's and can sniff between them - please post your findings.
I'm not supporting game copying, but if a game shares itself from one PSP to another so the second one can run the game, then by seeing how that is done - we can probably write a program that will allow us to probe the PSP. I.e. trick the PSP into thinking our laptop is another PSP thats trying to send a game.. Its alot faster to do it that way because the game should be in memory - and worst come to worst, the PSP can be rebooted. Its safer than playing with the OS file and risk making your PSP go bad.
Beside, theres another good reason to figure out the network protocol. A program could be made that will allow you to play against somebody else anywhere in the world.. By tunneling the PSP protocol through TCP/IP.
Are you sniffing in monitor mode? Try sniffing in ad-hoc mode, but join the network essid the PSP is trying to create: PSP_AULUS10002_L_
You can usually do this under linux by typing:
iwconfig <interface> mode ad-hoc essid PSP_AULUS10002_L_ channel 6
All you're seeing the broadcast packets of the PSP trying to create the ad-hoc network instead of the actual data. :)
You may also want to take a look at the namco gameshare information we've discovered so far as it may be similar:
http://forums.ps2dev.org/viewtopic.php?t=1264
We've got some of the protocol kinda figured out, and a few dumps from tcpdump that may interest you.
Good work, btw. Keep it up. :)
You can usually do this under linux by typing:
iwconfig <interface> mode ad-hoc essid PSP_AULUS10002_L_ channel 6
All you're seeing the broadcast packets of the PSP trying to create the ad-hoc network instead of the actual data. :)
You may also want to take a look at the namco gameshare information we've discovered so far as it may be similar:
http://forums.ps2dev.org/viewtopic.php?t=1264
We've got some of the protocol kinda figured out, and a few dumps from tcpdump that may interest you.
Good work, btw. Keep it up. :)
Thanks :)ooPo wrote:Are you sniffing in monitor mode? Try sniffing in ad-hoc mode, but join the network essid the PSP is trying to create: PSP_AULUS10002_L_
You can usually do this under linux by typing:
iwconfig <interface> mode ad-hoc essid PSP_AULUS10002_L_ channel 6
All you're seeing the broadcast packets of the PSP trying to create the ad-hoc network instead of the actual data. :)
You may also want to take a look at the namco gameshare information we've discovered so far as it may be similar:
http://forums.ps2dev.org/viewtopic.php?t=1264
We've got some of the protocol kinda figured out, and a few dumps from tcpdump that may interest you.
Good work, btw. Keep it up. :)
I looked at the thread, and I also got the capture. I can host the PDF file if necessary. The above was done in monitor mode, but the recent capture is in ADHOC mode.
Maybe this thread and the other thread should be spliced together so all the information is in one place.. Maybe a new thread?
Packet 1:
0x00, 0x02, etc.. bunch of data.. 82 bytes, so I wont retype here.
Packet 2:
0x00, 0x01, 0x01, 0x02, 0x00, 0x80, Fireether 0x00, 118 FF's. 134 bytes of data.
Looked in the other thread - the second packet looks excactly like yours, except without the FROM field.
Looking at packet 1 and 2.. Packet 1 seems to be game info, etc.. 82 bytes of data, but starting the same way as yours did. Packet 2 is my name, and its 134 bytes of data. Those sizes do not include any headers.
ooPo, when you have the time, can you "share" a game between the two PSP's you have, and post an ethereal capture of it?
I.e. export ethereal data as a Postscript file, showing all the data and detailed packet, etc.. Then use ps2pdf to convert it to a PDF.
http://air.fireether.net/noah/PSP/ADHOCLUM.PDF is the PDF file of my capture.
I.e. export ethereal data as a Postscript file, showing all the data and detailed packet, etc.. Then use ps2pdf to convert it to a PDF.
http://air.fireether.net/noah/PSP/ADHOCLUM.PDF is the PDF file of my capture.
I don't use ethereal, and I don't think a pdf would be the best way to transport the information.
The dump I posted in the namco gameshare thread is a tcpdump of the sharing of a game between two PSPs. Its all there for your perusal, if you know how. :)
( http://www.oopo.net/psp/namco-gameshare-adhoc.data.gz )
Using tcpdump, you can replay captures from a file with the -r option. As ethereal is essentially a front end to tcpdump, I'm sure you can do the same. Load it up and view it however you want.
The dump I posted in the namco gameshare thread is a tcpdump of the sharing of a game between two PSPs. Its all there for your perusal, if you know how. :)
( http://www.oopo.net/psp/namco-gameshare-adhoc.data.gz )
Using tcpdump, you can replay captures from a file with the -r option. As ethereal is essentially a front end to tcpdump, I'm sure you can do the same. Load it up and view it however you want.
Thanks.
Its a bit confusing that your username doesnt appear in .eng format. I'll start analyzing this, and maybe I'll do the same thing (capture) of namco (if I get the game) or of another game to compare it versus your results.
I like ethereal because it breaks down the protocols used within. Also Namco's sharing is different from Lumines - alot more data involved. But the fact that they both use a similiar starting header argues that there is an API for the sharing. I.e. one API for sharing a game, and another API for multiplayer games that both have the same basic protocol.
I'm getting tired, so forgive me if I start spouting nonsense. :)
Its a bit confusing that your username doesnt appear in .eng format. I'll start analyzing this, and maybe I'll do the same thing (capture) of namco (if I get the game) or of another game to compare it versus your results.
I like ethereal because it breaks down the protocols used within. Also Namco's sharing is different from Lumines - alot more data involved. But the fact that they both use a similiar starting header argues that there is an API for the sharing. I.e. one API for sharing a game, and another API for multiplayer games that both have the same basic protocol.
I'm getting tired, so forgive me if I start spouting nonsense. :)
-
threeballspin
- Posts: 7
- Joined: Thu Apr 21, 2005 8:17 pm
- Location: Colorado