Hacking.. This is something that I am interested in, more specifically MODDING.
I understand the process of using the editor, I mean, getting it running and decompiling the code... but once you have the code, how do you find out what it does? Is this just a long process of exploring? I mean.. like how do you know what its suppose to do?
I have done hex modding for games but its simple because the hex editor itself can check for values changed or values that stay the same and then change them, in some games you can even use this to find the sprite arrays and change which sprites are loaded. But I still cannot figure out how to understand what the rest of the code is doing. Assembly, I guess is a process of googling, and hex editing is even more complex..
But I just understand the basics of what the symbols do, like psh, pop, jmp, ect.. I don't understand how you use the series of these things to figure it out. To me it seems like a billion piece puzzle with insane possibilities.
Can someone explain what you do, or more the theory behind it.. How do you understand what it does as a whole section of code..
A link would be cool too.
How are games and programs hacked?
Hacking.. This is something that I am interested in, more specifically MODDING.
I understand the process of using the editor, I mean, getting it running and decompiling the code... but once you have the code, how do you find out what it does? Is this just a long process of exploring? I mean.. like how do you know what its suppose to do?
I have done hex modding for games but its simple because the hex editor itself can check for values changed or values that stay the same and then change them, in some games you can even use this to find the sprite arrays and change which sprites are loaded. But I still cannot figure out how to understand what the rest of the code is doing. Assembly, I guess is a process of googling, and hex editing is even more complex..
But I just understand the basics of what the symbols do, like psh, pop, jmp, ect.. I don't understand how you use the series of these things to figure it out. To me it seems like a billion piece puzzle with insane possibilities.
Can someone explain what you do, or more the theory behind it.. How do you understand what it does as a whole section of code..
A link would be cool too.
You never really have to understand the assembly for a full program, if you use a debugger you can find the locations that are interesting.
If you want to for example modify the function that handles damage to the player you can start by locating the players health in memory and then set a data breakpoint that halts execution when the value changes, this will stop execution at the location you're interested in and going from there should be fairly easy (Looking at the callstack should tell you where the call to the function you stopped at was made from aswell if the actual calculation was done outside the function that made the change).
If we look at how copyprotection is beaten its getting complicated, 20+ years ago it was often as easy as replacing a compare or jump instruction but these days the commercial copyprotection solutions are far more advanced going as far as to install their own kernel level drivers in the OS (Which is part of the reason why some of them have gotten a bad reputation, even small bugs at this level can cause huge problems for the end user.
In general, if you are going the route of a custom kernel driver for your copy protection scheme you better know what the f--k you're doing because messing up even a tiny bit can open up huge security holes for the end user (Sony XCP), degrade performance (Starforce), or cause nasty bluescreens (SecuROM), in the worst case scenario you could have a lawsuit on your hands (Sony did and ended up with a settlement having to not only replace the CDs with DRM free versions but also give the customers the same music in mp3 format plus a choice of either $7.50 + a free digital album download (out of a selection of ~200) or 3 free digital album downloads).
Placing anti-hack protection into your game is not always the best way to approach this.
The better your protection, the more hackers you attract. Hacker's love a challenge, if you provide them with one they'll step up to the mark. It only takes one hacker who is a smart enough to find the weakest point in your security and break it. Anti-hack protection will keep out script kiddies and might give you a number of days or weeks before your game is cracked. For a small indie setup, that isn't even enough time to generate enough interest in your game.
Anti-hack protection can have negative consequences if it interferes with legitimate users - they might find themselves locked out of a game they paid for and will be very vocal in complaining about this on the internet. Another issue is that you have no quality control over hacked clients. People might download "your game", which is a hacked but crippled copy, and then complain that no one should buy it because it is "buggy".
A different approach is something like Minecraft. The hackers have a moving target, every few weeks there are new features and a hacked client will quickly become out of date and unusable. Instead of investing serious time into keeping hackers out, the investment of time goes straight to the legitimate players, cool new features to play with! Minecraft has the serious advantage of having a multi-player mode, which gives the player a strong incentive to have an up to date client to play with other people *.
Set your goals realistically. A simple goal is to deter non-technical users from casually copying the game. This is a decision you should think about, as for small developers word of mouth is one of your major marketing arenas. So you should certainly consider some kind of free demo if you want to do this (if you aren't considering this anyway).
The other option is the "added value" approach - the game is free but a paid account gets you extra features. It is essentially the same thing but it looks and feels different to the customer.
Larger organisations have tried and failed to stop piracy completely. Take a holistic approach to piracy. Your target shouldn't be to reduce piracy for its own sake, your objective is to increase your overall revenue. Sometimes the best approach is to reward the people who are willing to pay you rather than fight with those who aren't.
* This post is about hacking for piracy purpose. If you are concerned about hacking for cheating, that is a different thing entirely, and merits an aggressive approach to dealing with it as this will affect your ordinary users - the victims of such cheating.
The better your protection, the more hackers you attract. Hacker's love a challenge, if you provide them with one they'll step up to the mark. It only takes one hacker who is a smart enough to find the weakest point in your security and break it. Anti-hack protection will keep out script kiddies and might give you a number of days or weeks before your game is cracked. For a small indie setup, that isn't even enough time to generate enough interest in your game.
Anti-hack protection can have negative consequences if it interferes with legitimate users - they might find themselves locked out of a game they paid for and will be very vocal in complaining about this on the internet. Another issue is that you have no quality control over hacked clients. People might download "your game", which is a hacked but crippled copy, and then complain that no one should buy it because it is "buggy".
A different approach is something like Minecraft. The hackers have a moving target, every few weeks there are new features and a hacked client will quickly become out of date and unusable. Instead of investing serious time into keeping hackers out, the investment of time goes straight to the legitimate players, cool new features to play with! Minecraft has the serious advantage of having a multi-player mode, which gives the player a strong incentive to have an up to date client to play with other people *.
Set your goals realistically. A simple goal is to deter non-technical users from casually copying the game. This is a decision you should think about, as for small developers word of mouth is one of your major marketing arenas. So you should certainly consider some kind of free demo if you want to do this (if you aren't considering this anyway).
The other option is the "added value" approach - the game is free but a paid account gets you extra features. It is essentially the same thing but it looks and feels different to the customer.
Larger organisations have tried and failed to stop piracy completely. Take a holistic approach to piracy. Your target shouldn't be to reduce piracy for its own sake, your objective is to increase your overall revenue. Sometimes the best approach is to reward the people who are willing to pay you rather than fight with those who aren't.
* This post is about hacking for piracy purpose. If you are concerned about hacking for cheating, that is a different thing entirely, and merits an aggressive approach to dealing with it as this will affect your ordinary users - the victims of such cheating.
The Game Genie product for the NES worked like this. All the codes were just addresses and values. Getting infinite health was just a matter of finding the address, and writing to it with a high value.
Correct as a first approximation, but there are complications due to the way the hardware is set up.
The Game Genie was inserted between the CPU and the ROM cartridge, so it could only alter data actually being read from the ROM - since the main RAM was internal to the machine, and main RAM accesses ignored the cartridge bus, the game genie couldn't alter variables held in main RAM, which imposes limitations on exactly what the game genie was actually able to do. (Some games had additional RAM on the cartridge that could theoretically be altered by the game genie - though in practice, it was impossible, because it was outside the address space patchable by the game genie.)
Because of this, many Game Genie codes operated by altering the code being run by the CPU rather than the data being fetched by it. For example, because a variable like Health would be stored in RAM, the Game Genie wouldn't be able to change it directly; but it could change the starting value of it (which by necessity had to be loaded from somewhere in ROM), or it could alter the code used by the game to alter Health (by, for example, causing a damage-processing function to return immediately instead of applying damage, or to increase health when damage is taken instead of decrease it). But if a game had many different subroutines that processed damage, there would be no realistic game genie workaround, since each subroutine would require it's own game genie code, and the game genie could only support 3 codes at once, with additional codes being usable only by daisy-chaining multiple game genies together.
As an aside, Game Genie codes actually had three parts on the NES - address, data, and an optional key. This is because of bankswitching - since the NES only had a 64k CPU address space, with only 32k allocated to the cartridge ROM (and an additional 8k that could be used bu on-cartridge RAM), as games grew past that limit they needed bankswitching hardware to determine which 32k subset of ROM was actually visible to the CPU. Because there were many different forms of bankswitching used on the NES, the game genie needed some way to recognize the current ROM bank so it could patch the correct bytes without having to know anything about the bankswitching hardware being used. Thus the optional key - without a key, it simply checks the address being read by the CPU and if it matches one of the codes in use, presents the data in that code to the CPU, but if there is a key, is checks the data that the cartridge presents at the tat address, and only if it matches the key does it present the data from the code instead. The Genesis and SNES versions, since those consoles didn't make use of bankswitching, don't have an optional key, and so codes are just address-data pairs, although due to hardware design, they can't patch system RAM either.
A different approach is something like Minecraft. The hackers have a moving target, every few weeks there are new features and a hacked client will quickly become out of date and unusable. Instead of investing serious time into keeping hackers out, the investment of time goes straight to the legitimate players, cool new features to play with! Minecraft has the serious advantage of having a multi-player mode, which gives the player a strong incentive to have an up to date client to play with other people *.<br /><br />Set your goals realistically. A simple goal is to deter non-technical users from casually copying the game. This is a decision you should think about, as for small developers word of mouth is one of your major marketing arenas.
Are you sure about that? All the times I have read about it, it worked by writing to memory on every vsync interval. Perhaps this only functioned this way on later systems?
...
The PS, N64, and later models of the Game Sharks and competitors even came with debugging tools you could run to find the addresses you wanted to patch over. On an RPG you'd have 500 codes for all the stats on all the various characters.
On some games you couldn't get infinite health or ammo because there wasn't a constant location for these values. The player was just another random entity, and it changed based on level size and difficulty.
On other games, you'd have a different codes for every level!
I think you misunderstand my post. Minecraft is certainly a financial exception. It wouldn't make sense to build a business on the expectations that you'd have the same success in the same time frame, that would be an extraordinarily risky thing to do.
My point was that Minecraft is actually hard to pirate, not because of any DRM, but because of the development model. Yes, you can probably hack a stand alone client for single player mode easily, but users who download this will be annoyed when their paying friends have some cool features next month, and can play together online.
Not every game is suited to such a model, and not every developer can keep to a regular feature release schedule, but it is something to consider. The investment in anti-piracy is lost as soon as a good enough hacker figures it out. AAA games make most of their profits in the first few weeks, so all their anti-piracy needs to do is outlast this peak. For indie games, their sales are over a longer time frame, as they generally lack the marketing to get a critical mass of sales in a short time span. This means that any DRM needs to last a long time, which is quite difficult. The advantage that solo developers have is that until their game does hit a critical mass of popularity there is a lower probability of hackers trying to break any copy protection.
My point was that Minecraft is actually hard to pirate, not because of any DRM, but because of the development model. Yes, you can probably hack a stand alone client for single player mode easily, but users who download this will be annoyed when their paying friends have some cool features next month, and can play together online.
Not every game is suited to such a model, and not every developer can keep to a regular feature release schedule, but it is something to consider. The investment in anti-piracy is lost as soon as a good enough hacker figures it out. AAA games make most of their profits in the first few weeks, so all their anti-piracy needs to do is outlast this peak. For indie games, their sales are over a longer time frame, as they generally lack the marketing to get a critical mass of sales in a short time span. This means that any DRM needs to last a long time, which is quite difficult. The advantage that solo developers have is that until their game does hit a critical mass of popularity there is a lower probability of hackers trying to break any copy protection.
I think Minecraft is an exception. The guy became an overnight millionaire, so he can make up whatever story he wants, "piracy doesn't affect me",
blah, blah, blah. Piracy kills profit. Just ask someone who can't make a decent buck because some hacker uploaded his wares for free.
The problem isn't the one person who steals and keeps it to himself, it's the one person who makes it easy for everybody to steal.
Nope, piracy has very very little effect on profit. Why? Because pirates are not customers. They are not gong to buy your app no matter what. If you somehow made a app that could not be cracked you would get no more sells.
Nope, piracy has very very little effect on profit. Why? Because pirates are not customers. They are not gong to buy your app no matter what. If you somehow made a app that could not be cracked you would get no more sells.
I don't know how much effect it has on profit, but it definitely has some effect. Do you think that pirates are people who would never play video games but for piracy? Some, for sure, but I don't think that the entire pirate population is made up of people who wouldn't have bought any games if we were still in the 16-bit era, where piracy was impractical. Its not that piracy has no effect on profit, it's the timeframe when the piracy happens, like rip-off said.
Are you sure about that? All the times I have read about it, it worked by writing to memory on every vsync interval. Perhaps this only functioned this way on later systems?
[quote name='Anthony Serrano' timestamp='1302234550' post='4795810']
...
The PS, N64, and later models of the Game Sharks and competitors even came with debugging tools you could run to find the addresses you wanted to patch over. On an RPG you'd have 500 codes for all the stats on all the various characters.
On some games you couldn't get infinite health or ammo because there wasn't a constant location for these values. The player was just another random entity, and it changed based on level size and difficulty.
On other games, you'd have a different codes for every level!
[/quote]
Game Sharks operate very differently from Game Genies, because they operate on systems with significantly different program storage schemes, based upon the speed of the storage medium.
One scheme, used on systems where the storage medium is as fast as system RAM (i.e. all consoles up through the 16-bit era and all handhelds up through the GBA), runs code directly from the ROM, and therefore only has a small amount of system RAM for storing variables. Because they run directly off the cartridge ROM, the entire CPU bus runs to the cartridge connector - and because of this, it's trivial to insert a new device between the cartridge and the console to monitor ROM reads and substitute your own data in place of the data from ROM. However, because the system RAM control signals are not brought out to the cartridge connector - they don't need to be, after all - it's incredibly difficult to alter or mask RAM data without causing bus contention, and because there's no area of system RAM that is guaranteed not the be used by the game code, you can't easily install your own interrupt handler to patch RAM while the game is running, either. Additionally, many games on these consoles use strict timing loops, and can break horribly if some other code is stealing processing time from them. Game Genies were exclusive to this type of system.
The other scheme, used on systems where the storage medium is far slower than system RAM (i.e. all disc-based systems, the N64, and the DS), is very different. Because the storage medium is slow, they instead have a much larger amount of system RAM, and load code and data from storage into RAM before doing anything with it. Thus, the storage medium is not exposed to the full CPU interface - rather it is accessed through a separate device with a command-based interface for fetching data off the medium. Thus, when the system boots, it can't boot directly into the game - the CPU by itself doesn't know how to control the storage device. Instead, these systems boots into a BIOS that is responsible for system initialization and device management; the BIOS typically copies itself, into system RAM (for faster execution speed), loads the game's boot sector, and starts the game up.
Because the storage medium is not exposed to the full CPU bus, it's extremely difficult to intercept data and patch as it is being read. On the other hand, it's possible to in essence "hijack" the boot sequence, causing the CPU to boot your own code rather than the game, which then installs it's own interrupt handlers - typically into unused portions of the BIOS shadow in RAM - and then boots the game as normal, allowing it to easily patch system RAM while the game itself is running. This is the method used by most forms of Game Shark.
And this distinction between different types of console cheat device is why I made sure to restrict my original post to the Game Genie, rather than referring to cheat devices in general.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
