About Pointer Scanning - reverse-engineering

At the moment I am trying to find pointers myself in a Game without using any kind of additional software. I've been programming my own software but I couldn't come with a way of replicating, or finding a way of implementing Pointer Scanning or even a way to find pointers...
Can someone explain to me how it works, maybe even im missing fundamentals.
Extra question: Isn't pointers are just integers? That points to someother memory address? Can't we just read them by ReadProcessMemory winapi function?
Extra Question2: In cheat engine what does Green addresses mean when you search a value? (I think they are static? or pointers?) And how do cheat engine determine it?

A pointer is a variable which can contain a memory address, and it can be represented by an integer yes.
Pointer Scanner in Cheat Engine brute forces all pointer paths with the parameters you give it.
You give it an address to scan for, it scans for this address to find all pointers to it. It then subtracts a number like 0x1000 and then scans each one of those addresses in that range for pointers which point to those addresses. In this way it will find all 1 level pointer with an offset between 0 and 0x1000. Then it goes through this new list and does the same thing, going one level deeper. It keeps doing this until it either finds a static address or an address that is relative to a module's base address and it can't go any deeper.
The pointer "chains" as I like to call them are then listed in the pointer database.
Before you try to understand pointers in the context of reverse engineering you should become an adequate programmer, in this way your understanding of how pointers work moving forwards can be applied to your understanding of them going in the opposite direction, which is the process of reversing them.

Related

How to "broaden" an IPv6 to the network level?

I have IP addresses stored in a MySQL database and as I'm learning to run queries, one thought I had was to see if I could find entries that share a common network. To do this, I "broaden" my search by removing the last group of numbers from an IPv4.
So I'll do a LIKE search for an IP of XXX.XX.XXX. and see what comes up.
I have two questions:
Is what I'm doing stupid? Like, does trimming off the last group even achieve what I think I'm doing?
If not, how would I "broaden" a search for IPv6?
I've done some research on the groupings of IPv6, but I'm afraid I'm still not understanding what each grouping does. Admittedly I have only cursory knowledge of the anatomy of even IPv4.
Again, this isn't really a serious issue, but I couldn't find any information about something like this (which is what leads me to believe that I may not even be doing what I think I am doing)...
Is what I'm doing stupid? Like, does trimming off the last group even achieve what I think I'm doing?
To answer that first requires some definition of what it means to "share a common network". After all, the Internet itself is a "common network" that is "shared" by every device connected to it!
Network engineers tend to talk in terms of "domains": collision domains, broadcast domains, administrative domains, etc. At a guess, you might be thinking in terms of administrative domain.
For a short time in history, a chunk of the IP address space (known as "Class C" addresses) were assigned such that the first three octets indicated the network number, and therefore "trimming off" the final octet would (for that chunk of the IP address space) have behaved exactly as you describe.
However, since the introduction of CIDR, it no longer works like that: addresses can now be assigned in any (2-exponent) size of block and you cannot determine the size of the allocated block from the address alone. Moreover, blocks can be repeatedly subdivided and reallocated.
TL;DR—it's not clear what you think you're doing but in any event trimming off the last group probably doesn't achieve it.
Now, if you only want to determine whether a given address is on your network you can do so by performing a bitwise AND between it and your network mask; then comparing the result with the bitwise AND of your address and your network mask.
Beyond that, you'd need to lookup properties of the address in external datasets...

Chess Engine - Confusion in engine types - Flash as3

I am not sure this kind of question has been asked before, and been answered, by as far as my search is concerned, I haven't got any answer yet.
First let me tell you my scenario.
I want to develop a chess game in Flash AS3. I have developed the interface. I have coded the movement of the pieces and movement rules of the pieces. (Please note: Only movement rules yet, not capture rules.)
Now the problem is, I need to implement the AI in chess for one player game. I am feeling helpless, because though I know each and every rules of the chess, but applying AI is not simple at all.
And my biggest confusion is: I have been searching, and all of my searches tell me about the chess engines. But I always got confused in two types of engines. One is for front end, and second is real engines. But none specifies (or I might not get it) which one is for which.
I need a API type of some thing, where when I can get searching of right pieces, and move according to the difficulty. Is there anything like that?
Please note: I want an open source and something to be used in Flash.
Thanks.
First of all http://nanochess.110mb.com/archive/toledo_javascript_chess_3.html here is the original project which implements a relatively simple AI (I think it's only 2 steps deep) in JavaScript. Since that was a contest project for minimal code, it is "obfuscated" somewhat by hand-made reduction of the source code. Here's someone was trying to restore the same code to a more or less readable source: https://github.com/bormand/nanochess .
I think that it might be a little bit too difficult to write it, given you have no background in AI... I mean, a good engine needs to calculate more then two steps ahead, but just to give you some numbers: the number of possible moves per step, given all pieces are on the board would be approximately 140 at max, the second step thus would be all the combination of these moves with all possible moves of the opponent and again this much combinations i.e. 140 * 140 * 140. Which means you would need a very good technique to discriminate the bad moves and only try to predict good moves.
As of today, there isn't a deterministic winning strategy for chess (in other words, it wasn't solved by computers, like some other table games), which means, it is a fairly complex game, but an AI which could play at a hobbyist level isn't all that difficult to come up with.
A recommended further reading: http://aima.cs.berkeley.edu/
A Chess Program these days comes in two parts:
The User Interface, which provides the chess board, moves view, clocks, etc.
The Chess Engine, which provides the ability to play the game of chess.
These two programs use a simple text protocol (UCI or XBoard) to communicate with the UI program running the chess engine as a child process and communicating over pipes.
This has several significant advantages:
You only need one UI program which can use any compliant chess engine.
Time to develop the chess engine is reduced as only a simple interface need be provided.
It also means that the developers get to do the stuff they are good at and don't necessarily have to be part of a team in order to get the other bit finished. Note that there are many more chess engines than chess UI's available today.
You are coming to the problem with several disadvantages:
As you are using Flash, you cannot use this two program approach (AFAIK Flash cannot use fork(). exec(), posix_spawn()). You will therefore need to provide all of the solution which you should at least attempt to make multi-threaded so the engine can work while the user is interacting with the UI.
You are using a language which is very slow compared to C++, which is what engines are generally developed in.
You have access to limited system resources, especially memory. You might be able to override this with some setting of the Flash runtime.
If you want your program to actually play chess then you need to solve the following problems:
Move Generator: Generates all legal moves in a position. Some engine implementations don't worry about the "legal" part and prune illegal moves some time later. However you still need to detect check, mate, stalemate conditions at some point.
Position Evaluation: Provide a score for a given position. If you cannot determine if one position is better for one side than another then you have no way of finding winning moves.
Move Tree and pruning: You need to store the move sequences you are evaluating and a way to prune (ignore) branches that don't interest you (normally because you have determined that they are weak). A chess move tree is vast given every possible reply to every possible move and pruning the tree is the way to manage this.
Transpotion table: There are many transpositions in chess (a position reached by moving the pieces in a different order). One method of avoiding the re-evaluation of the position you have already evaluated is to store the position score in a transposition table. In order to do that you need to come up with a hash key for the position, which is normally implemented using Zobrist hash.
The best sites to get more detailed information (I am not a chess engine author) would be:
TalkChess Forum
Chess Programming Wiki
Good luck and please keep us posted of your progress!

What is a "badboy" in reverse engineering

Ok so I've recently started doing some reverse engineering, and I keep coming across a term (I think) I have no idea what it means? A badboy?
00013F92 7E 24 JLE SHORT function.00013FB8 ; badboy
Could anyone explain?
Maybe this is the answer:
http://www.codeproject.com/Articles/30815/An-Anti-Reverse-Engineering-Guide
Search for "bad boy".
Let me paste that in, four and a half years after the fact, to satisfy the moderator:
There are three types of breakpoints available to a reverse engineer:
hardware, memory, and INT 3h breakpoints. Breakpoints are essential to
a reverse engineer, and without them, live analysis of a module does
him or her little good. Breakpoints allow for the stopping of
execution of a program at any point where one is placed. By utilizing
this, reverse engineers can put breakpoints in areas like Windows
APIs, and can very easily find where a badboy message (a messagebox
saying you entered a bad serial, for example) is coming from. In fact,
this is probably the most utilized technique in cracking, the only
competition would be a referenced text string search. This is why
breakpoint checks are done over important APIs like MessageBox,
VirtualAlloc, CreateDialog, and others that play an important role in
the protecting user information process. The first example will cover
the most common type of breakpoint which utilizes the INT 3h
instruction.

How do I go about reverse engineering a UDP-based custom game protocol with nothing other than Wireshark?

How do I go about reverse engineering a UDP-based custom game protocol with nothing other than Wireshark? I can log a bunch of traffic, but then what? My goal is to write a dissector plugin for Wireshark that will eventually be able to decode the game commands. Does this seem feasible? What challenges might I face? Is it possible the commands are encrypted?
Yeah, it's feasible. But how practical it is will depend on the game in question. Compression will make your job harder, and encryption will make it impossible (at least through Wireshark - you can still get at the data in memory).
Probably the best way to go about this is to do it methodically - don't log 'a bunch of traffic' but instead perform a single action or command within the game and see what data is sent out to communicate that. Then you can look at the packet and try to spot anything of interest. Usually you won't learn much from that, so try another command and compare the new message with the first one. Which parts are in the same place? Which parts have moved? And which parts have changed entirely? Look especially for a value in a fixed position near the start of the packet that could be describing the message type. Generally speaking the start of the packet will be the generic stuff like the header and later parts of the packet will be the message-specifics. Consider that a UDP protocol often has its own hand-rolled ordering or reliability scheme and that you might find sequence numbers in there near the start.
Knowing your data types is handy. Integer values might be stored in big-endian or little-endian format, for example. And many games send data as floating point values, so be on the look-out for 2 or 3 floats in a row that might be describing a position or velocity.
Commercial games expect that people will try to hack the protocol as a means to cheat, so will generally use encryption and probably tamper-detection as well.
Stopping this type of activity is of great concern to game makers because it ruins the experience for the majority of players when a few players have super-tools. For games like online poker the consequences are even more severe.

how are serial generators / cracks developed?

I mean, I always was wondered about how the hell somebody can develop algorithms to break/cheat the constraints of legal use in many shareware programs out there.
Just for curiosity.
Apart from being illegal, it's a very complex task.
Speaking just at a teoretical level the common way is to disassemble the program to crack and try to find where the key or the serialcode is checked.
Easier said than done since any serious protection scheme will check values in multiple places and also will derive critical information from the serial key for later use so that when you think you guessed it, the program will crash.
To create a crack you have to identify all the points where a check is done and modify the assembly code appropriately (often inverting a conditional jump or storing costants into memory locations).
To create a keygen you have to understand the algorithm and write a program to re-do the exact same calculation (I remember an old version of MS Office whose serial had a very simple rule, the sum of the digit should have been a multiple of 7, so writing the keygen was rather trivial).
Both activities requires you to follow the execution of the application into a debugger and try to figure out what's happening. And you need to know the low level API of your Operating System.
Some heavily protected application have the code encrypted so that the file can't be disassembled. It is decrypted when loaded into memory but then they refuse to start if they detect that an in-memory debugger has started,
In essence it's something that requires a very deep knowledge, ingenuity and a lot of time! Oh, did I mention that is illegal in most countries?
If you want to know more, Google for the +ORC Cracking Tutorials they are very old and probably useless nowdays but will give you a good idea of what it means.
Anyway, a very good reason to know all this is if you want to write your own protection scheme.
The bad guys search for the key-check code using a disassembler. This is relative easy if you know how to do this.
Afterwards you translate the key-checking code to C or another language (this step is optional). Reversing the process of key-checking gives you a key-generator.
If you know assembler it takes roughly a weekend to learn how to do this. I've done it just some years ago (never released anything though. It was just research for my game-development job. To write a hard to crack key you have to understand how people approach cracking).
Nils's post deals with key generators. For cracks, usually you find a branch point and invert (or remove the condition) the logic. For example, you'll test to see if the software is registered, and the test may return zero if so, and then jump accordingly. You can change the "jump if equals zero (je)" to "jump if not-equals zero (jne)" by modifying a single byte. Or you can write no-operations over various portions of the code that do things that you don't want to do.
Compiled programs can be disassembled and with enough time, determined people can develop binary patches. A crack is simply a binary patch to get the program to behave differently.
First, most copy-protection schemes aren't terribly well advanced, which is why you don't see a lot of people rolling their own these days.
There are a few methods used to do this. You can step through the code in a debugger, which does generally require a decent knowledge of assembly. Using that you can get an idea of where in the program copy protection/keygen methods are called. With that, you can use a disassembler like IDA Pro to analyze the code more closely and try to understand what is going on, and how you can bypass it. I've cracked time-limited Betas before by inserting NOOP instructions over the date-check.
It really just comes down to a good understanding of software and a basic understanding of assembly. Hak5 did a two-part series on the first two episodes this season on kind of the basics of reverse engineering and cracking. It's really basic, but it's probably exactly what you're looking for.
A would-be cracker disassembles the program and looks for the "copy protection" bits, specifically for the algorithm that determines if a serial number is valid. From that code, you can often see what pattern of bits is required to unlock the functionality, and then write a generator to create numbers with those patterns.
Another alternative is to look for functions that return "true" if the serial number is valid and "false" if it's not, then develop a binary patch so that the function always returns "true".
Everything else is largely a variant on those two ideas. Copy protection is always breakable by definition - at some point you have to end up with executable code or the processor couldn't run it.
The serial number you can just extract the algorithm and start throwing "Guesses" at it and look for a positive response. Computers are powerful, usually only takes a little while before it starts spitting out hits.
As for hacking, I used to be able to step through programs at a high level and look for a point where it stopped working. Then you go back to the last "Call" that succeeded and step into it, then repeat. Back then, the copy protection was usually writing to the disk and seeing if a subsequent read succeeded (If so, the copy protection failed because they used to burn part of the floppy with a laser so it couldn't be written to).
Then it was just a matter of finding the right call and hardcoding the correct return value from that call.
I'm sure it's still similar, but they go through a lot of effort to hide the location of the call. Last one I tried I gave up because it kept loading code over the code I was single-stepping through, and I'm sure it's gotten lots more complicated since then.
I wonder why they don't just distribute personalized binaries, where the name of the owner is stored somewhere (encrypted and obfuscated) in the binary or better distributed over the whole binary.. AFAIK Apple is doing this with the Music files from the iTunes store, however there it's far too easy, to remove the name from the files.
I assume each crack is different, but I would guess in most cases somebody spends
a lot of time in the debugger tracing the application in question.
The serial generator takes that one step further by analyzing the algorithm that
checks the serial number for validity and reverse engineers it.