Figuring out how a program works

[Fishy80]

I'm wondering how people figure out how programs and systems work? for example...

how does someone figure out how the blizzard authenticator system works, and program their own custom authenticator...

or how do people find out exactly what warden was doing? (to make something like that warden watching program)

no I don't actually want to do that, but I would love to know the process behind it... which skillset is needed? I'm assuming reverse engineering.. maybe programming to understand what your reading? both? is it as simple as attaching a debugger and then... well I dunno, I've messed with ollydbg before, so I know that outputs some things, but is it just ollydbg and then understand what its saying?

any suggested programs or tutorials? places to start? sorry if anything like this has been asked already or if it seems like a stupid question, I just really don't know...

[chaddiablo]

Try spy++ . It comes with microsoft visual studio. I do not know how ever if you can get separate.
Spy++ looks at the window/process and it reads it out to see what that window/process is doing.

[DarkLinux]

IDA Pro + XRAY
Just look at The Pirate Bay . org

You Will find a free copy...

[Carebear]

Olly debugger is the best way to go, but takes some time to learn.

[Fishy80]

Thank you guys, now I do have somewhere to start =) and I do understand it a bit more now, makes sense =)

time to hit the books =)

[kixer]

Disclaimer: This is my point of view.

There are two main programming languages used on PCs today used for the "runnable programs". C and it's successors (C, C++, C#) and Java. C, C++ translate (compile) the program to bytecode (let's call this one native code) - set of instructions interpreted by CPU. C# and Java translate the program to another program (let's call this one bytecode), that is interpreted by a Virtual Machine (.Net or Java VM) - this is similar to CPU, the VM just translates the bytecode to native code.

To find out how program works:

1) you have the source code and understand it - this is pretty straight forward
2) you have the bytecode and a decompiler - this is very easy option. The current languages are well structured and there are many decompilers that will translate the bytecode or machine code back to the program in C, C++, C# or Java. I prefer this option. Works best with Java.
3) you have the bytecode and understand it - not many people understand the bytecode
4) you understand the native code - you can view the program in some dissasembler, that will show you the exact instructions interpreted by CPU. You can also hook such program to currently running program in memory. You will also see it's open handlers (like which file/library is it using) and memory range that it is addressing.

You can call 2,3 and 4 reverse engineering.

Where to start

I am not sure what is the best approach to start understanding programs. I've followed this path:

0) learned BASIC and ZX80 assembler (language of the native code instructions) myself. This is pretty much useless now, but I can figure out the native code of the today's processors more or less (but I don't do that).

1) very easy procedural programming language that looks similar to english - in my case this was Pascal (useless again), but you can start with lua, this is used in many games to alter their behaviour.

2) usefull procedural language - in my case that was C/C++

2.5) Haskell and Prolog at the University...

3) OOP (object oriented programming) language - in my case this was Java, the money maker...

4) scripting languages, very popular today. I've learned groovy, python and lua (started this weekend )

How Blizzard Authenticator works

This one should be pretty easy. There exists a Java authenticator for mobile phones. Mobile phones use very simple Java and the Authenticator is quite a simple program itself. So what you can do is download the Java authenticator, unpack the java archives, decompile it to Java source code. The program usually misses some variable names, but overall looks much like the original. And then study it.

All the modern languages looks pretty much the same, you won't make a mistake by learning any of them. If you want to perform reverse engineering, you should learn low-level stuff like assembler, C/C++, how memory allocation and addressing works and so on. You should learn the basics of operating system libraries, memory and file management.

If you want to make money, go for C# (Windows) or Java (everything else).

[danielrhodea]

wow!!! I understood parts of this thread, but not all of it. I believe the person wants to know how you know what a program is doing / how it uses it's data by viewing it in a debugger. The answer is, with lots and lots of practice, downloading idapro and xray will probably confuse you, as will trying to learn 4-5 languages (as the last post suggests).

I'd go with another option, learn the basics so get an understanding of asm and build a list of asm commands and what they do (so google mov ecx,0x50 for example), get a debugger like ollydbg, a hex editor like xvi32 and open up say wow.exe in ollydbg, then open a file in xvi, use an adt for example (conviniently forgetting extract the adt from the Mpq I know), then in ollydbg do a function search for the extension of the file, wow has countless %s.extensions, for finding specific file types, you can then follow the code copy and paste the asm and set about understanding it using google, forums and past experience.

To be completely honest I have been doing this for a while now and I've nearly given up trying to understand wow (it works on a rolling-release system so stuff keeps on changing, what you learn this week will be outdated in a month or so's time), it also means you'll need to look at the data instructions are operating on, so you may need to dump the programs memory a few times, check the registers, flags etc, it's one massive headache and if you simply want to do a few edit's it can be best to join a group of like-minded gamers

[Dragonef22]

Short:

there are programs to read packets =) with some skills your able to understand how it works

[Sychotix]

Short:

there are programs to read packets =) with some skills your able to understand how it works

um.... no. Packets are only showing you it interactions with external servers, not how the program itself works.

And you bumped something from 4 weeks ago.

[Dragonef22]

um.... no. Packets are only showing you it interactions with external servers, not how the program itself works.

And you bumped something from 4 weeks ago.

You might be right

Sorry for bumping this old thread, didn´t realize it, won´t happen again I guess