Function memory address (ASM)

Question

I have decompiled a program with VB Decompiler and it says that my target function (the one which I want to see the code) is at the address 0x00617B70. So once I have disassembled the application I go to that memory address and I see:

  CALL    0861BBA1
  ADD     BYTE PTR [EAX], DH
  IN      AL, 0
  XOR     AL, 0
  ADD     BYTE PTR [EAX], AL
  ADD     BYTE PTR [EAX], AL
  ADD     BYTE PTR [EAX], AL
  SBB     BYTE PTR [EAX], AL
  ADD     BYTE PTR [EAX], AL
  ADD     BYTE PTR [EAX], AL
  SBB     AL, 0
  ADD     BYTE PTR [EAX], AL
  ADD     BYTE PTR [EAX], AL
  ADD     AL, 0
  ADD     BYTE PTR [EAX], AL
  ADD     BYTE PTR [EAX], AL
  OR      AL, FF
  ADD     EAX, DWORD PTR [EAX]
  JE      00617B99
  ADD     DWORD PTR [EAX], EAX
  INSB
  INC     DWORD PTR [EBX]
  ADD     BYTE PTR [EAX-1], DH
  ADD     EAX, DWORD PTR [EAX]
  AND     BYTE PTR [EAX], AL
  ADD     BYTE PTR [EAX], AL
  ADD     BYTE PTR [EAX], AL
  ADD     EAX, 0
  ADD     BYTE PTR [EAX-1], AL
  ADD     DWORD PTR [EAX], EAX
  INC     ESP
  INC     DWORD PTR [EBX]
  ADD     BYTE PTR [EAX-1], BL
  ADD     AL, BYTE PTR [EAX]
  XOR     BH, BH
  ADD     AL, BYTE PTR [EAX]
  ADC     BH, BH
  ADD     AL, BYTE PTR [EAX]
  INSB
  OR      AL, 0
  OR      BYTE PTR [EAX], CL
  ADD     BYTE PTR [ESI], AL
  INC     EAX
  ADD     BYTE PTR [EAX+71], AL
  PUSHAD
--
  SHL     BYTE PTR [EAX-1], 1
  PUSH    ES
  ADD     AH, BH
  ADC     AL, 8
  OR      BYTE PTR [EAX], AL
  MOV     DWORD PTR [EAX+6E70AD00], EAX
--
  SHL     BYTE PTR [EAX-1], 1
  POP     ES
  ADD     AH, BH
  ADC     AL, 8
  OR      BYTE PTR [EAX], AL
  MOV     DWORD PTR [EDX+6C70AD00], EAX
  JMP     FAR FWORD PTR [EBX+6E]

That doesn't look like a function, right? I don't know anything about ASM, but I expect something like this:

PUSH EBP
MOV EBP, ESP
SUB ESP, 8
...more stuff here...
RETN

Specially the RETN instruction says that it's about a function, right?

Any ideas what I'm doing wrong?

You can show the relevant parts of the **disassembly of the executable**? That **disassembly of a memory region** is almost certainly data, and thus not intended to be executed. And the decompiled code too. — nrz, Dec 16 '13 at 00:56
Sorry, I don't understand ASM yet. Which are the relevant parts of the disassembly? That code is the one auto-selected by MHS6.1 when I do Right click in the first ASM line > Select function. — cdonts, Dec 16 '13 at 01:44
You say you have decompiled using VB decompiler. ARe you sure you executable was written in VB language ? — Madhur Ahuja, Dec 16 '13 at 04:10
Yes, 100 percent sure. It is possible that vbdecompiler shows a wrong address for the function? — cdonts, Dec 16 '13 at 16:40
I'm not familiar with the VB decompiler, but it looks like the value `617B70` isn't a memory location but an offset into the loaded bytecode image. Note, for example, your label values like `loc_617AF7`, etc. The VB decompiler documentation should be able to tell you how to convert that value to an actual memory location. — Jim Mischel, Dec 18 '13 at 21:42
Hey, thanks for the comment! That sounds very logical and convicing. I couldn't find anything in the documentation (http://www.vb-decompiler.org/documentation.htm). Also when I decompiled other programs, I simply copied the address from the VBDecompiler and I was able to call the function with that address. Any other idea? Thanks again. — cdonts, Dec 19 '13 at 02:41

score 0 · Answer 1 · answered Dec 22 '13 at 11:02

It seems to me that your principal error is thinking this should be x86 CPU code. Instead, the code you got and showed by VB decompiler is a kind of intermediate machine bytecode, which is performed not by the CPU itself, but by an intermediate interpreter. (Sorry if you already know it but your question is very unclear in that.) This is the main method for JVM, .NET runtime, etc. Googling for some words in your listing (FStStrCopy, CBoolVarNull) gives hints this is VB specific P-code. And it obviously won't expose instructions like "mov ebp, esp" or "retn"; even if a code is decoded that way, it would be clear occasion and not the intentional result. Even if you know there is an entry point of something, this entry point could be processed not by CPU, but by a P-code interpreter.

So, to solve this you should determine where exactly p-code is used in the analyzed binary and where native code should be (if should). If you thought it should be native code, something is wrong in your analysis method and/or compiling options.

Hi thanks for the answer. I do not expect that the VBDecompiler shows me instructions like "mov ebp, esp" or "retn". I expect that the disassembly shows me that. The first code is the disassembly and the last one is the P-Code that gived me the VBDecompiler. As I said in other comment, when decompiling other programs I just copy the address showed in the VBDecompiler and then go to the disassembler for that address; and there it shows me what I expect `mov ebp, esp` and the `retn`instruction at the end. I don't understand why in some programs it shows me what I expect and in others it doesn't — cdonts, Dec 22 '13 at 18:53

Function memory address (ASM)

1 Answers1