https://bugs.winehq.org/show_bug.cgi?id=42125
Bug ID: 42125 Summary: 8k demos often fail with Bad EXE Format Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: aaronbpaden@gmail.com Distribution: ---
Several 8k demos fail to load because of a Bad EXE format error. I'm assuming they're hacking off unnecessary bits from the executable format to get within their size constraints, and wine is getting confused.
This is the error I get in the logs: wine: Bad EXE format for Z:\home\aaron\eos_-_blue_morpho_1280x720.exe.
This particular demo can be found at http://www.pouet.net/prod.php?which=68352
https://bugs.winehq.org/show_bug.cgi?id=42125
winetest@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winetest@luukku.com
--- Comment #1 from winetest@luukku.com --- I tested wine 2.0rc3 and I couldnt get it run but I dint see the message. Then another try with wine-staging 2.0.rc3 and I do see the message. I have had that error message on exes that have been only partly downloaded.
Can't explain this if it truly works fine on windows.
https://bugs.winehq.org/show_bug.cgi?id=42125
--- Comment #2 from Aaron Paden aaronbpaden@gmail.com --- Created attachment 56664 --> https://bugs.winehq.org/attachment.cgi?id=56664 objdump -x
The executable loads in my XP VM. It doesn't actually do anything -- I think this particular demo is NVIDIA only and it likely requires much more than the 128 MB of video memory that VirtualBox allows -- but the executable loads and uses up a bunch of memory and cpu time.
This error happens with fresh 32- and 64 bit prefixes with multiple 8k demos, not just this one.
I think to figure out what's going on would require someone who understands exes to look at it with a hex editor or whatever it is people use to examine exes. `objdump -x` is able to recognize the file as an executable, but somehow runs out of memory when trying to read the symbol table.
https://bugs.winehq.org/show_bug.cgi?id=42125
--- Comment #3 from Aaron Paden aaronbpaden@gmail.com --- Actually, I think the memory exhausted error with objdump is common to all of these executable. Does wine use libopcodes or something? I wonder if this might be a bug somewhere else in the stack.
https://bugs.winehq.org/show_bug.cgi?id=42125
--- Comment #4 from Dmitry Timoshkov dmitry@baikal.ru --- Created attachment 56675 --> https://bugs.winehq.org/attachment.cgi?id=56675 patch
That was an interesting exercise for a boring new year evening :)
Attached patch makes the demo load, but since my panel doesn't support 1280x720 mode and the demo doesn't check the return value of ChangeDisplaySettings it crashes here shortly after the following message:
err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found 1280x720x32 @0! (XRandR 1.2)
P.S. When testing the patch don't be surprised by huge loading times, the demo loading takes quite a bit of time also under Windows.
https://bugs.winehq.org/show_bug.cgi?id=42125
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
--- Comment #5 from Dmitry Timoshkov dmitry@baikal.ru --- Confirming.
https://bugs.winehq.org/show_bug.cgi?id=42125
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #56675|0 |1 is obsolete| |
--- Comment #6 from Dmitry Timoshkov dmitry@baikal.ru --- Created attachment 56676 --> https://bugs.winehq.org/attachment.cgi?id=56676 patch
It looks like I still had another hack in my tree that worked around another loader issue, and without that hack the patch won't work. Here is an improved version of the patch that should work better.
https://bugs.winehq.org/show_bug.cgi?id=42125
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |2.0-rc3
https://bugs.winehq.org/show_bug.cgi?id=42125
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com
--- Comment #7 from Austin English austinenglish@gmail.com --- Out of curiosity, what does file report for the exe?
https://bugs.winehq.org/show_bug.cgi?id=42125
--- Comment #8 from winetest@luukku.com --- (In reply to Dmitry Timoshkov from comment #6)
Created attachment 56676 [details] patch
It looks like I still had another hack in my tree that worked around another loader issue, and without that hack the patch won't work. Here is an improved version of the patch that should work better.
I can't test. I get a cash at gpu drivers. =>0 0x797e936f in amdgpu_dri.so (+0x1b5836f) (0x7d5aa680)
https://bugs.winehq.org/show_bug.cgi?id=42125
--- Comment #9 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to winetest from comment #8)
I can't test. I get a cash at gpu drivers. =>0 0x797e936f in amdgpu_dri.so (+0x1b5836f) (0x7d5aa680)
That means that the demo has successfully launched and started to create the textures in memory.
https://bugs.winehq.org/show_bug.cgi?id=42125
--- Comment #10 from Aaron Paden aaronbpaden@gmail.com ---
Out of curiosity, what does file report for the exe?
eos_-_blue_morpho_1280x720.exe: MS-DOS executable, MZ for MS-DOS
It's not really an MS-DOS program, though.
That means that the demo has successfully launched and started to create the textures in memory.
Yeah, it's not a surprise that the demo would crash. Not a lot of QA testing in the demoscene, I gather. :) The bug is only about the exe failing to load. Good job figuring out what was going on!
https://bugs.winehq.org/show_bug.cgi?id=42125
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Staged patchset| |https://github.com/wine-com | |pholio/wine-staging/tree/ma | |ster/patches/kernel32-PE_Lo | |ader_Fixes Status|NEW |STAGED CC| |dmitry@baikal.ru, | |erich.e.hoover@wine-staging | |.com, michael@fds-team.de, | |sebastian@fds-team.de
https://bugs.winehq.org/show_bug.cgi?id=42125
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |kernel32
https://bugs.winehq.org/show_bug.cgi?id=42125
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, obfuscation CC| |focht@gmx.net Blocks| |44860 Summary|8k demos often fail with |4k/8k demos often fail with |Bad EXE Format |'Bad EXE Format' due to | |Crinkler executable file | |compressor's "optimized" | |usage of PE header fields | |(loader compatibility) URL| |http://www.pouet.net/prod.p | |hp?which=68352 Component|kernel32 |ntdll Staged patchset|https://github.com/wine-com |https://github.com/wine-sta |pholio/wine-staging/tree/ma |ging/wine-staging/tree/mast |ster/patches/kernel32-PE_Lo |er/patches/kernel32-PE_Load |ader_Fixes |er_Fixes
--- Comment #11 from Anastasius Focht focht@gmx.net --- Hello folks,
filling/correcting some fields.
I've split out the OS loader problem with %EBX -> PEB address on PE entry to bug 44860 as these things are technically not related.
Most of the PE tools struggle or even crash when trying to get something useful out of this due to the "optimized" usage (truncation) of DOS, PE headers (basically providing the bare minimum info to not have the OS loader crash).
ProtectionID scan:
--- snip --- -=[ ProtectionID v0.6.9.0 DECEMBER]=- (c) 2003-2017 CDKiLLER & TippeX Build 24/12/17-21:05:42 Ready... Scanning -> Z:\home\focht\Downloads\eos_-_blue_morpho_1280x720.exe [!] Warning : File has NO sections (suspicious) [!] Warning : File has NO imports (suspicious) File Type : 32-Bit Exe (Subsystem : Win GUI / 2), Size : 8181 (01FF5h) Byte(s) | Machine: 0x14C (I386) [!] Warning - Entrypoint is INVALID (file may be damaged) Compilation TimeStamp : 0x7F61DB01 -> Mon 21st Sep 2037 04:18:09 (GMT) [TimeStamp] 0x7F61DB01 -> Mon 21st Sep 2037 04:18:09 (GMT) | PE Header | - | Offset: 0x0000000C | VA: 0x0040000C | - [LoadConfig] CodeIntegrity -> Flags 0xA3F0 | Catalog 0x46 (70) | Catalog Offset 0x2000001 | Reserved 0x46A4A0 [LoadConfig] GuardAddressTakenIatEntryTable 0x8000011 | Count 0x46A558 (4629848) [LoadConfig] GuardLongJumpTargetTable 0x8000001 | Count 0x46A5F8 (4630008) [LoadConfig] HybridMetadataPointer 0x8000011 | DynamicValueRelocTable 0x46A66C [LoadConfig] FailFastIndirectProc 0x8000011 | FailFastPointer 0x46C360 [LoadConfig] UnknownZero1 0x8000011 [File Heuristics] -> Flag #1 : 00010001000001111110000011001000 (0x1107E0C8) [DllCharacteristics] -> Flag : (0x0000) -> NONE [SectionCount] 0 (0x0) | ImageSize 0x2003B6EB (537114347) byte(s) [!} Warning - image has NO Data Directories... [!] Warning : Import Table is bad !!! -> Suspicious MZ Header.. [!] File appears to have no protection or is using an unknown protection - Scan Took : 0.174 Second(s) [0000000AEh (174) tick(s)] [506 of 580 scan(s) done] --- snip ---
LordPE dump:
NOTE: Most fields are not correctly interpreted due compressor taking advantage of fields being optional.
--- snip --- ->DOS Header e_magic: 0x5A4D e_cblp: 0x3032 e_cp: 0x4550 e_crlc: 0x0000 e_cparhdr: 0x014C e_minalloc: 0x0000 e_maxalloc: 0xDB01 e_ss: 0x7F61 e_sp: 0xD010 e_csum: 0x7317 e_ip: 0x4775 e_cs: 0xF9EB e_lfarlc: 0x0008 e_ovno: 0x0002 e_res: 0x010BC911854579C0 e_oemid: 0x011F e_oeminfo: 0x50D3 e_res2: 0xE2F73D90005C0000F3F7C139DB1948EB00000040 e_lfanew: 0x00000004
->File Header Machine: 0x014C (I386) NumberOfSections: 0x0000 TimeDateStamp: 0x7F61DB01 (GMT: Mon Sep 21 04:18:09 2037) PointerToSymbolTable: 0x7317D010 NumberOfSymbols: 0xF9EB4775 SizeOfOptionalHeader: 0x0008 Characteristics: 0x0002 (EXECUTABLE_IMAGE)
->Optional Header Magic: 0x010B (HDR32_MAGIC) MajorLinkerVersion: 0x11 MinorLinkerVersion: 0xC9 -> 17.201 SizeOfCode: 0x79C08545 SizeOfInitializedData: 0x50D3011F SizeOfUninitializedData: 0x3D90E2F7 AddressOfEntryPoint: 0x0000005C BaseOfCode: 0xC139F3F7 BaseOfData: 0x48EBDB19 ImageBase: 0x00400000 SectionAlignment: 0x00000004 FileAlignment: 0x00000004 MajorOperatingSystemVersion: 0xA30F MinorOperatingSystemVersion: 0x9C2D -> 41743.39981 MajorImageVersion: 0x4001 MinorImageVersion: 0x8D00 -> 16385.36096 MajorSubsystemVersion: 0x0004 MinorSubsystemVersion: 0xCEEB -> 4.52971 Win32VersionValue: 0x00000000 SizeOfImage: 0x0000469C SizeOfHeaders: 0x00000040 CheckSum: 0xBBED3153 Subsystem: 0x0002 (WINDOWS_GUI) DllCharacteristics: 0x0000 SizeOfStackReserve: 0x0174BE90 SizeOfStackCommit: 0x016A0040 SizeOfHeapReserve: 0x0000BF58 SizeOfHeapCommit: 0x00B10042 LoaderFlags: 0x12EB5790 NumberOfRvaAndSizes: 0x00000000 ... --- snip ---
The PE compressor used for most of these 4K/8K demos is named "Crinkler":
--- quote --- Crinkler is an executable file compressor (or rather, a compressing linker) for Windows specifically targeted towards executables with a size of just a few kilobytes. As of 2018, it is the most widely used tool for compressing 4k intros.
Crinkler is being developed by Rune L. H. Stubbe (Mentor/TBC) and Aske Simon Christensen (Blueberry/Loonies). --- quote ---
The compression itself and some parts of imports resolver are nicely covered here:
http://code4k.blogspot.de/2010/12/crinkler-secrets-4k-intro-executable.html
Original presentation: ftp://ftp.scene.org/pub/parties/2005/assembly05/seminars/crinkler-compression.ppt (check "Header optimization" slides)
The decompression area for code, data etc. starts usually at fixed 0x420000 address range. One can easily bypass all the decompression stuff from entry and set a hardware breakpoint on execution to 0x420000.
I'm surprised that the 8K demo from http://www.pouet.net/prod.php?which=68352 does work at all. Crinkler uses the PE optional header 'SizeOfImage' field to have the loader allocate a huge chunk of memory which used for decompression. In case of the aforementioned demo it's only 0x0000469C (rounded up -> 0x5000). That executable should not work on modern Windows nor in Wine. Did someone really test this on Windows XP SP3(latest), Windows 7 and current Wine-Staging?
Memory map:
--- snip --- Address Size Owner Section Contains 00110000 00010000 00220000 00001000 Process Parameters 00230000 00003000 Environment 00400000 00005000 eos_-_blue_morph PE header 00410000 00001000 00411000 00001000 00412000 0174E000 Stack of main thread 7B420000 00001000 KERNEL32 PE header 7B421000 00221000 KERNEL32 .text Code 7B642000 001B1000 KERNEL32 .data Data,imports,exports,resources 7BC30000 00001000 ntdll PE header 7BC31000 000BF000 ntdll .text Code 7BCF0000 0001D000 ntdll .data Data,exports,resources 7FFD8000 00004000 Data block of main thread 7FFDF000 00001000 Process Environment Block 7FFE0000 00010000 --- snip ---
Even with that huge thread stack near (accessible mapping) it can't work by chance, because the decompressor wants access memory beyond that (0x194Bxxxx).
I've tested some other 8K demos and they actually work with the staged patchset. For example: http://www.pouet.net/prod.php?which=66502
$ sha1sum lns-* 482e8d0fe4b5e6f7ffa6f2125143da5aadab34ad lns-lpt-psyltcipher_1080.exe 1da4738309c2738f5f89c4713c689a93b94cd898 lns-lpt-psyltcipher_1080_vsync.exe 7bab7cb1c8f528878b1547147d2c97dfa1032eab lns-lpt-psyltcipher_720.exe 85d1624523110af6c00cc53027e3b504ef3d5362 lns-lpt-psyltcipher.zip
$ du -sh lns-* 8.0K lns-lpt-psyltcipher_1080.exe 8.0K lns-lpt-psyltcipher_1080_vsync.exe 8.0K lns-lpt-psyltcipher_720.exe 24K lns-lpt-psyltcipher.zip
The demo from http://www.pouet.net/prod.php?which=68352 doesn't even work with Wine-Staging 3.4 due to aforementioned reasons.
$ sha1sum eos_-_blue_morpho* 0403b96eaf17c44e09fa3e171c18b1cb86c37718 eos_-_blue_morpho_1280x720.exe 9eda39b824ebb57f0b48010b5b1e75207885c083 eos_-_blue_morpho.zip
$ du -sh eos_-_blue_morpho* 8.0K eos_-_blue_morpho_1280x720.exe 1.2M eos_-_blue_morpho.zip
$ wine --version wine-3.4-256-g725ad420e1
Regards
https://bugs.winehq.org/show_bug.cgi?id=42125
tokktokk fdsfgs@krutt.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fdsfgs@krutt.org
https://bugs.winehq.org/show_bug.cgi?id=42125
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |aros@gmx.com
--- Comment #12 from Dmitry Timoshkov dmitry@baikal.ru --- *** Bug 47895 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=42125
--- Comment #13 from Zebediah Figura z.figura12@gmail.com --- *** Bug 38176 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=42125
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |48898
https://bugs.winehq.org/show_bug.cgi?id=42125
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|4k/8k demos often fail with |4k/8k demos often fail with |'Bad EXE Format' due to |'Bad EXE Format' or 'error |Crinkler executable file |c0000020' due to Crinkler |compressor's "optimized" |executable file |usage of PE header fields |compressor's "optimized" |(loader compatibility) |usage of PE header fields | |(loader compatibility)
--- Comment #14 from Anastasius Focht focht@gmx.net --- Hello folks,
adjusting the summary line to include the error from bug 48898
--- snip --- 0009:err:module:__wine_process_init failed to load L"Z:\home\focht\Downloads\End of time 720p.exe", error c0000020 --- snip ---
Starting with Wine 4.20, the error message changed from 'Bad EXE Format' to 'error c0000020'. Most likely due to commit https://source.winehq.org/git/wine.git/commitdiff/b0199ea2fe8f9b77aee7ab4f68... ("ntdll: Load the main binary directly in ntdll when possible.").
$ wine --version wine-5.6
Regards
https://bugs.winehq.org/show_bug.cgi?id=42125
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Fixed by SHA1| |ae9eb36e21c9b8e31b1e4a4c1eb | |6deae9b90262d Status|STAGED |RESOLVED
--- Comment #15 from Dmitry Timoshkov dmitry@baikal.ru --- The patches are now in git: ae9eb36e21c9b8e31b1e4a4c1eb6deae9b90262d a0772da5cf507b10800d5358554d682f82f48724 360820fb5830750b23543dc34188970aa9431835 1a7dd7cdbe184ff3fdf2781e9a2222872bacee2c
Thanks Alexandre for further improvements.
https://bugs.winehq.org/show_bug.cgi?id=42125
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #16 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 5.9.
https://bugs.winehq.org/show_bug.cgi?id=42125
Oleg Kuznetsov oleg.kuznetsov@metamint.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |oleg.kuznetsov@metamint.ru
--- Comment #17 from Oleg Kuznetsov oleg.kuznetsov@metamint.ru --- (In reply to Anastasius Focht from comment #11)
Hello folks,
--- snip ---
The PE compressor used for most of these 4K/8K demos is named "Crinkler":
--- quote --- Crinkler is an executable file compressor (or rather, a compressing linker) for Windows specifically targeted towards executables with a size of just a few kilobytes. As of 2018, it is the most widely used tool for compressing 4k intros.
Crinkler is being developed by Rune L. H. Stubbe (Mentor/TBC) and Aske Simon Christensen (Blueberry/Loonies). --- quote ---
The compression itself and some parts of imports resolver are nicely covered here:
http://code4k.blogspot.de/2010/12/crinkler-secrets-4k-intro-executable.html
Original presentation: ftp://ftp.scene.org/pub/parties/2005/assembly05/seminars/crinkler- compression.ppt (check "Header optimization" slides)
The decompression area for code, data etc. starts usually at fixed 0x420000 address range. One can easily bypass all the decompression stuff from entry and set a hardware breakpoint on execution to 0x420000.
I'd like to note, that the source of the tool was released a few days ago: https://github.com/runestubbe/Crinkler/
https://bugs.winehq.org/show_bug.cgi?id=42125
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- URL|http://www.pouet.net/prod.p |https://web.archive.org/web |hp?which=68352 |/20210319082714/http://www. | |amietia.com/eos_-_blue_morp | |ho.zip