Crash after accessing parts before allocated memory

[Fabian Maurer]

This is a kind-of follow up to "Debugging wine and finding the cause of a 
crash", but another question.

The program I'm debugging works reliably on windows/ReactOS, but on wine it 
crashes every time. I can get it to work by hacking RtlAllocateHeap to always 
allocate 5500 bytes more than needed, but that's hardly a solution.
> From what I currently know, the issue stems from a few negative offsets being

added on a pointer returned from RtlAllocateHeap. On windows this leads to 
accessing a memory region filled with zeroes, on wine it accesses random 
memory. The program can handle nullpointers, but not bogus pointer.

Any ideas how to deal with that, or is UB like that just a no-go? I have zero 
knowledge about the internal management of the heap, so help would be 
appreciated. At least is seems suspicious subtracting something from a pointer 
it got from RtlAllocateHeap, but maybe there's some plan behind it.

[Marcus Meissner]

Hi,

this is really undefined behaviour ... Can you fix the application?

CIao, Marcus
On Thu, Nov 17, 2016 at 06:08:13PM +0100, Fabian Maurer wrote:
> This is a kind-of follow up to "Debugging wine and finding the cause of a 
> crash", but another question.
>
> The program I'm debugging works reliably on windows/ReactOS, but on wine it 
> crashes every time. I can get it to work by hacking RtlAllocateHeap to always 
> allocate 5500 bytes more than needed, but that's hardly a solution.
>
> From what I currently know, the issue stems from a few negative offsets being 
> added on a pointer returned from RtlAllocateHeap. On windows this leads to 
> accessing a memory region filled with zeroes, on wine it accesses random 
> memory. The program can handle nullpointers, but not bogus pointer.
>
> Any ideas how to deal with that, or is UB like that just a no-go? I have zero 
> knowledge about the internal management of the heap, so help would be 
> appreciated. At least is seems suspicious subtracting something from a pointer 
> it got from RtlAllocateHeap, but maybe there's some plan behind it.

[Fabian Maurer]

On Friday, November 18, 2016 3:01:57 PM CET Marcus Meissner wrote:
> this is really undefined behaviour ... Can you fix the application?

I'm afraid not. It's a closed source indie game from ~2000, only downloadable 
form third-party sites.

I just did a few tests on windows on a VM, and it seems indeed to be UB. The 
code behaves exactly the same on wine and windows, just the UB is different. I 
mean, I could make a patch - it's just a single bit that needs to be flipped 
(movsx -> movzx) - but that's not a solution for wine.

I'll probably make an appdb entry and provide a hack, but any idea what else I 
could do? I mean, it works on windows/reactos, even if I don't know exactly 
why.

[Stefan Dösinger]

> Am 20.11.2016 um 19:49 schrieb Fabian Maurer :
>
> I just did a few tests on windows on a VM, and it seems indeed to be UB. The 
> code behaves exactly the same on wine and windows, just the UB is different. I 
> mean, I could make a patch - it's just a single bit that needs to be flipped 
> (movsx -> movzx) - but that's not a solution for wine.

There are applications that try to read private heap data structures by using magic offsets. I’m not entirely sure why, my guess is that they’re trying to fiddle with these things for Anti-Cheat or Copyprotection purposes.

Wine tries to accommodate those programs to as good as it can, but it’s not perfect. To make matters more complicated, those private structures differ from Windows version to Windows version and so different programs have different expectations.

You could try to find out what is supposed to be stored at the offset used by the program and see if you can modify Wine to behave similarly to Windows. It’s tricky to do that without violating Microsoft’s copyright though (I only found https://www.winehq.org/pipermail/wine-devel/2007-August/058455.html https://www.winehq.org/pipermail/wine-devel/2007-August/058455.html and the follow-up mails in a quick google search).

It is also possible that the program is really just broken and incredibly lucky on Windows. Even then you could in theory find out why it’s unlucky on Wine (e.g. how the allocated addresses look after its HeapAlloc calls) and try to improve the odds, but there is no guarantee that you can make it reliable.

[Fabian Maurer]

On Sunday, November 20, 2016 8:20:32 PM CET Stefan Dösinger wrote:
> You could try to find out what is supposed to be stored at the offset used
> by the program and see if you can modify Wine to behave similarly to
> Windows.

Well, there isn't much stored, on windows it's just null-bytes all the way. 
Probably because wine has a different allocation scheme in RtlAllocateHeap 
than windows.
> It is also possible that the program is really just broken and incredibly
> lucky on Windows. Even then you could in theory find out why it’s unlucky
> on Wine (e.g. how the allocated addresses look after its HeapAlloc calls)
> and try to improve the odds, but there is no guarantee that you can make it
> reliable.

I fear that's the case, it looks broken. Though I'll probably investigate it a 
bit longer before giving up.