From Newsgroup: alt.comp.os.windows-10

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

When I click on the Download link, it lists 2 downloads:

hvciscan_arm64.exe
hvciscan_amd64.exe

I don't have an ARM computer. I also don't have an AMD CPU, but "amd"
can mean different things. 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).

I got the "amd" version, and ran it. It found one driver incompatible
with Memory Integrity. I knew about this, because I contacted a dev
whose software had a problem a decade ago with Secure Boot which
requires digitally signed kernel-mode drivers, and theirs wasn't signed.
They since fixed that incompatibility, but report a new one. They said:

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 driversrCoincluding those used by audio capture softwarerCoif
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.

This for Replay Media Capture (RMC) from Applian (who rebrand jaksta's
Media Recorder program). It can capture video streams, including those
that yt-dlp cannot. It actually rolls in yt-dlp for the easy captures,
but has its own code and proxy for sites where yt-dlp fails.

A decade ago, I ran into RMC wouldn't run in Secure Boot mode, because
its drivers weren't digitally signed, so a lesser capable method of
capture was required. They fixed that, but now Memory Integrity causes
them problems even with their digitally signed kernel-mode drivers.

I'm not intimate with all this hardware-level security fluff to know
what Applian would need to change to make their driver compatible with
Memory Integrity. I'm not sure Memory Integrity really gives big bang
for the buck regarding security. The more I read about Memory Integrity
(and Core Isolation), the less I'm impressed. I think I saw a Microsoft article recommending disabling Memory Integrity when gaming. Should be
called Sometimes Incompatible Possibly Slowing Memory Integrity.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-10

On Mon, 1/12/2026 7:56 PM, 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

When I click on the Download link, it lists 2 downloads:

hvciscan_arm64.exe
hvciscan_amd64.exe

I don't have an ARM computer. I also don't have an AMD CPU, but "amd"
can mean different things. 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).

I got the "amd" version, and ran it. It found one driver incompatible
with Memory Integrity. I knew about this, because I contacted a dev
whose software had a problem a decade ago with Secure Boot which
requires digitally signed kernel-mode drivers, and theirs wasn't signed.
They since fixed that incompatibility, but report a new one. They said:

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 driversrCoincluding those used by audio capture softwarerCoif
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.

This for Replay Media Capture (RMC) from Applian (who rebrand jaksta's
Media Recorder program). It can capture video streams, including those
that yt-dlp cannot. It actually rolls in yt-dlp for the easy captures,
but has its own code and proxy for sites where yt-dlp fails.

A decade ago, I ran into RMC wouldn't run in Secure Boot mode, because
its drivers weren't digitally signed, so a lesser capable method of
capture was required. They fixed that, but now Memory Integrity causes
them problems even with their digitally signed kernel-mode drivers.

I'm not intimate with all this hardware-level security fluff to know
what Applian would need to change to make their driver compatible with
Memory Integrity. I'm not sure Memory Integrity really gives big bang
for the buck regarding security. The more I read about Memory Integrity
(and Core Isolation), the less I'm impressed. I think I saw a Microsoft article recommending disabling Memory Integrity when gaming. Should be called Sometimes Incompatible Possibly Slowing Memory Integrity.

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/

Protected Video Path, might be what Applian is trying to access. 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. If the video is not protected, perhaps
watching a frame buffer address would be sufficient. NVidia designed
one video decoding method, so that userspace could not access the RAM
being used, and the HDCP on the output connector and the encryption,
prevent the movie from being captured by an external capture device
(which just sees snow).

Breaking the Protected Video Path then, could be a money maker for
someone to sell as a video recorder service.

Paul
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-10

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 driversrCoincluding those used by audio capture softwarerCoif
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
--- Synchronet 3.21a-Linux NewsLink 1.2