The difference in executing null bytes between Win10 and XP

Index > Windows > The difference in executing null bytes between Win10 and XP

Author

Thread

Mat Quasar

Joined: 15 Dec 2024
Posts: 54

Mat Quasar 01 Jan 2025, 15:30

Hi, I believe this is known bug in Windows XP, it has been improved in Windows 10.

I took the HELLO.ASM example from FASMW folder, then intentionally insert "d dq 0" (8 null bytes) at the beginning of entry point.
It runs on Windows 10, but not so under Windows XP.

Is this an improvement in Windows 10?

Code:

; example of simplified Windows programming using complex macro features

include 'win32ax.inc' ; you can simply switch between win32ax, win32wx, win64ax and win64wx here

.code

  start:

d dq 0

        invoke  MessageBox,HWND_DESKTOP,"May I introduce myself?",invoke GetCommandLine,MB_YESNO

        .if eax = IDYES
                invoke  MessageBox,HWND_DESKTOP,"Hi! I'm the example program!","Hello!",MB_OK
        .endif

        invoke  ExitProcess,0

.end start

Description:	Running modified HELLO.EXE under Windows 10 is fine
Filesize:	82.45 KB
Viewed:	450 Time(s)

Description:	Running modified HELLO.EXE in Windows 10 is fine but not so under Windows XP
Filesize:	118.01 KB
Viewed:	451 Time(s)

Description:	Access violation error (0xc0000005) when running HELLO.EXE in Windows XP
Filesize:	61.62 KB
Viewed:	451 Time(s)

01 Jan 2025, 15:30

AsmGuru62

Joined: 28 Jan 2004
Posts: 1671
Location: Toronto, Canada

AsmGuru62 01 Jan 2025, 16:46

The sequence of 8 bytes set to 0x00 is these 4 opcodes:

Code:

00402320 >/$  0000          ADD     BYTE PTR DS:[EAX], AL
00402322  |.  0000          ADD     BYTE PTR DS:[EAX], AL
00402324  |.  0000          ADD     BYTE PTR DS:[EAX], AL
00402326  |.  0000          ADD     BYTE PTR DS:[EAX], AL

In theory it is possible that when program starts on XP the Register EAX points to a non-writable memory and these opcodes do harm right away.
On next Windows OS the EAX may point to writable block, so the opcodes will not do much harm (maybe later).

01 Jan 2025, 16:46

Mat Quasar

Joined: 15 Dec 2024
Posts: 54

Mat Quasar 01 Jan 2025, 17:31

AsmGuru62 wrote:

The sequence of 8 bytes set to 0x00 is these 4 opcodes:
Code:
00402320 >/$  0000          ADD     BYTE PTR DS:[EAX], AL
00402322  |.  0000          ADD     BYTE PTR DS:[EAX], AL
00402324  |.  0000          ADD     BYTE PTR DS:[EAX], AL
00402326  |.  0000          ADD     BYTE PTR DS:[EAX], AL
    
In theory it is possible that when program starts on XP the Register EAX points to a non-writable memory and these opcodes do harm right away.
On next Windows OS the EAX may point to writable block, so the opcodes will not do much harm (maybe later).

Now I have better understanding, null bytes are still opcodes. I agree with the possibility of non-writable memory and later writable memory.

I first encountered this about 3 years ago in my compiler project that I forgot to set entry point to the address after variable in writeable code section, and user started complaining. But only today I have the chance to run the experiment.

Thanks AsmGuru62.

01 Jan 2025, 17:31

macomics

Joined: 26 Jan 2021
Posts: 1041
Location: Russia

macomics 01 Jan 2025, 19:35

Just look in the debugger

EAX points to kernel32.dll .text section (readonly).

Description:
Filesize:	240.95 KB
Viewed:	412 Time(s)

Description:
Filesize:	177.97 KB
Viewed:	412 Time(s)

01 Jan 2025, 19:35

macomics

Joined: 26 Jan 2021
Posts: 1041
Location: Russia

macomics 01 Jan 2025, 19:42

In other OS versions, there may be a different address in eax and, accordingly, other consequences.

01 Jan 2025, 19:42

Mat Quasar

Joined: 15 Dec 2024
Posts: 54

Mat Quasar 01 Jan 2025, 19:50

macomics wrote:

In other OS versions, there may be a different address in eax and, accordingly, other consequences.

Nice finding! Looks like you use Windows 7, which is same behaviour as Windows XP (i.e. DS:AX points to read-only memory area).

I will check my debugger on Windows 10, after I wake up tomorrow.

01 Jan 2025, 19:50

Mat Quasar

Joined: 15 Dec 2024
Posts: 54

Mat Quasar 01 Jan 2025, 20:05

I think 0xDFFCC is writeable, as startup value for EAX register, on my Windows 10 22H2.

So, the reason behind the difference has been revealed.

Thank you everyone!

Description:
Filesize:	27.61 KB
Viewed:	397 Time(s)

Description:
Filesize:	138.2 KB
Viewed:	397 Time(s)

01 Jan 2025, 20:05

macomics

Joined: 26 Jan 2021
Posts: 1041
Location: Russia

macomics 01 Jan 2025, 21:20

Mat Quasar wrote:

I think 0xDFFCC is writeable, as startup value for EAX register, on my Windows 10 22H2.

Of course, writing is possible at this address. It is enough to look at the stack area. With these commands, you will corrupt the pointer to the SEH handler. If any error occurs, the system exception handler in your program will no longer receive control. (0xE4 changed to 0xCC => 0x000DFFCC not valid SEH record infinite loop!).

01 Jan 2025, 21:20

< 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