Remote Control - 3rd party application awareness of Remote control Target session activity (Active, Monitor etc)

[orbiton]

Hi,.

I’ve got a customer that use Remote Control on some Medical equipment.

On that equipment, there is an application that should not be started while there is an “Active” session with the Remote Control Target.

Thanks

[f.pezzotti]

If the customer is using Remote Control in managed mode (RC server is installed in the environment) you can use the Denied Program Execution List policy on the server:

Take a look a it here:

https://help.hcltechsw.com/bigfix/10.0/lifecycle/Lifecycle/Remote_Control/RC_Admin_Guide/rcrelsessionpolicies.html?hl=panic%2Ckey

NOTE: This feature stopped working on Windows 8 and newer because now when the secure boot is enabled on the machine BIOS the OS prevent the usage of the API used by the Remote Control Target to enforce the process execution list.

So in order to get it working you need to disable the secure boot on the BIOS. I don’t know if this is feasible for the customer.

Take a look at this guide:

https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/disabling-secure-boot?view=windows-11

[orbiton]

@f.pezzotti Thanks for the reply!
That is not exactly what the user requires

He wishes that a 3rd party application which is installed on the same machine that is being controlled (Target machine)

Will identify when a session started and when the session activity will become "Active"
It will use internal logic to pause the application while that is the case
And when the session activity will change to another type like: Monitor or the session will be closed - the application will resume.

I though about parsing the Target log file , but as of right now - I couldn’t understand all of the phases there

[f.pezzotti]

You can try to leverage this message:

(GMT) INFO [ xxxx] INITIAL SESSION MODE 0xXXXX, KNOWN MODES 0xXXXX, SUPPORTED MODES 0xXXXX, ALLOWED MODES 0xXXXX

More precisely the INITIAL SESSION MODE will tell you what session mode will be used at connection time.

When the session mode is changed on the Controller you will see:

(GMT) INFO [ xxxx] Console Requested Session Mode 0xXXXX

When the session mode is changed on the Target you will see this message:

(GMT) INFO [ xxxx] Requested session change to mode X

These are the session codes:

 0x0001   // Chat
 0x0002   // Monitor
 0x0004   // Guidance
 0x0008   // Active
 0x0020   // File Transfer
 0x0080   // Reboot System
 0x8000   // Session should be disconnected

[JasonWalker]

Would a check for port status (listening/open/closed) be easier than log parsing?

[f.pezzotti]

Easier but not effective. You can’t figure out what session is currently selected from the process or network status.

[JasonWalker]

Ah, I see, I was taking this as a request for their application to pause while a session is connected, but it seems the ask is also to toggle their application based on the session states of ‘monitor’ vs ‘control’, etc.

[orbiton]

@f.pezzotti Nice I will check that out!

I’m still missing few more options -

• Session Mode when the Session is Started
• Indecation when the Session ended

Do you have any links to some documentation where I could make further reading?

[f.pezzotti]

As I already said you can use INITIAL SESSION MODE for the session mode selected when the session is started.

(GMT) INFO [ xxxx] INITIAL SESSION MODE 0xXXXX, KNOWN MODES 0xXXXX, SUPPORTED MODES 0xXXXX, ALLOWED MODES 0xXXXX

For the session end you can use this message:

(GMT) INFO [ xxxx] RECV Thread: Stopped

No unfortunately I don’t have any link to this subject. I don’t think we document the content of the component logs.

[orbiton]

Hi @f.pezzotti

I’m attaching session activities and their associated logs:

• User Acceptance Denied - Initial

2023.10.23-09:25:07.468 (GMT) INFO [21512] INITIAL SESSION MODE 0x0008, KNOWN MODES 0x01af, SUPPORTED MODES 0x01af, ALLOWED MODES 0x80af
2023.10.23-09:25:07.468 (GMT) INFO [21512] grace_time 45 timeout_proceed 0 req_mode 8 allowed_modes 80af hide_windows 0 allow_mode_override 1
2023.10.23-09:25:07.468 (GMT) INFO [16412] Received pkt type 0101
2023.10.23-09:25:07.468 (GMT) INFO [16412] forth_con_check_session_takeover(), rc = -25
2023.10.23-09:25:07.484 (GMT) INFO [16412] forth_con: target is busy, goodbye!
2023.10.23-09:25:13.061 (GMT) INFO [21512] forth_audit_log_event: ibm.trc.audit.005D
2023.10.23-09:25:13.061 (GMT) INFO [21512] IT GOT REFUSED REASON 13

• User Acceptance Accepted - Initial and User Acceptance Denied - Mode change

2023.10.23-09:26:55.766 (GMT) INFO [21736] INITIAL SESSION MODE 0x0002, KNOWN MODES 0x01af, SUPPORTED MODES 0x01af, ALLOWED MODES 0x80af
2023.10.23-09:26:55.766 (GMT) INFO [21736] grace_time 45 timeout_proceed 0 req_mode 2 allowed_modes 80af hide_windows 0 allow_mode_override 1
2023.10.23-09:27:03.540 (GMT) INFO [21736] CLEARING BLACK LIST
2023.10.23-09:27:03.555 (GMT) INFO [21736] BLACK LIST IS NOW EMPTY
2023.10.23-09:27:03.555 (GMT) INFO [21736] ADDED 0 programs to BLACKLIST
2023.10.23-09:27:03.761 (GMT) INFO [21736] CONTROLLER DID NOT CANCEL
2023.10.23-09:27:03.762 (GMT) INFO [21736] IT GOT ACCEPTED REASON 241
.
.
.
There is no “Requested session change to mode” message

• User Acceptance Accepted - Initial and Mode change

2023.10.23-09:26:55.766 (GMT) INFO [21736] INITIAL SESSION MODE 0x0002, KNOWN MODES 0x01af, SUPPORTED MODES 0x01af, ALLOWED MODES 0x80af
2023.10.23-09:26:55.766 (GMT) INFO [21736] grace_time 45 timeout_proceed 0 req_mode 2 allowed_modes 80af hide_windows 0 allow_mode_override 1
2023.10.23-09:27:03.540 (GMT) INFO [21736] CLEARING BLACK LIST
2023.10.23-09:27:03.555 (GMT) INFO [21736] BLACK LIST IS NOW EMPTY
2023.10.23-09:27:03.555 (GMT) INFO [21736] ADDED 0 programs to BLACKLIST
2023.10.23-09:27:03.761 (GMT) INFO [21736] CONTROLLER DID NOT CANCEL
2023.10.23-09:27:03.762 (GMT) INFO [21736] IT GOT ACCEPTED REASON 241
.
.
.
2023.10.23-09:27:13.487 (GMT) INFO [21968] Requested session change to mode 8

• No User Acceptance - Initial and Mode change

2023.10.23-09:32:38.946 (GMT) INFO [22448] INITIAL SESSION MODE 0x0002, KNOWN MODES 0x01af, SUPPORTED MODES 0x01af, ALLOWED MODES 0x80af
2023.10.23-09:32:38.946 (GMT) INFO [22448] CLEARING BLACK LIST
2023.10.23-09:32:38.946 (GMT) INFO [22448] BLACK LIST IS NOW EMPTY
2023.10.23-09:32:38.946 (GMT) INFO [22448] ADDED 0 programs to BLACKLIST
2023.10.23-09:32:39.149 (GMT) INFO [22448] CONTROLLER DID NOT CANCEL
2023.10.23-09:32:39.150 (GMT) INFO [22448] IT GOT ACCEPTED REASON 0
2023.10.23-09:32:39.150 (GMT) INFO [22448] status: forth_set_status_connected
.
.
.
2023.10.23-09:32:45.580 (GMT) INFO [19856] Requested session change to mode 8

Did I understand the Log correctly?

Is it possible to write those events on Event Viewer (On Windows)?

[f.pezzotti]

Hi @orbiton,
Yes it seems correct to me.

You can see all relevant session activities on the Event Log on Windows by setting the property AuditToSystem on the Target to yes.

https://help.hcltechsw.com/bigfix/10.0/lifecycle/Lifecycle/Remote_Control/RC_CUser_Guide/rccusr_auditing.html?hl=audittosystem

These entries are under: Windows Logs -> Application
You can filter the list by source. The RC Target entries have this source: TRCTARGET

I don’t know if you will find all the need information there but the messages are more cleaver than the messages in the Target log.

[orbiton]

@f.pezzotti Thanks!

So just to clarify
The Logs are under Windows Logs -> Application with filtered Source: TRCTARGET

I’ve checked the Logs and got the following information:
Event ID: 1 - Session attempt
Event ID: 92 - Session denied by the user
Event ID: 70 - Session accepted by the user
Event ID: 74 - Session accepted. User acceptance disabled
Event ID: 4 - Session Mode changed to … (Active \ Guidance etc…)
Event ID: 112 - Request to change Session Mode
Event ID: 113 - Request to change Session Mode accepted
Event ID: 114 - Request to change Session Mode denied
Event ID: 23 - Session ended by the controller
Event ID: 24 - Session ended by the user

Is there any official documentation about the classification of each event id?
It will be much helpful to other customers.

[orbiton]

Hi @f.pezzotti
Another question, I’ve explained to the customer a logic which will help him to indentify if the Remote Control Target is on Active Session or not.

When he will start the application - the Application will listen to Events for Application Event Log filtered with Source: TRCTARGET from that timestamp

• When Event ID 4 will arrive it will look into the details - if it contains Active - The application will flag “Active Mode Started”
• When another Event ID 4 will arrive with a different value OR Event ID 23 OR Event ID 24 - it will unflag “Active Mode Started”

The only situation I could not provide a solution as of right now is as followed:

• There is already an Active Remote Control Session and the Customer Application is not open, when He starts the application - it will not recognize that there is already an open session which is active.

Can you provide any throughs about this scenario?

[f.pezzotti]

Hello @orbiton,

No the IDs are not officially documented because they are only used internally to map the event to a message and they are only available on Windows while on Linux and macOS (where the source is still TRCTARGET) only the messages are shown without a numerical id.

[f.pezzotti]

If your problem is detecting if the screen is captured or not (so if an Active, Monitor or Guidance session is on), you can monitor the Target machine for the presence of the trc_dsp.exe process. If this is present the screen is being captured. You can also use the OSSN (On-screen session notification) to further warn the remote user about the fact that the screen is being captured (Enable On-screen Session Notification policy for managed mode or EnableOSSN property for P2P).