Some additional info: * The issue is with TestDllInterceptor.exe (not TestDllInterceptorCrossProcess.exe). * You can run the TestDllInterceptor.exe in dist/bin by copying mozglue.dll from dist/mozglue to dist/bin and installing VCRuntime from [1]. * The disease has spread since this report. Using Windows 8.1 x64, I am seeing additional failures. Remembering that the trampoline needs 13 bytes, the offenders and their x64 machine codes are: ** CloseHandle: ff 25 ca 21 12 00 90 90 90 90 90 90 ff 25 1e 1a *** The second rip-relative jmp starts at byte 13. CloseHandle could work as a 10-byte trampoline. I don't see another safe solution at this point. ** SetWindowLongPtrA: 41 b9 01 00 00 00 e9 a5 f8 ff ff 41 b8 ff ff 00 *** The issue again is instructions in the first 13 bytes that follow a jmp. *** The disassembly is: 0x0000000000000000: 41 B9 01 00 00 00 mov r9d, 1 0x0000000000000006: E9 A5 F8 FF FF jmp 0xfffffffffffff8b0 [...] so the "41 b8" bytes follow the jmp and are in the trampoline space. Again, this could work with a 10-byte trampoline. ** SetWindowLongPtrW: 45 33 c9 e9 48 ff ff ff b2 01 e8 71 fe ff ff 48 *** Disassembly: 0x0000000000000000: 45 33 C9 xor r9d, r9d 0x0000000000000003: E9 48 FF FF FF jmp 0xffffffffffffff50 0x0000000000000008: B2 01 mov dl, 1 0x000000000000000a: E8 71 FE FF FF call 0xfffffffffffffe80 *** I'm at a loss as to what to do here. We can only handle the first 8 bytes so even the 10-byte patch would fail. Presumably something jmps to the mov at 0x8 or else it would be worthless, so its not ok to overwrite it. *** The usage is for crash-protecting Flash WndProc. -------- I'm attaching a patch that forces 10-byte patches for CloseHandle and SetWindowLongPtrA. I think this is the right solution in those cases; it fixes them in the test. For SetWindowLongPtrW, I need some advice -- NI to Aaron. ------ [1] https://www.microsoft.com/en-us/download/details.aspx?id=52685
Bug 1489391 Comment 5 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Some additional info:
* The issue is with TestDllInterceptor.exe (not TestDllInterceptorCrossProcess.exe).
* You can run the TestDllInterceptor.exe in dist/bin by copying mozglue.dll from dist/mozglue to dist/bin and installing VCRuntime from [1].
* The disease has spread since this report. Using Windows 8.1 x64, I am seeing additional failures. Remembering that the trampoline needs 13 bytes, the offenders and their x64 machine codes are:
* CloseHandle: ff 25 ca 21 12 00 90 90 90 90 90 90 ff 25 1e 1a
* The second rip-relative jmp starts at byte 13. CloseHandle could work as a 10-byte trampoline. I don't see another safe solution at this point.
* SetWindowLongPtrA: 41 b9 01 00 00 00 e9 a5 f8 ff ff 41 b8 ff ff 00
* The issue again is instructions in the first 13 bytes that follow a jmp.
* The disassembly is:
0x0000000000000000: 41 B9 01 00 00 00 mov r9d, 1
0x0000000000000006: E9 A5 F8 FF FF jmp 0xfffffffffffff8b0
[...]
so the "41 b8" bytes follow the jmp and are in the trampoline space. Again, this could work with a 10-byte trampoline.
* SetWindowLongPtrW: 45 33 c9 e9 48 ff ff ff b2 01 e8 71 fe ff ff 48
* Disassembly:
0x0000000000000000: 45 33 C9 xor r9d, r9d
0x0000000000000003: E9 48 FF FF FF jmp 0xffffffffffffff50
0x0000000000000008: B2 01 mov dl, 1
0x000000000000000a: E8 71 FE FF FF call 0xfffffffffffffe80
* I'm at a loss as to what to do here. We can only handle the first 8 bytes so even the 10-byte patch would fail. Presumably something jmps to the mov at 0x8 or else it would be worthless, so its not ok to overwrite it.
* The usage is for crash-protecting Flash WndProc.
--------
I'm attaching a patch that forces 10-byte patches for CloseHandle and SetWindowLongPtrA. I think this is the right solution in those cases; it fixes them in the test. For SetWindowLongPtrW, I need some advice -- NI to Aaron.
------
[1] https://www.microsoft.com/en-us/download/details.aspx?id=52685