Greetings, my name is Silabsoft.
You might know me from RSGoldie, the program that has, to date, helped 297 injusticed people and given a total of 1.2 billion in gold.
Well, there is more good news. A friend of mine named Robert joined my team about a month into it, and we soon grew to a team of seven programmers. Daniel, Me, Robert, Rosie, Charlie, James, and Michael. Together, not only have we helped people with gold, we have embarked on a new program project to help with statistics.
Have you ever felt that every one around you was more powerful or stronger in their skill levels? It was that feeling in me, as I inefficiently tried to mine coal among superior miners that brought forth the idea for my new program. It might seem doubtful to you, it did to me at first, but, with some research, I soon saw how to make it happen.
Let me start with the complex details:
When a player logs in to RuneScape, a connection must be made with the character and the mainframe of the system, and a certain large section of it we have come to call the User Skills Database. This database is largely a collection of inter-looping and interdependant files with a Linux Kernel overseeing them. For those of you who do not know, a kernel is the name for the "moderator" of any Linux based system. By this, it sets parameters for the function every file under its command can operate in, thus making hacking quite hard. You see, if a file is hacked, it, by definition, is operating outside its own limits, causing an illegal move in the kernel's eyes. Thusly, messages are sent to the kernel that the file is operating out of its parameters and the kernel interprets it as a malfunctioning program and performs a "clean dump". A clean dump is a very specific deletion of files, in this case only the malfunctioning file and those closely interacting with it.
Now, this database is largely how the high scores are created. It has two main functions: 1. The storage and updating of users statistics and 2. The creation and updating of the top 500,000 high scores.
Every two seconds, the database accepts thousands of messages from user tag-lines and updates itself accordingly. In explanation, when a user gains experience, the PHP tag-code on his character GENERATES (that is very important to remember for later) and sends a message to update the database. About 6,000 experience is gained, give or take 1,500 due to prime time hours or specific days, each two seconds.
Now, remember how the PHP tag generates the messages. This is how we hit the gold. We have written custom tag-codes that we can attach manually with our new STATEdit program to the character. These are system "zombies" (A zombie is a term for a program that "outsources" [meaning gives to a seperate not attached third-party] the core-functions and abilities of a program to a third party) that overwrite the PHP tag-lines and generate their own messages. Thusly, we can generate thousands upon millions (the set limit in our current user-interface is 999,999,999,999 or 999 billion per skill) of experience in a second. This means we can make any character of level 99 in every stat and combat level 200 in a second.
Sounds simple enough? Thats what we thought, too, until we realized the major problems. The first was this: How can we generate millions of experience when the "break-point" is probably well below that. The term break-point is what we call the point where the kernel will recognize a malfunctioning system and do a clean-dump. The break-point in terms of experience for each 2 seconds, we estimate, is probably around 20,000 (being too high for it to be reached any time soon, and too low as to detect hackings). A system "spike" (as in a large uppage of something that lasts only a second or so and then returns to normal, which was well below the spike) such as was created by our own program would certainly cause a "clean-dump". This was a horrible prospect, as the "cleanness" of the dump would be as specific as possible within the entire system, but could only be narrowed down as low as worlds. This means, if we were detected, the entire world full of players would have the accounts irrepairably deleted due to us. We couldn't have this, so we had to devise to such things:
1. An encryption stringent code that operates "below the radar" and is indetectable by the kernel. This took us nearly two weeks of non-stop coding, and on April 9th we almost brought all players of world 46 down with us. So, if you were there, we apologize we almost caused your account to be lost. We finally did it, though, but it caused us to have to add our second program attachment, to keep permanent records out:
2. We decided, since we want no permanent records, we needed to erase the statistic changes at the end of the players logged-on session. Therefore, we encoded a second function for clicking the "log out" button on our coded character files. Thusly, when you click it, it sends a PHP tag-line with a trojan worm that infiltrates the kernel and database and deletes our own programs. This part was a stroke of genius, if I may so myself. Because, how can it know what files to delete, so we used an existing code line to "tag" the files. It makes me giddy even explaining it; when a "clean dump" is done of "banned" (they're actually deleted but saved on seperate disks and kept in the high-scores [in case you didn't know]) characters that attempted hacking, the kernel follows tag-lines to certain programs that are items the hacker traded or unfairly created. By being in his possession, the item obtains a tag-line with the number attached to the character by his ranking in chronological order of the players who started playing the game first. We utilized this method to tag the players statistical levels and made the "bloodhound" (as we call our PHP system worm) follow the tag-lines into the system and delete only the edited files. Thusly, since the high scores are edited when you log off for you only, it makes no actual change so drastic as to be considered as "hacking".
To re-cap, a PHP stringent code is sent across the connection made by a player when he logs on, uses encryption to operate "under the radar" of the kernel and edits all stats as the player would like. (Note, our beta-testers [read-on and you'll understand] do not set these, we do, and we set them to invincibility for every time they log on, so they don't have the program, just the tag-lines on their own character that operate by themselves) When the player logs off, a new message is sent to delete all the changes, and we are safe from being discovered.
Now, why am I telling you all this? Because, we are still working out how to let players keep earning experience that is not destroyed while under the operations of this program (meaning, we want you to earn undeletable experience for your original levels while under the invincible influence of this program) currently, our program deletes all earned experience during the session, and we don't like that. Therefore, as of today we are accepting 200 BETA TESTERS FOR STATEDIT V.033B. To enter, please send an e-mail to [email protected]
, our teams e-mail address. Please, use the following template:
Subject: Beta Testing
I would like to beta-test because (insert why here).
We will be accepting for several months, and it is entirely free. If you are accepted, you will recieve an e-mail saying "Yes" and how long it will take, based on how long the queue for it is.
Why would you want the beta-test?
Simply because when we work out this final kink, we will be selling the full program for around $100 to $400 and Beta testing means you get it before every one else, and you don't pay.
So, if you do want your own perfect skill levels and a combat level of 200 (By the way, this skill level will let you do a maximum of 68 damage with a dragon battle-axe [we tested it]). So, please, we badly need testers, and there is no risk of account deletion. [email protected]