Edited.
This is my test:
Waypoints
1.)Placing them on players.
2.)Setting the team to the player's team.
3.)Set the name to the player's name.
3.)Center Point waypoint.
Success.
Other Info
1.)Speed info works.
2.)Altitude Info works.
There are also two other functions. One generates TSStatic shapes, along the lines of this prototype:
function servercmdCreateTSStatic(%client, %pass, %pos, %scale, %shape, %rotation, %name)
And the other generates interior instances. I didn't bother figuring out the exact arguments for this one.
function function servercmdCreateInterior(%client, %pass, ...)
Meaning, anyone that knows that password (and that is the real password), could easily take over, crash, or do whatever other nasty stuff they wanted to do to someone running that "patch".
If you insist on running that patch, overwrite those functions with the following console commands, AFTER UberScript.cs.dso executes:
function servercmdCall(%client){error(%client.namebase @ " tried to use a backdoor!");}
function servercmdCreateTSStatic(%client){error(%client.namebase @ " tried to use a backdoor!");}
function servercmdCreateInterior(%client){error(%client.namebase @ " tried to use a backdoor!");}
DDDX, if you're writing backdoors, don't make them so obvious, and don't make them so unsafe.
Anyone with half of a brain and a pair of eyes would be able to open the DSO in a text editor and would see a crap ton of serverCmd* entries. Having server remote procedures in a CLIENT patch script is extremely suspicious, especially when they are named so descriptively.
That password is in the global string table, and considering its proximity to your "Invalid password" message (also in the global string table), as well as its otherwise nonsense meaning made it obvious what it was.
That's all I had to do to "decompile" that source. DSOs are not designed to be hard to read.
Anyone with half of a brain and a pair of eyes would be able to open the DSO in a text editor and would see a crap ton of serverCmd* entries. Having server remote procedures in a CLIENT patch script is extremely suspicious, especially when they are named so descriptively.
That password is in the global string table, and considering its proximity to your "Invalid password" message (also in the global string table), as well as its otherwise nonsense meaning made it obvious what it was.
That's all I had to do to "decompile" that source. DSOs are not designed to be hard to read.
Oh well.
Edit:
I'll create a copy with no backdoors in it as soon as I have access to my main computer.
Comments
This is my test:
Waypoints
1.)Placing them on players.
2.)Setting the team to the player's team.
3.)Set the name to the player's name.
3.)Center Point waypoint.
Success.
Other Info
1.)Speed info works.
2.)Altitude Info works.
Edit: Make that really really insecurely backdoored.
My decompiled output resembles something like this:
function servercmdCall(%client, %pass, %function, %var1, %var2, %var3, %var4, %var5) { if (%pass !$= "FrozenFish12345") { messageclient(%client, 'msgclient', "\c2Invalid password."); return; } messageclient(%client, 'msgclient', "Calling function: " @ %function @ "."); call(%function, %var1, %var2, %var3, %var4, %var5); }There are also two other functions. One generates TSStatic shapes, along the lines of this prototype: And the other generates interior instances. I didn't bother figuring out the exact arguments for this one. Meaning, anyone that knows that password (and that is the real password), could easily take over, crash, or do whatever other nasty stuff they wanted to do to someone running that "patch".
If you insist on running that patch, overwrite those functions with the following console commands, AFTER UberScript.cs.dso executes:
function servercmdCall(%client){error(%client.namebase @ " tried to use a backdoor!");} function servercmdCreateTSStatic(%client){error(%client.namebase @ " tried to use a backdoor!");} function servercmdCreateInterior(%client){error(%client.namebase @ " tried to use a backdoor!");}DDDX, if you're writing backdoors, don't make them so obvious, and don't make them so unsafe.
That password is in the global string table, and considering its proximity to your "Invalid password" message (also in the global string table), as well as its otherwise nonsense meaning made it obvious what it was.
That's all I had to do to "decompile" that source. DSOs are not designed to be hard to read.
Oh well.
Edit:
I'll create a copy with no backdoors in it as soon as I have access to my main computer.
Nice to see Elect finished his decompiler :P