PSP Namco museum transfer

[Oobles]

The guys at psp.wtfwasthat.com grabbed an ethereal capture of a PSP Namco museum transfer in their goal of running linux on the PSP. Just after doing that they gave up researching the logs because Sony use a proprietry protocol. Just for fun I thought I'd have a look and see what I could see. The log is available from their site. This is what I found.

First thing I searched on was the ethernet protocol type. 0x88c8. I found this site. http://standards.ieee.org/regauth/ethertype/eth.txt which describes the protocol as Sony's:

"In our protocol, only one field must be required. It is two byte "sub-type" field. We manage this sub-type and assign it to each application. Acutual protocol in each application may be vary. If sub-type is allocated, its protocol and data format can be freely designed."

From this little bit of info we can see that the log has two protocol sub types. 00 01 and 00 02. The actual game transfer uses 00 02. If you look at the pattern of packets you will see that 00 02 looks suspicously like TCP. A sliding window protocol. The 50byte confirmation packets also contain a non-encrypted packet number.

If you look at the pattern of packets for 00 01 and where they happen. It looks like this is a key agreement protocol. I think its safe to assume that as 00 02 packets only start after what looks to be mutual key agreement, that this key is used for all 00 02 traffic.

The 00 01 protocol seems to have another sub-type. Only 01 seems to be present. After that a key stage identifies what stage of the key agreement the two sides are up to.

Lets take a closer look. I'll call the PSP 2a and 51 after the start of their MAC address. The log goes as follows:

1-23: 2a broadcasts its presence looksing for another PSP. 00 01 01 02. The end of the packet looks like a null terminated string with padding ff at the end.

24: 51 replies. with 00 01 01 03. Includes its name "Keck Lab" in the data.
25: 2a responds back. with 00 01 01 04.
26: 51 replies. with 00 01 01 05.
27: 2a response back. with 00 01 01 06.

28: 51 starts broadcasting the same as 2a did in messages 1-23.
29: 2a continues its original broadcast looking for other PSPs.
32: The first message of 00 02 type from PSP 51. However these are broadcast packets. Possibly similar to UDP? As 51 eventually sends its game to 2A, we can possibly assume this is broadcasts of what is available to send.

The above broadcasts continue until.

112: 2a sends packet with 00 01 01 08.
113: 51 response back with the same packet. 00 01 01 08. This seems to complete the key agreement for one direction.

129: 51 sends a 00 01 01 07.
153: 2a sends a 00 01 01 07.

The key agreement seems to go in the other direction with the following:

178: 2a response to 51 broadcast with 00 01 01 03
179: 51 response to 2a with 00 01 01 04
180: 2a responds with 00 01 01 05
181: 51 resposne with 00 01 01 06

From there a proper TCP like connection is started over protocol 00 02.

The question is can a man in the middle attack be accomplished? Lets assume that this key exchange protocol has some basis in SSL which uses the Diffie-Hellman algorithm. A quick google finds:

http://www.rsasecurity.com/rsalabs/node.asp?id=2248

The interesting bit is that Diffie-Hellman is suseptable to man in the middle attacks. Of course you still need to know what algorithm they are using. If however they are smart enough to also use a digital signature then this attack may not be possible.

I didn't get any more time to look closer at the key agreement messages, but its a start. I'd be interesting in any other peoples thoughts.

Oobles.

[Oobles]

Protocol 00 01 also contains the length of the packet. Seems redundant, but if you look at legs 3,4,5,6. They all contain the length. From the first key agreements.

<protocol>00 01 <type>01 <leg>03 <size>01 20 .....

<protocol>00 01 <type>01 <leg>04 <size>01 10 .....

<protocol>00 01 <type>01 <leg>05 <size>01 00 .....

<protocol>00 01 <type>01 <leg>06 <size>00 60 .....

I also noticed that the lengths of packets are the same for key agreement in both directions. 294, 278, 262, 102. The lengths of the first two packets look suspicously long for *just* key agreement. It does need more analysis before we can say for sure though.

Enough for me tonight..
Oobles.

[Kamilion]

Glad I lit a fire under someone ^_^

[Oobles]

If anyone is able to perform this type of capture of sending a game between two PSPs. Can they do it and provide some commentry about what they did to each PSP and when. ie.. use a watch and record what you pressed and what each of the PSPs did. This can then be correlated with the log recorded.

If you can.. give each of the PSPs a long ASCII network name. This should show up in the first packets and possibly elseware. At the moment I'm only interested in the packets leading up to the transfer; not the transfer itself.

I don't have a PSP.. let alone two. So any help would be appreciated. This may still be a complete deadend, but definately worth analysing further.

Oobles.

[Oobles]

This was posted by Cheetah in another thread. Looks like its useful information for this thread.

http://www.rsasecurity.com/press_releas ... oc_id=5648

more info..

http://quimby.gnus.org/internet-drafts/ ... afe-00.txt

and BSafe implementation..

https://www.cypherpunks.to/bsafeeay/

Still no idea if this is related though.

[Oobles]

And just because I like replying to myself. Could the key agreement transaction look something like the Host Identity Protocol?

http://www.hip4inter.net/documentation/ ... se-02.html

[jimbo]

I noticed the WipeOut "Broadcast Mode" for the first time last night, under Profile->Records. There's a "Receive Stats" mode too, perhaps this traffic is worth sniffing as well.

[ooPo]

Ahh yes, the merge stats stuff... that's the other thing I meant to take a look at.

[jimbo]

I noticed the WipeOut "Broadcast Mode" for the first time last night, under Profile->Records. There's a "Receive Stats" mode too, perhaps this traffic is worth sniffing as well.

[ooPo]

Some captures I did tonight. They're probably wrong as I'm working with a wireless card with unsupported firmware for monitor mode. Bleh.

http://www.oopo.net/psp/namco-gameshare.data

http://www.oopo.net/psp/wipeout-savemerge.data

http://www.oopo.net/psp/wipeout-multiplayer.data

I think the 'keck lab' you were seeing may be noise from a nearby access point. Never once have I been able to see the nicknames from the two PSPs.

[ooPo]

Ok, after I thought about it for a moment I came up with a new capture.

http://www.oopo.net/psp/namco-gameshare-adhoc.data.gz

Sniffing in monitor mode was just giving me the essid they were on. This time I switched to ad-hoc mode, joined the right essid/channel, and data was captured that is similar to the other one, so... nevermind.

The two nicknames were ooPo and ooPo2, which don't show up in the dump. Strange...

[cheetah]

Has anyone messed with the psp online protocol? I have been replaying packets to login to the Twisted Metal game lobby. None of the communications look to be encrypted to me. I would post my code and dumps but I'm pretty sure my serial number or a unique id is being passed.

Here is a link to a socument about the PS2 online game lobby structure. http://www.scee.sony.co.uk/sceesite/fil ... etwork.pdf

From observing packets, I think the PSP online game lobbies are identical to the PS2. With twisted metal, first a connection is opened on port 10075 then a connection is opened to some kind on authentication server. I think its the MAS Medius Authentication Server as decscribed in the pdf. The protocl looks similar to gamespys game server protcol. Each packet has a 2 byte header then a null byte. Most packets are followed by a 2 byte number that is incremented in the response packet. The other thing you will notice is in the first few packets a sequence number is assigned from the game lobby server. That number is merely a sequential sequence number. If you disconnect your tcp session and create a new once, the number will increase by one or a small numebr(since sequence numbers are being handed out to real gamers too). The sequence number is used repeatedly throughout the session.

Why would anyone do this anyway? Well, to make a cool server browser to keep track of your friends playing online or to use the game lobby as a personal chat room.

[cheetah]

oops lost my train of thought. But what I was trying to say was, the PSP online game protocol doesn't appear to be encrypted. If a serial number or unique id is being passed, by reversing the protocol, it would be possible to steal people's credentials if they were playing on an unwepped network or if one had the wep key. does anyone know of information about the game lobby protocol for the PS2? I think its the same thing.

[Oobles]

cheetah, I think you're looking to a different protocol from us. Sounds like you're connecting to an internet server. This is definately a different protocol to the adhoc networking captures we are looking at between two PSPs. It might be worth starting a new thread for that topic.

oopo, Are both your PSPs .jap versions? Look at the differences between packets 22 and 23. The location where the Keck Lab name was in the other capture is very similar between packets 22 and 23. Only the end is different. Could this be oopo and oopo2 in some kind of .jp UTF8 encoding?

The other interesting thing is that you only have one handshake. There must have been something else going on to create the two handshakes of the first capture I was looking at. This is a good thing because it means that the handshake is not so complex. :) Your capture also doesn't contain the other handshake packet types 07 and 08.

After the broadcast message, only the key exchange messages 03,04,05,06 are needed to establish a link. If we can work out whats in 03, the rest should be easy. ;)

Oobles.

[Oobles]

oopo, your encoding is definately .jp and is making the name of your PSPs look strange in the packets. Back to packet 22 and 23.

ef bd 8f = o
ef bc b0 = p
ef bc 92 = 2

you'll see that both names are there.

If you look at the packet type 03 (packet 17 in your capture). It has the following structure.

00 01 packet type for key exchange
01 sub type. maybe indicate algorithm.
03 stage of key agreement.
01 20 size of message
...160 characters unknown (1280 bits)...
...128 characters for the name (1024 bits)...

The unknown data doesn't seem to have any similarity between the three examples I've seen. It could be just a very big public key from Diffie-Hellman, but I doubt it. I'm guessing its encrypted. That requires that every PSP comes with a known symmetric key that is used to encrypt it. But.. it could be that the name of the PSP could be used part of a symmetric key. That would make sense and be good reason why the full 1024bits are transported and why the first reply also includes the full name of the replying PSP.


It would be interesting to see if between two PSPs that the exchange is repeatable. ie do the same packets appear. And if it is repeatable see what changes when the PSP name is changed.

Another experiment which would take a bit of coding is if a router could be developed. Capture all the packets from a wifi access point with Ethernet type 88c8 and transport them to another access point (on the other side of the globe) and broadcast them. Should'nt be too difficult to write.

Oobles.

[ooPo]

Doesn't software like xlink kai already do that? :)

Tonight I'll recapture the namco share to see if its the same. I'll also redo the wipeout savemerge and multiplayer captures now that I can do it correctly.

I currently have two japanese v1.0 psps, two copies of wipeout, a copy of namco classics (j), piposaru academy (j), ridge racers (j), lumines, ape escape, metal gear acid and darkstalkers chronicle. Any capture requests?

[Mawdsley]

I currently have two japanese v1.0 psps, two copies of wipeout, a copy of namco classics (j), piposaru academy (j), ridge racers (j), lumines, ape escape, metal gear acid and darkstalkers chronicle. Any capture requests?

A little off topic, but whats your wipeout browser user agent string on a v1 psp? Is it the same or different to a v1.5? Wondering if browser is on umd or hidden in the psp firmware.

[cheetah]

SCEJ PSP BROWSER 0102pspNavigator

[ooPo]

So, you take your favorite linux machine with a wireless card and type the following:

Code: Select all

iwconfig eth0 mode ad-hoc
iwconfig eth0 channel 6
iwconfig eth0 essid "PSP_S000000001_L_GameShar"
ifconfig eth0 up

Now you're ready to sniff or interact with the PSP in general. Using tcpdump, you should be able to capture packets. Or, using this:

Code: Select all

 #include <stdio.h>
 #include <sys/socket.h>

 int main&#40;int argc, char **argv&#41; &#123;
  int sock, size, loop0;
  unsigned char buffer&#91;65536&#93;;
  unsigned char from&#91;256&#93;; int fromlength;

  // Turn off stdout buffering.
  setbuf&#40;stdout, NULL&#41;;

  // Open the socket.
  sock = socket&#40;PF_PACKET, SOCK_DGRAM, 0x88C8&#41;;

  for &#40;;;&#41; &#123;

   // Listen for a packet.
   size = recvfrom&#40;sock, buffer, sizeof&#40;buffer&#41;, MSG_TRUNC, &#40;struct sockaddr *&#41;from, &fromlength&#41;;

   // Print out the packet information.
   printf&#40;"SIZE&#58; %x\n", size&#41;;
   printf&#40;"TYPE&#58; %02X%02X %02X%02X %02X%02X\n", buffer&#91;0&#93;, buffer&#91;1&#93;, buffer&#91;2&#93;, buffer&#91;3&#93;, buffer&#91;4&#93;, buffer&#91;5&#93;&#41;;
   printf&#40;"FROM&#58; "&#41;; for &#40;loop0=0;loop0<fromlength;loop0++&#41; &#123; printf&#40;"%X", from&#91;loop0&#93;&#41;; &#125; printf&#40;"\n\n"&#41;;
   printf&#40;"DATA&#58; "&#41;; for &#40;loop0=6;loop0<size;loop0++&#41; &#123; printf&#40;"%02X", buffer&#91;loop0&#93;&#41;; &#125; printf&#40;"\n\n"&#41;;

   // Clear the packet.
   memset&#40;buffer, 0xFF, sizeof&#40;buffer&#41;&#41;;

   // Populate the packet.
   buffer&#91;0&#93; = 0x00;    // protocol subtype
   buffer&#91;1&#93; = 0x01;
   buffer&#91;2&#93; = 0x01;    // data type
   buffer&#91;3&#93; = 0x02;
   buffer&#91;4&#93; = 0x00;    // data size
   buffer&#91;5&#93; = 0x80;
   sprintf&#40;&buffer&#91;6&#93;, "Test"&#41;;   // data payload

   // Send off the packet.
   sendto&#40;sock, buffer, 0x86, 0, &#40;struct sockaddr *&#41;from, fromlength&#41;;

  &#125;

  // End program.
  return 0;

 &#125;

You'll be able to see the packets as they're sent from the PSP, and attempt to respond. So, let's take a look at what we see. First, if we do not actually send a response:

Code: Select all

SIZE: 86
TYPE: 0001 0102 0080
FROM: 00:11:88:C8:00:00:00:02:00:01:01:06:00:01:4A:5A:74:ED:00:00:
DATA: EFBD8FEFBD8FEFBCB0EFBD8F00FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

(REPEATING UNTIL I HIT CANCEL)

SIZE: 32
TYPE: 0002 0000 0000
FROM: 00:11:88:C8:00:00:00:02:00:01:01:06:00:01:4A:5A:74:ED:00:00:
DATA: 00:00:00:00:00:00:00:00:00:00:00:00:90:6E:FF:0E:99:E4:24:2A:58:32:8D:9B:62:7A:D8:D7:B7:DD:0B:CA:75:B7:44:08:29:3C:6E:59:7B:00:82:F8:

SIZE: 26
TYPE: 0001 0107 0020
FROM: 00:11:88:C8:00:00:00:02:00:01:01:06:00:01:4A:5A:74:ED:00:00:
DATA: 01:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:D4:99:04:1D:BD:2B:3C:52:7A:67:FA:E3:03:B0:4D:DC:

Basically the PSP is broadcasting that it is there (the nickname was ooPo, btw), until I tell it to stop. Those last two packets are sent immediately when I hit cancel.

Now, if I actually respond with a 0001 0102 packet:

Code: Select all

SIZE: 86
TYPE: 0001 0102 0080
FROM: 00:11:88:C8:00:00:00:02:00:01:01:06:00:01:4A:5A:74:ED:00:00:
DATA: EFBD8FEFBD8FEFBCB0EFBD8F00FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

SIZE: 126
TYPE: 0001 0103 0120
FROM: 00:11:88:C8:00:00:00:02:00:01:00:06:00:01:4A:5A:74:ED:00:00:
DATA: 0769B8FB1514ECA8FDB42B0493B2E689A8C8C688E582783021C2DCD45E6BC4ACCF02FA7E9A1EA3C37C4FB630551C91FEBC10FEAB2501049701CF68858ACDFCE42CD6A3ECB2521AAD7F6DD2A6881C37
2D182E4B6050B8C96F7447E98435E658089B596572AA0DE4EB08E25AD7E7ACA58C5114462B5BD1531BBFCAA057435A52DED52A1288BF0192230344B2104EABAFDE948695A9FCBF34D24952A5C75CEA
DF9EEFBD8FEFBD8FEFBCB0EFBD8F00FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

SIZE: 126
TYPE: 0001 0103 0120
FROM: 00:11:88:C8:00:00:00:02:00:01:00:06:00:01:4A:5A:74:ED:00:00:
DATA: 0769B8FB1514ECA8FDB42B0493B2E689A8C8C688E582783021C2DCD45E6BC4ACCF02FA7E9A1EA3C37C4FB630551C91FEBC10FEAB2501049701CF68858ACDFCE42CD6A3ECB2521AAD7F6DD2A6881C37
2D182E4B6050B8C96F7447E98435E658089B596572AA0DE4EB08E25AD7E7ACA58C5114462B5BD1531BBFCAA057435A52DED52A1288BF0192230344B2104EABAFDE948695A9FCBF34D24952A5C75CEA
DF9EEFBD8FEFBD8FEFBCB0EFBD8F00FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

Basically a pattern of 0001 0102 (x1) 0001 0103 (x2), repeating every second or so.

So, spoof a 0001 0104 back? Well, its not so easy. It never did respond to any attempt I made, so I looked a bit harder. It seems the 0001 0103 data payload changes every two cycles. Here's a few examples:

Code: Select all

SIZE: 126
TYPE: 0001 0103 0120
FROM: 00:11:88:C8:00:00:00:02:00:01:00:06:00:01:4A:5A:74:ED:00:00:
DATA: 0769B8FB1514ECA8FDB42B0493B2E689A8C8C688E582783021C2DCD45E6BC4ACCF02FA7E9A1EA3C37C4FB630551C91FEBC10FEAB2501049701CF68858ACDFCE42CD6A3ECB2521AAD7F6DD2A6881C37
2D182E4B6050B8C96F7447E98435E658089B596572AA0DE4EB08E25AD7E7ACA58C5114462B5BD1531BBFCAA057435A52DED52A1288BF0192230344B2104EABAFDE948695A9FCBF34D24952A5C75CEA
DF9EEFBD8FEFBD8FEFBCB0EFBD8F00FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

SIZE: 126
TYPE: 0001 0103 0120
FROM: 00:11:88:C8:00:00:00:02:00:01:00:06:00:01:4A:5A:74:ED:00:00:
DATA: 88C38DB1C2E150EA032BBF4E9E83A63C050A2F8AC625EBF0ADEC8F5DD1DAA17EC3F065E8945D040E4EBDD09DB814C5005C11DB19AE929E30DAE532D769472CE612E9FEC552EA4676CF71F1DC247D6E
5E07E932F169D3A0C0E294C51D7BDFDF5ED59AD75B214168080AB8281C98C84101606AEB8B2706942C202D007AA4381F739ABB91B7FF16E7FBCB97D1E2A4DFD08BBEE2452C78F3FA1B19F467BD130A
C737EFBD8FEFBD8FEFBCB0EFBD8F00FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

SIZE: 126
TYPE: 0001 0103 0120
FROM: 00:11:88:C8:00:00:00:02:00:01:00:06:00:01:4A:5A:74:ED:00:00:
DATA: 97AE0AFD7053A5978C8B34F44ACDCD4459940D8247D29BB14A0F348147B06F3307462EFDA8CA276A4D24C4E374BCAE82C211767342AA8EC72581D4D3447768FD53D770B7C33880ED7CFFC8C4C42A9A
971686D75FEC8318D8019807AB55641BDF6A777FE80F9E83BBB434D2F6EDCA94746BE78CA192759BDFF08AE037E8519D3DAE2D39B5E4C818EA5B491FA4868391C9AF510C9C8464CC8C8ABF98C9E438
6F13EFBD8FEFBD8FEFBCB0EFBD8F00FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

SIZE: 126
TYPE: 0001 0103 0120
FROM: 00:11:88:C8:00:00:00:02:00:01:00:06:00:01:4A:5A:74:ED:00:00:
DATA: 3122F900865CF4F1CC1983DBB2BCD38BFA51421B0DD6476180F1629DFA172F247482D4B36562D3B155E66E2D926B9643B60C542EFC768DA1A8DFBE94DE8EA6370F07CD1AC33B44A2759E883E5643DA
07891D8192890D877669EDE0A780F1CB10038ABFB726439948E93A52FFED8EB33C4379D5A9A649596642E89AD84A30B0F136175D9B1B464013E09D0D1C9E47F1E2553D93965D4DC8C82E62093B2DAB
D243EFBD8FEFBD8FEFBCB0EFBD8F00FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

SIZE: 126
TYPE: 0001 0103 0120
FROM: 00:11:88:C8:00:00:00:02:00:01:00:06:00:01:4A:5A:74:ED:00:00:
DATA: 6BC5C4BD99F230EB10343572B1BD39B6063188E9182ED8171B1CDA6B61753ED8E7CAA15373AF6BFABC502924B1FADF212FD4A1E039C2B260387E6080A30A5DB730853D26DB63AC68631FCE454AF3EF
E91B40B94DE247ABD5F1F7870E11554A9E719CF12A2965F5E9C9E759B364887356BC13959D3FEE5549368D3964174BD031C2BF3FC2FA1ECA21D376204A99A6B9484C56A91BAC68AA5A8B0E6EE4EA18
A86BEFBD8FEFBD8FEFBCB0EFBD8F00FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

A weird blob of data that changes once per second. Take that as you will.

Oh! A few words about that FROM line.

Code: Select all

FROM: 00:11:88:C8:00:00:00:02:00:01:01:06:00:01:4A:5A:74:ED:00:00:
FROM: 00:11:88:C8:00:00:00:02:00:01:00:06:00:01:4A:5A:74:ED:00:00:

00:11 - ???
88:C8 - The protocol sony uses.
00:00 - ???
00:00 - ???
02:00 - ???
01:xx - 01:01 for 0001 0102 packets, but 01:00 for 0001 0103 packets
00:06 - ???
00:01:4A:5A:74:ED - The psp's mac address.
00:00 - ???

That's the actual header from the 0x88C8 packet type, basically sitting at what would be the IP layer in a normal, internet (AF_INET) packet. Perhaps it has some tasty information I'm missing.

I ran out of time to play with this tonight, so I figured I'd share what I have so far and see if someone else can figure it out before I pick it up again.

[ooPo]

I should add that this was from a psp in the standard browser, using the option under Game->Game Sharing. I was hoping to spoof a game showing up in the list. Next I'll see if I can spoof a game share request to a psp running the game itself.

[mharris]

A weird blob of data that changes once per second. Take that as you will.

This is probably part of the crypto handshake. My guess is that it's probably either sending a salt or a block-cypher key, possibly encrypted with its private key (and therefore decryptable by using its public key), in which case the public key would probably be part of this message too.

I spent a few hours looking at it with Ethereal, and that was my conclusion (and by "conclusion," I mean "best guess"). It looks vaguely similar to the HTTPS protocol, but I suspect it might be subtly different.

[PspPet]

Commentary:
Promising, however the usefulness will be limited if Sony does the obvious thing of encrypting the code transfered between the two PSPs (ie. the actual data bits sent inside the custom transfer protocol)

[[ Ignoring the software pirating and website or netstats spoofing applications, the interesting case is the feature of transfering runnable code from one PSP to another (currently only supported by the Japanese Namco Museum AFAIK) ]]

The memory stick loader includes signed and encrypted binaries (EBOOT.PBP) for games as well as flash ROM update
Heck they even sign and encrypt their Game Save data.

I would be surprised if the Sony programmers left such a gaping hole in the technology and assumed that the tranfer protocol encryption was good enough

[ooPo]

Perhaps, but it doesn't hurt to look.

[vvuk]

I don't own a copy of Namco Museum (yet, I think; fry's had a jp import last time I was there, I'll have to pick it up), but I attempted to repeat some of the findings.

If I send my PSP the 0x0103 packet that was in ooPo's namco gameshare capture, it responds with a 0x0104 packet; same packet each time. The response is different than the 0x0104 in the capture, though.

If I change the PSP name in the 0x0103 packet, I get back a completely different 0x0104 packet (but agian, the same one for each given 0x0103 input).

I then changed my PSP name to be the same one that ooPo's was broadcasting ("ooPo2", in the unicode jp codepage); different 0x0104.

There's only 4 pieces of data in play here at the time of the 0x0104 reply:

1) Sending PSP Mac Addr
2) Sending PSP Nickname ("ooPo" in the capture)
3) Receiving PSP Mac Addr
4) Receiving PSP Nickname ("ooPo2" in the capture)
5) The unknown 160 bytes in the 0x0103 message.

If we hold 2, 4, and 5 constant, the 0x0104 message changes; so, my guess is that it's the mac addresses that holds some sway into the encryption. I'll be hacking my little program to spoof ooPo's sending PSP mac addr as well shortly.

Edit: just repeated this, with forcing my own (sender) MAC address to be the same as in the capture -- the 0x0104 packet is different again. So, varying any of 1-4 results in a completely different 0x0104 packet. It would be nice to get a few ore transfer captures to see how the 160 bytes in the 0x0103 vary, but it sounds like this is a dead end -- figuring out how those 4 chunks of data are used (total 268 bytes) is probably going to be... difficult. (Somewhere out there a SCEA exec is pumping his fist in the air and saying "Score!")

On the flip side, it could be something as simple as a SHA1 hash of all 4 concatenated in some order :p

[ooPo]

If I get some free time this week I'll see about putting linux back on the ibook and get some more captures for you.

[geran]

If I get some free time this week I'll see about putting linux back on the ibook and get some more captures for you.

can't you make the captures under osX?

[ooPo]

As you're the third person to point this out to me since I last posted, I'll explain:

The ibook currently has neither osx nor linux on it.

[pedroleite]

How my god... you got the PSP OS XMB running on your iBook : ) <grin>

Hope you get back to Os X :)

[ooPo]

I was attempting a netbsd install, but it went poorly... so I decided to wait for tiger to finally come out.