Damn, my IDA is acting up...I can't open the xex for some reason I can't understand, but if you look at page 6, i posted some function names I found while browsing the xam.xex file
, and there were some more about encryption, but I can't make anything out of them because I find ppc instructions a bit weird
There's also the XNetConnect function which I read about in the XDK Documentation, and I remember seeing it in the xam.xex also.
XNetConnectEstablishes a secure connection with a specified Internet address (in_addr).
INT XNetConnect(
const IN_ADDR ina
);
Returns zero if successful, an error code otherwise.
If the in_addr specified in ina is invalid, the function returns WSAEINVAL. For a valid in_addr that is in the PENDING or COMPLETED states, the function does nothing and returns zero (but see XNetGetConnectStatus). For an in_addr to an online server with which a security connection has been lost, the function will reinitiate the security connection and return zero. For an in_addr to an Xbox 360 peer with which a security connection has been lost, the function does not reinitiate a connection, and instead returns WSAEINVAL.
Secure connections are normally automatically created in the background the first time a packet is sent to a valid in_addr. A title can call XNetConnect to explicitly start that process before the first packet is sent, initiating the NAT traversal and key exchange required to establish a secure connection. Once a security connection has been lost, the connection is not automatically reestablished when packets are sent; to reestablish lost security connections, titles must either call XNetConnect (for connections to an online server), or XNetXnAddrToInAddr (for connections to another Xbox 360).
A secure connection can be lost when either side of the connection calls XNetUnregisterInAddr or XNetUnregisterKey, or when normal background keep-alive packets are not received for long enough that the connection is deemed broken. XNetGetConnectStatus will return XNET_CONNECT_STATUS_LOST for connections that are in the LOST state.
The process for creating a secure connection and for reestablishing a lost connection depends on the type of connection: Xbox 360-to-Xbox 360 (active), or Xbox 360-to-Xbox 360 (passive).
Xbox 360-to-Xbox 360 (Active Connect)
For a connection from one Xbox 360 to another Xbox 360, the title gets the in_addr to the other Xbox 360 by calling XNetXnAddrToInAddr. This security association starts out in the IDLE state. The state becomes PENDING if the title calls XNetConnect or if a packet is sent to the given in_addr. In the PENDING state all packets sent on the security association are queued for transmit until the key exchange completes successfully and the state changes to CONNECTED.
Should key exchange fail, or should the security association become disconnected (either because the other side sent an explicit disconnect request with a call to XNetUnregisterInAddr or XNetUnregisterKey, or because a packet has not been received from the other side for a while), the state of the security association becomes LOST. An Xbox 360-to-Xbox 360 in_addr in the LOST state is forever invalid, and any attempt to transmit a packet to that in_addr will return WSAEHOSTUNREACH.
Once a peer-to-peer security association becomes LOST the only way to reestablish connectivity to the peer is for the title to once again call XNetXnAddrToInAddr, which will return a different in_addr to the peer. A packet transmitted over this new security association, or an explicit call to XNetConnect, will initiate key exchange and a new security connection with the peer.
Xbox 360-to-Xbox 360 (Active Connect)For a connection from one Xbox 360 to another Xbox 360, the title gets the in_addr to the other Xbox 360 by calling XNetXnAddrToInAddr. This security association starts out in the IDLE state. The state becomes PENDING if the title calls XNetConnect or if a packet is sent to the given in_addr. In the PENDING state all packets sent on the security association are queued for transmit until the key exchange completes successfully and the state changes to CONNECTED.
Should key exchange fail, or should the security association become disconnected (either because the other side sent an explicit disconnect request with a call to XNetUnregisterInAddr or XNetUnregisterKey, or because a packet has not been received from the other side for a while), the state of the security association becomes LOST. An Xbox 360-to-Xbox 360 in_addr in the LOST state is forever invalid, and any attempt to transmit a packet to that in_addr will return WSAEHOSTUNREACH.
Once a peer-to-peer security association becomes LOST the only way to reestablish connectivity to the peer is for the title to once again call XNetXnAddrToInAddr, which will return a different in_addr to the peer. A packet transmitted over this new security association, or an explicit call to XNetConnect, will initiate key exchange and a new security connection with the peer.
Xbox 360-to-Xbox 360 (Passive Connect)A passive connection from Xbox 360 to Xbox 360 occurs when a host or peer that has registered a key pair (with a call to XNetRegisterKey) receives an incoming key exchange initiator from another peer. At that point, a security association is passively created. The title, upon receiving a packet from the peer, can determine the XNADDR of the peer by calling XNetInAddrToXnAddr.
The initial state of a passive security association is CONNECTED, because a packet cannot arrive until the security association has been established. The security association becomes LOST if the other side fails to send a packet for a while, or if the other side sends an explicit disconnect request with a call to XNetUnregisterInAddr or XNetUnregisterKey. An Xbox 360-to-Xbox 360 in_addr in the LOST state is forever invalid, and any attempt to transmit a packet to that in_addr will return WSAEHOSTUNREACH.
As for an active connection, once a passive peer-to-peer security association becomes LOST the only way to reestablish connectivity to the peer is for the title to once again call XNetXnAddrToInAddr, which will return a different in_addr to the peer. A packet transmitted over this new security association, or an explicit call to XNetConnect, will initiate key exchange and a new security connection with the peer.
Requirements
Header: Declared in Winsockx.h.
Library: Use Xnet.lib.
I'm sorry for posting this if you already know about it
Author
Topic: Ping Limit Bypass (Read 1535 times)