Hey RCE Forums,

I am new to these forums, and pretty new to OllyDbg. I have been experimenting with it, and I have a question. Lets say I want to analyse an intermodular call like GetTickCount (thats an intermodular call, right?).

How can I find the opcode that starts the call to GetTickCount?
Thanks for reading, i hope you can answer my question.

ctrl+n
rtfm

Ctrl + N displays a list of all symbolic names. How is that going to help me finding the opcode that starts the call to GetTickCount?

you are just lazy bastid,carry on!

I'm not lazy, I have googled this question, but just couldn't find a way to do this. Therefore I decided to ask my question in this forum.

I am not sure I understand the question. If you want to see the CODE at the API function GetTickCount, right click on the

:0045678 E8 call GetTickCount

and choose: follow (enter)

GetTickCount is an intermodular call all right but more precisely, it belongs to a windows module Kernel32.dll These are more commonly referred to as API calls, calls to the windows system .dlls

Intermodular calls refers in general to calls to another module loaded in memory, be it a windows module (kernel32.dll) or a user module (.dll typically) provided by the program in use.

To look at all the modules loaded with your program, click View->Executable Modules (Alt-E)

Thank you for your answer, I really appreciate it that you're taking the time to answer my question, but it doesn't exactly answer my question. Let me try to simplify it.

Let's say I have an API that's being called to, in this case it's CreateProcessA. How can I find out what opcode calls to it?
There has to be some way to find that out, right?

Sorry if I still am not clear, I will try to re-ask my question if neccesary.

ask the programmer

e8 xx xx xx xx local call typically goes to an FF 15 xx xx xx xx
or FF 15 xx xx xx xx far call api...

do some damned research yourself, this stuff is pretty rudimentary...

I think he try to find where (address) this API (CreateProcessA) was called.

If i'm right, in the stack window (bottom right) you've the return address.

As Squallsurf is referring to, breakpoint the API (i.e. GetTickCount, go to its location with method described by naides above). Run the program, and when the breakpoint hits, check the return address on the stack, it will point to the instruction after the one that called the API.

Alternatively, analyze the program in question in IDA, and check the cross references for the API in question.

If I understand you correctly, you want to find opcode for let say GetThickCount.

So in Olly CPU window right click and Search for All Intemodular calls. Then click on destination tab and just type getthickcount and Olly will bring you on right spot.


Orthodox

Following orthodox line, there used to be a tutorial, which I can't remember the name, where the author showed you how from the hex code, you could determine the assembly code. Does any one remembers it, I thought that was great on explaning how opcodes work from a machine points of view.

If you remember the title, please let me know, I would love to get the link. It seems I lost my copy.

heheh GetThickCount, love it

The FRET (French Reverse Engineering Team) is releasing the Fret Disassembly project containing papers (in frenchà about how to disassemble opcode to have mnemonics, following LDE64 and BeaEngine (disassembler library). May this is what you want.
http://www.binary-reverser.org/

I want to thank all of the responders for your insightful answers comments and interpretations.

But, but, but, to this point, I haven't the foggiest idea what darkevil was indeed asking, nor if any of the answers hit the bull's eye.
Dark??

I guess I just sucked at asking my question - never mind, I already fixed it. It appeared that, indeed, that what I need could be found at the little screen at the bottom right.

I want to thank you all for taking the time to read my problem and providing an answer.

So you were looking for the function address right? (pls. answer this, its driving me bananas)
Just so you know: This [1] is what opcode means.

[1] http://en.wikipedia.org/wiki/Opcode ("http://en.wikipedia.org/wiki/Opcode")

I think he was looking for the address of the CALL DWORD PTR DS:[<&GetTickCount>]. And it looks like he did it by setting a breakpoint on the function's first instruction then following the return-address in the stack window and tracing back a step.

Exactly .