dwm_lut

dwm_lut copied to clipboard

same here too

#20

is there any clue if this issue is being fixed or not?

Same issue after upgrading to 22H2, definitly Microsoft updated DWM. Hopefully this will be fixed in the end, just be patient.

I rolled back to windows 10 in a moment I realized this awesome app doesn't support win11 22h2 yet (got the same error). Can't imagine my PC not having dwm lut ♥️

Same issue after upgrading to 22H2, definitly Microsoft updated DWM. Hopefully this will be fixed in the end, just be patient.

Microsoft is finally getting around to a color managed desktop.

https://devblogs.microsoft.com/directx/auto-color-management/

Same issue after upgrading to 22H2, definitly Microsoft updated DWM. Hopefully this will be fixed in the end, just be patient.

Microsoft is finally getting around to a color managed desktop.

https://devblogs.microsoft.com/directx/auto-color-management/

https://github.com/dantmnf/MHC2 It's holding me over while dwm_lut is being updated for 22H2.

Hope it will still be possible to use DWM LUT with this new 22h2 color management. It's always been everything wrong with ICC implementations for calibration and profiling displays. I'm talking about sRGB vs Gamma 2.2 display assumed EOTF holy wars.

I'm talking about sRGB vs Gamma 2.2 display assumed EOTF holy wars.

It's not that contentious. Calibration tools use a pure 2.2 gamma with sRGB/Rec.709 primaries as the default target. Tagged content displays correctly on color managed apps, which take account for TRC differences. Untagged content displays ok with the assumed sRGB/2.2 target because it's an average of uncalibrated displays native output.

Will there be an update any time soon? :)

Seconded - is there any progress? I just updated to W11 yesterday, and was devastated to discover that DwmLutGUI has been broken

Despite I "watch all activity" of this repo and get everything from here to my email, I'm still checking any news here almost everyday :) Really the only thing that holds me from switching to Windows 11.

@ledoge if the update takes too much time to starting working on it, maybe it would be better to make the app paid?

My wallet w'd be ready. 😅

@ledoge

The new pattern for COverlayContext_Present for Windows 11 is: { 0x40, 0x53, 0x55, 0x56, 0x57, 0x41, 0x56, 0x41, 0x57, 0x48, 0x81, 0xEC, '?', '?', '?', '?', 0x48, 0x8B, 0x05, '?', '?', '?', '?', 0x48, 0x33, 0xC4 }

The new pattern for COverlayContext_IsCandidateDirectFlipCompatbile for Windows 11 is: { 0x40, 0x55, 0x53, 0x56, 0x57, 0x41, 0x54, 0x41, 0x55, 0x41, 0x56, 0x41, 0x57, 0x48, 0x8B, 0xEC, 0x48, 0x83, 0xEC, 0x68, 0x48, 0x8B, 0x05, '?', '?', '?', '?', 0x48, 0x33, 0xC4, 0x48, 0x89, 0x45, 0xF0 }

The new pattern for COverlayContext_OverlaysEnabled for Windows 11 is: { 0x83, 0x3D, '?', '?', '?', '?', '?', 0x75, 0x04, 0x32, 0xC0, 0xC3, 0xCC, 0x83, 0x79, 0x2C, 0x01, 0x0F, 0x97, 0xC0, 0xC3 }

I'm trying to reverse the updated dwmcore dll and find some way to fix the dwm_lut program

Anyway, use the following AoB pattern search algorithm, it's more robust:

bool aob_match_inverse(const void* buf1, const void* mask, const int buf_len)
{
	for (int i = 0; i < buf_len; ++i)
	{
		if (((unsigned char*)buf1)[i] != ((unsigned char*)mask)[i] && ((unsigned char*)mask)[i] != '?')
		{
			return true;
		}
	}
	return false;
}

I'm trying to reverse the updated dwmcore dll and find some way to fix the dwm_lut program

Sounds promising! Where can we follow the progress?

I'm trying to reverse the updated dwmcore dll and find some way to fix the dwm_lut program

Sounds promising! Where can we follow the progress?

Right now I'm comparing Windows 10 offsets with Windows 11 ones. I have one laptop with Windows 10 and a PC with Windows 11. I'm doing remote debugging of the DWM.EXE process from the Windows 11 machine to the Windows 10 laptop and I managed to verify the offset for the hardware protection flag, which is -0xBC for the W10 OS.

Will there be an update any time soon?

Hi, I'm trying to find out the offset for the IDXGISwapChain in W11. I'm still new to Windows Reverse Engineering and this stuff, so I might take some time. Do you know how you got the offset in the first place? I verified that the old offset for W10: -0x118 is correct, but I don't know why the DXGISwapChain object is placed at that location (with respect to the OverlaySwapChain object)

@lauralex Can someone help you somehow here with this? I mean, maybe there is a task, that requires a lot of not very complicated actions to be done, so someone without highest coding skills could make this part? I apologize if I'm saying something completely irrelevant, I'm not a coder at all, so I don't understand, what is DXGISwapChain and all that stuff unfortunately.

@lauralex Can someone help you somehow here with this? I mean, maybe there is a task, that requires a lot of not very complicated actions to be done, so someone without highest coding skills could make this part? I apologize if I'm saying something completely irrelevant, I'm not a coder at all, so I don't understand, what is DXGISwapChain and all that stuff unfortunately.

If the dwmcore dll didn't change much, all that needs to be done is to find the correct offsets for the IOverlaySwapChain_HardwareProtected_offset_w11, COverlayContext_DeviceClipBox_offset_w11 and IOverlaySwapChain_IDXGISwapChain_offset_w11. Unfortunately, to do this, some Reverse Engineering skills are required, the tools I'm using right now are IDA and some plugins like Sig Maker and HexRaysCodeXplorer

I managed to find the new IOverlaySwapChain_HardwareProtected_offset_w11, which should be -0x12C, but I'm still working at finding the rest, i.e., I_OverlaySwapChain_IDXGISwapChain_offset_w11 and COverlayContext_DeviceClipBox_offset_w11

Hi, sorry for the radio silence on my part, with recent work stuff and some PC issues I just haven't had any motivation to work on/think about this stuff. Glad to see that @lauralex is working on it now though :)

I checked my notes and IDA database, and I believe this is how I obtained the remaining offsets:

• IOverlaySwapChain_IDXGISwapChain_offset should just be the difference between the second arguments of COverlayContext::Present and CD3DDevice::Present when you set breakpoints in both (and ideally only have one monitor active, so you know they'll correspond to the same one)
• COverlayContext_DeviceClipBox_offset_w11 should be the difference between the first argument of COverlayContext::Present and the address of the first float value accessed in CLegacyRenderTarget::IsPrimaryMonitor

Hi, sorry for the radio silence on my part, with recent work stuff and some PC issues I just haven't had any motivation to work on/think about this stuff. Glad to see that @lauralex is working on it now though :)

I checked my notes and IDA database, and I believe this is how I obtained the remaining offsets:

• IOverlaySwapChain_IDXGISwapChain_offset should just be the difference between the second arguments of COverlayContext::Present and CD3DDevice::Present when you set breakpoints in both (and ideally only have one monitor active, so you know they'll correspond to the same one)
• COverlayContext_DeviceClipBox_offset_w11 should be the difference between the first argument of COverlayContext::Present and the address of the first float value accessed in CLegacyRenderTarget::IsPrimaryMonitor

Oh, so you suggest doing remote debugging and checking the differences between these addresses

Yeah, I didn't even try to reverse the actual C++ stuff going on, I just used dynamic analysis and breakpoints to figure out all the offsets.

Ahahahah, I spent like three days filling my IDA database with types, virtual tables, etc.

It's insane

Ok I found out the offset for the new IDXGISwapChain**, which should be +0x0E0

Hi, sorry for the radio silence on my part, with recent work stuff and some PC issues I just haven't had any motivation to work on/think about this stuff. Glad to see that @lauralex is working on it now though :)

I checked my notes and IDA database, and I believe this is how I obtained the remaining offsets:

• IOverlaySwapChain_IDXGISwapChain_offset should just be the difference between the second arguments of COverlayContext::Present and CD3DDevice::Present when you set breakpoints in both (and ideally only have one monitor active, so you know they'll correspond to the same one)
• COverlayContext_DeviceClipBox_offset_w11 should be the difference between the first argument of COverlayContext::Present and the address of the first float value accessed in CLegacyRenderTarget::IsPrimaryMonitor

Actually you cannot just get the difference by setting a breakpoint, because only the double pointer to the IDXGISwapChain is static, so I just reversed the logic of the the CD3DDevice::Present method callers (CLegacySwapChain::Present -- COverlayContext::Present)