3
votes

I'm just doing some analysis of a disassembled 32-bit program I wrote in C. Here is a portion of the output from the disassembler:

41153c  02 00   add al, [eax]
41153e  00 00   add [eax], al
411540  44  inc esp
411541  15 41 00 F8 FF  adc eax, 0xfff80041 ; "A"
411546  FF  invalid 

I'm just trying to make sense of the ADC instruction. From what I've read in both the Intel developers manual, and various articles on x86 ASM the opcode 0x15 is the ADC instruction using EAX as the destination, and it would appear that following the opcode is a four byte 'immediate' that indicates the memory address for use in the add with carry.

However I'm a little unsure as to why the following byte (0xFF) is being marked as invalid.

I'm quite new to assembler, but I'm assuming that this is something to do with the carry flag, and might possibly be there to sign extend the value.

I've used two separate disassemblers to look at the code, and whilst one marks it as invalid, the other simply ignores it.

If someone could offer some advice, I'd appreciate it.

Thanks

UPDATE

I'll add a bit more information to this post, as there are another two ADC operations, and one of them doesn't have the extra 'invalid' byte

411547  FF 04 00    inc [eax+eax]
41154a  00 00   add [eax], al
41154c  61  popa    
41154d  15 41 00 EC FF  adc eax, 0xffec0041 ; "A"
411552  FF  invalid 

411553  FF 04 00    inc [eax+eax]
411556  00 00   add [eax], al
411558  5C  pop esp
411559  15 41 00 74 65  adc eax, 0x65740041 ; "A"
41155e  73 74   jnc 0x4115d4 ↓

The second ADC that's taking place also has the extra 0xff 'invalid' byte, however the third does not.

From what I can see, the only difference between all three ADC operations is that the first two start with 0xff and have an extra 'invalid' byte, whilst the third does not. I'm assuming that this is forming some kind of flag to indicate if the extra byte is needed.

1
What's the part of the C code that generated this?Kerrek SB
Unfortunately I don't have the code in front of me. I wrote it on a system I don't have access to as I'm currently working from home. Once I get access to the code I'll post it on here. Thanks.Tony
What's after the "stray" 0xFF byte? Does it form a valid instruction?Michael Foukarakis
Immediately after the 0xff is another 0xff which is the start of a valid instruction. For example the first one at 0x411546 is invalid, however at 0x411547 is the opcode ff0400 which is an INC instruction.Tony
Are you sure that you're disassembling correctly? x86 has variable length instructions and when you start disassembling inside an instruction you might get something that appears to disassemble correctly while not actually making any sense or being what's actually executed. The code you're posting here looks just like something like that. This is not code that a compiler would generate and the random pops and "inc esp" definitely look suspicious. What offset did you start disassembling from?Art

1 Answers

3
votes

This is not code. You're trying to disassemble data.

If we rearrange the bytes aligned to 4, we can make some sense of it:

411548: 04 00 00 00  ; integer 4
41154C: 61 15 41 00  ; address 0x411561
411550: EC FF FF FF  ; integer 0xFFFFFFEC (-20)
411554: 04 00 00 00  ; integer 4
411558: 5C 15 41 00  ; address 0x41155C
41155C: 74 65 73 74  ; string 'test'