extremely easy guide for makin hit anywhere codes?

[olala]

Wey anydood, ive interestin of hit anywhere code, i saw nolberto have writin down some guide already, but as usualy for newbie like me, it wasnt pretty easy, i dunt know low level language, so if anydood have other guide like ram method or maybe easly way for, please feed me dood, am realy want to try shotin slap anywhere codethancoudood

[olala]

Forgot somethin:-Pim usin artmoney,ce,tsearc,vbthankyoudood

[Helder]

There is no easy way unless you know assembly of some kind for the system you are using and you need a debugger with breakpoints to get you rolling in the right direction. Learn some assembly and then it will be easy otherwise forget it.

[olala]

Uh dood sounds pretty hard. I do tried asm, 011011, but i cant understand whole of guided. Is theres good source for learnin tut mecha language? Sure i need it for free, otherwisely ill give up and tryin to crackin it down with mi own tool:-Ddood

[Abystus]

Uh dood sounds pretty hard. I do tried asm, 011011, but i cant understand whole of guided. Is theres good source for learnin tut mecha language? Sure i need it for free, otherwisely ill give up and tryin to crackin it down with mi own tool:-Ddood

You don't have to know that much ASM to make a Hit Anywhere for *most* games, though some require more than simple changes to the routine handling hit detection. Do the following to get started:

1. Pick a system (I recommend you start with NES since its instruction set is very basic.), and find a list of its ASM opcodes (NES/SNES Opcode List).
2. Get familiar with the Branch/Conditional Jump types (BEQ, BNE, BVC, BVS, BPL, BMI, BCC, BCS, etc...), as they are the equivalent to "IF" statements in programming.
3. Find an emulator with a debugger and trace functionality (FCEUX is the best NES emulator with debugging tools built in). Also get familiar with how to set breakpoints (read/write/execute), and work the debugger/trace to file.
4. Save a state near whatever your going to be working with in-game so you can repeat your tests by reloading this state.
5. Find something about the enemy that you want to monitor via breakpoint that only happens when you hit them (ex: health decreases, something else in memory is increased on decreased, etc...)
6. Set a breakpoint for write on that address, start a trace to file, and hit the enemy (this should hit the breakpoint and stop the game).
7. Turn the trace to file off, and disable the breakpoint.
8. Open your saved trace file in a utility such as Branch Finder, and check the right side after the file is loaded.
9. Scroll to the bottom of that list (since the break occurred at the end of the file), then work your way back up the list setting breakpoints for execute on the top most selection in the selected group you click on until you find one that breaks when you attack when not near the enemy (make sure it only breaks when you attack, though sometimes "checks" are continuously executed in some games while not attacking).
10. When you find your address, open up your saved trace file in notepad, and find the last occurrence of that address in the file (start from the bottom).
11. Step through the code in the emulator and compare it to what is in the file (you want to make the code follow the same path in the file every time, though sometimes you may have to change a bit more to cancel additional "checks" than what is shown in the file). Usually there are "checks" to see if you actually hit whatever it is or not, and may range from one to several checks in a row (hence why the program groups all common branch to addresses on the right).
12. Depending on the hit detection routine in question, you may need to either kill all the "checks" (I recommend the BIT instruction which is value 24), or make them some of them always true (this is game dependent, and will rely on the code path you see in the file).
13. If the area of code your working with doesn't produce a hit anywhere, move to a different section that breaks when you attack while not near the enemy and repeat the steps till you find it.
14. Test your code thoroughly in multiple areas of the game (a quick play-through) to make sure that your code does not crash the game, and that it works everywhere (most codes need to be tweaked).

Take note that this method does not work with every game. The game may just use one "check" instead of multiples, or use multiple "checks" that don't branch to the same address. In the case that you don't find it on the right side, work your way up from the left side (start at the bottom once again) and repeat the steps above while attacking when not close enough to hit the enemy. If all else fails, open the trace file in notepad and find where the code changes course by setting breaks on execute for addresses in question starting from the bottom of the file until you find something that breaks when not near the enemy (compare the file to the code path in the debugger when attacking).

If you run into issues, pick a game that already has a Hit Anywhere made for it to study what the hacker changed to create the code (repeat the steps above to see if you can create it on your own based on what you saw the hacker do). There are also games (very few) that use an entirely different method which I will not discuss here as it gets a bit more complex than just changing a few conditional checks. Remember, games are coded by different people/companies, so the coding style used for hit detection will be different for the most part per game (though some do share common aspects in the way they are setup).

Sorry if this confuses you, but there is really no "set" way of making these types of hacks as they vary so much per game in how the routine is setup. It is a lot of trial and error (and state reloading), along with having the knowledge to know how to manipulate the code to do what you wish, instead of what it is currently doing. If you haven't guessed it by now, this is the next step (rom hacking) after you master ram hacking. Hope that helps.

[olala]

Uh am not familiar with operationalcde, but thanks dood, seems pretty fun to learn weirdo thin:-P, ill give a shot, even it will take age for understood since am noy smart:-)dood:-)

[dlevere]

http://en.wikipedia.org/wiki/Assembly_language

http://gamehacking.org/wiki/Assembly_Hacking