Paul <
nospam@needed.invalid> wrote:
VanguardLH wrote:
With all the problems I find with other users encounter with Memory
Integrity option, I thought to run Microsoft Memory Integrity tool
(HVCIScan) to see if it might report a problem.
https://www.microsoft.com/en-us/download/details.aspx?id=105437
I have an Intel Core i7 8700, so 8th gen. Apparently Memory
Intregity works best with 8th gen CPUs with in-silicon MBEC
(Mode-Based Execution Control), an extension to SLAT (Second Level
Address Translation).
It found one driver incompatible
with Memory Integrity.
Applian's Replay Media Capture
a rebranding of
jaksta's Media Recorder
jaksta had a problem with their payment system when I tried to buy an
upgrade, so I went to Applian. Applian/jaksta fixed the Secure Boot incompatibility by signing their kernel-mode driver, but they noted:
The Newer Hurdle: Memory Integrity (Core Isolation)
The primary compatibility hurdle you will face today, especially when
moving to Windows 11, is not Secure Boot, but Memory Integrity (a part
of Core Isolation in Windows Security). This advanced security
feature, which uses hardware virtualization, blocks many older
kernel-mode drivers?including those used by audio capture software?if
they are not specifically built to its stricter standards.
o Result: Even with a properly signed driver, Windows 11 with Memory
Integrity enabled will typically prevent the RMC driver from
loading, causing capture to fail.
o The Workaround: As you anticipated, the standard guidance from
Applian and similar software vendors is to disable Memory
Integrity to install and use our driver.
They would be using an exploit against HVCI, one that security
researchers identified and presented as proof of concept. Microsoft
has to plug these, and the result is, that a program that "worked" in
one year, suddenly stops working.
https://connormcgarr.github.io/hvci/
Reminds me of when I subscribed to Scientific American. Would take me a
month of rereading to get a partial sense for the content, and then the
next monthly issue arrives to start all over.
My choice are:
- Use Memory Integrity and forego Replay Media Capture.
- Forego Memory Integrity to use RMC.
After reading the HVCI article you cited, seems Memory Integrity, Core Isolation, and all that VBS stuff is the better choice. I don't do
extreme gaming, so I don't care about the loss of a few FPS. Plus, I'd
need a new video card for those extreme video games.
RMC does have other capture methods, but devolves to a yt-dlp equivalent
with a nice GUI frontend.
Protected Video Path, might be what Applian is trying to access.
Applian won't snag protected content. For example, while RTMPe was not supposed to be a DRM mechanism, it got used that way. It was supposed to
allow secure delivery of content without SSL. Applian's RMC won't snag RTMPe-protected streams. They don't want to embroil themselves into
court battles over violated DRM content. It's been many years, but I
remember a stream snag tool (maybe rtmpdump) that would capture and
decrypt RTMPe, but they had to move around to avoid legal persecution;
see
https://en.wikipedia.org/wiki/RTMPDump.
yt-dlp would normally open a series of download threads and do
block-range downloads and reassemble the video afterwards. If a video
server is not designed to be levered that way, then the slower method
is to record the screen at a 1x speed. Which means a one hour video
would take one hour to download.
Perhaps that is why yt-dlp fails at some sites. Some sites don't want
multiple connections to the same video stream. Typically for, say, a
2-1/2 hour movie, RMC and yt-dlp capture it in maybe 10 minutes. It
isn't playing the video stream, but snagging it as fast as the server
will deliver. I have seen delivery for some videos deliberately choked
to 1x speed at the server. Takes as long to snag the video as it does
to watch it.
Although I can use yt-dlp to snag most videos, it does occasionally
fail. I can then use RMC to snag the video, but each time I switch it
into Auto capture mode there is about 5 minutes of outage to the network
almost like it takes that long for some transparent proxy to load. In addition, yt-dlp and RMC (in non-Auto mode) won't capture protected
content, like that using RTMPe.
yt-dlp and RMC in non-Auto mode won't capture videos that require using
a Javascripted player ran within the web browser. The video is
encrypted, the Javascripted player (e.g., KVSplayer) somehow is informed
how to decrypt, and the user sees the decrypted video. While yt-dlp
will fail on the videos requiring the Javascripted player, RMC manages
in its Auto mode to snag the video content. Alas, while yt-dlp and
non-Auto RMC manage to isolate the primary video stream to only capture
that, RMC in Auto mode captures all streams. I can end up with lots
(hundreds) of garbage videos snagged by Auto RMC. In Auto mode, RMC
didn't know what to snag, so it snags everything.
Breaking the Protected Video Path then, could be a money maker for
someone to sell as a video recorder service.
Likely it is RMC's kernel-mode (now signed) driver in its Auto mode that intercepts video streams like a proxy. yt-dlp doesn't use a driver. In non-Auto mode, RMC runs like yt-dlp. In fact, yt-dlp and ffmpeg are
buried inside of RMC. It is RMC's Auto mode that goes beyond what
yt-dlp can snag.
Usually yt-dlp and RMC in non-Auto mode snag most of the videos I want
to view later. RMC in Auto mode can snag more, but also snags all video content at a site resulting in hundreds of videos populating the save
folder with the vast majority of them being preview streams lasting a
few seconds. Auto RMC can capture more, but more can be too much.
However, even with RMC in Auto mode has problems with sites that use Javascripted players that decrypt the video stream upon delivery.
Both yt-dlp and RMC in non-Auto mode cannot snag video streams that are
RTMPe protected. They cannot snag videos that rely on Javascripted
players that decode the stream, and are ran inside the web browser. The
kill point with RMC's Auto mode seems to be with its driver. Once they
signed their driver, it was no longer incompatible with Secure Boot.
Apparently they haven't yet figured out how to make it HVCI compliant.
https://learn.microsoft.com/en-us/windows-hardware/test/hlk/testref/driver-compatibility-with-device-guard
--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)