Page 2 of 2 FirstFirst 12
Results 16 to 18 of 18

Thread: new linux disassembler

  1. #16
    Programmer Run Amock... Bengaly's Avatar
    Join Date
    Aug 2001
    Somewhere over the Rainbow
    Blog Entries
    hi 0x0f,

    "i hope to already have a good disassembler for you"
    hrm, for me?.. for the linux community

    do you trace control flows of indirect jumps, jump tables (i.e: jmp eax, jmp [eax+xx]).
    recursive flow is good way, but this takes x amount of time.
    sometimes the recursive flow can go deep soo much that the stack could not bear it and will crash (theory, but its possible if i am not mistaken)

    i knowi can install linux, but i dont have hdd space for it.
    keep up the good work.
    "knowledge is now free at last, everything should be free from now on, enjoy knowledge and life and never work for everybody else"

  2. #17
    hey ben,

    yes, i take care of indirect jumps, but not yet jump tables.
    i even think of implementing analysis to check for call [eax] - not always possible of course.

    some function scanning and disassembling of caves for most executables yet creates same results as using objdump which is probably more luck at the moment.

    recursive flow is good way, but this takes x amount of time.
    no, this is not the case. at least i do not understand why it should? i on the fly update a map where i immediately see, if i already disassembled areas.
    so 3 calls to the same functions: it is only once stepped into.
    also call function+27: the destination address if it is marked as already disassembled i do not need to go there anymore.
    i create a buffer with the size of the executable. for each instruction i disassemble i set at the address of the instruction (offset) the first byte to eg 1. for the remaining bytes of the instruction i set their correspond buffer values to 2. so if i disassemble offset 345, and my buffer[345]==1,
    then i was already ecactly there.
    using the map i can see even more:
    i see if i want to disassemble at a point where i previously have disassembled, and the byte where i want to disassemble previously was a byte in the middle of an instruction.
    meaning if the buffer[345]==2 then i attempt to disassemble the "middle" of a previous processed instruction.


    addr001 instruction -> buf[001]=1,buf[002]=2,buf[003]=2
    addr004 instruction -> buf[004]=1,buf[005]=2
    addr006 label1: instruction -> buf[006]=1,buf[007]=2,buf[008]=2
    addr009 instruction
    at another place:
    jmp label <------- here i immediately see that i have already dis-
    assembled exactly this address :
    buf[006] == 1
    jmp label+1 <-------- here i immediately see, that i have already
    disassembled the address, but the concerned
    instruction i have disassembled before started
    one byte before, so i am disassembling
    the middle of an instruction
    buf[007] == 2

    cool, ey

    sometimes the recursive flow can go deep soo much that the stack could not bear it and will crash (theory, but its possible if i am not mistaken)
    hehe. you are right. i tested it with nesting of over 5000 levels, and i only once segfaulted, because i was using a temp buffer as local variable, whcih i made to a global var, since then no problems.
    but in theory it is possible of course!
    in praxis i did not find any executable yet where it happens.
    once i have enhanced the algorythm enough i will take time to build
    up own "recursive" data structure for the local vars.
    i really see no more comfortable way to disassemble than recursive.
    i think you need to do so.
    the problem is: i can not create a "complete" list of destination addresses, even in multiple runs - if i do not have recursion. i can not know where jumps/calls are located. anyway i find it the best technique for me, as it takes same time as plain disassembling from start to end.
    at least same number of calls to "disassemble_address".

    the good thing nevertheless is that even now without jump tables, you get
    perfect results for nearly all "standard applications, gcc binaries" - and for any situation - you get the unrecognized data displayed as
    DB xx, xx, xx
    from there you can look at the data and disassemble from any address you want. just "d address" "d address+1"... and you see, if there is code hidden.
    so the goal IS to disassemble as accurate as possible, but maybe there is always a situation where i can not recognize code areas.

    sthg like
    call label1
    call function
    ; after here lets say eax contains a calculated value
    pop ebx
    add eax, ebx
    call [eax] ->>>>>>>> where to go from here ??

    therefor function scanning would cathc the destination if it uses stack setup prologue. if not - it would be in the middle of
    DB xx, xx, xx, xx, xx

    using the debugger you will see the destination(s) and can then use
    "d address"
    to update your deadlisting. this is how i planned to use lida

    cheers, 0xf001
    Last edited by 0xf001; August 11th, 2004 at 09:03.

  3. #18

    there's a new version of lida available. i have added

    - bookmarks
    - dump disassembly to text file
    - representation of data sections

    and removed
    - bugs hehe

    check it out

    btw you probably might find the information i give on the website stone-age old about the objdump disadvantage, but - i have been asked that really

Similar Threads

  1. Analyzing and debugging not linux binaries on linux
    By Xgrzyb90 in forum The Newbie Forum
    Replies: 2
    Last Post: June 13th, 2010, 12:50
  2. some anti-disassembler trick ?
    By NoLOcKs in forum OllyDbg Support Forums
    Replies: 2
    Last Post: May 13th, 2009, 17:00
  3. BeaEngine 3 : disassembler library x86 and x64
    By BeatriX in forum Tools of Our Trade (TOT) Messageboard
    Replies: 2
    Last Post: February 13th, 2009, 14:36
  4. CPU disassembler Code vs Executable
    By Tom Smith in forum OllyDbg Support Forums
    Replies: 1
    Last Post: July 11th, 2004, 05:27
  5. Dos cracking with Softice 2.8 someone help with disassembler please
    By funfstern00 in forum Tools of Our Trade (TOT) Messageboard
    Replies: 0
    Last Post: January 5th, 2001, 15:50


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts