add [bx+si],al means what?

[kemaletikan]

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?

[gerard4143]

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...

[kemaletikan]

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?

[gerard4143]

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.

[kemaletikan]

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.

[gerard4143]

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

If your looking for a good 32/64 bit disassembler that works in Linux then check out Biew at:

http://biew.sourceforge.net/en/biew.html

[cyb3rl0rd1867]

To be quite literal it means to add the register al to the address at bx+si.

[pepsieudonim]

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.

[programagor]

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...)

[programagor]

The case you see the "add [bx+si],al" instruction is that the disassembler decodes the "0000" opcode so. Look into an instruction set specifications to see which instruction has which opcode and how the operands are represented (like this one: http://www.cs.ucla.edu/~kohler/class/aosref/i386/ADD.html )

[gusano79]

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.

[AceStryker]

That means that the file @SI + 1 will be stored in BH

[010101]

Well, i have to tell you that it is just a null byte!

`