Update communication_protocol.md

[professor-jonny]

major update from re of firmware and fuzzing interface.

The firmware is very telling as the c struct 's are there in plain view.

[agarmash]

An absolutely colossal work, hats off @professor-jonny !

What I'd really love is to have a bit more structure in this document. I believe it makes sense to first list the general info about the different packets in the "Packet Types" section, and for example, list that the payload of the " NETWORKS_LIST_RESPONSE" has an array of the network slots. The structure if the network slot can be described in a subsequent section and be cross-referenced. Also, having a bit more granular TOC would also be quite helpful, I believe there's a VSCode plugin that does that automatically.

Please let me know if I can help you with anything! Cheers!

[professor-jonny]

you are right it needs a refactor, for the time being while I'm still trying to decipher more stuff ill leave it as is and do a formal final, when I think I'm in a better place to do so.

I'm trying to make my c code statefull with structs so responses can be dynamic as I plan to port this to OpenWrt or esp32 but the Xbox hand shake throws a spanner in the works being as you connect to a network and the response alters and bam the xbox bumps you.

I have made my c program a four in one with:
Xbox emulator
(interactive shell to control adaptor)

Adaptor emulator
(emulate a semi stateful response system)

Bridge mode where Xbox and adaptor plugged into separate network ports.
(listen only no port mirroring required):

Hex upload to Xbox or adaptor
(This depending on direction uses the real xbon nounce and re calcs the hex payload as valid packet)

My code needs a refactor too as it has been altered chopped and changed lots of times every time i find out something new.

[professor-jonny]

An absolutely colossal work, hats off @professor-jonny !

What I'd really love is to have a bit more structure in this document. I believe it makes sense to first list the general info about the different packets in the "Packet Types" section, and for example, list that the payload of the " NETWORKS_LIST_RESPONSE" has an array of the network slots. The structure if the network slot can be described in a subsequent section and be cross-referenced. Also, having a bit more granular TOC would also be quite helpful, I believe there's a VSCode plugin that does that automatically.

Please let me know if I can help you with anything! Cheers!

If you could look over my work it would be great!!!, I think I have finished now, but some of it needs a second pair of eyes over it.
I have formatted the document better now as you suggested and now i think it is in a much more presentable state.
With the disassembly Ill export that and likely put in a pull request for that but for the time being I'm still getting enjoyment from unlocking it's secrets :-).

if i can figure out how of flash the device Ill try and enable the webpage and figure out the serial port connections as debug output will likely be handy going off the string table.

I have also sent you a pm on discord and sent some ghidra stuff to ponder over, I'm slowly continuing to onlock a bit more.

[professor-jonny]

I'm finished with adding protocol information now the info is complete to the point I have a working emulator in windows that is able to use your pc as an Xbox wireless adaptor and control the radio and preform site surveys attach to networks passing the info on to the Xbox for signal strengths etc....

The documentation, needs someone else to look over and review it and it for sure needs a tidy up.

There are referenced logs of all the captures, Ghidra xml's for the adaptor firmware and I have updated the xonlinedash xml's quite a bit so I could see the tag enum and values and confirm stuff not able to be confirmed from the adaptor disassembly alone such as values direct from radio vtables, dash rssi scaling etc...,

Madwifi source is not available for this SOC so I have cross referenced and worked out as much of the radio structs etc to give me reliable and accurate data to build the manual and build an emulator.

I went far over kill with the adaptor disassembly way more than needed every function is named and all the important stuff and stuff that is used a lot has had structs and datatypes created to make it easily readable.