Codecov Report

Attention: Patch coverage is 57.14286% with 3 lines in your changes missing coverage. Please review.

Project coverage is 53.86%. Comparing base (c491c14) to head (e980cf6).
Report is 43 commits behind head on master.

@@            Coverage Diff             @@
##           master    #1028      +/-   ##
==========================================
- Coverage   54.09%   53.86%   -0.24%     
==========================================
  Files         242      239       -3     
  Lines       13854    13817      -37     
  Branches     1527     1529       +2     
==========================================
- Hits         7494     7442      -52     
- Misses       6032     6053      +21     
+ Partials      328      322       -6     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Thanks for your contribution. We'll review the changes as soon as time permits.

@TomJampen you could automatically clear sebs cache folder on pc start (this removes session lock)
(maybe your code works just fine though :) i didnt test it)

I dont get the relevance to the exact issue this pr addresses?

Wouldn't cache deletion evade certain security measures?

I dont get the relevance to the exact issue this pr addresses?

Wouldn't cache deletion evade certain security measures?

Cache deletion evades security measures yes
This pr doesnt, altough i haven't tested wether it actually compiles and stuff.
You haven't read the author's message have you?

Your comments still appear to lack any relevance to this code/pr. Please open another issue, pr or discussion, if you want something else to be implemented.

I read the authors message, I infact co-authored it, just like I wrote the code that is in this PR.

Your comments still appear to lack any relevance to this code/pr. Please open another issue, pr or discussion, if you want something else to be implemented.

I read the authors message, I infact co-authored it, just like I wrote the code that is in this PR.

I was just mentioning how automatic cache deletion on pc restart might also solve the issue.
I didn't want the a feature to be added, hope this clears my previous answers up.

Well then. Automatic cache deletion does not solve the issue this PR addresses.
This PR aims to address redscreens that are triggered by student behaviour that is not actually cheating (closing/suspending your laptop).

In case the behvaiour of redscreens stays like it is, exam invigilators would have to unlock the computer after a student reopens their laptop. It is "legal" to close your laptops, invigilators would unlock the session for students by typing in the quit password.

The redscreen that is triggered by improper shutdown in a session beforehand (e.g. what is stored in the cache) would never be shown to students. Sessions would never be ended improperly.

Cache deletion would only stop redscreens from triggering that were produced by unintended behaviour/cheating. Closing your laptop is not cheating...

Hope you can follow this.

I see, didnt know it that closing laptops wasn't handled in the same way.
Sorry for my bad solution lol

Students currently do not have the ability to close/suspend their laptops during (longer) exams because then a redscreen is shown. Furthermore, the shown redscreen message confuses invigilators as it does not allow to differenciate between cheating (user switch) and suspend/lock.

Luckily, the windows api sends different events depending on the action taken. As shown below, the SessionLock/SessionUnlock event can be filtered out as a user switch also produces a ConsoleDisconnect/ConsoleConnect event in addtion to the SessionLock/SessionUnlock event.

lock/unlock Session locked Session unlocked

user switch Console disconnected Session locked Console connected Session unlocked

The exact SessionSwitch event is currently already logged but not propagated to the MonitoringResponsibility class.

With this PR SessionLock/SessionUnlock is only filtered out when ignoring SEB service as UserSwitch and UserLock can be enabled/disabled when using SEB service.

Furthermore, we've introduced a new lockscreen message in case the event is a UserSwitch as the existing message is still used when using SEB service. We've added a german and an english translation. If our PR is acceptable it should be easy to copy and modify the other translations.

tltr;

Here is some paste:

void SetDisableSleep(BOOL state)
{
    if (state == TRUE)
    {
        SetThreadExecutionState(ES_CONTINUOUS | ES_SYSTEM_REQUIRED | ES_DISPLAY_REQUIRED);
    }
    else
    {
        SetThreadExecutionState(ES_CONTINUOUS);
    }
}

Here is some more paste to detect emulated mose movements:

LRESULT lockdown::KeyboardMouseMonitor::mouseHandler(int code, WPARAM wParam, LPARAM lParam)
{
    MSLLHOOKSTRUCT *struc = (MSLLHOOKSTRUCT *)lParam;
    if (code == HC_ACTION)
    {
        if (monitor != nullptr && !monitor->stop)
        {
            if (struc->flags & LLMHF_LOWER_IL_INJECTED || struc->flags & LLMHF_INJECTED)
            {
                monitor->mouseCallback(monitor); // non blocking. Just report
            }
        }
    }

    return CallNextHookEx(monitor->mouseHook, code, wParam, lParam);
}

Hi
Is there a chance that this pull request will implemented in 3.10?
Thanks, Daniel

It is currently in our backlog with high priority, but unfortunately not at first position. But I do think our product owner board will schedule this to be implemented for version 3.10.0.

We would be very happy, to find this pull request implemented in v. 3.10.
Thanks a lot!

@TomJampen, @strau0106: The changes are now integrated, please test the latest development build for version 3.10.0: https://sebdev.ethz.ch/api/buildjobs/3eyfn84giwp3gyl5/artifacts/SEB_3.10.0.808_SetupBundle.exe. Please note that any further improvements or changes must be done before July 31st in order to be part of the upcoming release version 3.10.0.

Thank you kindly for merging @dbuechel!

The unit tests still pass and manual testing also shows no issues.