Shifu-Hacks Blog


Archive for September, 2007

DLL Update

Posted by compactwater on September24 2007

DLLDynamic Link Library
If your program is going to have constant updates, you should consider using a dll to update it’s functions. It will save time when updating, and won’t aggravate users by having to download a newer version every week or so. Don’t know how to make a dll? Try this. After reading, you’ll understand it better.

What should go in a dll:
Version information
Main functions
Form information (Colour, size, etc)
Images and sounds (by using .res)
Changed update location

What should not go in a dll:
Temporary information
Operating System (OS) dependent functions
Release notes
Encrypted/Packed/Obfuscated information
A dll (Yes, a dll should not go in a dll.)

And now all that’s left is finding a reliable (or free) server to host the updates.


Posted in General Programming | 3 Comments »

Just-in-case ASM Knowledge

Posted by compactwater on September16 2007

If you don’t know basic Assembly/Assembler/Whatever you want to call it (ASM), then you should read a tutorial, this is for people who have at least a basic understanding.
Sometimes a game cannot be hacked because it has simple protection, or the value is randomly generated (obfuscated), or encrypted. This is where you must look into the game’s memory to hack it, though some of it may be randomly allocated.

Finding the memory is (usually) simple, using “Find out what accesses/reads/writes to this address” with Cheat Engine on an interesting value. If the game knows when something should not be changed, you can usually ‘nop-out’ the code that detects the odd change, but more advanced detection methods would require actual thought. The general things you need to know,is reversing, changing the value of a register (asm or debug), and nopping.


Reversing & Nop-ing:

Making a code do the opposite. Example:
jne 005B667F
changes to
je 005B667F

jne means “jump if NOT equal”, and je means “jump IF equal”. “jump” means to goto an address, at the current state, usually to check something, and if correct, do something, such as decrement health or ammo. Example:
mov eax,005B667F
add eax,5D
cmp eax,ecx
je take_damage
jne return

mov (move) moves “005B667F”, the location of the address, add loads the pointer, and cmp (compare) compares eax to ecx, which if it is equal, will cause you to take damage, and if not equal, will return. There are many ways you could stop yourself from taking damage, the simplest is to change jne to je, but you can also nop it.

Changing & Setting Debug Registers

Cheat Engine has a built-in ability to set debug registers. You can also choose to use Int3 breakpoints. When setting a debug breakpoint, or editing the memory to change the value of something, always be sure you’re doing it correctly, and that you have enough memory allocated; never be scared to over allocate. For changing a register, you will need to ‘code-cave’, redirected memory that can be changed freely with (almost) no fault. Example:
add eax,ecx
cmp eax,edi
add eax,edx
cmp eax,edi
jne here
je there

Your code-cave:
mov eax,your_value
cmp eax,edi
mov eax,your_value2
cmp eax,edi
jne somewhere
je elsewhere
jmp return

Modified 005B667F:
jmp code-cave

So, the code will goto your code-cave instead of the actual thing, and will do whatever you want. This is best for games that may have simple anti-hacking protection, or computers that have an inability to set a debug register, otherwise you can do that in Cheat Engine, and set the value of a register, or a flag (such as ZF).

Posted in Flash Hacking | Leave a Comment »

Too good?

Posted by compactwater on September12 2007

Some games have the build-in or server-sided ability to detect when a player is just “too good”, and will raise a flag that will result in your ban. On the other side, it may detected the player being too good, and immediately ban them, or boot them from the current game, and set them for review by game masters/administrators. Not all games have this, and it is usually only included in online games, to keep users from using trainers, or bots, to cheat in the game. A problem with most bots, is they do the same exact thing in every case, and it can lead to an obvious hacker, which is why “Human Error” should always be an option on a bot (if the game detects the original pattern). If the bot varies its results, it will become harder for it to be detected as a bot.

The simple point behind it, is to make it as if someone where actually sitting at the computer, monitoring every move to be only as perfect as a human can get. Meaning, instead of getting 5/5 every time, get 4/5, maybe even 2/5, and sometimes 5/5, depending on actual results from a human player. Bots should always be tested for a long period of time to be sure they do not cause (large) damage to the user, and to be sure that there are no errors.

If you move your mouse to X,Y every 10 seconds and click, then move it to X,Y and click after 3 seconds for 5 hours, you’re going to get banned, it’s simple. Now, if you click at X+random,Y+random every 10+random seconds and move to X+random,Y+random and click again every 3+random seconds for maybe 2-3 hours, it’d be harder to find out if that person was cheating, but still possible.

Let’s take Gaia Fishing for example. In Gaia Fishing, there is user-interaction, which could lead to someone figuring out you’re cheating, and reporting you. The reason varies from, “I hate hackers” to “Teach me how to hack”. You can never tell why they do it, but they do, and it’s just another thing you have to look out for. Thus: An auto-chat. A small tool that will respond to common phrases said in the game, out of random parts of a sentence.
I am busy fishing, I’ll talk later.
I’m fishing, I will talk later.
I’m busy!

Bye, Later, Cya, Goodbye, Hello, etc…

That would lower suspicion, but if done wrong (in an obvious way) , it could make you stand out. Human Error can only be created through trial and error… or if you happen to know any sort of detection methods they may use, you can try to reverse it, disable it, or create a bot with Human Error.

Posted in Flash Hacking, Gaia Online, General Programming, Trainers | Leave a Comment »

Online Flash Hacking, what you should know

Posted by compactwater on September9 2007

When hacking an online/web-based flash game, you should always remember you can get banned, and even worse, an IP ban. This list is to help anyone become a “not-so-nooby flash hacker”, and maybe even learn something. (Note: This is mainly based on Neopets.)

  1. Always use a proxy when testing hacks, don’t use the same proxy for more than one account, and don’t communicate between multiple accounts, you may get chain-banned.
  2. Never use ‘tools’ or ‘hacks’ downloaded from the internet that ask for a username, password or other personal information, that includes online forms that ask for information.
  3. Never give out your in-game-name, or anyother information that may lead to your account, game masters do watch sites.
  4. Don’t boast about being a hacker, that’s the quickest way to get banned.
  5. Don’t share your account, no matter who it is or who you ‘think’ you can trust, your account can be banned for being accessed by more than one person.
  6. Never go above or close to high scores, you’ll probably be banned, and there may be a max limit to how much you can earn from the game.
  7. It’s your choice to give the public information or hacks, if someone else does it before you, there’s nothing you can do about it.
  8. If you don’t need an item, sell it for cheap, drop it, or give it away, so there’s room for something you do need.
  9. Neopoint Generators are real, not the kinds you see on forms as scams. There are many ways to do it, but don’t give away your information, you will get scammed, use another account to test if it is real.
  10. Never use the same, or similar information for more than one account, it can be traced, and you can be chain-banned by it- never underestimate the game masters.
  11. If you are banned, or IP banned, get another proxy, and make a new account with new information. (Name, e-mail, birth date, etc.) and write it down somewhere safe.
  12. Using a bot is probably more dangerous than hacking. If you’re online for more than a few hours/days, you have a high chance of being banned, especially since your movements/patters will be the same every time.
  13. If the game includes more than one player (yourself), don’t hack, you will get banned, or hack lightly.
  14. Don’t act ‘l33t’ or better than everyone else, don’t become a top member, etc., or you’ll be targeted quickly, and possibly banned.
  15. Give and take from the hacking community, learn, and don’t become a “leecher“.

Posted in Flash Hacking, Neopets | 1 Comment »

Simple bot creation (Part 3/3)

Posted by compactwater on September4 2007

The long awaited Pixel Detection post! (Not really.)
Pixel detection is used mainly to tell the bot when (and where) to do something, and when to do another thing, or to do nothing. This entire blog entry is a source-code example of usage for GetPixel, GetB/G/RValue. Feel free to modify and re-distribute this.

Edited: 9/7/07

Someone e-mailed me about this entry, wondering where the tutorial/information was, I guess I didn’t explain good enough. The source contains an example of pixel detection, and all of it is commented for an easier idea of what’s actually going on within the code, so the source IS the information. Sorry about the misunderstanding.

Download it…….here.

Posted in General Programming, Trainers | Leave a Comment »

Simple bot creation (Part 2/3)

Posted by compactwater on September2 2007

Editor’s note: This is only a small sample and explanation of usage.

Now you know how to click. And you probably want to type something, or press a key, to make your bot better! It’s simple, but there’s many ways to do it, so you’ll have to find the best method for your needs. Something you should never do, is have the game loaded in your program, and give input to the game like that. It usually always leads to slow game-play, and crashing. Keep that in mind when making a bot, always think ahead, so you don’t get lost and have to start all over.

SendMessage or PostMessage can be used to Send or Post a message (who knew?). Remember to choose which one will be best for your use, if you don’t understand the difference, click here for more information. When using S/PMessage, you should always use error handling (try, except, finally) in case of an error. If something were to go wrong, your application may crash or become unstable- never let this happen, use error handling! It’ll look something like this:

try //start something
HAND:=FindWindow(nil, PChar(Edit1.Text)); //Find the window
MySayso:=StrToInt(Edit2.Text); //Set the message. You may want to use Cardinal instead of Integer.
SendMessage(HAND, MySayso, 0, 0); //Send the message
except //If there’s an error…
on error: Exception do
MessageBox(Self.Handle, PChar(String(error.Message)), PChar(String(error.ClassName)), MB_OK); //Show what (if anything) went wrong.

With that, the user can specify a message to send to anyother window, and if there’s a problem sending the message, the program won’t crash so easily. If you’re a beginner, you should stick to “mouse_input” and “Send/PostMessage”, SendInput can be a bit complicated, and if not used correctly, cause many errors. Personally, I only use simple functions in my projects, unless it’s a larger project. Torry’s Delphi Pages may be of more help on SendInput, and other functions.

Pixel Detection will be next, It will be more detailed as well.

Posted in General Programming, Trainers | Leave a Comment »