1

This one works fine yet provides all of the machine addresses as beginning at zero: 

xed -i Halt7.obj

I really need the machine addresses to begin at their COFF object file offsets.

Here is what I have tried:
They give me the help message (list of options) indicating a syntax error in my specification of options.

xed -i  -as 0xb4              Halt7.obj
xed -ir -as 0xb4              Halt7.obj
xed -i  -as 0xb4 -ae 0x121    Halt7.obj
xed -ir -as 0xb4 -ae 0x121    Halt7.obj

One of the following is required:

    -i input_file             (decode pecoff-format file)
    -ir raw_input_file        (decode a raw unformatted binary file)

Optional arguments:

    -as addr      (Address to start disassembling.
                   Use 0x for hex addresses)
    -ae addr      (Address to end   disassembling.
                   Use 0x for hex addresses)
Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
polcott
  • 143
  • 1
  • 13

1 Answers1

1

-i -as tells it the input file is -as. And then there are stray arguments 0xb4 and Halt7.obj which aren't the args to any options.

You have to keep the file name as the next option after -i or -ir.

xed -as 0xb4 -ae 0x121  -i Halt7.obj

I think -as and -ae just limit the range of which instructions get disassembled. They don't change what address gets printed next to any instruction that is disassembled.

I think what you actually want is to set the base address with -b:

xed -i a.out  -b 0x55000

produces disassembly like this for a Linux PIE executable.

# SECTION 13                     .text addr 10e0 offset 10e0 size 1541
XDIS 560e0: WIDENOP   BASE       F30F1EFA                 nop edx, edi
XDIS 560e4: LOGICAL   BASE       31ED                     xor ebp, ebp
XDIS 560e6: DATAXFER  BASE       4989D1                   mov r9, rdx
XDIS 560e9: POP       BASE       5E                       pop rsi
XDIS 560ea: DATAXFER  BASE       4889E2                   mov rdx, rsp
XDIS 560ed: LOGICAL   BASE       4883E4F0                 and rsp, 0xfffffffffffffff0
XDIS 560f1: PUSH      BASE       50                       push rax
XDIS 560f2: PUSH      BASE       54                       push rsp
XDIS 560f3: MISC      BASE       4C8D05E6050000           lea r8, ptr [rip+0x5e6] <__libc_csu_fini+0x55000>
XDIS 560fa: MISC      BASE       488D0D6F050000           lea rcx, ptr [rip+0x56f] <__libc_csu_fini+0x54f90>
XDIS 56101: MISC      BASE       488D3D62010000           lea rdi, ptr [rip+0x162] <__libc_csu_fini+0x54b8a>
XDIS 56108: CALL      BASE       FF15D22E0000             call qword ptr [rip+0x2ed2] <__libc_csu_fini+0x57900>
XDIS 5610e: SYSTEM    BASE       F4                       hlt

...

Without the -b option, the image base is 0 (and the .text section starts 0x10e0 into the file) so we get

# SECTION 13                     .text addr 10e0 offset 10e0 size 1541

SYM _start:
XDIS 10e0: WIDENOP   BASE       F30F1EFA                 nop edx, edi
XDIS 10e4: LOGICAL   BASE       31ED                     xor ebp, ebp
XDIS 10e6: DATAXFER  BASE       4989D1                   mov r9, rdx
XDIS 10e9: POP       BASE       5E                       pop rsi
XDIS 10ea: DATAXFER  BASE       4889E2                   mov rdx, rsp
XDIS 10ed: LOGICAL   BASE       4883E4F0                 and rsp, 0xfffffffffffffff0
XDIS 10f1: PUSH      BASE       50                       push rax
XDIS 10f2: PUSH      BASE       54                       push rsp
XDIS 10f3: MISC      BASE       4C8D05E6050000           lea r8, ptr [rip+0x5e6] <__libc_csu_fini>
XDIS 10fa: MISC      BASE       488D0D6F050000           lea rcx, ptr [rip+0x56f] <__libc_csu_init>
XDIS 1101: MISC      BASE       488D3D62010000           lea rdi, ptr [rip+0x162] <main>
XDIS 1108: CALL      BASE       FF15D22E0000             call qword ptr [rip+0x2ed2] <__libc_csu_fini+0x2900>
XDIS 110e: SYSTEM    BASE       F4                       hlt
XDIS 110f: NOP       BASE       90                       nop

...

It seems the -b option messes up symbol info. Without it, the output is broken up into functions.

But with -b, it's just flat with no marker at the top of a function.

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
  • That did not work. Instead of a syntax error it gave me detailed stats that it did not process anything. When we give it -ir instead of -i it ignores the start and end addresses (processing from address zero to file size) thus disassembling incorrectly because it is not synced at the right start address. – polcott Feb 21 '20 at 01:13
  • @polcott: well maybe `-as` and `-ae` don't do what you want; I haven't used xed much / at all. I'm just answering the option syntax error part of your problem since the answer was right in the help output in the question. I considered just commenting instead of answering. – Peter Cordes Feb 21 '20 at 01:20
  • On the basis that you used to answer my question the answer was very excellent. I am only wanted -as to simply do what it says it will do, specify the address to start disassembling. I will try other combinations. – polcott Feb 21 '20 at 01:30
  • @polcott: You got me curious about xed; I updated my answer since I had it installed since it came with SDE. Are you really trying to limit which instructions are disassembled? Maybe an example of what you get vs. what you want would help. – Peter Cordes Feb 21 '20 at 01:34
  • Although the syntax that you provided completely solved my problem people looking at this exchange in the future may wonder why your stipulated -b 0x55000 came out as XDIS 560e0. Because of this I rewrote your answer in my question. I made sure to give you full credit. – polcott Feb 21 '20 at 04:37
  • @polcott: The `.text` section in my actual linked executable started `0x10e0` bytes into the file. That's why disassembly without `-b` started at that "address". BTW, in general you should post answers as answers, but in this case it's not really a separate answer, just a confirmation that I'd figured out what you were really trying to ask + an example. That's fine to leave in the question. – Peter Cordes Feb 21 '20 at 05:21
  • Yes, you answered my question helping me, and we both were careful that this dialogue leaves a good legacy for the future, making it a win-win for all. My original question became moot by your answer. You provided the means for the end result that I needed to achieve. – polcott Feb 21 '20 at 05:33