SRL Archive - Help

So I was reading around on a few threads and someone mentioned something that made me get an idea. I don't remember what they were talking about but I remember that it gave me the idea of uploading debugs real time to something that could be accessed easily by me so that I can theoretically have a solution to a problem before it's fixed. Being able to read through important debugs would be really helpful for me as a scripter, because usually a tester doesn't have as much knowledge about what information I need in order to fix it.

Another potential use is that I could upload proggies after runs so I actually see all the progress reports rather than simply the ones that get sent in. This is more effective than SRL stats because not a lot of people have stats, and you can't just force them to get stats.

The only downside I can see from a system like this is that it could in theory be used for password stealing. I would allow any Staff, Dev, SSRL, etc who was trusted to look through the code before it was released, so they could make sure.

Then comes the major downside, I really don't have much knowledge of how to write the side that sends information or the side that receives it. This is where the 'Help' part would come in. If anyone has any ideas about how to go about this I'd really appreciate it.

http://villavu.com/forum/showthread.php?t=60327

See PHP and AddPostVariable used by Frement here http://villavu.com/forum/showthread.php?t=61143

As for passwords, we can tell users how to look for that (actually a script to search for password outside of declareplayers, loginplayer, etc would be doable too). And if they don't want to bother, they can stick to scripts that are vetted (or in the future script manager).

From: mormonman
http://villavu.com/forum/showthread.php?t=60327

From: Boreas
See PHP and AddPostVariable used by Frement here http://villavu.com/forum/showthread.php?t=61143

As for passwords, we can tell users how to look for that (actually a script to search for password outside of declareplayers, loginplayer, etc would be doable too). And if they don't want to bother, they can stick to scripts that are vetted (or in the future script manager).

E: Misunderstood Boreas, thanks.

It's also possible to make some sort of safety system for SRL.
Add a function named something like PASSWORD_Encrypt, and one for PASSWORD_Decrypt, both of them requiring a string input, which could be either the password, or the encrypted password. To make it even more secure you could use a salt. Now edit DeclarePlayers to encrypt the password, and loginplayer to decrypt it when logging in and encrypt it again.

Now when someone tries to do anything with Players.Pass, they'll get an encrypted string.
I did this for TUBI, but removed it later on.

What about MD5 encryption? This was used alot in private servers when they developed a more serious outlook on security. Example: P2P servers.

From: Flight
What about MD5 encryption? This was used alot in private servers when they developed a more serious outlook on security. Example: P2P servers.

MD5 is only useful for comparing if a string is the same. It's pretty hard (if not impossible) to decrypt a MD5 hash.

But an MD5 wouldn't need to be applied to encrypt the full script, right? Would it not be used to simply encrypt a single string at a time for Usernames/Passwords ect? I might be wrong as I never used it, but I've seen quite a few examples through Java, but not PHP and such.

I was thinking of this a while ago, when someone stops a script it sends the progress report to a server and I can just view them all there, so people don't need to post it and I can get an idea on how often my script is used

Hashing won't work as the plain text needs to be entered into RS. Hashing only works when you are in control of the backend and frontend. Encrypting and decrypting won't work as loginplayer and a stealer function would both have the same access to the decrypting function and variables. It's better to just leave the password variable as it is, and look to make sure it is only being written to in declareplayers, and read from in loginplayer etc. A verifier script could do this easily for people that don't want to read through the code.

Simba side can be as simple as this:

program new;

const ServerURL = 'http://www.yourhost.com/folder/proggy.php';

function SendProgressReport(Data: String): Boolean;
var Client: Integer;
begin
  Result := False;
  Client := InitializeHTTPClient(False);
  ClearPostData(Client);
  AddPostVariable(Client, 'proggy_data', Data);
  if (Pos('Success', PostHTTPPageEx(Client, ServerURL)) <> 0) then
    Result := True;
end;

begin
  if (SendProgressReport('Progress Report here!')) then
    Writeln('Progress report sent succesfully!');
end.

And the PHP side isn't much complex, heres an example:
[PHP]<?php

/*
Username + password check can also be performed. You can get username and password from a database and then compare,
just add another post variable on the Simba side. Access the post variable like "proggy_data", $_POST["username"].
If username and password do not match, perform this:
die("Error: Invalid username and/or password."); // This prevents any other code after this line from being executed.
*/

if (isset($_POST["proggy_data"]) && strlen($_POST["proggy_data"]) > 1) { // Checking that post data is not empty, and length is greater then 1.
$data = addslashes($_POST["proggy_data"]);
$hash = md5($data); // Generating MD5 hash of the progress report for the filename.
if (!file_exists("proggies/".$hash.".rpt")) { // Checking if exactly same progress report already exists, I doubt this will happen, but its good to check.
$file = fopen("proggies/".$hash.".rpt", "w+"); // Opening file for writing, and truncating it to 0 length.
fwrite($file, $data); // Writing progress report to the file we just opened.
fclose($file); // Closing the file handle.
echo "Success"; // Outputting Success that the Simba side knows everything went smoothly.
} else {
echo "Error: Exactly same progress report already exists."; // Outputting error.
}
} else {
echo "Error: Too short progress report."; // Outputting error.
}

?>[/PHP]

Wow nice Frement, that makes sense even to me. :D

Client := InitializeHTTPClient(False);
  ClearPostData(Client);

Wouldn't this open a new browser though? (I'm still nub with Scar and Simba functions)

From: Flight
Wouldn't this open a new browser though? (I'm still nub with Scar and Simba functions)

No, that opens a socket connection.

Ah ok, that seems simple enough. I'll keep this in mind, seems like it could be very practical for a few ideas I have in mind.

It's a very simple script, and for the database handling if someone decides to make such, remember to sanitize input, only allow some letters so there are no SQL injection holes.

Like this:
[PHP]$username = preg_replace("[^a-zA-Z0-9 _-]", "", $_POST["username"]);[/PHP]
That code allows for characters from a-z, A-Z, 0-9, space, underscore and dash. If you decide to add more allowed characters, some characters like ] and [ need to be backslashed, like \] and \[.