MSI AB / RTSS development news thread

I was planning to perform final pre-release stability testing for RTSS 7.2.3 on weekends but unfortunately I had to change my plans and focus on different issue again.
Some nice gentlemen discovered and published exploit based on MSI Afterburner driver. But due to some odd reason gentlemen decided that traditional responsible disclosure model, which is normally used by security researchers and software developers is not for him so the exploit is published without any attempts to contact either me directly or MSI. So I had to cancel all tasks and focus entirely on this issue. The fix is easy, I've already protected the driver against such exploiting by adding kernel mode MMIO whitelists, so kernel mode read/write IOCTLS (the ones he abused) no longer allow to read and write to any kernel address ranges besides previously mapped MMIO ranges (both kernel and user mode mapping interface itself is already protected like I described in the past in comments here a few years ago). Unfortunately we cannot launch update right now because my MSI digital signature is not EV, and Microsoft no longer allow using standard signatures for kernel driver signing. So it will take a few days while MSI upgrade their signature to EV and issue new code signing certificate. Then we sign new driver and launch MSI AB 4.6.2 beta as final to make all users to upgrade.

 

Nope, I don't think so. In any case exploit discovery and rapid software protection against it is always a positive thing, regardless of way used to reach it. Responsible disclosure is entirely ethical question, it is not his obligation to inform anyone prior to publishing it. Yes, it is much more correct, safe, responsible and smart way for the real researcher. But hell, you cannot force anyone to act smart. I believe there were NO bad intentions in publishing it without informing developers, most likely the person just underestimated the consequences. So let it be as it is.

I think I also know where the idea of such exploit creation came from. This summer, Defcon 27 hacking conference had a presentation, dedicated to exploiting the systems using fundamental arbitrary hardware access interfaces, which can be found in almost all kernel drivers from major HW manufacturers.

https://eclypsium.com/wp-content/up...off-the-kernel-if-you-cant-drive-DEFCON27.pdf

So in next few weeks/months we'll probably see flow of similar exploits targeted at all kinds of hardware control/monitoring software and created by other kewlhaxorz who saw it @ Defcon and decided to leave his name in CVE history. Too bad that such glory hunters do not understand that it works against improving system security.

 

7.2.3 is officially released now and available in Guru3D downloads, we made it visible to update servers so all RTSS users should start receiving new version notifications now. That's exactly the same build 20686 as release candidate published a few posts above in this thread, so if you already have it installed - no need to redownload/reinstall anything.

Non-beta final version of MSI AB 4.6.2 is also around the corner. Once MSI renew EV code signing certificate required to sign kernel driver (I hope it's a question of couple days) we'll launch new version of AB with driver protected against exploiting approach mentioned here. There won't be anything different in it comparing to the previous MSI AB beta besides including protected driver and bundled final RTSS 7.2.3. Some additional things were planned to be included in 4.6.2, but we'll shift them to future releases. We're absolutely forced to release official 4.6.2 ASAP to make new version visible to all application users in update system to minimize risks because of "responsible" disclosure.

Stay tuned!

 

Good news, MSI got new EV signature so I hope that new version can be launched soon. It still needs some time for MSI to get adopted to more complex process of EV signing the driver through Microsoft portal. But I hope it won't take long.
A few words on changes in IO driver, aimed to protect it from exploiting demonstrated in link a few posts above:

- MSR register access IOCTLs are still arbitrary, but EFER/SYSENTER/SYSCALL MSRs are now blacklisted and no longer accessible
- Kernel mode MMIO read/write IOCTLs no longer allow faking MMIO base address and accessing arbitrary memory locations in kernel address space. Now IOCTL handler is validating specified base address and allowing to access only whitelisted MMIO ranges, which belong to registers aperture of some physical PCI device and which were previously mapped and internally whitelisted by driver
- More restrictions on user and kernel mode MMIO mapping IOCTLs. Previously it was possible to map MMIO registers aperture of any physical PCI device, now it is restricted to VGA class PCI devices only

 

And once again, PLEASE don't use this thread for general troubleshooting issues and don't flood it with things, unrelated to new version development. It is not intended for that. Next time I'll simply remove such questions without repeating the same things over and over again.

Edit: Thanks for removing it. Feel free to create separate thread dedicated to your question and probably some body else can help you there.

 

Thanks, but I'll be able to start compatibility testing related to new OS version only after its' official release and when we have drivers intended for it.

 

A few days ago I’ve been contacted by a user, who was recently banned in one online game by EAC anticheat. He assumed that it could due to RTSS usage so he wanted to clarify that. Here is my post with short summary of some basic principles, explaining some anticheat related basics: delayed banning approach, whitelisted applications and “no ban lift” policies. I think it can be rather useful for many players to understand why you can and why you cannot be banned by modern anticheats:

https://www.reddit.com/r/apexlegend...ver/f16y15w?utm_source=share&utm_medium=web2x

Quote myself:


"This thread is a good example demonstrating how the myths are born. No, it is not RTSS. And no, it is not ReShade. Banned users are periodically contacting me, claiming that they used nothing but RTSS and got their ban because of it and asking me to help to contact game publisher or anticheat developer in order to shift ban. And no, I cannot help such users because it is not true, overlays are never the reason of bans.

You physically cannot say that you’re banned because of any overlay, be it RTSS, GFE or anything similar, which hooks the game to render OSD. You cannot say that you’re banned because of videocapture software like DXTory or OBS, which also hooks the game to capture frames from it. You cannot say that you’re banned because of ReShade, which hooks the game to intercept frames and apply post processing to it. You cannot claim that you were running nothing but such absolutely legitimate application then suddenly got unfair ban by EAC so such application was the reason. You cannot, because all modern anticheats use delayed banning principle and ALWAYS ban account for some restricted activity, which was detected and took place in the past (from few days to few _weeks_ ago). If it were banning for cheat usage immediately, it would be much simpler for cheat developers to debug commercial cheats. Delayed banning is always used so you never know for sure that you cheat is not detectable when you use it or develop it. So the applications you run during or immediately prior to receiving the ban are never the reason of it.

You cannot assume that you were probably using something legitimate, which is simply not whitelisted by anticheat yet, so it falsely triggered the ban. The principle of whitelisting allowed software in anticheats doesn’t work that way. If software is not whitelisted by anticheat, it doesn’t mean that it will trigger the ban. Modern anticheats like EAC simply will not allow such (i.e. non-whitelisted) software to interact with game process (i.e. hook it and display overlay, capture video or apply postprocessing effects like Reshade do). It will _never_ ban you when it sees something unknown, anticheats do not use heuristic to apply bans. Everything unknown (i.e. not whitelisted) is simply isolated from the game process. Quite opposite, anticheat apply ban _only_ if it sees some blacklisted modules injected in game (i.e. something uniquely known as cheat related).

Due that reason anticheat usage policy assume that developers never tell you what exactly caused your ban and never tell you when it exactly cheat related activity was detected. So attempts to contact the game publisher, anticheat developers or third party developers will never succeed. The only exception when you can see your account falsely banned and returned back to you is failure in anticheat implementation. But such things sometimes have place on initial stages of game launch and results in _massive_ waves of false bans and get investigated by anticheat developers fast and without dealing with you directly.

Also, always keep in mind that anticheats also analyze software you have installed and run on your PC. So having something like CheatEngine installed and simply passively running in background during playing anticheat protected game (even if you don’t try to use it to cheat in this game) can be enough reason to get your account lost.

Summarizing, you cannot do anything by contacting game publisher or EAC developers. It will never work due to anticheat policy. If your ban is caused by anticheat failure, then you’re definitively not the only one suffered because of it and it will be shifted itself. Otherwise, play fair, do not download and do not install ANY applications related to game cracking/cheating (even if you plan to use it for different game) and you’re safe."

 

They know that it is urgent. And yelling doesn't make it to be signed faster.

 

I just received good news from MSI and I'm glad to report that they finally adapted to the process of driver signing via Microsoft so I've received patched driver and it is properly signed now. I'll need couple more days for testing it then we'll see new beta of MSI AB and final release of 4.6.2 shortly after that.
Stay tuned!

 

Some update on progress:
New signed driver works fine under W10, but sadly new W10-targeted signing way is not too compatible with W7 and older OSes. So releasing it as is doesn't sound as a good idea for me, I'd still like to keep compatibility with older OSes too. I'll investigate possible ways of keeping backward compatibility during weekends.

 

I'm sorry but this thread is not intended for support and general questions. Create separate thread where somebody else can probably help you.

 

Yep, I mean KMCS policy, binary signing approach and new digital signatures compatibility with previous OS families of course. All new EV code signing certificates, issued be major certificate authorities, are SHA256 so they can have compatibility issues with W7 (without some updates installed) and they are completely incompatible with Vista (which I also still trying to support, in addition to old good XP).
Furthermore, on my test W7 rig (even with all updates installed, including SHA2 support related) I still cannot load the driver signed by latest MSI EV certificate (SHA256). So the options are:

- Leave it as is and declare W7 and Vista unsupported - no go, I still want to keep support for those OSes
- Ask MSI to issue one more SHA1 code code signing certificate, special for old OSes - it will take a few more weeks, but I'd like to launch new version with protected driver faster to prevent users from being nervous and feeling unprotected (thanks to "responsible" disclosure )
- Use new protected driver for W10 but leave the previous legacy driver for compatibility with the previous OS families - that's optimal way for now IMHO