In that case a ping limit bypass via packet manipulation should be relatively easy to achieve (in theory).
The way I see it, the connection times out somewhere during the initial broadcast/exchange packets (if anyone could upload some captures from netmon or wireshark of both successful and unsuccessful joins we could establish exactly when it happens). The best way to beat this is a man in the middle program on both ends of a connection. Allow me to demonstrate
Xbox1 = Computer1 = (internet) = Computer2 = Xbox2
(assume each computer is running our hypothetical program)
Bored User1 is sitting at home and decides he wants to play some games over the web. Unfortunately, he just lost his job, so no xbox Live service, and consequently he had to downgrade his internet package to the point that his ping between nearly everyone makes him unable to connect. So he boots up his Xbox1 and the Computer1 which is connected to his xbox and launches our software. The software is, in essence, a software bridge that receives data on one nic, either leaves it untouched or edits it somehow, and forwards it out of the other. After the program fires up and User1 has chosen his two nics, he goes into the system link lobby and searches games, which causes Xbox1 to begin sending out some boadcast packets seeking a game and Computer1 forwards these packets as they come. Just as it happens regularly, these packets go across the virtual lan network and all available hosts respond, ect, ect up until the point that User1 decides to join one of the games now populating his screen. As User1 joins User2s game (what a coincidence!), Xbox1 creates a key exchange packet and sends it out. The software on Computer1 receives this packet but does not forward it, instead creating a generic packet that requests a connection to Computer2. Quickly, the software on Computer1 creates a fake key exchange response and sends it to Xbox1, establishing the secret key between them (DH, the algorithm used in key generation, is extremely susceptible to MITM which makes this possible). Upon receiving the generic connection request packet, Computer 2 does the same for Xbox 2. Each computer has established an encrypted and hashed connection between it and its respective xbox, and in a time far faster than would be regularly possible by sending the exchange packets over the network, so the connection passes the ping limit. Now to communicate, Xbox1 sends out a packet which is received by Computer1, stripped of its hash and decrypted using Xbox1s negotiated key, sent over the network to Computer2 where it is hashed and encrypted using Xboxs2s negotiated key, and sent out to Xbox2 (this process is done both ways).
Its not perfect, and definitely just a simple outline, but it pans out conceptually and you get the idea. The hashing and encrypting seem like they would take a lot of time but Im predicting no more than 20 m/s overhead. Still working on that bridge
not very good at programming and didn't know C++ till this morning. Once that's set up we'll have a platform to manipulate packets from.
The only really glaring problem is that the exact way the broadcast and exchange packets work is somewhat blurry at this point; specifics are not mentioned in the xbox or 360 sdk, there's not any particularly useful information the winsockx.h file, and the netmon parser can only tell us packet layouts and not implementation. Either someone reverse engineers... well, whatever controls the xbox's network security, or we're left to do a lot of guess and check work based on what very little we know, and that is, in all honesty, extremely unlikely to succeed.
Anyways
just my perspective on the issue. Tell me if you see any other problems.