This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Virtualalloc wrong return type
Type: behavior Stage: resolved
Components: ctypes, Windows Versions: Python 3.9
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: baptistecrepin, eryksun, paul.moore, steve.dower, tim.golden, zach.ware
Priority: normal Keywords:

Created on 2021-05-05 16:04 by baptistecrepin, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Messages (4)
msg393019 - (view) Author: (baptistecrepin) Date: 2021-05-05 16:06
The ctypes.windll.kernel32.VirtuAlloc function return by default a ctypes.c_long but on 64bits systems memory addresses can be higher so it should be a ctypes.c_uint64 or ctypes.c_void_p.
msg393042 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2021-05-05 20:47
The return type of a ctypes function is set by whoever is accessing it. If that is you, then you should do:

ctypes.windll.kernel32.VirtualAlloc.restype = ctypes.c_void_p

If it's not you, can you point out which code is getting this wrong? ctypes defaults to 32-bit int by default because that's what C does, and it has no knowledge of the function you're calling to do anything different.
msg393045 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2021-05-05 21:47
> ctypes.windll.kernel32.VirtuAlloc function return by default 
> a ctypes.c_long

In Windows, ctypes.c_int is an alias for ctypes.c_long, which is a signed 32-bit integer. This is the default conversion type for the integer parameters of an FFI (foreign function interface) call, as well as the result. It's up to the author of a library wrapper to define the correct function prototypes, pointer types, and aggregate struct/union types. Some common Windows types are defined/aliased in the ctypes.wintypes module, but none of the API is prototyped.

> ctypes.windll.kernel32.VirtuAlloc

I suggest avoiding the global ctypes.windll loader. IMO, it's not a great idea to use a global library loader since it caches WinDLL instances, which cache function pointer instances. This make it possible for unrelated projects to interfere with each other and the main script by defining incompatible function prototypes -- particularly for common Windows API functions. It also doesn't allow passing use_last_error=True to enable the safe capturing of the thread's last error value as ctypes.get_last_error().

I recommend creating individual CDLL / WinDLL instances. For example:

    import ctypes

    kernel32 = ctypes.WinDLL('kernel32', use_last_error=True)

    kernel32.VirtualAlloc.restype = ctypes.c_void_p
    kernel32.VirtualAlloc.argtypes = (
        ctypes.c_void_p, # lpAddress
        ctypes.c_size_t, # dwSize
        ctypes.c_ulong,  # flAllocationType
        ctypes.c_ulong)  # flProtect

If the call fails, you can raise an OSError as follows:

    base_addr = kernel32.VirtualAlloc(None, size, alloc_type, protect)
    if base_addr is None:
        raise ctypes.WinError(ctypes.get_last_error())
msg393071 - (view) Author: (baptistecrepin) Date: 2021-05-06 07:51
Thank you, I didn't know that ctypes wasn't prototyped.

I only use VirtualAlloc in combination with RtlMoveMemory and CreateThread in order to execute shellcodes for research purposes.
History
Date User Action Args
2022-04-11 14:59:45adminsetgithub: 88217
2021-05-06 07:51:46baptistecrepinsetmessages: + msg393071
2021-05-05 21:47:15eryksunsetstatus: open -> closed

components: + ctypes

nosy: + eryksun
messages: + msg393045
resolution: not a bug
stage: resolved
2021-05-05 20:47:07steve.dowersetmessages: + msg393042
2021-05-05 16:06:52baptistecrepinsetmessages: + msg393019
2021-05-05 16:04:21baptistecrepincreate