On Thu, Jul 12, 2018 at 11:31 AM, xxxxx@osr.com wrote:
>
>
> Are you being deliberately argumentative, or do you actually not understand that both the things you listed require SE_DEBUG_NAME privilege for a process that’s not your own?
>
My point is to make you aware of a flaw in Microsoft’s logic, yes.
Cargo cult security is obnoxious and makes my life harder on the
daily.
So it was worth gating them behind a privilege - why? They’re
potentially insecure and even if a special permission is required in
practice I am able to debug every program in a user’s session once I
can run code in it. Basically every OS has this “problem” and it makes
irrelevant the vast majority of security concerns about X, Y, or Z
because fixing those does not fix the general lack of intrauser
permission separation.
It’s best to just remove them. Despite any purpose they might serve I
could exploit their existence.
>
>
> Save your baseless and emotional anti-Windows rants, please, for a site where the management is sympathetic to your cause, shares your particular brand of religious zeal, and/or where other *nix fanboys congregate.
>
> This particular forum would fall into none of those categories.
>
This will be my last post on the matter, sir. I apologize. As I am not
very smart I sometimes say things I should not.
I do not intend this to be one OS versus the other. It is more along
the lines of “this company sold a broken product and is attempting to
disclaim liability for it” with a touch of “this company is now being
hoist by their own petard.”
Cheers,
R0b0t1
@Tiago Castro
Question 1:
The commercial products you have seen - which Windows version are they running on?
Is it possible that you have seen them run on Windows 7 with an old XPDM display driver active?
This environment only supports AERO OFF glass transparency theme disabled.
According to the information above, the “D3 approach” might indeed work in such an environment.
Question 2:
The commercial products you have seen - if running on Windows 10 at all - are they maybe showing selected Windows content only instead of showing the whole desktop?
Question 3:
If none of the questions above can be answered with yes, then could you name these products?
Marcel Ruedinger
datronicsoft
@Marcel Ruedinger
Q1. Windows 10
Q2. Shows the whole desktop
Q3. Not sure if it’s allowed to share products as per forum rules but I can pm you if you like?
I thought it is OK as long as it is no advertisement.
But agreed: Better to get in touch by private mail.
You’ll easily find my email contact data on our datronicsoft website.
Looking forward to inspect the product and see what it is really doing 
Marcel Ruedinger
datronicsoft
> I thought it is OK as long as it is no advertisement
It definitely IS OK… as long as it’s not some sort of commercial or advocacy for a product.
The idea isn’t to not mention the names of products. The idea IS to not having people try to sell or advertise products via this forum.
In any case, thank you very much for your consideration for the rules.
Carry on…
Peter
OSR
@OSRDrivers
Alright then, it’s TeamViewer.
It’s not enabled by default, you have to fiddle around the settings, and it’ll install a driver for you.
Once it’s enable you can connect and the monitor will be off (can’t remember if it actually turns off the display or if it just shows dark colour)
Isn’t TeamViewer just using “out of the box” standard Windows functionality RDP (Remote Desktop Protocol) to support this scenario?
Can’t exactly the same functionality be achieved with two plain Windows machines?
Run RDP client software on one machine (client).
Then connect the client to the other machine (server) via RDP.
Isn’t the Server machine console user locked out while RDP client is active?
This approach could possibly be a valid suggestion for the OP:
- Just use or write a RDP client software.
- Write a monitor driver (Power Policy Owner) which puts the server’s locked out console Window monitor to sleep while a RDP client is connected (no need to capture the locked out console monitor content anyway).
Marcel Ruedinger
datronicsoft
On 13/07/18 03:07 PM, xxxxx@datronic.de wrote:
Isn’t TeamViewer just using “out of the box” standard Windows functionality RDP (Remote Desktop Protocol) to support this scenario?
Can’t exactly the same functionality be achieved with two plain Windows machines?
Run RDP client software on one machine (client).
Then connect the client to the other machine (server) via RDP.
Isn’t the Server machine console user locked out while RDP client is active?
This approach could possibly be a valid suggestion for the OP:
- Just use or write a RDP client software.
- Write a monitor driver (Power Policy Owner) which puts the server’s locked out console Window monitor to sleep while a RDP client is connected (no need to capture the locked out console monitor content anyway).
In my experience, though RDP can connect to “Desktop” OSes (vs
“Server”), you’re then forced to deal with that protocol which probably
half defeats the purpose of the alternate remote desktop access
solution. (Even if you implement alternate framegrab you are at minimum
forced to keep the RDP connection alive with e.g. occasional frame acks,
to prevent the session from suspending).
A Remote Desktop Services Protocol Provider (RDSPP) can use a custom
protocol, but only works on Windows Server. MS uses the same
rdpcorets.dll RDSPP implementation for RDP on Desktop and Server OSes,
but it seems they whitelist themselves for desktop OS, nobody else is
allowed to load. (If somebody knows otherwise I’d be happy to find out how.)
-Nathan
Not sure what those “RDP services” are but TV doesn’t look like the standard RDP. With TV you get access to the remote PC but it doesn’t log you in, you get the same thing you’d otherwise see on your remote monitor.
This “Blackout” feature does exist indeed.
It is called “Enable black screen if partner input is deactivated”.
It is definitely NOT using RDP.
It uses a replacement of standard Windows Generic PnP Monitor driver (monitor.sys).
It seems to work on various Win10 platforms with WDDM graphics adapters.
There is at least one platform (Win10 x64 Nvidia GeForce GTX 980M) where it fails.
Might be a plain bug (or might be an indicator that it is unstable using unsupported hacks).
Hope I’ll find a large enough time slot soon to analyze what it is really doing…
Marcel Ruedinger
datronicsoft
Finally, the “Blackout” feature demystified:
Standard monitor Function Driver (monitor.sys) is replaced by a different monitor Function Driver called “MonitorFunction” (TVMonitor.sys).
This alternative monitor driver destroys standard Windows functionality (e.g. display brighntness function keys on the keyboard don’t work any more).
This alternative monitor driver achieves the “Blackout” feature by putting the monitor into D2 power state. A short look into the ACPI spec (Appendix A.6 Display Device Class) seems to indicate that D2 support is only required for CRT (Cathod Ray Tube) monitors. Other monitors might not support D2.
This alternative monitor driver can be observed to fail on various platform (“Blackout” doesn’t work). One potential explanation is lacking D2 support as stated above. Probably there are other reasons, too.
Cool company actually (~100 employees - worth more than one billion US$ - “Unicorn” in investor’s talk). This device driver, however rather appears like an unreliable old hack (from the times of CRT monitors). Wonder if/how they can/will continue supporting it in the future when already today it fails on quite a few platforms…
Marcel Ruedinger
datronicsoft