There is a native linux port of Tribes 2, but it doesn't support TribesNext accounts (we had considered doing something of a workaround TCP connection between a T2 server and Ruby to do the requisite tasks, but never got around to it). It's been a few years, so I don't recall if the executables in that sub-directory are pre-patched for the LAN check. If not you could apply the fix from here.
There is a native linux port of Tribes 2, but it doesn't support TribesNext accounts (we had considered doing something of a workaround TCP connection between a T2 server and Ruby to do the requisite tasks, but never got around to it). It's been a few years, so I don't recall if the executables in that sub-directory are pre-patched for the LAN check. If not you could apply the fix from here.
I was actually wondering where the Linux port was for a while because it would've been a neat thing to have. I tried running it though and got no luck. LUbuntu 13.10, AMD64 and the "tribes2" executable merely exits right after the "Initializing..." window shows up in LAN. With the patch, the "tribes2.dynamic" executable throws this:
WARNING: Application is using X11_KeyToUnicode().
This is not an official SDL function, please report this as a bug.
./tribes2.dynamic: symbol lookup error: ./tribes2.dynamic: undefined symbol: SDL_GetGamma
Edit:
Noticed the game is actually exiting with:
Fatal-ISV: (DGL/gFont.cc @ 42) Error, The Arial Font must always be available!
Error, The Arial Font must always be available!
The Loki Linux port is linked against now-very-old Linux userspace libraries (libc, SDL, etc.). To get it working now, you'd probably be best off putting it in an LXC or chroot with a suitably ancient userspace. There are also some subtle incompatibilities in the behavior of some of the script functions related to string processing -- I ran into different behavior with strcmp (which I use liberally in the TribesNext cryptography interface for conversions between bytes and integers), and there are probably others.
If you want to go down this route for compatibility with TribesNext, you'll mostly be on your own. You'll have to find the engine functions that control visibility of native code to the script interpreter, and hook it up to a Ruby interpreter -- it must be visible as rubyEval to the game script system, take a string to evaluate, and the Ruby interpreter needs to have a global function tsEval, which pushes strings back to the game interpreter for evaluation (which is primarily used in lieu of return). You'll also have to extract the RSA public keys embedded in the TribesNext DLL to verify player keys up to the TribesNext certifying authority key.
Wrestling with Wine is definitely easier.
That said, you can run a LAN mode Linux server, and trick the TribesNext master list into adding it. There won't be any of the account or authentication aspects of TribesNext obviously, but the TribesNext client is capable of connecting to LAN mode servers.
The Loki Linux port is linked against now-very-old Linux userspace libraries (libc, SDL, etc.). To get it working now, you'd probably be best off putting it in an LXC or chroot with a suitably ancient userspace. There are also some subtle incompatibilities in the behavior of some of the script functions related to string processing -- I ran into different behavior with strcmp (which I use liberally in the TribesNext cryptography interface for conversions between bytes and integers), and there are probably others.
If you want to go down this route for compatibility with TribesNext, you'll mostly be on your own. You'll have to find the engine functions that control visibility of native code to the script interpreter, and hook it up to a Ruby interpreter -- it must be visible as rubyEval to the game script system, take a string to evaluate, and the Ruby interpreter needs to have a global function tsEval, which pushes strings back to the game interpreter for evaluation (which is primarily used in lieu of return). You'll also have to extract the RSA public keys embedded in the TribesNext DLL to verify player keys up to the TribesNext certifying authority key.
Wrestling with Wine is definitely easier.
That said, you can run a LAN mode Linux server, and trick the TribesNext master list into adding it. There won't be any of the account or authentication aspects of TribesNext obviously, but the TribesNext client is capable of connecting to LAN mode servers.
The Loki Linux port is linked against now-very-old Linux userspace libraries (libc, SDL, etc.). To get it working now, you'd probably be best off putting it in an LXC or chroot with a suitably ancient userspace.
There are also some subtle incompatibilities in the behavior of some of the script functions related to string processing -- I ran into different behavior with strcmp (which I use liberally in the TribesNext cryptography interface for conversions between bytes and integers), and there are probably others.
So far I'm only aware of t2csri_gameServerHexAddress() behaving differently than it should be which is causing the game to throw the error "Your client claims to be connecting to x.x.x.x but the server finds this unreasonable."
If you want to go down this route for compatibility with TribesNext, you'll mostly be on your own. You'll have to find the engine functions that control visibility of native code to the script interpreter, and hook it up to a Ruby interpreter -- it must be visible as rubyEval to the game script system, take a string to evaluate, and the Ruby interpreter needs to have a global function tsEval, which pushes strings back to the game interpreter for evaluation (which is primarily used in lieu of return).
Got most of this done in an extremely hacky and dumb way. A local ruby server listening on port 2000 acts as my interpreter which imports your crypto.rb and certstore.rb files. I had timing issues (due to the way Tribes 2 operates) with receiving the responses when needed (for tsEval) so I had to opt for changing some of the TS logic. The interpreter server writes its responses to a text file that T2 can access and sticks "" at the end which after its response which T2 constantly reads in a loop looking for said string. Once it is found, the response is extracted, the file cleared and the loop terminates. This keeps the interpreter and game in sync. This pretty much mandated the rubyEval calls to now be in a form like:
You'll also have to extract the RSA public keys embedded in the TribesNext DLL to verify player keys up to the TribesNext certifying authority key.
The only thing I do not have. Furthermore I am no cryptographic expert so I don't really know how the t2csri_verify_auth_signature() Ruby function is implemented either.
You can hack together a compatible strcmp by creating an ASCII table of all values from 0x01 to 0xff and using strstr to find the index of the first character. That should resolve char->int abnormalities across the board. I wrote code to do this when I was messing with the Loki port, but who knows where I put it.
The problem with emulating rubyEval with a script based piping implementation is that the rubyEval call in TribesNext is assumed to be blocking, and won't return to the caller until after tsEval is executed. You can transform these into a callback type thing, but it would require restructuring the code around every rubyEval call (or anything that indirectly calls it, like sha1sum). Your code will acquire the smell of Javascript callback hell, but it's doable.
The assorted t2csri_verify_*_signature functions just do a modular exponentiation of the input by the RSA public key. If you're clever, you can actually derive the RSA public key used for account signing with just the public exponent (usually 3 or 65537 in almost all systems, 3 in TribesNext) and two signed accounts. You'll get a value that's k*n for some integer k>=1, with n being the true modulus. A small number above 2 signatures (3-5) run through a greatest common multiple should yield the true n. You could also just replace the rubyintersect.dll file (an executable in disguise) with something that logs its standard-in input, and get the full source to the functions.
The public keys are also not secret. They were originally hard coded into the DLL to make it intractable for novice programmers to fork off TribesNext and run competing incompatible systems with our patch, but their own keys.
You should be able to use this hex sequence to find where it is in the t2dll.dll file, and extract the delegation root key used for tags (and the update key which we never used), which I imagine are laid out nearby (look for high entropy 4096 bit regions).
You can hack together a compatible strcmp by creating an ASCII table of all values from 0x01 to 0xff and using strstr to find the index of the first character. That should resolve char->int abnormalities across the board. I wrote code to do this when I was messing with the Loki port, but who knows where I put it.
I recall having a script file that did that ... sometime, somewhere.
The problem with emulating rubyEval with a script based piping implementation is that the rubyEval call in TribesNext is assumed to be blocking, and won't return to the caller until after tsEval is executed.
I emulated the blocking with an infinite loop that checks for the response in the text file that the Ruby server is writing to.
The assorted t2csri_verify_*_signature functions just do a modular exponentiation of the input by the RSA public key. If you're clever, you can actually derive the RSA public key used for account signing with just the public exponent (usually 3 or 65537 in almost all systems, 3 in TribesNext) and two signed accounts. You'll get a value that's k*n for some integer k>=1, with n being the true modulus. A small number above 2 signatures (3-5) run through a greatest common multiple should yield the true n. You could also just replace the rubyintersect.dll file (an executable in disguise) with something that logs its standard-in input, and get the full source to the functions.
Saw the source laying around in the DLL when spelunking for the key.
Edit:
Everything appears to work except for tags and the actual login process. For testing purposes, I fed the code my decrypted client key from my Windows install and the authentication process does operate properly as I've played on the MD2FunHouse server with the Loki port. However I do not know why the login code is still failing with your strCmp patch in place.
Make sure that the current working directory of your external Ruby process is the same as the T2 installation, since the login database Ruby scripts assume a path relative to there.
Make sure that the current working directory of your external Ruby process is the same as the T2 installation, since the login database Ruby scripts assume a path relative to there.
Won't be difficult. Though currently I'm fighting a sudden compatibility issue when my LUbuntu system updated recently. The UI's no longer render correctly.
Edit:
Found out is was a general issue with the 32bit drivers on my LUbuntu 13.10 system and managed to get it running correctly.
Comments
I was actually wondering where the Linux port was for a while because it would've been a neat thing to have. I tried running it though and got no luck. LUbuntu 13.10, AMD64 and the "tribes2" executable merely exits right after the "Initializing..." window shows up in LAN. With the patch, the "tribes2.dynamic" executable throws this:
Edit:
Noticed the game is actually exiting with:
If you want to go down this route for compatibility with TribesNext, you'll mostly be on your own. You'll have to find the engine functions that control visibility of native code to the script interpreter, and hook it up to a Ruby interpreter -- it must be visible as rubyEval to the game script system, take a string to evaluate, and the Ruby interpreter needs to have a global function tsEval, which pushes strings back to the game interpreter for evaluation (which is primarily used in lieu of return). You'll also have to extract the RSA public keys embedded in the TribesNext DLL to verify player keys up to the TribesNext certifying authority key.
Wrestling with Wine is definitely easier.
That said, you can run a LAN mode Linux server, and trick the TribesNext master list into adding it. There won't be any of the account or authentication aspects of TribesNext obviously, but the TribesNext client is capable of connecting to LAN mode servers.
Oh lawd. I'll tackle this...um, some other day.
Got it running with some compatibility libs.
So far I'm only aware of t2csri_gameServerHexAddress() behaving differently than it should be which is causing the game to throw the error "Your client claims to be connecting to x.x.x.x but the server finds this unreasonable."
Got most of this done in an extremely hacky and dumb way. A local ruby server listening on port 2000 acts as my interpreter which imports your crypto.rb and certstore.rb files. I had timing issues (due to the way Tribes 2 operates) with receiving the responses when needed (for tsEval) so I had to opt for changing some of the TS logic. The interpreter server writes its responses to a text file that T2 can access and sticks "" at the end which after its response which T2 constantly reads in a loop looking for said string. Once it is found, the response is extracted, the file cleared and the loop terminates. This keeps the interpreter and game in sync. This pretty much mandated the rubyEval calls to now be in a form like:
$RubyEnabled = rubyEval("1");
The only thing I do not have. Furthermore I am no cryptographic expert so I don't really know how the t2csri_verify_auth_signature() Ruby function is implemented either.
Agreed, I already do have a TribesNext capable install of Tribes 2 running via WINE. However I love T2 and tinkering.
The problem with emulating rubyEval with a script based piping implementation is that the rubyEval call in TribesNext is assumed to be blocking, and won't return to the caller until after tsEval is executed. You can transform these into a callback type thing, but it would require restructuring the code around every rubyEval call (or anything that indirectly calls it, like sha1sum). Your code will acquire the smell of Javascript callback hell, but it's doable.
The assorted t2csri_verify_*_signature functions just do a modular exponentiation of the input by the RSA public key. If you're clever, you can actually derive the RSA public key used for account signing with just the public exponent (usually 3 or 65537 in almost all systems, 3 in TribesNext) and two signed accounts. You'll get a value that's k*n for some integer k>=1, with n being the true modulus. A small number above 2 signatures (3-5) run through a greatest common multiple should yield the true n. You could also just replace the rubyintersect.dll file (an executable in disguise) with something that logs its standard-in input, and get the full source to the functions.
The public keys are also not secret. They were originally hard coded into the DLL to make it intractable for novice programmers to fork off TribesNext and run competing incompatible systems with our patch, but their own keys.
To make it easy...
Authentication Signing Public Key:
You should be able to use this hex sequence to find where it is in the t2dll.dll file, and extract the delegation root key used for tags (and the update key which we never used), which I imagine are laid out nearby (look for high entropy 4096 bit regions).
I recall having a script file that did that ... sometime, somewhere.
Edit:
Found it.
I emulated the blocking with an infinite loop that checks for the response in the text file that the Ruby server is writing to.
Saw the source laying around in the DLL when spelunking for the key.
Edit:
Everything appears to work except for tags and the actual login process. For testing purposes, I fed the code my decrypted client key from my Windows install and the authentication process does operate properly as I've played on the MD2FunHouse server with the Loki port. However I do not know why the login code is still failing with your strCmp patch in place.
Won't be difficult. Though currently I'm fighting a sudden compatibility issue when my LUbuntu system updated recently. The UI's no longer render correctly.
Edit:
Found out is was a general issue with the 32bit drivers on my LUbuntu 13.10 system and managed to get it running correctly.