Hi fellas,
I have a question about disassembled code. I have a very simple assembly code that prints "Hello world" to screen. When I disassembled it by using nasm(ndisasm), I got a text file. After that I opened it and started to analyze it. However, in a section that comes after " int 0x80" there are a lot of "add [bx+si],al" statement. What does it means? Can you explain me?

Hi fellas,
I have a question about disassembled code. I have a very simple assembly code that prints "Hello world" to screen. When I disassembled it by using nasm(ndisasm), I got a text file. After that I opened it and started to analyze it. However, in a section that comes after " int 0x80" there are a lot of "add [bx+si],al" statement. What does it means? Can you explain me?

Depends really...it could be a bunch of data that the de-compiler is having trouble with...more likely, its just the header or footer information that comes with every executable...If you want to look your code try objdump instead. Objdump conveniently removes all this extra data...

Depends really...it could be a bunch of data that the de-compiler is having trouble with...more likely, its just the header or footer information that comes with every executable...If you want to look your code try objdump instead. Objdump conveniently removes all this extra data...

thanks for your help. I tried objdump and I got a clear code. add [bx+si],al are lost. Are you sure it is de-compiler problem? Can it be something important about program?
The program writes on screen. Can it be related with writing operation?

thanks for your help. I tried objdump and I got a clear code. add [bx+si],al are lost. Are you sure it is de-compiler problem? Can it be something important about program?
The program writes on screen. Can it be related with writing operation?

Like I said its probably the header or footer information that's added to the exe. This information. header/footer is used by the linker and operating system...

If you really want to see what's in your file then open it in a hexeditor and check the result against the objdump. You'll easy see where the header, footer and your code begins and ends.

Edited 7 Years Ago by gerard4143: n/a

Like I said its probably the header or footer information that's added to the exe. This information. header/footer is used by the linker and operating system...

If you really want to see what's in your file then open it in a hexeditor and check the result against the objdump. You'll easy see where the header, footer and your code begins and ends.

Thanks pal, you are really for me. I appreciate it.
Best regards.

As I think, it's the way the exe uses to give control back to the OS, giving info about it's return status. Not quite sure, I would like to know for sure. "This question is not relevant" is NEVER the answer to any question.

My disassembler (ndisasm under cygwin) gives me a bunch of

00004164  0000              add [bx+si],al
00004166  0000              add [bx+si],al
00004168  0000              add [bx+si],al
...

If you look at the opcode "0000" you can easily see that this is something like blank area of a program, to fill a unit of memory (page, segment...)

Like I said its probably the header or footer information that's added to the exe. This information. header/footer is used by the linker and operating system...

If you really want to see what's in your file then open it in a hexeditor and check the result against the objdump. You'll easy see where the header, footer and your code begins and ends.

It could also be program-specific data that were included at compile time. I believe it's more common for program resources to be stored separately from the executable these days, but this is especially true of older software, which would include fonts, graphics, text, sounds, and whatever else was needed.

Some disassemblers are better than others at automatically identifying bytes as code or data. Even the smart ones get a little confused when certain tricks are used, either intentionally or as a result of compiler optimization. In particular, interesting use of the stack pointer and unusual absolute jumps seem to get missed frequently.

The IBM PC port of Spacewar has some interesting features like this, one of which involves a procedure that displays text from data immediately following the call to the procedure, and resumes execution after the first '\0' byte--even IDA, which in my experience is a pretty clever disassembler, couldn't figure this one out automatically.

This article has been dead for over six months. Start a new discussion instead.