PSP to Computer AD HOC

[tilkinsc]

How does the PPSSPP and PSP ad hoc system work?

Is it possible to pair a device to a computer? What if the computer broadcasted a network? A lot of PSP games had an infrastructure mode in which would let two devices communicate over a network. This would be a cool addition feature to what has been worked on recently aside from graphical bugs.

[JacobMrox]

@adenovan, not a huge issue, we have some and other ways to still sniff them.

[tilkinsc]

@adenovan thank you I appreciate the contribution.

[tilkinsc]

So I know for sure that the PPSSPP requires the hardware to talk to it using its very own protocol. The file C:\Windows\System32\drivers\etc\protocol may be of use. However, I have not figured out how to write such a protocol.

The process goes like this after all: PSP creates standard Ad Hoc network, PSP finds Ad Hoc network and tries to connect to it by sending its very own protocol (IP/UDP/TCP, but a new one of these) request. If I can do this, I can mimic the two devices interacting with each other by debugging the core two responses from a PSP->existing network and existing network -> PSP.

The only reason I am stumped is I lack ability to send a correct message from the PC to the PSP. It should be almost exactly like how a PSP asks to join the existing Ad Hoc network.

https://docs.microsoft.com/en-us/windows-hardware/drivers/network/ndis-protocol-drivers2

I think the first step to actually doing this is create only a relay in that we can use the computer as a PSP but it actually reroutes EVERYTHING to the other PSP.

[tilkinsc]

Here are my findings on the packets.

Windows tries its hardest to do DHCP and formal handshaking to set up negotiations. But PSP don't care.

Capture.zip

Let's review the packets.

My PSP Fat 1000 Specs: Mac - 00:16:FE:4F:EF:86 Nickname - P636 Firmware - 6.60 PRO-C System Language - English Date - 1/8/2011 1:37 AM

Test Game: Monster Hunter Freedom Unite English

The first 32 bytes of a packet are reserved for the PSP. This must be the packet descriptor. Each packet sent has data that changes and data that doesn't change. Most of this is constant. The first 16 bytes are always constant. Bytes 0x10 and 0x11 may change. In two different states.

State 1: I am not really sure what happens here. I am assuming I am missing an additional packet where 0x10 and 0x11 would be 0x00 0x0C. Between these kinds of packets 0x10 always increments by some number.

      | 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F |
0000  > FF FF FF FF FF FF 00 16 FE 4F EF 86 88 C8 00 02
0010  > 0F 0C 00 00 00 00 00 00 00 00 00 00 00 00 00 00

State 2: This is where bytes 0x10 and 0x11 are 0x01 0x02. After a 0x00 there exists your PSP name. Each of these packets are 166 bytes long and have the exact same contents. They happen every 5 or 7 packets. Probably only 5 due to timing :?

      | 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F |
0000  > FF FF FF FF FF FF 00 16 FE 4F EF 86 88 C8 00 01
0010  > 01 02 00 80 50 36 33 36 00 00 00 00 00 00 00 00   ....P636........

The delta between the increases on byte 0x10 between multiple packets make no sense. I don't see a clear pattern. At all. I don't want to rule out something to do with a formula and a for statement. As for the textual representation in hex it also doesn't make much sense. The number seems to rock back and forth though.

After these 32 bytes it's anyone's guess. This data doesn't say much and I can't find other packets with the same data sent between packets. Although, the packets don't go over 256 bytes in size. They can only be 96, 144, or 256 bytes.

Packet Sizes (Not including 166 byte State 2 packets): 96 bytes - 5 144 bytes - 7 256 bytes - 13 Total: 25 entries, 5 omitted which ensures my 'state 2 packet every 5 packets' theory

When I ran the two files through a similarity checker it didn't find anything between any of it besides the P636 nickname. I will do additional tests later to see if I can reproduce some changes to the 32 byte header, meaning if I changed the GH maybe.

I have coined together how to communicate between the two devices. I will program a test case for a PSP and put it to the test. Theory is using raw sockets and the mac address is known by these packets being sent every 5 seconds of the users in the area.

[anr2me]

So I know for sure that the PPSSPP requires the hardware to talk to it using its very own protocol. The file C:\Windows\System32\drivers\etc\protocol may be of use. However, I have not figured out how to write such a protocol.

The process goes like this after all: PSP creates standard Ad Hoc network, PSP finds Ad Hoc network and tries to connect to it by sending its very own protocol (IP/UDP/TCP, but a new one of these) request. If I can do this, I can mimic the two devices interacting with each other by debugging the core two responses from a PSP->existing network and existing network -> PSP.

The only reason I am stumped is I lack ability to send a correct message from the PC to the PSP. It should be almost exactly like how a PSP asks to join the existing Ad Hoc network.

https://docs.microsoft.com/en-us/windows-hardware/drivers/network/ndis-protocol-drivers2

I think the first step to actually doing this is create only a relay in that we can use the computer as a PSP but it actually reroutes EVERYTHING to the other PSP.

This is exactly what XLink Kai did :) and they need Promiscuous mode to do that.

https://en.wikipedia.org/wiki/Promiscuous_mode

In IEEE 802 networks such as Ethernet, token ring, and IEEE 802.11, and in FDDI, each frame includes a destination MAC address. In non-promiscuous mode, when a NIC receives a frame, it drops it unless the frame is addressed to that NIC's MAC address or is a broadcast or multicast addressed frame. In promiscuous mode, however, the NIC allows all frames through, thus allowing the computer to read frames intended for other machines or network devices.

Btw, if you want to analyze the packet isn't it better to use/create a simple adhoc homebrew than using a commercial game?

[tilkinsc]

Promiscuous mode nor xlinkkai isn't necessary at all. I know all but a few things now and its definitely possible without.

I said hi to the PSP :)

I changed the Mac Address of a state 2 packet to my adapter. I then sent a state 2 packet to Mac FF:FF:FF:FF:FF:FF just like the PSP did but I changed the name of P636 to something like Q636. The PSP responded with many packets.

[tilkinsc]

So heres how Ad Hoc works. Each PSP managers their own stuff, so its only locally done stuff. That's why MHFU has the limitation of client sided monsters. Anyways...

The PSP broadcasts indefinitely 5 unique size types of packets: 96, 144, 166, 256.

A 96 length packet is unknown and there is seemingly no respond to sending one of these out. A 144 length packet is a unknown and there is seemingly no respond to sending one of these out. A 166 length packet is a discovery packet, which is used to chain together negotiations between a PSP, and upon rebroadcast the PSP responds with a 326 length packet that has its broadcasting 166 packet in it (and ofc I swapped the P636 nick for Q636 where applicable), and upon receiving this 326 length packet it sends back a 292 length packet with no information being seen before. A 256 length packed is a unknown and there is seemingly no respond to sending one of these out.

Moreover in the State 2 packets being sent out, each response tier seems to ++ byte 0x11.

I found out the timings of sending of each packet. Or at least roughly the timings, as some have a delay before they are sent again.

96 - 2 sends with a 0.26 delay between then 2 second delay 144 - 1 send of 0.66 delay, with maybe no additional delay 166 - 1 send of 1 delay, with no additional delay 256 - 1 send of 0.26 delay, with maybe no additional delay

I have not observed any attempt of IPs being set up.

[anr2me]

So heres how Ad Hoc works. Each PSP managers their own stuff, so its only locally done stuff. That's why MHFU has the limitation of client sided monsters. Anyways...

The PSP broadcasts indefinitely 5 unique size types of packets: 96, 144, 166, 256.

A 96 length packet is unknown and there is seemingly no respond to sending one of these out. A 144 length packet is a unknown and there is seemingly no respond to sending one of these out. A 166 length packet is a discovery packet, which is used to chain together negotiations between a PSP, and upon rebroadcast the PSP responds with a 326 length packet that has its broadcasting 166 packet in it (and ofc I swapped the P636 nick for Q636 where applicable), and upon receiving this 326 length packet it sends back a 292 length packet with no information being seen before. A 256 length packed is a unknown and there is seemingly no respond to sending one of these out.

Moreover in the State 2 packets being sent out, each response tier seems to ++ byte 0x11.

I found out the timings of sending of each packet. Or at least roughly the timings, as some have a delay before they are sent again.

96 - 2 sends with a 0.26 delay between then 2 second delay 144 - 1 send of 0.66 delay, with maybe no additional delay 166 - 1 send of 1 delay, with no additional delay 256 - 1 send of 0.26 delay, with maybe no additional delay

I have not observed any attempt of IPs being set up. Isn't because PSP's Adhoc doesn't use IP to communicate between each other and only use MAC? PSP only use IP on Infrastructure mode, right?

[adenovan]

this 96, 144, 166, 256 packet is specific to mhfu game only the packet contain character name, model and bunch of other stuff. me personally really doesnt care about that packet it go throught pdpSend hle function which is broadcast packet on mhfu and each game has their unique packet size.

maybe you should only focus on 32bytes first packet there is the network scan and handshake implementation. psp only use mac address and port to do communications as long as you on same network and know the peer mac and port you can play together.

[tilkinsc]

I was actually wrong about it being 32 bytes. It is actually smaller than that. Something like 16 + <7 bytes. However, that clears some stuff up about what I have been viewing. I was originally confirming data transfer to the PSP in the first place (raw packet transfers are hard to figure out). I don't think that there is a handshake to begin with. MHFU communicates with peers through broadcasts and packets sent to specific MACs found being broadcast by the state 2 packet. I think the State 2 packet is a discovery packet. This means that it constantly is sent out to aid in the discovery of MACs. Each game could have their implementation of this though.

I will first need to be able to compile PPSSPP. This is my goal for now. Once I do that I can open up some sockets and gather some broadcast packets. I should be able to convert them into PPSSPP ready packets somehow.

[tilkinsc]

The types of packets we are dealing with are Ethernet Packets. This is what the basic component structure of an ethernet packet is...

[6 byte destination][6 byte source][2 byte protocol][blob data]

Ad Hoc is a connection-less network. Your NIC is likely to fake the connection of IPs using programs on your computer. This is namely done by Microsoft programs. So you wouldn't be able to 'get the PSPs IP' so to speak, because there isn't one in the first place. The PSPs don't have a handshake between PSP to PSP. They just appear in range and the program would reach out and connect depending on the broadcasting packet. The MAC is found this way also. I have no clue how the ports work though. They might have a unique identifier system for that.

So basically you just need to write a packet router so that PPSSPP can speak to the PSP. It should already be set up if the packets are the same. As for the game 'ports', this should be emulated publicly and broadcasted in the same manor as any other packet I have seen so far. This would be PSP bios.

I have confirmed that state 2 packet with length 166 is standard between games. Twisted Metal Head On (TMHO) is broadcasting the same exact packet. The only difference between MHFU and TMHO is that it is memset with FF at first. OR, since 0x90-0x93 is 0xFF, MHFU memsets a sub range inside the packet with 0x00.

[anr2me]

Port is part of Protocol header.

Btw, have you checked & analyze all the structs of adhoc server emulation? it's suppose to emulate a PSP's adhoc communication, so all those structs being used by adhoc should give enough info of what's in the raw packet headers being sent/recv by PSP, although it's wrapped in TCP/IP or UDP/IP due to emulation, but the raw struct should be the same one used by a real PSP.

[tilkinsc]

Could you drop me some sources?

[anr2me]

Could you drop me some sources?

It's there included in PPSSPP source, but if you want the standalone version you can get it here https://github.com/MrColdbird/aemu

[tilkinsc]

PPSSPP source is everywhere. I can't really tell what's going on anywhere from a glance. I will check this over and extract what information I can.

From a first glance it looks like the discover section is completely blank. Therefore I don't think I am going to find any struct data here that is relevant. To the state 2 packets. This is what I am after.

[adenovan]

only focus on 3 source file, look on proadhoc.h, proadhoc.cpp and scenetadhoc.cpp the source of discovery emulation mostly in hle function that have CTL name. ex : SceNetAdhocctl, ctl = computational tree logic.

[tilkinsc]

Ok I know enough to get started on writing test cases for data sniffing in the packets. I don't know all the ad hoc functions I need to create a test case though. I asked hrydgard for a functions list but he prolly ignored this post and deletes it in his email.

So I will take a look at learning some of this stuff.

[theAkito]

What's the status of this today?

[adenovan]

without cfw looks like no luck on psp side unless we know more information by reversing on the wlan hardware and the default encryption used on psp side to do adhoc , beside of that many sceNet , sceNetAdhocctl , sceNetAdhocMatching still not properly tested to document all the apis how its work.

[tilkinsc]

I could very well do this. I don't own two PSPs so that is my current roadblock.

[adenovan]

well then im thingking too much on host machine actually that running windows or android we need dynamic ssid on first step

PSP adhoc network is open wireless without password after all

SSID prefixed with PSP_A(GAMEID)L(CONTROLNAME)

when creating much test i found some driver crash captured by psplink maybe usefull

Thread ID - 0x02F47E49
Th Name   - SceWlanMac
Module ID - 0x02F5F231
Mod Name  - sceWlan_Driver
EPC       - 0x88198408
Cause     - 0x10000010
BadVAddr  - 0x8002013A
Status    - 0x00088603
zr:0x00000000 at:0x00000001 v0:0x8002013A v1:0x10000020
a0:0x881BD488 a1:0x881B4FE8 a2:0x00000070 a3:0x0000002D
t0:0xFFFFFFC8 t1:0x881B4FD0 t2:0xFFFFFFE8 t3:0x00000017
t4:0xA8020054 t5:0x00010000 t6:0x881B4F20 t7:0x88017028
s0:0x881B4FE8 s1:0x00000070 s2:0x881B4FE8 s3:0x881BD488
s4:0x0000002D s5:0xFFFFFFC8 s6:0x00000000 s7:0xFFFFFFFF
t8:0x00000001 t9:0x881B4F18 k0:0x00000000 k1:0x00000000
gp:0x881B5290 sp:0x882F2BC0 fp:0x00040000 ra:0x88198408
0x88198408: 0x8C430000 '..C.' - lw         $v1, 0($v0)

[ghost]

There is still hope for infrastructure/PSN emulation : https://www.youtube.com/watch?v=G7uvDFSw6A0 It's for ps3 but it might be similar to how PSP does it too.

[anr2me]

There is still hope for infrastructure/PSN emulation : https://www.youtube.com/watch?v=G7uvDFSw6A0 It's for ps3 but it might be similar to how PSP does it too.

Currently only support matchmaking for P2P multiplayer (probably similar to AdhocServer), while a true infrastructure mode (ie. Client-Server mode) relies on dedicated server hosted by each publisher, right? thus requires a private server (ie. DeSSE) for each game if the publisher are no longer hosting it.

But knowing how PSN authentication works like this might help in PSP network emulation (ie. implementation of sceNp) too probably, even though it will only support P2P over the internet similar to Adhoc emulation with Adhoc Server. I think games like Patapon 3 doesn't relies on dedicated server on infrastructure mode (since you can choose as Host/Join on infrastructure mode), thus might works as long we can do the matchmaking on PSN emulation.

[tilkinsc]

This is nothing AdhocServer isn't doing. Thusly, infrastructure mode on the PSP had nothing to do with P2P connections, there was always a matchmaking server - lest everyone had to port forward their router to allow PSP IP connections inbound and outbound.

This thread is for Ad Hoc only. It is already bloated as is.

Oh and for the record, I already created a program to join PPSSPP thru matchmaking only thru pure ad hoc, on the game twisted metal.

[anr2me]

Oh and for the record, I already created a program to join PPSSPP thru matchmaking only thru pure ad hoc, on the game twisted metal.

That's pretty cool if you're able to communicate using pure adhoc (ie. real PTP/PDP protocol instead of emulated one using TCP/UDP). Are you using NPcap to send/recv the packet? Are those packets encrypted?

[tilkinsc]

PTP/PDP is just fancy talk. Protocols are just formats of raw packets i.e. they are typically just headers. TCP is a packet format standard aswell. Think of it like the 54 byte header to BMP files. The fact you call it PTP or PDP is meaningless, but as for how they are sent - thats useful. A TCP protocol will keep connections alive. A UDP just throws packets out as if it may never reach the destination. An IP protocol is just like UDP in the regard. Remember, the stack looks like this, raw -> IP -> UDP , raw -> IP -> TCP. Every UDP, TCP, and PTP, PDP packets have IP headers in that regard.

The packets sent and received are thru direct broadcast exclusively aka 'ethernet' (no, not your rj45 cable). You have to talk to the devices manually yourself with specific attention to the IP header. It's really easier done than said.

The packets themselves are not encrypted. The contents can be encrypted as the contents are 'implementation defined'. In my test case scenario, I joined the PSP lobby thru sheer packet sniffing and duplication followed by modification of the destination and sender fields of the IP header. Easy stuff.

As I only have one PSP, I can't tell what the specifics they share when connecting together are to mimic it. It will always be flawed because I can't then mimic the behavior in PPSSPP code.

[anr2me]

Ah i see, i guess you are using CFW-PRO? where sceNet* API already replaced with a wrapper for TCP/UDP so that it can be used on adhoc server over the internet, while the real adhoc protocol on PSP (ie. PDP/PTP) doesn't contains an IP and only use MAC. If it is like that i think you're trying to reinventing the wheel (ie. adhoc server/aemu/pro-online project), unlike XLink Kai which is dealing with a true PDP/PTP protocol (ie. using promiscuous mode) that can works with OFW, but due to the encryption on the wireless adapter hardware, it doesn't know the contents of the packet and can only pass it through to the other side over the internet by wrapping it with TCP/UDP.

[tilkinsc]

Ah i see, i guess you are using CFW-PRO? where sceNet* API already replaced with a wrapper for TCP/UDP so that it can be used on adhoc server over the internet, while the real adhoc protocol on PSP (ie. PDP/PTP) doesn't contains an IP and only use MAC.

No. PDP/PTP implements IP headers, but a modified format. I haven't deciphered it all. Like I said, though, all of it is sent thru broadcasting aka 'ethernet' so there is never an exchange of ip address - just MAC. Any old wireless adapter can send out a raw packet into the air for a MAC to pick up. 802.11 is a standard, 802.11b 802.11g etc are implementations of that standard, 802.11b can talk with 802.11g. So its not difficult to do - and yes you should buy hardware that can supports the device. I know that both my old acer laptop and my netgear WNDA4100 both work with the PSP.

If it is like that i think you're trying to reinventing the wheel (ie. adhoc server/aemu/pro-online project), unlike XLink Kai which is dealing with a true PDP/PTP protocol (ie. using promiscuous mode)

You seem to forget the original intent of developing this software - I am trying to connect a PSP with a PC and interface with PPSSPP. Nothing more. Nothing less. Promicuous mode is only needed to sniff the packets for understanding what is going on in the immediate exchange to keep the PSP linked to the PC. From here on out I will not reply to anything including xlink kai - it is irrelevant to my purpose. There is no encryption between my products used for testing. The packets are sniffed fully. The data is readable. Games understand the packet data - encrypted or not. The only thing that matters is the packet headers and what the fields mean, when to send them out, and anything else.

Here is a diagram:

Perhaps I am trying to say is I am wanting to implement a driver which natively interfaces with the PSP and PPSSPP condones to the standard.

[adenovan]

@tilkinsc for you to analyze , its between vita , brite 3000 , psp-go adhoc broadcast over channel 6

adhoc_sniff.zip

[tilkinsc]

The packets seem to be missing the data attached to the packet. Anyways, it wouldn't be much help to me because I lack a development environment. Good news though, I just cashed in my CurseForge mod money and some money into a secondary psp 3000. I have both 1000 and 3000 now. It should be arriving Sept 3. -> Sept 9. and I will have a play with it then.

[adenovan]

most of the data is on llc layer ,

broadcom adapter lost almost all of packet transmitted even its near the wireless range thats why on the first attempt only wireless beacon shown.

I use usb stick adapter on 01.pcap as old as psp wireless adapter and the game packet is there

[tilkinsc]

It will be easier to parse it myself. I've already done some super cool things using a script talking to a psp. So I can't wait to actually jump into this project, knowing I understand a lot of it. Add this to my list of 30 things I am trying to do at once :)

Update: PSP Arrive 8/31 by 8pm

Update: The PSP was last used in 2009. They were a furry. I'm setting up the PSP to be ready for testing! Sadly, they are charging and I got CFW set up in the meanwhile. Going to get WireShark again and set up my modem setup.

[ghost]

This is very nice I hope for good progress on this.

[ghost]

If you are still working on it. JPCSP is getting more progress with emulating local wireless/adhoc like a real psp would over HLE : https://github.com/jpcsp/jpcsp/commits/master Even got how the encryption works over wlan somewhat.

[adenovan]

drop resource on dfa the key

https://www.youtube.com/watch?v=LxCd80cYdOw&feature=youtu.be

[tilkinsc]

The project is going really well. I got a PSP talking with a computer, which then translates it over to another PSP for testing purposes. The latency is extremely low (lower if it was connected to PPSSPP). It's basically a 'proxy' at this point which also modifies said packet's data (if I want to). I am probably not going to add anything to PPSSPP because that would involve a lot more work than I can handle in its current state. Perhaps once I am done playing around with the packets exchanged I can open source it.

And yes, the computer is directly connected to the PSP. I have implemented the computer as being another player, which the fruit of it is another character spawns and acts exactly like another player.

[tilkinsc]

So I figured I would come back to this post after some time.

PPSSPP is accurately fit to support PC -> PSP communication. In fact, anyone could code a simple mechanism for it as long as they know they are doing. However, PPSSPP is missing a few settings and a bit of code to make this possible.

What's missing is the ability to communicate with PPSSPP's network through an auxiliary pipe. PPSSPP has a high level interface rooted in code derived from coldbird designed to communicate between PPSSPP instances and therefore one would have to design around its structure in the middleware that would connect PPSSPP to a PSP. In fact, middleware can be easily adopted.

Second there needs to be middleware; an exchange server. Or have this built in to PPSSPP. The exchange server is vital due to handling the transfer of packet to and from each device as well as handling packet decryption.

In order to transfer packets you will need to perform packet sending using the (raw) Ethernet protocol. https://wiki.wireshark.org/Ethernet This is layer 1 - Network Access Layer. In which a packet looks something like this. Note that this is 802.11b. The frame control always states that this is a broadcast packet, as well with the other packets but that can change.

[Omitted][MAC_ADDRESS addr1 6 bytes][MAC_ADDRESS addr2 6 bytes][MAC_ADDRESS addr3 6 bytes][MAC_ADDRESS addr4 6 bytes][Frame Control 2 bytes][Duration 2 bytes][RA 6 bytes][TA 6 bytes][BLOB][CRC 4 bytes]

This looks reminiscent of our PSP packet. Except our header is 32 bytes long. Which looks like this,

[Omitted][MAC_ADDRESS addr1_recipient 6 bytes][MAC_ADDRESS addr2_sender 6 bytes][Frame Control 2 bytes][Duration 2 bytes][unknown decrypted blob 16 bytes][Data BLOB]

In the omitted section, you have,

[Preamble][PLCP Header]

Which contain the length of the packet, singaling of frames, and CRC of it. Not important as its taken care by the upper layer.

This additional 16 byte section of a repurposed header is pretty strange. Firstly byte F:00 alternates in a pattern seemingly random. However, it is actually a counter probably a frame counter. Byte F:01 is also always 0c. It contains important information used by the device in firmware like P363 which was the PSP name in question in this packet

0000   ff ff ff ff ff ff 00 16 fe 4f ef 86 88 c8 00 01   .........O......
0010   01 02 00 80 50 36 33 36 00 00 00 00 00 00 00 00   ....P636........
0020   00 00 00 00 62 88 00 00 00 00 00 00 00 00 00 00   ....b...........
0030   00 00 00 00 0c 3b d9 09 9c 3c d9 09 34 8a d9 09   .....;...<..4...
0040   94 3c d9 09 02 00 00 00 00 00 00 00 00 00 0b 00   .<..............
0050   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0060   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0070   00 00 00 00 98 4b d9 09 00 00 00 00 00 00 00 00   .....K..........
0080   01 00 00 00 00 00 00 00 06 00 00 00 64 00 00 00   ............d...
0090   ff ff ff ff 01 04 10 00 06 06 02 04 10 00 00 05   ................
00a0   03 04 00 00 00 00   

Further, broadcast packets are encrypted and use time as the IV probably, as two packets are never equivocal even though the same data is sent. I also know this much due to the PSP following a modified join packet scenario I set up for additional packet production using Twisted Metal. So that you cant analyze how the numbers look and see an ascii looking picture if a raw bmp was sent for instance. Groundbreaking for it's time, really. KIRK has an AES-128 key vault of 128 keys and 1 master key so finding those out and trying to use them may prove fruitful - it wouldn't be wrong for the byte F:00 to point to a key in the keystore. It also uses something called ECDSA which is asymmetric which is proprietary encryption and verification. SHA-1 but that isn't to be reversed. It's anybody's guess. I bet my apples on the F:00 due to the above packet being the same between the same packets or perhaps its just that its raw. https://playstationdev.wiki/pspdevwiki/index.php?title=Keys It's handled at the kernel level, as PPSSPP has no such issues.

Good luck! If anyone can point me to a kernel code dump in assembly that would be wonderful.

[ghost]

IMO someone will need to adapt what JPCSP does because it connects to the PSP in the low level (its basically adapts it machine code wise like you want). You can even use the JPCSP's debugger to see what it does there. Actually by being low level you actually lose more compatibility but you get more accurate results to the console if you talk about internet play (but local play will be the same somewhat). Problem is most of the code on PPSSPP is on the high level. The best middlware is xlink kai currently btw and thats what JPCSP uses to communicate with the PSP. It uses something called the DDS protocol: https://www.teamxlink.co.uk/wiki/DDS_Protocol Someone could create their own one though if they desire I guess (There is also Adhoc Party but you need a PS3 for that ofc).

[tilkinsc]

By the way middleware is cut completely out. If PPSSPP had the ability to emit its network packets to a socket or something, that socket can be read and a program can listen to that and emit that as an ethernet packet. This would bridge our gap. However, my shortcoming was the lack of this and I don't have any desire to program something like that. The code to do what I say here is probably less than 100 lines of code as its a simple repeater once the data is made available.

[anr2me]

Regardless the low level raw packets issue, even the high level packets generated by PPSSPP are different than what PSP generate. Since PPSSPP only support packets generated/used by pro-online (which is a simplified version) it will never be compatible with PSP (unless when using pro-online plugin of course), except for games that only use low level API and dealt with PTP/PDP socket directly without using high level API such as AdhocMatching, and also GameMode API (i'm not sure whether GameMode is high level API or not as it use a different way of communication by using undocumented internal syscalls, most-likely have access to beacons, and not supported by legacy pro-online)

For example, packet generated for AdhocMatching (which is used by many games) communication, pro-online is using a simple structure: [opcode][data/mac][optional data] while a real PSP use a more complex structure, containing sections (header, body, footer), and each section contains data (data type + data value), similar to the structure used for X-I-5 Ticket (but only contains a few data) https://www.psdevwiki.com/ps3/X-I-5-Ticket#Composition Even the handshaking implemented by pro-online is being forced by using a faked ACK, regardless whether the packet really successfully sent or not.

The only way to get a fully compatible high level packets & communication is by using prx files from official firmware (which is not going to be supported by PPSSPP any time soon, or may be ever)

Anyway, this issue should be covered by implementing XLink Kai which is already matured instead of creating something similar from scratch, but due to incompatible high level packets generated by PPSSPP/pro-online and the lack of raw socket support, this can't be implemented yet.

[tilkinsc]

I was under the impression that they packets other than the ones the OS would handle (ack) were simplistic packets. Its been a long time since I've attempted to do any development with this. Perhaps I can tee off of pro-online and implement packet translation as a work around. My problem is getting the data. Using xlink kai and pro online isn't the point of this issue.

[anr2me]

I was under the impression that they packets other than the ones the OS would handle (ack) were simplistic packets.

This is true for PTP (TCP) protocol, while AdhocMatching is using PDP (UDP) and implement it's own handshaking.

[adenovan]

its Ethernet Layer, to change ssid configuration as the game request to create network with some pattern we know , if its not same ssid and same repeat of beacon its will not discoverable by the PSP , its expensive operation on adhoc part just to discover each peers on the network it has their limitation of distance also.

for the first part you need to configure adapter like this PSP_A(GAMEID)L(CONTROLNAME/GROUPNAME) , implementing this to commercial wifi adapter on strict operating system that did not has root access or allow to configure its wlan adapter freely is an headache because what sdk is under operation system you want to use changing SSID name like the game request, except you has a root level adapter permission or promiscious mode or as driver of wlan adapter to do that set the ssid like the pattern on the game. then set the adapter channel to match psp one if you do it correctly it will be seens as peer this must through code not user set it manually if it can do a code like that.

its will start transfering encrypted beacon to you which the encryption is not fully broken also on kirk decode some of the packet i dont want to waste time on that cause im to lazy broke an encyrption and decode encode it if you want to do that way just implement the driver that can change SSID of WiFi Adapter first then we will know what rest to do.

[hrydgard]

@AccountGc Stop spamming the same question everywhere . https://www.ppsspp.org/getgames/

[tilkinsc]

Ah I was really excited for someone to have contributed to this.

[AccountGc]

@AccountGc Stop spamming the same question everywhere . https://www.ppsspp.org/getgames/

ok thanks

[Double-0-seven7]

Ah I was really excited for someone to have contributed to this.

its Ethernet Layer, to change ssid configuration as the game request to create network with some pattern we know , if its not same ssid and same repeat of beacon its will not discoverable by the PSP , its expensive operation on adhoc part just to discover each peers on the network it has their limitation of distance also.

for the first part you need to configure adapter like this PSP_A(GAMEID)L(CONTROLNAME/GROUPNAME) , implementing this to commercial wifi adapter on strict operating system that did not has root access or allow to configure its wlan adapter freely is an headache because what sdk is under operation system you want to use changing SSID name like the game request, except you has a root level adapter permission or promiscious mode or as driver of wlan adapter to do that set the ssid like the pattern on the game. then set the adapter channel to match psp one if you do it correctly it will be seens as peer this must through code not user set it manually if it can do a code like that.

its will start transfering encrypted beacon to you which the encryption is not fully broken also on kirk decode some of the packet i dont want to waste time on that cause im to lazy broke an encyrption and decode encode it if you want to do that way just implement the driver that can change SSID of WiFi Adapter first then we will know what rest to do.

The PSP KIRK engine got reverse engineered recently so its just a matter of time for getting the adhoc encryption to be understood as well. It's handheld by the memab module.