The Ollydbg Tutorial Thread

[Mr. Fatty]

OK first I read and re-read Sir_General's tutorial.
Awesome tutorial but I need more info on following the code as it happens.So here's what I did:I started D2 and entered a game the attached Ollydbg to D2Game.exe,then selected that same .exe from the executables menu.Then I use a townportal from a tome and switch back to Olly.I expected to see somewhere a code like sub eax,1 and I did,quite a few of em actually.I changed those to nop's but my tome still gets reduced by 1 each time I use it.Where did I go wrong?

Also Olly says paused in the lower right corner all the time and I never see the registers change when I change things in-game.

Sorry for the silly newbie questions I hope someday (soon) to be providing Dll offsets for everybody.I just need to get the hang of this.

[EDIT 9/1/2004]

I have renamed this thread and made it sticky again. Sure enough, when it disappears, somebody wants to know how to run Ollydbg. Until we actually have a decent tutorial for using Ollydbg on D2, this thread is the best we have to offer.

~ Myhrginoc

[Myhrginoc]

You need to get familiar with the various commands on the View, Debug and right-click popup menus. In particular, you will use F2 (toggle breakpoint), F7 (single step), F8 (step over, to not follow into functions and REP prefixes), and F9 (run code) a lot. On the popup menu, Analyze Code gets a fair amount of use, it makes it easier to identify subroutines. The analyzer is not perfect, you will find cases (especially with D2Extra) where it just doesn't work as expected. In particular, since some subroutines have assertions trailing the last return instruction (a compiler oddity), you will see the function bracket extend past the return and assertion code, across some NOPs and into the next subroutine. If you don't like that, put a RETN in place of the first NOP and re-analyze, and you will get better bracketing. Assertions never come back from the final call, so the return would never get executed.

For debugging puposes, it is best to run D2 in windowed mode using the -w command line switch. First, make sure you actually get a D2 window before you attach Ollydbg. There are ways to get ahead of that, but that means coding debug stops into the DLLs. Game.exe is debugger-aware, so if you start D2 from within Ollydbg you will get dumped into Blizzard's trap code. Once you have attached to game.exe, and made any preliminary settings, remember to start executing the game with F9 and then click on the Diablo II task bar button or Alt-TAB to get back to the game.

If I am just reviewing code, I use Ollydbg as a disassembler. You can do that without pausing. Just use the View Executables command to get the module of interest (usually D2Game or D2Common), and right-click for the Disassemble command. In this mode, all imported functions get replaced by jump table references. The D2Extra tutorial covers this in depth, I won't repeat it here.

If I am actually debugging, I need some idea what to look for. There are several tools for locating the proper code section. The first is the strings reference. Right-click for popup menu, then choose the command that calls up all of the text string references. Most of them are the assertion messages we all get from time to time. Find messages dealing with your topic and those strings have addresses in the code where they are used. Right-click again and follow the reference to the code section.

Another tool is the list of names, which are actually imports and exports primarily. If you know a certain code section is calling D2Common.10518 for updating character stats, you can follow that function by name for all calls to it. Compare that with nearby text strings and you will have a sense of what that code section might be trying to accomplish.

A third tool is the breakpoint. This is what actually allows you to stop executing and follow through a code section. You have found something you want to examine, so look for the beginning of the function, set a breakpoint, hit F9, and play until you get stopped.

A fourth tool is the memory breakpoint. For this you need to get familiar with examining memory blocks and using the View Memory and Dump Memory commands. After you get used to those, you can follow data behavior by seeing what part of code accesses it. The full technique can be found here. That thread also has a description of the code difference between an assertion and an unhandled exception, and a typical Fog.10023 assertion setup.

[Mr. Fatty]

Thanks for your reply Myhrginoc.I spent alot of time reading old posts and I feel I've learned alot from them.But sadly I still haven't gotten the hang of this darn program.Since this is sticky I think I should ask a few more questions...

Here's where I'm at:I have the executable "game.exe" loaded in olly,the bottom corner says "running" and the game is running very slow.This means it is following the code right?So I use a town portal from my tome and switch back to olly but none of the registers have changed I see a few lines of code that are highlighted in red,so I put breakpoints at those lines-all of em-but when I switch to D2 and use a TP from my tome the game does not freeze I also put breakpoints at all "sub e*x,1"commands but still it does not freeze.Grrrrrr what little detail am I missing?Any help is greatly appreciated.I'm running out of hair to pull lol.

Also,what do SBB and SYSCALL do?

[Myhrginoc]

Finding where a certain game function is defined in code is one of the blackest of arts, and there are no hard and fast rules. I gave you four pointers in my previous post, and you should practice all of them. I find many things by inference myself. Breakpoints are invaluable, but they are only best applied if you are in the vicinity of what you are looking for. The string references and names table you use to get to the right vicinity.

Ollydbg and D2 will be sharing memory, so if you have a limited amount you will end up with more of the game in virtual memory. Go into a game, and even though you are soloing open a chat window. Type FPS in there, no quotes or spaces or anything else. Now you will have a couple of lines of text at the top of your screen. In the second line you will see two pairs of numbers which are your physical memory and your paging memory (e.g. swap file). The left number of each pair is your current usage and the right number is your maximum. If the physical memory is always running at maximum and you don't have this line in your System.ini file

  ConservativeSwapfileUsage=1

then you probably need more memory. The more of the game that runs out of the swap file, the slower you run.

Ollydbg starts by highlighting the address of what it thinks the first instruction of a subroutine is. There are many of them, so don't highlight any at all until you come up with another reason for picking certain ones.

SUB e*x,1 just means it is subtracting 1 from a register. That most often has nothing to do with using an item in a stack of items. And more often you would see DEC e*x instead of SUB e*x,1 --- they are the same result but the DEC instruction is more efficient in the processor. SBB is a related instruction, which you can find out in an assembly language reference. You need to get yourself one right away, if you don't already have one. Here is a link to the Intel manuals I use, volume 2A and 2B are the most important ones. I am linking the Pentium 4 version, elsewhere on the site are the earlier processor guides. In addition to excruciating detail about each instruction you will also see the machine code that results. When you are replacing bytes using spin's offset sheets or similar guide, you are actually working in machine code.

[EDIT 9/1/2004]

I updated the Intel link and description. The page now lists all sorts of Pentium 4 documentation. Scroll down to the Manuals section, and look for IA-32 Intel Architecture Software Developer's Manual Volume 2A: Instruction Set Reference, A-M and Volume 2B, M-Z.

~Myhrginoc

[Mr. Fatty]

When debugging with Olly is it best to run just D2 and Olly?
Will it be just as accurate if I have 10 more programs and files open?
FPS is good and I have lots of RAM to spare.

[Myhrginoc]

You want to keep the processor load down to a minimum, especially when tracing D2 actions with Ollydbg. And while it may not cause problems for D2, a really nasty crash might disturb your other software, especially if you are using Windows 95/98/ME instead of NT/2K/XP.

[DDDiablo]

Uh,

when I edited a memory thing in the program, how do I save it? There is no apparent save button when editing memory and game.exe by attachment.

This is a total newb question I know. Is it possible that it cannot be saved? That's a possibility.

[Sir_General]

The easiest way is probably to use "Copy To Executable". First select the portion that you want save. Then right-click and choose the "Copy To Executable" option. It should open up a new window with the changes you have selected in it. To save, right-click on thise window and choose "Save File" and it brings up a save file dialog box.

[DDDiablo]

Yep.

Many thanks bro.

[ChaoticDeath]

Is there a way to search for bytes in Ollydbg? If so, how?

[Alkalund]

Yep there is. Use View -> File to open the file you want. Right-Click on the window that will popup with the file, and select Search For -> Binary String (or simply use Ctrl+B). In the HEX +00 field, put in the bytes you want to search, and click OK. If you want to continue searching for the next occurrence fo the bytes, use Ctrl+L.

[TheWizard]

4 months almost since a post, time to add one

Two things with Olly :

1 - when I use copy/select all - copy to executable file - then save file, it does not seem to save the sections of memory that I think are .rdata etc. Is this the correct way to do this?

2 - when viewing PE Headers to see where the .rdata is, D2Net.dll shows up like D2Extra tutorial, but nothing like that for D2Game.dll. Why?

I am trying to get D2Game.dll to save my indirect call pointers when I save it but it refuses. Since the 6F706040 area is so small, I'm trying to use 6F706240 (or so - comes from memory) Is this area not part of D2Game.dll?

[Myhrginoc]

1) Alkalund tells me you put the right section in the dump window, make your changes there, right click, copy all, save to executable. I haven't gotten that to work myself, so I just make note of what changes work when testing in Ollydbg, then I edit the DLL with a hex editor later using (address - base address = offset) to find the right bytes.

2) When looking for sections in Ollydbg, you can call up the memory map (M main menu command) and examine the blocks between 6F700000 and 70000000:

Code: Select all

6F700000   00001000   d2extra  6F700000 (itself)                PE header
6F701000   000B1000   d2extra  6F700000              .text      code
6F7B2000   00005000   d2extra  6F700000              .rdata     imports,exports
6F7B7000   00040000   d2extra  6F700000              .data      data
6F7F7000   00001000   d2extra  6F700000              .rsrc      resources
6F830000   00001000   D2Gdi    6F830000 (itself)                PE header
6F831000   00007000   D2Gdi    6F830000              .text      code
6F838000   00001000   D2Gdi    6F830000              .rdata     imports,exports
6F839000   00005000   D2Gdi    6F830000              .data      data
6F83E000   00001000   D2Gdi    6F830000              .reloc     relocations
6F8A0000   00001000   d2win    6F8A0000 (itself)                PE header
6F8A1000   0001C000   d2win    6F8A0000              .text      code
6F8BD000   00002000   d2win    6F8A0000              .rdata     imports,exports
6F8BF000   000B1000   d2win    6F8A0000              .data      data
6F970000   00003000   d2win    6F8A0000              .reloc     relocations
6F980000   00001000   d2sound  6F980000 (itself)                PE header
6F981000   0000D000   d2sound  6F980000              .text      code
6F98E000   00002000   d2sound  6F980000              .rdata     imports,exports
6F990000   00005000   d2sound  6F980000              .data      data
6F995000   00002000   d2sound  6F980000              .reloc     relocations
6F9F0000   00001000   d2mcpcli 6F9F0000 (itself)                PE header
6F9F1000   00006000   d2mcpcli 6F9F0000              .text      code
6F9F7000   00001000   d2mcpcli 6F9F0000              .rdata     imports,exports
6F9F8000   0000C000   d2mcpcli 6F9F0000              .data      data
6FA04000   00001000   d2mcpcli 6F9F0000              .reloc     relocations
6FA10000   00001000   D2Launch 6FA10000 (itself)                PE header
6FA11000   0001E000   D2Launch 6FA10000              .text      code
6FA2F000   00002000   D2Launch 6FA10000              .rdata     imports,exports
6FA31000   00037000   D2Launch 6FA10000              .data      data
6FA68000   00005000   D2Launch 6FA10000              .reloc     relocations
6FA70000   00001000   d2gfx    6FA70000 (itself)                PE header
6FA71000   0000B000   d2gfx    6FA70000              .text      code
6FA7C000   00002000   d2gfx    6FA70000              .rdata     imports,exports
6FA7E000   00011000   d2gfx    6FA70000              .data      data
6FA8F000   00002000   d2gfx    6FA70000              .reloc     relocations
6FAA0000   00001000   D2Client 6FAA0000 (itself)                PE header
6FAA1000   000CB000   D2Client 6FAA0000              .text      code
6FB6C000   00009000   D2Client 6FAA0000              .rdata     imports,exports
6FB75000   00071000   D2Client 6FAA0000              .data      data
6FBE6000   00002000   D2Client 6FAA0000              .rsrc      resources
6FBE8000   0000F000   D2Client 6FAA0000              .reloc     relocations
6FC00000   00001000   D2Net    6FC00000 (itself)                PE header
6FC01000   00006000   D2Net    6FC00000              .text      code
6FC07000   00001000   D2Net    6FC00000              .rdata     imports,exports
6FC08000   00004000   D2Net    6FC00000              .data      data
6FC0C000   00001000   D2Net    6FC00000              .reloc     relocations
6FC10000   00001000   D2Lang   6FC10000 (itself)                PE header
6FC11000   0000A000   D2Lang   6FC10000              .text      code
6FC1B000   00002000   D2Lang   6FC10000              .rdata     imports,exports
6FC1D000   00006000   D2Lang   6FC10000              .data      data
6FC23000   00002000   D2Lang   6FC10000              .reloc     relocations
6FC30000   00001000   D2Game   6FC30000 (itself)                PE header
6FC31000   000CF000   D2Game   6FC30000              .text      code
6FD00000   00007000   D2Game   6FC30000              .rdata     imports,exports
6FD07000   00027000   D2Game   6FC30000              .data      data
6FD2E000   00008000   D2Game   6FC30000              .reloc     relocations
6FD40000   00001000   D2Common 6FD40000 (itself)                PE header
6FD41000   0007C000   D2Common 6FD40000              .text      code
6FDBD000   00008000   D2Common 6FD40000              .rdata     imports,exports
6FDC5000   00020000   D2Common 6FD40000              .data      data
6FDE5000   00007000   D2Common 6FD40000              .reloc     relocations
6FDF0000   00001000   D2CMP    6FDF0000 (itself)                PE header
6FDF1000   00019000   D2CMP    6FDF0000              .text      code
6FE0A000   00004000   D2CMP    6FDF0000              .rdata     imports,exports
6FE0E000   000E7000   D2CMP    6FDF0000              .data      data
6FEF5000   00003000   D2CMP    6FDF0000              .reloc     relocations
6FF00000   00001000   Bnclient 6FF00000 (itself)                PE header
6FF01000   00015000   Bnclient 6FF00000              .text      code
6FF16000   00002000   Bnclient 6FF00000              .rdata     imports,exports
6FF18000   00008000   Bnclient 6FF00000              .data      data
6FF20000   00001000   Bnclient 6FF00000              .rsrc      resources
6FF21000   00002000   Bnclient 6FF00000              .reloc     relocations
6FF50000   00001000   Fog      6FF50000 (itself)                PE header
6FF51000   0001F000   Fog      6FF50000              .text      code
6FF70000   00003000   Fog      6FF50000              .rdata     imports,exports
6FF73000   0002F000   Fog      6FF50000              .data      data
6FFA2000   00003000   Fog      6FF50000              .reloc     relocations
6FFB0000   00001000   storm    6FFB0000 (itself)                PE header
6FFB1000   00030000   storm    6FFB0000              .text      code
6FFE1000   00003000   storm    6FFB0000              .rdata     imports,exports
6FFE4000   0000A000   storm    6FFB0000              .data      data
6FFEE000   00001000   storm    6FFB0000              .CRT
6FFEF000   00003000   storm    6FFB0000              .rsrc      resources
6FFF2000   00003000   storm    6FFB0000              .reloc     relocations

[mouse]

I've got a newbie Olly question - i'm working through the Code Editing Tutorial- right now i've got diablo loading up (backpatched hopefully from 109d to 109b), and am attaching olly (1.06, I tried 109 and had the same problems) to it, hutting "run", then starting a game in diablo.

The problem i'm having is that D2GAME.DLL doesn't show up in the window! what is up with that? i see all the other dll's diablo is using, but not D2Game.dll.

Any idea what the heck is up with this? (d2client & d2common are the only dlls that show up (in red) as being new when I start a new game).

I'm sure this is something simple, but its driving me crazy because my progress is pretty much halted.


[EDIT: Ok. It was something stupid. Evidently the olly window refreshes itself enough to update d2client & d2common, but you have to manually update it (Alt + E or use View -> Breakpoints on the menu) before it shows d2game.dll. FUNKY. sorry to waste the post space, but maybe someone else will find this useful ]

[Myhrginoc]

I am not sure why you have trouble seeing d2game.dll. If I wait until the character appears in town then all DLLs are loaded, and I can start going after code. The only time I would want to access code earlier is if I am studying the actual startup sequence. (That is a big task, there is a lot of front-end processing before you arrive.)

Another way to see d2client.dll, d2common.dll and d2game.dll when any of them get loaded is to select Options | Debugging Options. Go to the Events tab and check as active the option Break on New Module (DLL).

[SVR]

Well, another newbie question from a non-newbie ;-)
How can I make Olly run D2 in a different working directory ?
I tried running Olly in a mod directory but it still runs D2 in the D2 directory.

[Myhrginoc]

You can run game.exe out of Ollydbg and not get caught up in the anti-debugging crash? I am astounded!

Seriously, I always attach to the running process myself, that way it doesn't matter where the game starts from or which DLLs are in the mod directory. You will see the modules as they are in memory. Start game.exe in your preferred way (I use the VB scripts), with Ollydbg running in the background. As soon as the first window is drawn, use File | Attach in Ollydbg to connect to game.exe. This works fine unless you are trying to watch the program startup.

[SVR]

Doh !

Thats how I usually run it. I've been using a loader lately for debugging and my brain went out the window.

Thanks man ;-)

[Drew-ID]

ok, i'm reallly new to this but i do understand most of it.

All i wanna know right now is how to edit the d2gfx.dll to enable muling. I read the other article that shows what to change, but how do i actually change that data? e.g: which program is best and how do i actually save the data after i change it with that particular program?

[bogdy]

realy newbie question:
how can I run trace while runing the game cuz if use step or animate it runs trace but I don't know what the hell is hapening in the game
this is very frustrating

[Myhrginoc]

Before somebody points to me as an Ollydbg expert, I have to admit I haven't used Run Trace much, and only for limited periods (from known point to known point or for several hundred lines). You can generate thousands of lines in very short order, if the game is going.

Have you tried starting a trace and alt-tabbing to the game or picking the game button on the task bar?

[baranobi]

Ok stupid question, you mentioned way up in beginning of this a D2extra tutorial. Either I am not seeing it or it was a different name, and I will lean closer to not seeing it. But if possible I would like link to that one also please.

[Myhrginoc]

It is a little hidden, since it is grouped with the d2extra plugin. You can find the 1.10 versions of the plugin kit, tutorial only, and jumpt table reference in our File Center.

D2Extra was developed to provide additional code space, since the slack in Blizzard dlls is rather scanty. But D2Mod is by far the superior system for adding custom code, so I would recommend only looking at the tutorial. I still use d2extra for thinking my way through assembly language projects, because I can work with it interactively in Ollydbg, before I run through the compile/link/try cycle that D2Mods requires. However, each of us has his own techniques.

[baranobi]

Thanks for the link Myhrginoc, it helped me greatly. I read the entire tutorial, and thousand of lightbulbs came on hehe. Now I will just go back to some of these other posts I have seen, and play with them for background work. It was a well designed tutorial, and I would love to see some for a few things in 1.10, maybe one day I might be good enough to design one, but not now. Again thanks.

[Nefarius]

I find it worthwhile to mention this site: http://maven.smith.edu/~thiebaut/ArtOfA ... ofasm.html

It is a guide to assembly programming and things are explained very clearly and in non-confusing way there.