Today as I was playing with Microsoft Visual Studio 2008, my eyes rolled to the Server Explorer Data Connections and the database connection I had created to sneak in to the backbone database of the tt6ynew.exe malware written by some jerk in .NET—which luckily Sadjad has reflected it to its source code and investigated its database connections earlier.
I had previously emptied its whole database hosted at ok8.com.ru, which surprisingly had multiple tables of data filled by the tt6ynew.exe malware, one with a mind-blowing 235 million records. My DELETE commands addressed the SQL server nicely, and within the first few hours of the Monday night, February 1, 2010, the SQL server was breathing serenely, since it has nothing to store anymore!
Tomorrow morning, the jerk has changed the “reader1006” password to the database user “dreader” in rush, because the thief was robbed. For days the password remained altered, resulting an abortion in the online database operation of this wicked malware—previously spread all over the world.
Now that the .NET virus programmer’s grown up a bit, he thought “Gee! Why not change the database policies, so not only the old instances of tt6ynew.exe spread all over the world can connect and send their swept data, but also records cannot be deleted.” Wise choice, jerk!
Now if you try to alter or delete anything, the SQL server will return a database connection error message indicating “拒绝了对对象 ‘users’（数据库 ‘allusers’，所有者 ‘dbo’）的 DELETE 权限。,” which in human language means “DELETE privileges for object ‘users’ (database ‘allusers’, owner ‘dbo’) was not authorized.”
What the jerk didn’t realize was that we have his source code written in C#.NET, so we have his other database username “idata” and password “haha8591”.
So once again, his database is plain clean:
Suggestion for jerks out there: Find yourselves proper jobs, and if bad economy has taken your jobs, don’t bother writing impotent malware and viruses in VB or C#.NET. Learn to program in Assembly and C++!فارسی