Skip to content

Error if allocated memory spans over the address 0x100000000 (4GB) #63

Closed

Description

@tobias-loew

FinalizeSections will fail if the allocated memory spans over the address 0x100000000 (4GB) since the addresses in the IMAGE_SECTION_HEADER are only 32-bit values.
I could fix it by putting the following code after the allocation of the variable "code":

#ifdef _WIN64
// check that memory-block does not span over the 4GB border
if(code < (LPVOID)0x100000000 && code + alignedImageSize >= (LPVOID)0x100000000)
{
auto old_code = code;
code = (unsigned char *)allocMemory(NULL,
alignedImageSize,
MEM_RESERVE | MEM_COMMIT,
PAGE_READWRITE,
userdata);
freeMemory(old_code, 0, MEM_RELEASE, userdata);
if(code == NULL) {
SetLastError(ERROR_OUTOFMEMORY);
return NULL;
}
}
#endif

Activity

  1. fancycode commented on May 11, 2017

    @fancycode
    Owner

    Hmm, that looks hacky ;-)

    From reading the original code, is the problem that sectionData.address is wrong in line 280 in your case?
    https://github.com/fancycode/MemoryModule/blob/master/MemoryModule.c#L280

    Also which version/commit are you using?

  2. tobias-loew commented on May 11, 2017

    @tobias-loew
    Author

    The problem is actually in line 295:
    when the memory spans the 4 GB boundary the expression
    (uintptr_t) sectionData.address + sectionData.size > (uintptr_t) alignedAddress
    evaluates to true and thus the code from 297 to 303 the erroneously executed.

    Please see my PR #64

    PS:
    I use memorymodule on a 64-bit machine to load like a 100 copies off the same dll, and everything works fine until I step over the 4 GB boundary

  3. tobias-loew commented on May 11, 2017

    @tobias-loew
    Author

    You can force the crash by spefifying a load address in line 582 that is just below the 4GB boundary, such address + alignedImageSize is above 4GB

  4. tobias-loew commented on May 12, 2017

    @tobias-loew
    Author

    I just figured out that the crash happens every-time the memory spans over A MULTIPLE of 4GB (obviously). My bad. I'll make a new pull request.

  5. ianhbell commented on Aug 2, 2017

    @ianhbell
    Contributor

    See #67

  6. added a commit that references this issue on Jul 4, 2024
    9e29595
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions