http://reverseengineering.stackexchange ... er-ollydbg
I've noticed something strange. OllyDbg seems to correctly load Wine's own dlls. But when I check PE header in OllyDBG it differs from that what I would expect. In all other cases file content is an exact match of PE header in OllyDbg. But in case of Wine libraries even the file signature is different.
First three bytes in file: 4D 5A 40 OllyDbg memory dump: 4D 5A 90
Then the rest of loaded library differs as well. I did not notice such behaviour with few Windows dlls that I have checked. Googling didn't help either. Does anybody know what's going on?
more finds
Example of differences
in file - OllyDbg PE header
DOS_PEOffset 60 - 40
Number of Sections 3 - 2
OllyDbg seems to be able to read exported Wine dll symbols despite of my own file analysis expecting Export Table RVA and Export Table Size to be 0. Please note that my own analysis works correctly on normal Windows dll files.
Above differences are from oleaut32.dll, but I’ve noticed similar when checking other Wine dlls. Location of Wine dlls: ~/.wine/drive_c/windows/system32
I'm using wine-1.4.1 and OllyDbg 2.01.
Strange behaviour of Wine dlls under OllyDbg
Re: Strange behaviour of Wine dlls under OllyDbg
bigos 1.4.1 is no longer supported to start off with.
~/.wine/drive_c/windows/system32 Is not the location of wine made dll replacements. Please note my words dll replacements. The dll replacements end in .dll.so (elf pe format).
In the ~/.wine/drive_c/windows/system32 you will set a set of fakes made by wine. I do mean fakes. They are the min form to convince programs the dll exists. Yes the fakes have export size 0. The fakes also contain no executable code sections.
Under debian that I run /usr/lib/i386-linux-gnu/wine/wine/ and /usr/lib/x86_64-linux-gnu/wine/wine are where the real .dll.so files are hiding. This is why they look different. Wine own dlls are not in fact in ~/.wine/drive_c/windows/system32 . Wine loader swaps them out.
Please bewared static looking at elf PE( what wine own binaries are ) will also not be what you are expecting. The in memory export table and the export table in a elf PE are different. In fact inside a elf can be different.
ifunc ("resolver") http://gcc.gnu.org/onlinedocs/gcc/Funct ... butes.html this exists on Elf platforms. So the address in the export table on disk may in fact just point to a resolver function that runs once then tells where the function is then does not run again.
Wine internally is it own format that just happens to be close enough to PE to keep windows applications happy.
~/.wine/drive_c/windows/system32 Is not the location of wine made dll replacements. Please note my words dll replacements. The dll replacements end in .dll.so (elf pe format).
In the ~/.wine/drive_c/windows/system32 you will set a set of fakes made by wine. I do mean fakes. They are the min form to convince programs the dll exists. Yes the fakes have export size 0. The fakes also contain no executable code sections.
Under debian that I run /usr/lib/i386-linux-gnu/wine/wine/ and /usr/lib/x86_64-linux-gnu/wine/wine are where the real .dll.so files are hiding. This is why they look different. Wine own dlls are not in fact in ~/.wine/drive_c/windows/system32 . Wine loader swaps them out.
Please bewared static looking at elf PE( what wine own binaries are ) will also not be what you are expecting. The in memory export table and the export table in a elf PE are different. In fact inside a elf can be different.
ifunc ("resolver") http://gcc.gnu.org/onlinedocs/gcc/Funct ... butes.html this exists on Elf platforms. So the address in the export table on disk may in fact just point to a resolver function that runs once then tells where the function is then does not run again.
Wine internally is it own format that just happens to be close enough to PE to keep windows applications happy.
