MSI AB / RTSS development news thread

Internal is CPU (Tctl/Tdie), and you can see implementation in open source MSI AB's CPU.dll plugin.

 

I mean that source code demonstrating implementation of MSI AB's internal CPU temperature monitoring, is available in SDK, in CPU.dll plugin. If you're not software developer (and you're obviously not, considering that "SDK" told you nothing), just ignore that.

 

Some development news:

The first beta of RTSS 7.3.0 (and the first beta in 2020 ) is around the corner, I expect to publish it in the next couple of weeks. It contains the following key changes and improvements:

- Various compatibility improvements in the hook engine:
o Now any application may manifest itself as incompatible with RTSS overlay/hooks either via declaring special named exported variable (recommended and preferred way for EXE-level implementation) or via setting process environment variable (alternate way for DLL-level implementation). So the applications incompatible with RTSS may prevent its API hooking functionality with just a couple lines of code at compile time without need to add exclusion profile for it from RTSS side
o Added user extendable profile mapper. The mapper is allowing RTSS to map multiple executable names matching with specified wildcard (e.g. vegas130.exe, vegas140.exe and so on for different versions of Sony Vegas) to a single profile file, so it is no longer necessary to create exclusion profiles for each version of such application independently
o Added user extendable injection ignore triggers list. Similar to injection delay triggers list, injection ignore triggers list allows defining the set of DLL modules, which will prevent RTSS from injecting target process when any of such modules is detected in the process context. This feature is aimed to exclude applications using typical GPU accelerated GUI libraries from hooking. The list currently includes WPF framework libraries (PresentationFramework.dll and PresentationFramework.NI.dll), so all WPF applications are excluded from hooking now
- Added new type of plugins, client plugins. RTSS is designed to act as a server process, which is running passively and providing different functionality (OSD rendering, screen and video capture, benchmarking etc) to multiple client applications connected to it (e.g. MSI Afterburner). GUI for such functionality (OSD visibility toggling, screen capture) is normally located at client application side. New client plugins allow integrating GUI for such functionality directly into RTSS, without the need to run additional client applications, so new type of plugins is intended for those who prefer to use RTSS as standalone solution without MSI Afterburner. SDK is now including hotkey handler client plugin with open source code, which is allowing processing hotkeys at RTSS side and toggle OSD visibility and framerate limiter without running any additional client processes.
- Added alternate and user configurable CPU yielding implementation to busy wait loops used in both framerate limiter and scanline sync implementations. Alternate CPU yielding implementation is used by default now, it can improve previously existing and close to ideal framepacing accuracy even further under heavy CPU load conditions due to minimizing context switching related timing penalties.
- Updated QSV video encoding plugin. The plugins was recompiled under newer version of Intel Media SDK in order to provide QuickSync video encoding compatibility with the latest Intel DCH drivers. As a side effect, RTSS distributive size has been decreased by a few megabytes due to more compact sizes of software QuickSync encoders in new SDK version
- Scanline sync is no longer disabled in OpenGL applications when OSD support is disabled at application profile level

 

It's close. The first implementation of RTSS client plugin is ready and breathing, this tiny (and open source) 40kb plugin module allows using RTSS as standalone screencapture application and adds native OSD/framerate limiter related hotkeys control to it.

 

It won't be transferred from MSIAB to RTSS and won't disappear from MSIAB. Similar hotkey handlers will coexist is both applications and may duplicate each other's functionality. Each handler "lives" in its own application context, so it won't allow you to map multiple actions to the same hotkey inside this application, but you'll still be able to define the same hotkey combination in different applications and yes, associated action will be performed twice in this case.

Mapping the same hotkey to screen capture action in both applications _may_ produce 2 screenshots at one button press depending on running applications environment (i.e. depending on synchronous (desktop) or asynchronous (3D application) screen capture mode).

 

Hehe, this story is not gonna stop. Some kewlhaxor's butt exploded during that exploit discussion that much so he decided to beat dead horse again. It was a fun read:

https://swapcontext.blogspot.com/2020/01/unwinding-rtcore.html

At least hfiref0x was smart enough to block me on his twitter to see no response.

 

Why not, hyping, airtime and collecting applause from malware creator kids was the primary target of posting that "research". If that's the only thing that makes that person happy, I can help with traffic with no problems. And share interesting read with MSIAB users at the same time.

 

More development news:

- Initially I planned to include just OSD visibility, framerate limiter toggle and screen capture hotkey control functionality in the first implementation of upcoming RTSS HotkeyHanlder client plugin sample. I excluded videocapture functionality from this list on purpose due to its rather complex configuration GUI, which I was too lazy to clone for a sample code, but I had some free time during weekends, so now the plugin got videocapture and benchmarking functionality too. So now the plugin is demonstrating full set of RTSS-powered functionality available in MSI AB GUI:



- After some stress-testing on different platforms I decided to roll back Intel SDK version to the previous one (new SDK version was used to provide QuickSync support on Intel DCH drivers). The reason is a backward compatibility with old QuickSync capable Intel CPUS, unsupported by DCH drivers. QSV encoder compiled under new SDK seem to crash spontaneously on test Ivy Bridge platform with pre-DCH driver. I definitively won't like to drop QuickSync support support for such systems, so I rolled back to older Intel SDK for now. Good news is that actually the only thing that requires recompilation under new IntelSDK is their device manager component, which is auto-selecting wrong (discreete) GPU instead of Intel's one on multi GPU systems under DCH drivers. So to bypass compatibility issue it is enough to provide GUI for manual Intel GPU device selection in QSV plugin, while still compile it under pre-DCH SDK. So on pre-DCH drivers it will auto select device and on DCH drivers you'll simply need to manually select Intel GPU in plugin's properties.
- Semi-development related offtopic and humor, related to exactly the same exploit, which we patched a few months ago: haxor's rage continues. Looks like I won't be able to continue development soon because hurt person demands MSI to fire me, heh