https://bugs.winehq.org/show_bug.cgi?id=38714
Bug ID: 38714 Summary: 64-bit ARM Windows applications from Windows SDK crash in entry (loader needs to set/randomize cookie for PE modules) Product: Wine Version: 1.7.44 Hardware: aarch64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs@winehq.org Reporter: focht@gmx.net Distribution: ---
Hello folks,
this is more an educated guess since I only have remote access to some 64-bit ARM Linux VM without proper debugging tools. Winedbg/gdb proxy is unusable as of now and my shiny JTAG Debugger for Cortex-A5x (ICD) can't work "remotely".
Anyway, I think I gathered enough information without the need for debugging.
Don't complain about 'root' - it's not my machine :)
--- snip --- # wine64 winedbg arm64/mt.exe
Wine-dbg>info process pid threads executable (all id:s are in hex)
00000024 1 'mt.exe'
00000026 2 _ 'wineconsole.exe' 00000014 4 'explorer.exe' 0000000e 5 'services.exe' 0000001b 3 _ 'plugplay.exe' 00000012 3 _ 'winedevice.exe'
Wine-dbg>info thread process tid prio (all id:s are in hex) 0000000e services.exe 0000001e 0 0000001d 0 00000016 0 00000010 0 0000000f 0 00000012 winedevice.exe 0000001a 0 00000019 0 00000013 0 00000014 explorer.exe 00000023 0 00000022 0 00000021 0 00000015 0 0000001b plugplay.exe 00000020 0 0000001f 0 0000001c 0 00000024 (D) Z:\root\wine\64\arm64\mt.exe 00000025 0 <== 00000026 wineconsole.exe 00000028 0 00000027 0 --- snip ---
--- snip --- Wine-dbg>si be_arm64_single_step: not done Unhandled exception: illegal instruction in 64-bit code (0x000000014010ce78). Register dump: ARM64 EL0t Mode Pc:000000014010ce78 Sp:0000007f8aa6fe20 Lr:000000014010ca7c Pstate:0000000060000000(-ZC-) x0: 0000007f8bd0c000 x1: 0000000000000005 x2: 0000007f8bd0e000 x3: 0000000000000001 x4: 0000000000000001 x5: f5183970d346f95f x6: 0000000000000001 x7: 0000000000000002 x8: 00002b992ddfa232 x9: 00002b992ddfa232 x10:00000000031bb537 x11:0000007f8bd0f078 x12:0000007ffb057a54 x13:0000007ffb057a58 x14:0000007ffb057b20 x15:0000007f8bb35908 ip0:0000007f8b966120 ip1:0000007f8b9c9e10 x18:0000007f8bb359d0 x19:0000007f8bd0c000 x20:000000014010ca70 x21:0000000000000000 x22:0000007f8b949000 x23:0000007f8acd3584 x24:0000007f8acfd000 x25:0000007f8aee07f0 x26:0000007ffb057e90 x27:0000007ffb057e08 x28:0000007f8ad15000 Fp:0000007f8aa6fe20 Stack dump: 0x0000007f8aa6fe20: 0000007f8aa6fe30 0000007f8acd35e0 0x0000007f8aa6fe30: 0000007f8aa6fe60 0000007f8b9310ac 0x0000007f8aa6fe40: 0000007f8acd3584 0000007f8bd0c000 0x0000007f8aa6fe50: 0000000000000000 0000000000000000 0x0000007f8aa6fe60: 0000007f8aa6ffe0 0000007f8b90ca20 0x0000007f8aa6fe70: 0000007f8bd0c000 0000007f8acd3584 0x0000007f8aa6fe80: ffffffffffffffff 0000007f8b941ab4 0x0000007f8aa6fe90: 0000007f8acb67cc 0000007f8acd3584 0x0000007f8aa6fea0: 0000007f8bd0c000 0000000000000000 0x0000007f8aa6feb0: 0000007f8b949000 0000007f8acd3584 0x0000007f8aa6fec0: 0000007f8acfd000 0000007f8aee07f0 0x0000007f8aa6fed0: 0000007ffb057e90 0000007ffb057e08 Backtrace: =>0 0x000000014010ce78 in mt (+0x10ce78) (0x0000007f8aa6fe20) 1 0x000000014010ca7c in mt (+0x10ca7b) (0x0000007f8aa6fe20) ... --- snip ---
The entry point code of the app:
--- snip --- entry: 0000000140020300 STP X29, X30, [SP,#-0x10]! 0000000140020304 MOV X29, SP 0000000140020308 BL 140020E40 000000014002030C BL 140020318 0000000140020310 LDP X29, X30, [SP],#0x10 0000000140020314 RET ... 0000000140020E40 ADRP X8, #0x140030000 ; .data 0000000140020E44 LDR X8, [X8,#0x800] ; offset to cookie 000000014010CE68 CBZ X8, 14010CE78 000000014010CE6C LDR X9, =0x2B992DDFA232 ; default cookie arm64? 000000014010CE70 CMP X8, X9 000000014010CE74 B.NE 14010CE7C 000000014010CE78 BRK #0xF003 ; whoops, bail here 000000014010CE7C MVN X8, X8 0000000140020E60 ADRP X9, #0x140030000 0000000140020E64 STR X8, [X9,#0x808] 000000014010CE88 RET
.data: ... 0000000140030800 DCQ 0x2B992DDFA232 ; module security cookie (default val) --- snip ---
Looks like the entry code checks for the default value of the security cookie and bails if it's still unmodified.
MSDN: https://msdn.microsoft.com/en-us/library/windows/desktop/ms680328%28v=vs.85%...
IMAGE_LOAD_CONFIG_DIRECTORY64 -> SecurityCookie (64-bit VA)
The loader needs to randomize the cookie for each module if present (= non-zero VA) before calling the entry.
---
Another tidbit:
For decoding the immediate field in the emitted 'brk' instruction I only found information for the Linux counterpart which says range 0x2000-0xffff is app/user-defined.
https://gcc.gnu.org/ml/gcc-patches/2013-11/msg02228.html
--- quote --- POSIX siginfo BRK #imm16 si_signo si_code Purpose ---------- -------- ------- -------
0000-0fff S/w breakpoint, reserved for debuggers 0000-3ff SIGTRAP TRAP_BRKPT- EL0 breakpoint (e.g. gdb) 0400-7ff SIGILL ILL_ILLTRP* EL1 breakpoint (e.g. kgdb) 0800-bff SIGILL ILL_ILLTRP* EL2 breakpoint 0c00-fff SIGILL ILL_ILLTRP* EL3 breakpoint
1000-1fff C/C++ runtime errors 1000 SIGABRT n/a libc abort() 1001 SIGFPE FPE_INTDIV integer divide by zero 1002 SIGFPE FPE_INTOVF integer overflow 1003 SIGFPE FPE_FLTDIV floating-point divide by zero 1004 SIGFPE FPE_FLTOVF floating-point overflow 1005 SIGFPE FPE_FLTUND floating-point underflow 1006 SIGFPE FPE_FLTRES floating-point inexact result 1007 SIGFPE FPE_FLTINV floating-point invalid op 1008 SIGFPE FPE_FLTSUB subscript out of range 1009-1fff SIGILL ILL_ILLTRP unused but reserved
2000-ffff SIGILL ILL_ILLOPC+ Guaranteed unused, resvd for apps
- This is the signal generated now for all values of BRK immediate. GDB currently uses "BRK #0"
* The EL1/EL2/EL3 breakpoints would deliver a SIGILL if they are executed by EL0 code, and caught by the EL1 kernel. A s/w debugger operating at a higher EL which placed such breakpoints would presumably catch them and handle them, without the EL1 kernel ever seeing them.
+ Immediate values 0x2000-ffff generate the same signal as any other UNDEFINED instruction encoding, but with guaranteed behaviour for JITs etc. The original imm16 value could be made available in the si_trapno field of the signal context. --- quote ---
Regards
https://bugs.winehq.org/show_bug.cgi?id=38714
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nerv@dawncrow.de
https://bugs.winehq.org/show_bug.cgi?id=38714
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download URL| |http://go.microsoft.com/fwl | |ink/p/?LinkId=536682 Summary|64-bit ARM Windows |64-bit ARM Windows |applications from Windows |applications from Windows |SDK crash in entry (loader |SDK for Windows 10 crash in |needs to set/randomize |entry (loader needs to |cookie for PE modules) |set/randomize security | |cookie for PE modules)
https://bugs.winehq.org/show_bug.cgi?id=38714
--- Comment #1 from Anastasius Focht focht@gmx.net --- Hello folks,
update ... Andre made a hack for security cookie initialization which proved my guess/analysis.
Some simple SDK apps actually started to run now (unless one feeds command line arguments that triggers vsnprintf/formatmessage/va_arg handling -> another bug):
--- snip --- $ ./tools/winedump/winedump arm64/uuidgen.exe Contents of arm64/uuidgen.exe: 22512 bytes
File Header Machine: AA64 (ARM64) Number of Sections: 6 TimeDateStamp: 5503E851 (Sat Mar 14 08:50:41 2015) offset 240 PointerToSymbolTable: 00000000 NumberOfSymbols: 00000000 SizeOfOptionalHeader: 00F0 Characteristics: 0022 EXECUTABLE_IMAGE LARGE_ADDRESS_AWARE
Optional Header (64bit) Magic 0x20B 523 linker version 12.10 size of code 0x2000 8192 size of initialized data 0x1600 5632 size of uninitialized data 0x0 0 entrypoint RVA 0x116c0 71360 base of code 0x10000 65536 image base 0x1140000000 section align 0x10000 65536 file align 0x200 512 required OS version 10.00 image version 10.00 subsystem version 6.02 Win32 Version 0x0 0 size of image 0x70000 458752 size of headers 0x400 1024 checksum 0x12b32 76594 Subsystem 0x3 (Windows CUI) DLL characteristics: 0xC160 DYNAMIC_BASE NX_COMPAT TERMINAL_SERVER_AWARE stack reserve size 0x40000 stack commit size 0x2000 heap reserve size 0x100000 heap commit size 0x1000 loader flags 0x0 0 RVAs & sizes 0x10 16
... --- snip ---
--- snip --- $ ./wine64 arm64/uuidgen.exe err:virtual:map_image 0x140010600 0x140000000 67072 err:virtual:map_image 140020008 5368840200 fixme:heap:RtlSetHeapInformation (nil) 1 (nil) 0 stub e93a8c80-aa6d-407d-bfe8-fe18eefce7fa --- snip ---
--- snip --- $ ./wine64 arm64/extidgen.exe err:virtual:map_image 0x140010260 0x140000000 66144 err:virtual:map_image 140020000 5368840192 fixme:heap:RtlSetHeapInformation (nil) 1 (nil) 0 stub
dwExtensionID0 = 0x087D0D4D; dwExtensionID1 = 0x44869C5A; dwExtensionID2 = 0x29DC7C85; dwExtensionID3 = 0x468DAFE7; --- snip ---
Regards
https://bugs.winehq.org/show_bug.cgi?id=38714
--- Comment #2 from Anastasius Focht focht@gmx.net --- Hello André,
I've seen your patch on mailing list.
https://source.winehq.org/patches/data/112108
Although the bug is about 64-bit ARM, apps targeting Windows 8.x x64 and Windows 10 x64 will require the same mechanism.
You are not free to chose any "magic" cookie value when you do the security cookie initialization in loader.
Example application, targeting newer 64-bit Windows x64:
http://files.emeditor.com/emed64_15.1.4_portable.zip
The app crashes with your patch. Unfortunately through some fast exit path, without winedbg/debugger being able to attach (bug 24038)
"init cookie" function at entry point:
--- snip --- ... 0000000140103CA0 mov [rsp+20h], rbx 0000000140103CA5 push rbp 0000000140103CA6 mov rbp, rsp 0000000140103CA9 sub rsp, 20h 0000000140103CAD mov rax, cs:qword_140135540 ; security cookie 0000000140103CB4 and qword ptr [rbp+18h], 0 0000000140103CB9 mov rbx, 2B992DDFA232h ; default init value for x64? 0000000140103CC3 cmp rax, rbx 0000000140103CC6 jnz short 140103D37 ; no? init already done by loader 0000000140103CC8 lea rcx, [rbp+18h] 0000000140103CCC call cs:GetSystemTimeAsFileTime 0000000140103CD2 mov rax, qword ptr [rbp+18h] 0000000140103CD6 mov [rbp+10h], rax 0000000140103CDA call cs:GetCurrentThreadId 0000000140103CE0 mov eax, eax 0000000140103CE2 xor [rbp+10h], rax 0000000140103CE6 call cs:GetCurrentProcessId 0000000140103CEC lea rcx, [rbp+20h] 0000000140103CF0 mov eax, eax 0000000140103CF2 xor [rbp+10h], rax 0000000140103CF6 call cs:QueryPerformanceCounter 0000000140103CFC mov eax, dword ptr [rbp+20h] 0000000140103CFF shl rax, 20h 0000000140103D03 lea rcx, [rbp+10h] 0000000140103D07 xor rax, qword ptr [rbp+20h] 0000000140103D0B xor rax, [rbp+10h] 0000000140103D0F xor rax, rcx 0000000140103D12 mov rcx, 0FFFFFFFFFFFFh ; highest word = zero! 0000000140103D1C and rax, rcx 0000000140103D1F mov rcx, 2B992DDFA233h 0000000140103D29 cmp rax, rbx 0000000140103D2C cmovz rax, rcx 0000000140103D30 mov cs:qword_140135540, rax ; newly randomized cookie 0000000140103D37 mov rbx, [rsp+48h] 0000000140103D3C not rax 0000000140103D3F mov cs:qword_140135548, rax 0000000140103D46 add rsp, 20h 0000000140103D4A pop rbp 0000000140103D4B retn ... --- snip ---
Runtime check for proper security cookie value:
--- snip --- 00000001400FB080 cmp rcx, cs:qword_140135540 ; security cookie 00000001400FB087 jnz short 1400FB09A 00000001400FB089 rol rcx, 10h ; get highest word 00000001400FB08D test cx, 0FFFFh ; highest word == zero? 00000001400FB092 jnz short 1400FB096 00000001400FB094 rep retn ; yes, oki 00000001400FB096 ror rcx, 10h ; restore highest word 00000001400FB09A jmp 1400FAE5C ; problem -> bail! --- snip ---
--- snip --- .data ... 0000000140135540 qword_140135540 dq 2B992DDFA232h ; default cookie magic x64 --- snip ---
Debugger:
ECX = 0x5ec0617fc0041eb9 = your "magic" value set in loader
--- snip --- Wine-dbg>info reg
Register dump: rip:00000001400fb087 rsp:000000000023f2e8 rbp:000000000023f530 eflags:00000346 ( - -- IT Z- -P- ) rax:0000000000000001 rbx:000000000023f330 rcx:5ec0617fc0041eb9 rdx:00000000ffffffff rsi:0000000000000100 rdi:0000000000000001 r8:0000000000000100 r9:000000000023f950 r10:0000000000000001 r11:000000000023f330 r12:000000000023f650 r13:0000000000000001 r14:00000000000004e4 r15:0000000000000100
Wine-dbg>si 0x00000001400fb089: rolq $0x10,%rcx
Wine-dbg>si 0x00000001400fb08d: testw $0xffff,%cx
Wine-dbg>info reg Register dump: rip:00000001400fb08d rsp:000000000023f2e8 rbp:000000000023f530 eflags:00000346 ( - -- IT Z- -P- ) rax:0000000000000001 rbx:000000000023f330 rcx:617fc0041eb95ec0 rdx:00000000ffffffff rsi:0000000000000100 rdi:0000000000000001 r8:0000000000000100 r9:000000000023f950 r10:0000000000000001 r11:000000000023f330 r12:000000000023f650 r13:0000000000000001 r14:00000000000004e4 r15:0000000000000100
Wine-dbg>si 0x00000001400fb092: jnz 0x00000001400fb096
Wine-dbg>si 0x00000001400fb096: rorq $0x10,%rcx
<process termination> --- snip ---
Regards
https://bugs.winehq.org/show_bug.cgi?id=38714
--- Comment #3 from Anastasius Focht focht@gmx.net --- Hello folks,
although not directly related I found this wiki with information on cross compiling FFmpeg for various Windows RT flavours, including Windows on ARM:
https://trac.ffmpeg.org/wiki/CompilationGuide/WinRT
It might prove useful to have this build setup running under Wine
* Microsoft Visual Studio 2013, 2015 (command line) * MSYS2 * YASM
Regards
https://bugs.winehq.org/show_bug.cgi?id=38714
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |7e1c886fbfd362376b6aebe5381 | |ab7d4433c3371 Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #4 from André H. nerv@dawncrow.de --- This is fixed by https://source.winehq.org/git/wine.git/commit/7e1c886fbfd362376b6aebe5381ab7...
https://bugs.winehq.org/show_bug.cgi?id=38714
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #5 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 1.7.47.
https://bugs.winehq.org/show_bug.cgi?id=38714
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- URL|http://go.microsoft.com/fwl |https://web.archive.org/web |ink/p/?LinkId=536682 |/20200915210324/http://down | |load.microsoft.com/download | |/6/3/B/63BADCE0-F2E6-44BD-B | |2F9-60F5F073038E/standalone | |sdk/SDKSETUP.EXE
--- Comment #6 from Anastasius Focht focht@gmx.net --- Hello folks,
adding stable download links via Internet Archive for documentation.
NOTE: Many older Windows SDK web-installers which use builtin 'bing.com' URL bootstrapper are broken by design.
Example snapshot:
https://web.archive.org/web/20150704231532if_/http://download.microsoft.com/...
--- snip --- ... [0250:0298][2021-07-18T22:42:33]w343: Prompt for source of package: package_.Net_Framework_4.5, payload: package_.Net_Framework_4.5, path: Z:\home\focht\Downloads\Installers\dotNetFx45_Full_x86_x64.exe [0250:0298][2021-07-18T22:42:33]i000: package_.Net_Framework_4.5 [0250:0298][2021-07-18T22:42:33]i000: Resolving download root for: http://go.microsoft.com/fwlink/?LinkID=535005 [0250:0298][2021-07-18T22:42:33]i000: HTTP status code: 302 [0250:0298][2021-07-18T22:42:33]i000: Redirected URL: https://www.bing.com?ref=go&linkid=535005 [0250:0298][2021-07-18T22:42:33]i000: Resolved redirected download root: https://www.bing.com?ref=go&linkid=535005/ [0250:0298][2021-07-18T22:42:33]i000: package_.Net_Framework_4.5 to https://www.bing.com/Installers/dotNetFx45_Full_x86_x64.exe [0250:0298][2021-07-18T22:42:33]i338: Acquiring package: package_.Net_Framework_4.5, payload: package_.Net_Framework_4.5, download from: https://www.bing.com/Installers/dotNetFx45_Full_x86_x64.exe [0250:0298][2021-07-18T22:42:34]e000: Error 0x80070002: Failed to send request to URL: https://www.bing.com/Installers/dotNetFx45_Full_x86_x64.exe [0250:0298][2021-07-18T22:42:34]e000: Error 0x80070002: Failed to connect to URL: https://www.bing.com/Installers/dotNetFx45_Full_x86_x64.exe [0250:0298][2021-07-18T22:42:34]e000: Error 0x80070002: Failed to get size and time for URL: https://www.bing.com/Installers/dotNetFx45_Full_x86_x64.exe [0250:0298][2021-07-18T22:42:34]e000: Error 0x80070002: Failed attempt to download URL: 'https://www.bing.com/Installers/dotNetFx45_Full_x86_x64.exe' to: 'C:\users\focht\Temp{d46d7f88-dc0a-4d24-b834-bbed388e3993}\package_.Net_Framework_4.5' [0250:0298][2021-07-18T22:42:34]i000: Retry downloading of payload [package_.Net_Framework_4.5] for Package package_.Net_Framework_4.5 ... --- snip ---
Newer snapshot of web-installer which uses 'go.microsoft.com' URL bootstrapper.
https://web.archive.org/web/20200915210324/http://download.microsoft.com/dow...
--- snip --- ... [03B4:03FC][2021-07-18T22:53:14]w343: Prompt for source of package: package_.Net_Framework_4.5, payload: package_.Net_Framework_4.5, path: Z:\home\focht\Downloads\Installers\dotNetFx45_Full_x86_x64.exe [03B4:03FC][2021-07-18T22:53:14]i000: package_.Net_Framework_4.5 [03B4:03FC][2021-07-18T22:53:14]i000: Resolving download root for: http://go.microsoft.com/fwlink/?prd=11966&pver=1.0&plcid=0x409&c... [03B4:03FC][2021-07-18T22:53:14]i000: HTTP status code: 302 [03B4:03FC][2021-07-18T22:53:14]i000: Redirected URL: https://download.microsoft.com/download/6/3/B/63BADCE0-F2E6-44BD-B2F9-60F5F0... [03B4:03FC][2021-07-18T22:53:14]i000: Resolved redirected download root: https://download.microsoft.com/download/6/3/B/63BADCE0-F2E6-44BD-B2F9-60F5F0... [03B4:03FC][2021-07-18T22:53:14]i000: package_.Net_Framework_4.5 to https://download.microsoft.com/download/6/3/B/63BADCE0-F2E6-44BD-B2F9-60F5F0... [03B4:03FC][2021-07-18T22:53:14]i338: Acquiring package: package_.Net_Framework_4.5, payload: package_.Net_Framework_4.5, download from: https://download.microsoft.com/download/6/3/B/63BADCE0-F2E6-44BD-B2F9-60F5F0... [03A0:03CC][2021-07-18T22:53:22]i000: Moving payload from working path 'C:\users\focht\Temp{f23f94c5-8bba-4202-85ad-c83d4402cdc1}\package_.Net_Framework_4.5' to path 'C:\users\focht\Downloads\Windows Kits\10\StandaloneSDK\Installers\dotNetFx45_Full_x86_x64.exe' ... --- snip ---
$ sha1sum SDKSETUP.EXE d9d88a2c3c8c196e06a948613b4c749addbaef04 SDKSETUP.EXE
$ du -sh SDKSETUP.EXE 1.2M SDKSETUP.EXE
Figuring out the actual installer payload package(s) of interest:
--- snip --- $ grep -ral arm64\\mt.exe .wine/drive_c/
.wine/drive_c/users/focht/Temp/standalonesdk/Windows_Software_Development_Kit___Windows_10.0.14393.33_20210718230231_009_package_WindowsSDKforWindowsStoreAppsTools_x86_en_us.log --- snip ---
--- snip --- ... [03B4:03FC][2021-07-18T22:53:46]i338: Acquiring package: package_WindowsSDKforWindowsStoreAppsTools_x86_en_us, payload: package_WindowsSDKforWindowsStoreAppsTools_x86_en_us, download from: https://download.microsoft.com/download/6/3/B/63BADCE0-F2E6-44BD-B2F9-60F5F0... SDK for Windows Store Apps Tools-x86_en-us.msi [03A0:03CC][2021-07-18T22:53:46]i000: Moving payload from working path 'C:\users\focht\Temp{f23f94c5-8bba-4202-85ad-c83d4402cdc1}\package_WindowsSDKforWindowsStoreAppsTools_x86_en_us' to path 'C:\users\focht\Downloads\Windows Kits\10\StandaloneSDK\Installers\Windows SDK for Windows Store Apps Tools-x86_en-us.msi' ... --- snip ---
Dumping tables with ORCA ...
'File' table:
--- snip --- ... filfba0d0fbe7048c6342ff44f6650d31f3 cmpfba0d0fbe7048c6342ff44f6650d31f3 mt.exe 1193664 10.0.14393.33 1033 512 102 fild620776100898ed00d5f7040d7387a05 cmpd620776100898ed00d5f7040d7387a05 mt.exe 1202688 10.0.14393.33 1033 512 166 fil98de9494e47bad794ffc26a4cd21e5ca cmp98de9494e47bad794ffc26a4cd21e5ca mt.exe 989368 10.0.14393.33 1033 512 300 ... --- snip ---
Sequence numbers: 102, 166, 300
'Media' table:
--- snip --- 1 0 2 2 15bc5316e373960d82abc253bceaa25d.cab 3 5 2630bae9681db6a9f6722366f47d055c.cab 4 8 61d57a7a82309cd161a854a6f4619e52.cab 5 10 68de71e3e2fb9941ee5b7c77500c0508.cab 6 103 69661e20556b3ca9456b946c2c881ddd.cab 7 180 b82881a61b7477bd4eb5de2cd5037fe2.cab 8 242 e072b3b3d3164e26b63338dce51862a7.cab 9 338 e3d1b35aecfccda1b4af6fe5988ac4be.cab --- snip ---
103 -> 69661e20556b3ca9456b946c2c881ddd.cab 166 -> b82881a61b7477bd4eb5de2cd5037fe2.cab 300 -> e3d1b35aecfccda1b4af6fe5988ac4be.cab
--- snip --- $ cabextract -F filfba0d0fbe7048c6342ff44f6650d31f3 -q 69661e20556b3ca9456b946c2c881ddd.cab && file filfba0d0fbe7048c6342ff44f6650d31f3
filfba0d0fbe7048c6342ff44f6650d31f3: PE32+ executable (console) x86-64, for MS Windows --- snip ---
--- snip --- $ cabextract -F fild620776100898ed00d5f7040d7387a05 -q b82881a61b7477bd4eb5de2cd5037fe2.cab && file fild620776100898ed00d5f7040d7387a05
fild620776100898ed00d5f7040d7387a05: PE32+ executable (console) Aarch64, for MS Windows --- snip ---
--- snip --- $ cabextract -F fil98de9494e47bad794ffc26a4cd21e5ca -q e3d1b35aecfccda1b4af6fe5988ac4be.cab && file fil98de9494e47bad794ffc26a4cd21e5ca
fil98de9494e47bad794ffc26a4cd21e5ca: PE32 executable (console) Intel 80386, for MS Windows --- snip ---
Snapshots of those via Internet Archive:
https://web.archive.org/web/20210718213628/https://download.microsoft.com/do...
https://web.archive.org/web/20210718213835/https://download.microsoft.com/do...
https://web.archive.org/web/20210718213916/https://download.microsoft.com/do...
https://web.archive.org/web/20210718214005/https://download.microsoft.com/do...
Maybe one day I write a script that populates all payload packages (.msi, .cab) from the SDK web-installers and automagically creates snapshots for those on archive.org. This way they will live in case the original web-installer and its payloads goes defunct. It also allows to download certain tools directly without all the unneeded garbage - as long as they don't require installation via MSI.
===
https://web.archive.org/web/20210212012422/files.emeditor.com/emed64_15.1.4_...
$ sha1sum emed64_15.1.4_portable.zip b38b83aab7164ff574aad936b8571dea30b72ab3 emed64_15.1.4_portable.zip
$ du -sh emed64_15.1.4_portable.zip 11M emed64_15.1.4_portable.zip
Regards