Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
[TUT] Introduction To OllyDbg And How To Find Your Way Around It
#1
Introduction To OllyDbg And How To Find Your Way Around It

Hello!
Once again guys I am back with another tutorial. This time I'm going to be discussing the program OllyDbg and giving you a brief introduction on how to use it/find your way around it. I will be asking you to install it at some point during this tutorial because it is REQUIRED for you to totally understand the tutorial and it also the program you will use when we start modifying the Little Fighter 2 program. So to start...

OllyDbg is a 32-bit assembly level analysing debugger. Thats all well and done but what does it mean? Lets start by taking a look at the word debugger. OllyDbg is a debugger that is used for debugging or locating and correcting errors in an executable file, like that of the Little Fighter Program.

Okay now for the slightly more tricky understanding in my opinion; assembly. Assembly level is the level of coding or programming just before machine code. It is the closest thing to machine code that a human can understand fully and write programs in, otherwise known as a low level language. Does that mean that there is a high level language? Yes, not just one, but lots of them. Examples of high level languages include C, C++ and C# (just to note down all the C's). 32-bit assembly level is Assembly written for programs or computers that can utilise or move memory in 32-bit groups.

That is all simple yes? So now lets put it all together. OllyDbg is used to analyse and locate or correct errors in 32-bit executable files. Now thats in a whole lot more easy context, we can begin looking at the program.

So why is OllyDbg important? You're going to be using it (in the majority of cases) more than any other Hex or .exe editing tool when you are looking at the Little Fighter program. So now lets get on to the actual inspection of this program.


Download:
http://OllyDbg.de

Download the program from the link given above. You're looking to download OllyDbg110 (not 2.0) which should be in a link on the left hand side of the web page.

Now once you've downloaded it, extract it to your desktop. Note that you do not need to install the program, you just need to run it. For Vista and Windows 7 users, I suggest right clicking and run as administrator - it gives you a pop up otherwise which you and I would much rather avoid than have to close down every time we open up the program.

Now once its open you should see either a white screen with four main panels, one of them with Registers written at the top of it or you will see a grey screen. If it's the grey screen then click on "View" and click on "CPU" from the drop down list. Now you should definately see four white panels on the screen stuck together, similar in appearance to this:

Numbered Screen (Slightly Large Image Warning) (Click to View)
I have numbered each of the panels that we see infront of us. So I'm going to give a brief look at each of the panels quickly so you can understand what they are:

1) CPU/Coding Panel -
The largest panel on the screen is the most important panel on the screen. The CPU or Coding Panel is where all of the Assembly code is produced or viewed when you are looking at an executable (.exe) file. In almost all of the Hex/.exe Editing tutorials or works produced by Silva and other Hexidecimal/Debugging experts you will have had to use this section of OllyDbg. This will be true to all the tutorials here to come, you will use this panel most of the time.

2) Registers Panel -
The Registers Panel is to the right hand side of the CPU/Coding Panel. This panel holds the information on standard registers, flags, section registers and extra information on FPU, MMX, Debugging, etc. As you go through the code it will be obvious to notice that the contents, register values and flags may change. They will not be the same everywhere that you look.

3) Stack Panel - This panel holds addresses for the program which you can then find in the disassembler/cpu section or in the memory dump section. These addresses can either be given as virtual addresses which identify virtual (non-physical) entities (used in virtual memory and virtual network addresses) or an offset (an integer that indicates the distance of the beginning of an object up to a specific element or point) from a specified or 'direct' address. Each four byte section is displayed as a hexadecimal value, which can then be shown as ASCII or UNICODE or not at all. Some extra comments like those in the CPU/Disassembly panel are also shown.

4) Memory Dump - This panel is a dump for any memory addresses in the program. Raw data is given alongside these addresses and the data can be displayed in ASCII, UNICODE, etc. The data can then be edited in a similar fashion to the disassembler itself. Each line represents one 32-bit section. Alongside the Disassembler/CPU panel, you will use this panel most.


Okay we've now become familiar with the panels we'll start looking at the program a bit more in action. To do this, you're going to need an UNMODIFIED LF2 v2.0a. If you use a different version chances are you may not be able to keep up with what I'm going to do in this tutorial.

If you haven't already got an unmodified LF2 v2.0a, here is the link to download it:
http://www.lf2.net/dn_fx.html

Just click the 'download now' button under the picture and it then you'll be directed to a new page where you get a pop up screen for the program download. Once you've downloaded it, install the Little Fighter program.


Okay, now in OllyDbg we are going to go to either:
1) Click File ---> Open
2) Press F3
3) Click the Folder Icon

This will bring you to a small window where at the top it reads:
"Open 32-Bit executable"

You will now go through to the folder where you installed LF2 v2.0a to, for most of you this will be:
Drive C: ---> Program Files ---> LF2_v2.0a
Then click the Lf2.exe icon and click open.

Your screen should now look like this:
Loaded Up Screen (Click to View)
As you more than likely cannot see the writing, this is the first four lines you should see in the disassembler/CPU:
    ASM-Code:
00445560 > $ E8 F8040000    CALL lf2.00445A5D   ; This line is highlighted in grey/black
00445565   .^E9 35FDFFFF    JMP lf2.0044529F
0044556A  /> 55             PUSH EBP
0044556B  |. 8BEC           MOV EBP,ESP



Now you can probably understand why I showed you the blank OllyDbg window first in this tutorial... it doesn't scare you off. Right now several of you (this happened to me as well) looked at the massive amount of EAX's, MOV's, DWORD's, numbers, etc and this thought ran through your mind or out of your mouth:
"OH MY BLOODY GOD, WHO ON THIS BLOODY PLANET CAN UNDERSTAND THIS!?"

Fortunately for you, this tutorial will not require us to go in depth into the language or for me to explain it to you. This is going to be a simple moving your way around the program kind of tutorial. So let us continue.


Running and Restarting
For a debugger to find any flaws in the code you need to be able to run the program. Well, this is possibly the easiest task I will ever set you in OllyDbg, so there is no need to worry about your skills, just familiarise yourself with the controls. Test out each of the following methods to run the program to make sure you understand:

1) Click Debug ---> Run
2) Press F9
3) Click Play Button


The Little Fighter program should now have started loading. It should then pop up on your screen or on your task bar. Feel free to click on it and play it, but make sure you can see the Disassembly panel in full when you do. When you're playing it for however long, keep looking at the panel.

Keep the Little Fighter window up after you've done playing, what special feature did you notice on the OllyDbg? Were you paying enough attention? If you can honestly say you saw absolutely nothing change then you were paying enough attention. Now close down the Little Fighter window. DAMN! The code jumped to some number beginning with 7?

Well, now we have a choice on how we're going to get back to the start of the code, which is vital if we really want to look throughout the program. So here's what we can do:

1) Close down the window in OllyDbg by clicking the exit button and reload everything (most time consuming).
2) Click Debug ---> Restart
3) Press Ctrl + F2

Now if you've done that correctly we're back at our first step, yay us!


Stepping Over, Stepping Into and Goto Expression
Alright, so we've learnt how to run our program and restart it just in case we lose our place. Unfortunately as you might have realised, we're running way too quickly through this code for us to really analyse it and do any work on it. What we really want is a way to go step by step through the code so that we can see what bits we like or don't like, and what bits we want or do not want to modify.

OllyDbg as a debugger requires the ability to do this for it to be an effective debugger. So that is absolutely perfect, we don't need to keep clicking through the code, we have something that does it for us. However, before we're going to do this, I want you to quickly look at the Registers panel (panel 2 in first image). It should look something like this:

Registers Panel (Click to View)
Note how it says this:
    ASM-Code:
EDX  00445560  lf2.<ModuleEntryPoint>


That shows you that the command or code:
    ASM-Code:
00445560 > $ E8 F8040000    CALL lf2.00445A5D


Is the 'Entry Point' of the program. This is where the code is read first when the program is loading up. So that's good news, we never have to hunt down the entry point for the Little Fighter 2 program. Note, that is entry point is not the same for all programs, it is only the entry point for LF2. So before we continue, lets note down the address:

00445560

We're going to need to remember that for whe we wish to get back to the Entry Point without restarting. So now lets get back on to the task at hand.

'Stepping over' is the process of going through code line by line in OllyDbg. It can be done by one of two methods:

1) Click Debug ---> Step Over (Slower)
2) Press F8 (Faster)

So lets quickly 'Step Over' onto the next line of code. We should now be on this:

[Code=ASM]00445565 .^E9 35FDFFFF JMP lf2.0044529F[/code]

Take a look at the Registers Panel again and you'll find that it has changed.

Registers Panel (Click to View)
Note how we can no longer see the <ModuleEntryPoint> and instead see something along the lines of this:

    ASM-Code:
EDX  770964F4  ntdll.KiFastSystemCallRet


As you step through code the Registers Panel will constantly change its information. But this is just going to be an observation for now, most of the time this will not be relevant to you in your work on modifying the Little Fighter program, so let us continue once more.

Press F8 again to step over the code to the next point. Damn, we're at a completely different location and none of the code looks the same! This is now the perfect point for me to explain to you a tiny amount about the JMP and CALL commands. Both of them are used to get the computer or machine to read instructions or code elsewhere in the program. So why didn't it change what we saw on the screen when we stepped over the CALL command? Good question. The JMP command is otherwise known as the "Jump" command. What it does is it sends the machine to an address where the machine then continues from there. With the CALL command, the machine is told where it needs to read some code from but it continues to read code after the CALL command. Thus you do not see the jump, it's still reading on from the last point.

So let's go back to the CALL command at the Entry Point of the program. How are we going to do this? We can do this in two ways, using the address we had before. So I'll show them here:

1) Right Click ---> Go to ---> Expression ---> 00445560 ---> OK
2) Press Ctrl + G ---> 00445560 ---> OK

Of course there are other ways to get back to it, but if you're really interested in a certain code the best option is to note down the address. You can then goto the address as it's shorter to type in and therefore easier to remember.

Most of you will wonder why we didn't press Ctrl + F like we do in all sorts of programs. Well it is used for finding stuff yes, it's used for searching for commands. Why didn't we use that? Commands are longer to type, and I doubt you would rather keep writing down commands you need to find when you realise that some lines have the same command.. oops. It's much easier to note down the address and goto the expression instead, also a lot less time consuming in most cases.

We should be back at the Entry Point now. We shall now see what code is being read through the CALL command. To do that we can go about in either of these two methods:

1) Click Debug ---> Step Into
2) Press F7

After we've done that, you should arrive at a screen like this:

Stepped Into (Click to View)
What you've just done is gone into the CALL command and address it tells the computer to read, which low and behold has a whole lot of new commands - YAY! However I am not going to explain what they mean for now, I am going to leave you to play around for a bit. Practise going through the 'Stepping Over', 'Stepping Into' and 'Go to' commands. Once you have done playing around with those commands, move on to the next section of the tutorial.


Breakpoints
Alright, press Ctrl + F2 if you haven't already to get back to the Entry Point of the program. We're now going to delve into the world of Breakpoints. Breakpoints are pauses within a program at certain points mainly for the purposes of debugging. This allows the person inspecting the code or program through the means of debugging to look at and test different bits of the code. It also allows them to inspect register values and other sorts of bits and pieces.

So what we're going to do in this part of the tutorial is set breakpoints, and give you a general idea of CALL and JMP commands first hand. So lets begin with how to insert breakpoints. There are many different ways to insert them and many different ways in which they function, for this tutorial though I am only going to explain your basic breakpoint. So there are two ways of inserting breakpoints:

1) Right Click ---> Breakpoints ---> Toggle
2) Press F2

So lets start off by 'Stepping into' the CALL command at the Entry Point. Press F7 to go into the CALL command. Now press F2 then F8 two times, followed by F2, and then F8 four more times before F2 again. Your screen should look something like this:

Breakpoints In CALL (Click to View)
As you can see, these little red markings on the address signal for breakpoints. So to prove that the CALL command gets the machine/computer to read these instructions we're going to restart the program using Ctrl + F2. Then we're going to run the program using F9. BAM! The program stopped at the first breakpoint, but didn't we restart the program?

OllyDbg remembers the breakpoints you put in a program, no matter how many times it has been restarted. So, lets just see what happens when we press F9 again. Once again the program is stopped from being read at the breakpoint. By pressing F9 and running the program again it will stop at our last breakpoint. So... what happens when we press F9 one last time? You guessed it, the program just continues being read as there are no more breakpoints. WOOHOO! As the program is still running, let us remove the breakpoints by clicking on their lines and removing them the same way we added them (press F2).

Now to show you the difference between CALL and JMP before your very eyes. So let us click on the JMP command line and press F2. This will set the breakpoint on that line. And then we'll click on the line below it and also press F2 to give it a breakpoint.

Breakpoints Set (Click to View)

We'll quickly press F8 to get OllyDbg reading the JMP command instead of the CALL command and we'll press F7 to 'Step Into' the JMP command. We'll press F2 to set another breakpoint and then press F8 twice and F2 once more to set the last breakpoint.

Last Breakpoints (Click to View)
Now we're going to press Ctrl + F2 to restart the program. Then we will press F9, as expected the program has stopped being read at the JMP command. So what we'll do is press F9 again. The program then stops at PUSH command and then if we press F9 again it stops at the next CALL command. Lets press F9 one more time after this. The program fully loads up... hmm, interesting. Lets click on the two lines after we went into the JMP command and remove the breakpoints. We'll then close down the Little Fighter window that popped up and press Ctrl + F2 to restart the program in OllyDbg.

Now lets go through it again, press F9. It's stopped at the JMP code as it had done last time. Now lets press F9 again. The Little Fighter window loaded up perfectly! How can this be? As I said before, JMP makes the machine change location of what its reading entirely, it doesn't 'Step Over' the JMP command and so that line isn't accessed. So you're bound to ask: Why on earth have that line there then? If it's not useful what is the point in it?
Answer: Who said there wasn't a point in it? It just isn't involved in the start up of the Little Fighter program window. It may well be useful later on in one of the game modes or during one of the fights where suddenly everything just stops working. Now wouldn't that be a lol?

Now would be a good time for you to restart the program using Ctrl + F2. After you've done that, click on the lines with breakpoints and remove them by pressing F2. You've now completed the breakpoints section of the tutorial. So let us move on to the next part.


Comments
To make code easier to understand, most people add comments to it. These are generally sections that the machine or computer does not read or take into account when running the program. They're visible only to the reader so that they may understand the code that is going on better.

I'm going to teach you how to add comments. It's a simple process and will only take up a short section of this tutorial. So please read it. Here is how we'll add a comment:

1) Right Click ---> Comment ---> Type In "This Is A Comment Example" ---> OK

2) Press ; ---> Type In "This Is A Comment Example" ---> OK


Oh look, our comment appears next to the code, like so:

    ASM-Code:
00445560 >   E8 F8040000    CALL lf2.00445A5D                        ;  This Is A Comment Example


Now you can add comments to your work. This should make your work slightly easier to read and to understand when you come back to it later.


Searches
You must be really dedicated to making your way towards becoming a Hex Editor/Exe modifier. This hasn't exactly been a short tutorial and you seem to have stuck through all the different sections and more than likely went through all the activities. If you have done so, well done. If you haven't, go back and do it or if you're too lazy - I suggest you stop reading this tutorial. There is no point in doing this if you do not wish to progress any further.

In this next section, I'm going to keep you up to scratch with using searches in OllyDbg. Yes we have already covered the use of 'Go to' feature, but what if we don't know the address of what we want? Well if we know different details then we can go about it different ways. So I'm going to show you a few of the ways.

1) Ctrl + F (Search For Command) -
If you know the command you are looking for then this is definately an option for you to search. What you simply have to do is press Ctrl + F or:

Right Click ---> Search For ---> Command ---> Type It In ---> Find

You can then type in the command that you are looking for, for example we're going to type in:

PUSH EBP

When you click on the Find button, the next four lines of code at the top of the Disassembly panel should look like this:

    ASM-Code:
004013FB  |. 55             PUSH EBP
004013FC  |. 57             PUSH EDI
004013FD  |. 56             PUSH ESI
004013FE  |. FFD1           CALL ECX


Well done, you've executed your first Command search. Unfortunately what you probably didn't think about before you did this (unless you're TheNave, Silva or other experienced .exe modifiers, or someone with an ounce of common sense) is that there is more than one line that has this command. Great, so lets try doing the command search again.

By repeating the steps above you find that you are... at exactly the same place? How can this be if there's more than one line with that code? Okay lets move on to finding the rest of them. This is what you're going to do:

Right Click ---> Search For ---> All Commands ---> Push EBP

Your OllyDbg screen should now look like this:

All Command Full (Click to View)
or like this:

All Command Mini (Click to View)
Either way, you've just taken a quick glimpse into raw hell. You now know why I told you NOT to use the 'Search For -> Command' earlier, it's just far too much hassle for you. You only need to use it when you can use a useful command line, but we'll go into that in other tutorials. For now, just use Ctrl + G (Go to) and type in 00445560 to get back to the entry point.


2) Search For: All Intermolecular Calls
Suppose you want to see all the different CALL commands in the program. This is probably a better way of looking at the CALL commands then doing the 'Search For: Command' to look for a CALL. What you do is this:

Right Click ---> Search For ---> All Intermolecular Calls

Similar to with the 'Search For: Command' window that pops up, you should get OllyDbg to look like this:

Intermolecular Calls Mini (Click to View)
Or this:

Intermolecular Calls Maxi (Click to View)

Feel free to run yourself up and down the list. There are some problems with this method still as some CALL commands may lead you to the same place. This is a lot less frequent than finding the same command over and over again in the 'Search For: Command'. Well I guess it's time to close that window and then once again Ctrl + G to the address 00445560.


3) Search For: All Referenced Text Strings
Right, searching for Strings will take you to sections where a certain word or phrase is produced, even an error message. So what we're going to do is find out about this String search.

Right Click ---> Search For ---> All Referenced Text Strings

You should get OllyDbg to look either like this:

String Mini (Click to View)
Or this:

String Maxi (Click to View)

Either way, it doesn't matter. Unlike in the other two sections of searching I have shown you, this one we're actually going to do some more in depth searching. So here is what you're going to do:

Right Click (In The New Window) ---> Search For Text ---> Tick Checkbox "Entire Scope" ---> Type In "hit_Fa" ---> Click OK

You should get a screen that looks like this:

hit_Fa Search (Click to View)

Feeling happy now aren't you? You found something which most of you can understand from your DC work and with very little fuss at all. So lets go find out some more about the code around it! So here's what you're going to do:

Right Click On The Line ---> Follow In Disassembler

You'll then reach a page with coding like this:

    ASM-Code:
0040D353   . 68 44804400    PUSH lf2.00448044                        ;  ASCII " hit_Fa: %d"
0040D358   . 56             PUSH ESI
0040D359   . FFD7           CALL EDI
0040D35B   . 83C4 0C        ADD ESP,0C
0040D35E   > 8B85 D8070000  MOV EAX,DWORD PTR SS:[EBP+7D8]


Wowza. We've learnt to find code related to specific strings. Now, lets see what the line is in the memory dump.

Right Click The Line ---> Follow In Dump


Your Memory Dump should now look like this:

Memory Dump (Click to View)
Not something you will find particularly easy to understand. In fact, by the looks of it, that is no use to you at all is it? But I'll give you a slight tip, looking at the first 5 double digit numbers in the Hex Dump (in your Memory Dump) and then look at the second column of the Disassembler from the left along the same line as "hit_Fa". They're exactly the same! Well spotted, that was just an observation though... nothing important to you... well for now most probably.

That is all I am going to teach you as of searches for now. It is my highest doubt that you will ever need most of the searches, if I am wrong I will simply cover them in a later tutorial. Now on to the final task at hand.


Modifying
Yes the one part of the tutorial that most of you have been waiting for; the chance to modify the Little Fighter program! This is possibly what you've all been thinking about the whole tutorial - why won't he get on with it. Well truth be told, you're not actually going to be modifying anything in this tutorial.
Reader/Pupil/: WHAT!? ARE YOU SERIOUS!?
Me: Yes, deadly.

If you've been reading through this tutorial as thoroughly as you should have been to get to this point, then it is next to impossible for your mind to really take in too much more information. So I'm only going to outline HOW you would go about modifying, not actually demonstrating any modification to you. If I explained the modification process, it'd mean I'd have to explain some of the code and what it's there for - not going to happen.

So let us begin the short lesson on modification of the program. Before you do anything towards changing or editing the code - YOU MUST MAKE A BACK UP OF THE .EXE FILE. If you make one mistake in the .exe you will find yourself in a bit of a pickle and your favourite game/program may have to be reinstalled again. If you downloaded it off the internet then deleted the downloadable files - serves you right if you don't make a back up. I suggest making a folder on your desktop named "back up exe's" or "original files".

Next is the very simple process of how to modify. Here is how you do it (please restart the program using Ctrl + F2 before you try this):

1) Press Spacebar
2) Right Click (in this case on CALL command) ---> Assemble

You should now have a little screen pop up. In this screen we would normally edit the code that goes into it by typing the instruction and then pressing Assemble. You are not going to do this right now so I suggest pressing Cancel.



We've finally reached the end of this tutorial. Hopefully you have gained a lot through reading this tutorial, it's taken me most of the week to write and then rewrite because I lost it, touch it up so the language was easy to understand, add screenshots and the like. I have to say its been one of my biggest tutorials so far in terms of size if not the biggest.

In summary, what you should have learned through this tutorial:
- What a Debugger is
- The layout of OllyDbg
- How to add comments
- How to modify (briefly)
- How to search through a program's code
- How to use Go to
- How to insert breakpoints
- How to Step Over and Step Into
- How to Run the program
- Brief introduction to JMP and CALL commands including similarities and differences
- Different types of searches
- How to restart the program within OllyDbg

I am sorry that I went so in depth with the tutorial, but it is better that way I suppose. If I didn't go in depth in the parts that might have needed it, then you wouldn't have understood it so well. For those of you 'Work Dodgers' you managed to escape narrowly without having to answer questions and for those of you 'Work Lovers' I am sorry I hadn't included any questions, I just didn't deem them necessary as part of the main tutorial.

Also quite a lot of you were expecting me to do a tutorial involving all the different programs that you may be using when trying to modify Little Fighter programs or other programs. The reason I have done OllyDbg seperately is because it is on a whole other level to the uses that you have with the other programs I'll be showing you. It takes a lot more time to explain in my eyes and so deserves a complete post of its own.

Okay, most of you are probably asking what tutorials are to come and how long they are going to be. There are quite a lot of tutorials to come and they will all be relatively long, some longer than this one and some shorter. I plan on only passing on the information you need to become proficient with the tools, languages and understanding and no further. I am not going to make you become absolute masters of the coding and programming languages, but I will not just scrape the surface on any of my subjects.

The tutorials that you can look ahead to:
- Introduction to ResourceHacker and Hex Editors (including Hex Workshop as a main Editor)
- The Basics of Assembly
- The Basics of C++
- Deeper Assembly and C++ Tutorials
- Specific Little Fighter Modifications (eventually involving the addition of new states and Itr's - when I get around to studying the program enough myself)
- Many, many more.


So yeah, this will not really be a short term fixture. I intend on keeping these tutorials coming for as long as there are people that may wish to read them or may inhabit this site/forum.

Now for a few side notes:

1) If you wish to take this tutorial and put it on another Little Fighter forum or website please come to me for permission to do so. I am not saying this because I feel harsh, I am saying this because I had intended on this tutorial giving people on Little Fighter Empire an upper hand or advantage against the other forums for Little Fighter programs. I also had a very polite young lady ask me through PM if she could take my last tutorial and put it on her school system, of course I gave her permission.

On the condition that I do give you permission, please state who wrote the tutorial and where it was from. It's only polite and is a good precaution against plaguerism.


2) For those of you that are interested, may you please post a reply if you want me to add some questions within the next few days for you to do. If not questions then ask and I will post some activities for you to try out where you can search through code and test your understanding of the tutorial. In general, just give me comments and criticism, it'd be great to improve in my next tutorial and make it more understandable for those of you who read the whole post (hopefully the majority).

Once again guys thank you for reading, it's been a pleasure to spend a lot of the last week writing this tutorial. And on one last note, based upon somewhat of a Hex Editing/Exe Modifying hero on these forums, Silva said:
'Not enough people read long posts'
Maybe it is a good idea if a lot of us start. If you don't read the length of my posts, most of the time you will not understand what I'm saying and so your replies will be useless.
If I have covered a topic that your reply specifically indicates and shows you haven't read it, I expect other forum members if not myself to simply tell you to 'read the first post'. I'm not trying to be harsh, but it will help you in the long run as most people will eventually tell you.


Thank you and I hope this helps,

Eddie

P.S - I think I just came up with a decent name instead of 'Unique Member'; Slave Driver. I've probably said it before, but the title fits.
One day, I shall become, TUTORIAL-MAN: Superhero of writing overly long, overly annoying tutorials which most people probably won't read, but will give it a stab at the first 5 lines!
Reply
#2
tl;dr


Reply
Thanks given by: Eddie
#3
MH'd better get his a** in here and stick your tutorials on the main site.
Reply
Thanks given by: Eddie , Bamboori
#4
u missed out all the tracing tools in olly :( - pretty much the only thing u will end up using besides breakpoints in olly and the totally awesome "-" and "+" keys which let you go back through addresses u select so u dont have to write them all down

ur explanation of the jmp/call stuff is pretty confusing as well(for me anyways) - they r essentially the same except a CALL remembers where it was called from and normally will return there using a RETN(doesnt matter how) while a jmp doesn't remember anything and just jmps

stepping into and stepping over are essentially the same as well - except stepping into will go into CALL's and stepping over will break after the call is returned from - neither of them skip code execution

other than that gj
...
Reply
Thanks given by: Eddie
#5
Well what he wrote was the first-hand experience of someone stepping from the shallows into deep waters for the first time. I, for one, understood him perfectly.

"HOLY K0A1A5!!! BLOW_FLY PRESSED THE +REP BUTTON!!!"
Hiding users' signatures and avatars was the best decision ever.
4ye 6anDy (Click to View)
We're watching you... (Click to View)
| Avatar made by Alectric |
Reply
Thanks given by:
#6
(11-11-2011, 12:05 AM)pmolson Wrote:  Thanks for the ODBG tut! the issue I have is as follows:

To login to the agent software (I'm trying to find what the password is for) I have to use Hot Keys. iow, there is no file that I can drag onto odbg and open it. Once the gui opened up for me to input the password, I've tried dragging that (the gui) to Odbg, but to no avail. Note that when I open the agent software (monitoring tool) installation file with odbg and try to do a text search I get an odbg log that says installation failed to launch....

Any help is greatly appreciated!

-P
I think U gotta make this as a separate thread bro.

[Image: signature.png]
A-Engine: A new beat em up game engine inspired by LF2. Coming soon

A-Engine Dev Blog - Update #8: Timeout

Reply
Thanks given by:
#7
I just did...Thanks Bro!
Reply
Thanks given by:
#8
This is like i am reading some book.Sry but i didnt read it. :(
Reply
Thanks given by:
#9
Your tutorial is crap. You got the VERY FIRST PART WRONG!!!!!

Quote:You will now go through to the folder where you installed LF2 v2.0a to, for most of you this will be:
Drive C: ---> Program Files ---> LF2_v2.0a
Then click the Lf2.exe icon and click open.

Your screen should now look like this:
Loaded Up Screen (Click to View)
As you more than likely cannot see the writing, this is the first four lines you should see in the disassembler/CPU:
    ASM-Code:
00445560 > $ E8 F8040000    CALL lf2.00445A5D   ; This line is highlighted in grey/black
00445565   .^E9 35FDFFFF    JMP lf2.0044529F
0044556A  /> 55             PUSH EBP
0044556B  |. 8BEC           MOV EBP,ESP


The first 4 lines of code are NOT
    ASM-Code:
00445560 > $ E8 F8040000    CALL lf2.00445A5D   ; This line is highlighted in grey/black
00445565   .^E9 35FDFFFF    JMP lf2.0044529F
0044556A  /> 55             PUSH EBP
0044556B  |. 8BEC           MOV EBP,ESP


Heck, they aren't even in the module LF2.exe.

Instead the first 4 lines are:
    ASM-Code:
777801B8    895C24 08       MOV DWORD PTR SS:[ESP+8],EBX
777801BC    E9 E99C0200     JMP 777A9EAA
777801C1    8DA424 00000000 LEA ESP,DWORD PTR SS:[ESP]
777801C8    8DA424 00000000 LEA ESP,DWORD PTR SS:[ESP]


and they are in the module ntdll.exe

Apparently the game accesses ntdll.exe (part of the Windows operating system) before it accesses its OWN PROGRAMING CODE!

Now why don't you try to remake your tutorial again, WITHOUT THIS GLARING MISTAKE! I'm trying to learn Ollydbg myself (I'm a noob at it, literally just started a few minutes ago, never even TOUCHED the program before then). But I need a tutorial that ACTUALLY WORKS!

Now maybe it's the fact that my OS is Windows 7 HomePremium x64 instead of some other OS like Windows XP Home x86. But whatever the problem is, PLEASE FIX YOUR TUTORIAL, so I can follow it on MY COMPUTER (which may be a different setup than the one you used back when you wrote this tutorial).
Reply
Thanks given by:
#10
First of all welcome to the forum.

I haven't tried the tutorial myself, but whenever I open up "lf2.exe" it does almost exactly what it does in the tutorial, however the line is in the middle of the screen instead of at the top, so it is likely different depending on what computer setup you have.

You can however still carry on with the tutorial by using the go to command (Ctrl+G) and entering the address you'd like to go to. In this case "00445560".
Age ratings for movies and games (and similar) have never been a good idea.
One can learn a lot from reinventing wheels.
Gaming isn't hostile to women. It is hostile to easily offended idiots.
An unsound argument is not the same as an invalid one.
volatile in C++ does not mean thread-safe.
Do not make APIs unnecessarily asynchronous.
Make C++ operator > again
LFE Red Theme: 85%
Reply
Thanks given by: A-Man




Users browsing this thread: 1 Guest(s)