Brutkey

Tom
@pertho@mastodon.bsd.cafe

I think I've gotten further with this #FreeBSD #wine issue, knowledge-wise. The program I run for it does some live patching in memory (basically reads in a .dll and binary patches it in memory)

This all runs just fine in
#Linux but fails in FreeBSD.

The system call I could find for it in WINE debugging was: KERNEL32.ReadProcessMemory

I also get this dreaded message:
wineserver: file_set_error() can't map error: Cannot allocate memory

This is FreeBSD 14.3, wine-devel 10.12.
Have tried disabling ASLR, enabling W^X (which I know is bad), have tried both 64-bit and 32-bit (WINEARCH=win32) prefixes. Same problem happens.

Is FreeBSD preventing WINE programs from reading each others' memory? I don't even know if it even got to the write part, it couldn't read it at all.

Please boost far and wide and many thanks in advance to anyone in the FreeBSD gaming community who might know the answer here (or a friendly FreeBSD dev?)

David Chisnall (*Now with 50% more sarcasm!*)
@david_chisnall@infosec.exchange

@pertho@mastodon.bsd.cafe

I would guess that these functions are implemented with ptrace (if they’re implemented at all, they might not be). There are
various sysctls and procctls that can prevent ptrace from working. It might be worth using trace to see which system calls are failing.


Tom
@pertho@mastodon.bsd.cafe

@david_chisnall@infosec.exchange I got quite a bit further. I ended up needing to mount /proc:

mount -t procfs proc /proc

Now I get odd SmartHeap error about being out of memory. Is there some sysctl I need to bump up? kern.ipc.shmall I set to 10x the normal amount but that didn't help.

I thought /proc was a relic of the past. I guess WINE still uses it for some syscalls.

David Chisnall (*Now with 50% more sarcasm!*)
@david_chisnall@infosec.exchange

@pertho@mastodon.bsd.cafe FreeBSD programs typically don’t use /proc, but a lot of things ported from Linux do. Did you run it in ktrace? That should help you find the system call that’s failing and leading to the OOM. If it’s something related to a file descriptor (e.g. a SysV memory object) then that should let you figure out which kind it is.