flat assembler
Message board for the users of flat assembler.

flat assembler > Windows > How does this 16-bit/32-bit bug cause an increase in value?

Author
Thread Post new topic Reply to topic
moveax41h



Joined: 18 Feb 2018
Posts: 46
This page discusses a specific software exploit. 99% of the page is not relevant, so I'll include the relevant part:
Quote:

SizeOfListInBytes is a DWORD size member of Os2FeaList. If shrinking is needed, the function treats SizeOfListInBytes as a Word member and it updates only the 2 bytes, instead of 4 bytes (with the shrunk size). The 2 most significant bytes remain untouched. This bug causes SizeOfListInBytes to be enlarged instead of shrunk.
If the value of SizeOfListInBytes is in the range of 216, there is no problem and the function works as expected.

However, if the value of SizeOfListInBytes is above the range of 216, it could be enlarged instead of shrunk.


Trying to understand this conceptually, I wrote a fasm program:

Code:
format ELF64 executable

entry main

segment readable executable
include 'io.inc'
include 'unistd64.inc'
main:
        mov eax, 0xFFFFFFFF
        add rax, 1
        mov rax, 0xFFFFFFFF
        add eax, 1
        xor eax, eax
        sub ax, 1
        mov eax, 0xFFFFFFFF
        add ax, 1

        call done
    


This program doesn't do anything really but it was intended for me to run it through gdb to view the register states.

If I add 1 to ax when eax when eax is full with 0xFFFFFFFF, it just wraps back to 0 again on the low word and remains 0xFFFF on the high word of eax. Similarly, if I load 0x00000000 into eax and then I sub ax, 1, it sets ax to 0xFFFF but again, I don't see how updating specifically the LO WORD of a DWORD could cause an abnormally large number that would not be caused by doing the same operation on the full DWORD.

Can someone with a bit more experience explain shed some light? Thank you.

_________________
-moveax41h
Post 27 Jul 2018, 00:37
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15912
Location: SDSS J140821.67+025733.2
IIUC the value is read as, say, 0x10001, the code then tries to truncate it to 0x0ffff (i.e. two bytes fewer) and then rewrites only the lower two bytes of the value giving 0x1ffff bytes.
Post 27 Jul 2018, 00:54
View user's profile Send private message Visit poster's website Reply with quote
moveax41h



Joined: 18 Feb 2018
Posts: 46
Ok so basically writing only the lower two bytes causes an improper carry into the 0x10000s place because the rewriting of the lower two bytes causes a carry which ends up there?
Post 27 Jul 2018, 18:50
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1201
moveax41h wrote:
Ok so basically writing only the lower two bytes causes an improper carry into the 0x10000s place because the rewriting of the lower two bytes causes a carry which ends up there?
There's no carry. What he's saying is that:

1) you have a number larger than 65536, e.g. 0x10001
2) since it doesn't fit in 16-bits, you saturate it to 65535 (0xFFFF) which is the max
3) but you only write back the lower 16-bits, which are now 0xFFFF.

Recall that the number was 0x10001. If you replace the lower 16-bits, you end up with 0x1FFFF, which is obviously larger than 0x10001.

You could say it's the absence of a borrow from the upper 16 bits. Wink
Post 27 Jul 2018, 19:11
View user's profile Send private message Reply with quote
moveax41h



Joined: 18 Feb 2018
Posts: 46
Aha, thanks Furs... That was a tricky one to understand but that makes a lot of sense. So it's more a problem of not clearing the bits above bit 16 than it is the contents of the low word.
Post 27 Jul 2018, 19:16
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2018, Tomasz Grysztar.

Powered by rwasa.