News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change

Main Menu

How to debug this ASM snippet of a function to know its meaning?

Started by bolzano, October 30, 2012, 07:59:57 AM

Previous topic - Next topic

bolzano

A friend gave me this ASM snippet of a function:
https://gist.github.com/97cca0671736bf448460
How could I debug this ASM snippet to know its meaning with OllyDbg or IDA and MASM?

Gunther

Hi bolzano,

why would you like to debug that piece of code? You've the source code. At the first glance it's a normal 32 bit procedure (callee) with good behaviour (registers are saved and restored, a stack frame is available etc). But you must know which parameters the caller has passed at the stack? Your friend should let you know the content of [ebp+8], [ebp+12] and [ebp+16]. If that's clear, the rest is very easy.

Welcome to the forum.

Gunther
You have to know the facts before you can distort them.

qWord

no debugging needed -> look up cld ; repz movsd/movsb in the manuals; the other instructions speak for them self ;-D
MREAL macros - when you need floating point arithmetic while assembling!

nidud

deleted

nidud

deleted

qWord

MREAL macros - when you need floating point arithmetic while assembling!

hutch--

bolzano,

The arguments are simple, source address, destination address and iteration count. The code itself looks like a disassembly and probably from a C compiler, if you know what it is being used for and it appears to be a simple memory copy operation, its no big deal to write a replacement for it that is cleaner and in the form of a MASM procedure. It can also be easily written without a stack frame if it gets hit at a high iteration rate.

MichaelW

FWIW this is the assembly output for the Microsoft memcpy.c source distributed with the 2003 PSDK, compiled with Visual C++ Toolkit 2003 and /O2 /G6 optimizations.

; Listing generated by Microsoft (R) Optimizing Compiler Version 13.10.3077

TITLE memcpy.c
.386P
include listing.inc
if @Version gt 510
.model FLAT
else
_TEXT SEGMENT PARA USE32 PUBLIC 'CODE'
_TEXT ENDS
_DATA SEGMENT DWORD USE32 PUBLIC 'DATA'
_DATA ENDS
CONST SEGMENT DWORD USE32 PUBLIC 'CONST'
CONST ENDS
_BSS SEGMENT DWORD USE32 PUBLIC 'BSS'
_BSS ENDS
$$SYMBOLS SEGMENT BYTE USE32 'DEBSYM'
$$SYMBOLS ENDS
_TLS SEGMENT DWORD USE32 PUBLIC 'TLS'
_TLS ENDS
; COMDAT _memcpy
_TEXT SEGMENT PARA USE32 PUBLIC 'CODE'
_TEXT ENDS
FLAT GROUP _DATA, CONST, _BSS
ASSUME CS: FLAT, DS: FLAT, SS: FLAT
endif

INCLUDELIB LIBC
INCLUDELIB OLDNAMES

PUBLIC _memcpy
; Function compile flags: /Ogty
; COMDAT _memcpy
_TEXT SEGMENT
_dst$ = 8 ; size = 4
_src$ = 12 ; size = 4
_count$ = 16 ; size = 4
_memcpy PROC NEAR ; COMDAT
; File c:\program files\microsoft visual c++ toolkit 2003\my\memcpy\memcpy.c
; Line 54
mov ecx, DWORD PTR _dst$[esp-4]
push esi
; Line 66
mov esi, DWORD PTR _count$[esp]
test esi, esi
push edi
mov edi, ecx
je SHORT $L827
; Line 54
mov edx, DWORD PTR _src$[esp+4]
$L809:
; Line 67
mov al, BYTE PTR [edx]
mov BYTE PTR [ecx], al
; Line 68
inc ecx
; Line 69
inc edx
dec esi
jne SHORT $L809
$L827:
; Line 73
mov eax, edi
pop edi
pop esi
; Line 74
ret 0
_memcpy ENDP
_TEXT ENDS
END

Well Microsoft, here's another nice mess you've gotten us into.

hutch--

Here is a simple example of a similar copy procedure but one that does not use a stack frame.



IF 0  ; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
                      Build this template with "CONSOLE ASSEMBLE AND LINK"
ENDIF ; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

    include \masm32\include\masm32rt.inc

    MCopy PROTO Source:DWORD,Dest:DWORD,ln:DWORD

    .data
      item db "12345678901234567890",0

    .code

start:
   
; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

    call main
    inkey
    exit

; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

main proc

    LOCAL pbuf  :DWORD      ; allocate a LOCAL pointer
    LOCAL buffer[64]:BYTE   ; allocate a 64 byte buffer

    lea eax, buffer         ; load the buffer address
    mov pbuf, eax           ; store it in the "pbuf" variable

    push LENGTHOF item      ; length of the source in BYTES
    push pbuf               ; the address of the destination buffer
    push OFFSET item        ; the source address
    call MCopy              ; call the procedure

    print pbuf,13,10        ; display the copied data

    ret

main endp

; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

align 4

OPTION PROLOGUE:NONE
OPTION EPILOGUE:NONE

MCopy proc Source:DWORD,Dest:DWORD,ln:DWORD

    push esi
    push edi

    cld

    mov esi, [esp+4][8]
    mov edi, [esp+8][8]
    mov ecx, [esp+12][8]

    shr ecx, 2
    rep movsd

    mov ecx, [esp+12][8]
    and ecx, 3
    rep movsb

    pop edi
    pop esi

    ret 12

MCopy endp

OPTION PROLOGUE:PrologueDef
OPTION EPILOGUE:EpilogueDef

; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

end start

bolzano

Thank you all for your very useful advices :D .

Gunther: I just want to know the way I could put some ASM snippet into compilable ASM file so that I could compile and debug it. Thank you for your suggestions, now I could figure it out.

Thank you for your works on the source code, hutch-- and MichaelW :) .

qWord, after more than 1 year without using MASM, I forgot almost everything but now it seems to be ok with the Intel manuals again :icon_mrgreen: .

BTW, I've just found a similar thread here:
http://bbs.pediy.com/showthread.php?t=3937

jj2007

By the way, there is more than one way to skin a cat ;-)

Algo           memcpy   MemCo1   MemCo2  MemCoC3  MemCoP4  MemCoC2   MemCoL
Description       CRT rep movs   movdqa  lps+hps   movdqa   movdqa   Masm32
                       dest-al    psllq CeleronM  dest-al   src-al  library
Code size           ?       70      291      222      200      269       33
---------------------------------------------------------------------------
2048, d0s0-0      556      566      363      363      373      363      560
2048, d8s9-1     1495     1516     1083     1149      738      744     1491


Taken from an old thread on Code location sensitivity of timings.