Calling LoadLibraryA function does not retain ECX register

[craigp1231]

Memory access violation occurs when attempting to reuse the ECX register after LoadLibrary is called.

call dword ptr[ebp + fn_LoadLibraryA]

When this function is called, it does not retain the ECX register. The ECX register is being used as an index for the hash location, but gets reused by the LoadLibraryA function, without pushing the ECX register onto the stack.

Any subsequent calls to find_function causes a memory access violation here...
mov [ebp + ecx], eax ; save the funtion address in our table

[rbergen]

That's not what Dave, Lasse and I are seeing, on a number of different machines. In the video, Dave shows the application starting and running.

Is this behavior you're describing based on observations you've made, or based on knowledge about how LoadLibraryA functions?

[lassehauballe]

I will agree with @rbergen that it may come down to different machines.

The ECX value is initially set at the beginning of resolve_symbols_kernel32. When find_function is called it is initialized with a pushad instruction, meaning all the registers are pushed to the stack including the ECX .

When find_function reaches its end in find_function_finished all these registers are then popped back using "popad". So ECX should indeed be correct.

Perhaps it is the case for you, that ECX is not zero when resolve_symbols_kernel32 begins?

[craigp1231]

When I pull the latest code from the Repo, it builds fine, but crashes when I attempt to run it. I used x64dbg to determine that an memory access violation occurred on the line shown above.

If I change the assembly to push ECX onto the stack, and pop it off after the LoadLibraryA function, the application builds and runs successfully. Notice I have to pop the 3 stack pushes before the call as well. I'm not sure why if stdcall convention is being used?

        push hash_GetStartupInfoA
        call find_function
		
	push ecx					; push the last index onto the stack

load_user32:                                    ; Push "user32.dll" onto the stack in reverse order
        push txt_ll
        push txt_32_d
        push txt_user
        push esp
        call dword ptr[ebp + fn_LoadLibraryA]

resolve_symbols_user32:
	pop ecx
	pop ecx
	pop ecx
	pop ecx				; The last index of ECX
        mov ebx, eax                            ; Load the base address of user32.dll into ebx

        push hash_LoadIconA
        call find_function

[craigp1231]

I will agree with @rbergen that it may come down to different machines.

The ECX value is initially set at the beginning of resolve_symbols_kernel32. When find_function is called it is initialized with a pushad instruction, meaning all the registers are pushed to the stack including the ECX .

When find_function reaches its end in find_function_finished all these registers are then popped back using "popad". So ECX should indeed be correct.

Perhaps it is the case for you, that ECX is not zero when resolve_symbols_kernel32 begins?

Before the call to LoadLibraryA, ECX is 0x24

After the call to LoadLibraryA, ECX is 0xF90000

Which then causes an memory access violation here...

[lassehauballe]

Thank you for your screenshots.

That is very weird. I just ran the code and checked the same places. My ECX doesn't change after LoadLibraryA is called. So mine is 0x24 when the call returns.

What version of Windows are you running?

[lassehauballe]

Perhaps, it was a bad idea to use the ECX register for this since it is a "volatile" register that is not guaranteed to stay the same after a call. But still, weird that it works for us but not for you..

[craigp1231]

Edition Windows 10 Pro
Version 21H2
Installed on ‎29/‎05/‎2020
OS build 19044.2364
Experience Windows Feature Experience Pack 120.2212.4190.0

[rbergen]

Maybe that's it. I run Windows 11 Pro 22H2, build 22621.963. I'm almost certain that Dave also runs a version of Windows 11.

@lassehauballe What about you?

[lassehauballe]

Yeah, I am also on Windows 11. Same build as @rbergen.

[lassehauballe]

I think it's a matter of using a volatile register. Since the code does use pushad and popad, it should be able to change from ecx to perhaps edi. I will test it and make a proposal for change.

[rbergen]

@lassehauballe If you do create another version that aims to address this, maybe @craigp1231 can test the respective branch on your fork on Windows 10 before we move towards merging?

[lassehauballe]

https://github.com/lassehauballe/HelloAssembly

I updated my forked repository. I changed it from ecx to edi. It works on my Windows 11.

The only problem is, that, unlike ecx, edi is not zero when we start so we lose some bytes by having to zero out the register first. Might be ways to optimize it.

@craigp1231 Please try it and let us know :)

[craigp1231]

@lassehauballe Yup, that appears to work fine :)