New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cryptnos loses all settings on systems with tighter security policies #8

GoogleCodeExporter opened this Issue Jun 26, 2015 · 5 comments


None yet
1 participant

GoogleCodeExporter commented Jun 26, 2015

This issue is difficult to define because I am still trying to determine 
exactly what causes it. I have at least two reports--one of which is my own 
from personal experience--of Cryptnos generating an error on start-up, then 
defaulting all settings and losing the user's preferences and data when 
subsequently restarted. Luckily, both I and the other reporter keep diligent 
backups of our parameter data, but this is a serious issue that needs to be 

The only known common factor is that both machines in these incidents were part 
of a corporate network and that recent changes in corporate policy resulted in 
tighter restrictions on the security policies of the machines. In my personal 
case, the network administrators generally removed local admin privileges to 
the machine, preventing me from installing new applications and, in some 
instances, upgrading existing installs. When this occurred, Cryptnos generated 
an error, then defaulted all settings, wiping out all my preferences and site 

In the other reported incident, the user check his event log and reported the 

"From what the event log is telling me, it looks like the Cryptnos process is 
calling SE_CREATE_GLOBAL_NAME, which according to MSDN 
spx> is used mainly during Terminal Services sessions.

"My SWAG is that since my work has standardized on the USGCB as the 'baseline' 
configuration for all systems, the lockdown of Terminal Server services on 
non-server systems (desktops, laptops, etc.) is the culprit.

"... Even though I have local Admin privileges, the GPO enforcement still 
blocks the call."

What's perplexing about this is that Cryptnos should not be referencing 
Terminal Services at all, so I have no idea where this is coming from.

I've created this issue to serve as a way to track this problem. I will update 
it as I find new data during my research. Until I can find out how and why this 
is occurring, it is strongly recommended that all users maintain a diligent 
backup process. Make sure to export ALL of your site parameters each time you 
make a change, and keep a copy of that export in a safe place. You may need to 
restore your backup if this problem occurs.

Original issue reported on by on 26 Sep 2012 at 6:38


This comment has been minimized.

GoogleCodeExporter commented Jun 26, 2015

I believe I've found the answer to the SE_CREATE_GLOBAL_NAME issue. Whether or 
not this answers the overall problem will require a bit more testing.

Cryptnos uses a small bit of code at start-up to prevent more than one instance 
of the application from running per user. This is a data safety measure; since 
Cryptnos stores all its data in a given registry key under HKCU, having 
multiple instances open at once could result in data corruption. One instance 
of Cryptnos could make a change to the registry that the other instance won't 
see, then the second instance might overwrite the first instance's changes.

To prevent this, Cryptnos uses a mutex (System.Threading.Mutex) to control 
access at start-up. When the first instance opens, it creates the mutex and 
claims ownership, holding on to it until the instance closes. If a second 
instance starts, it will attempt to claim the mutex and will fail. In this 
case, it won't create the main app window but will instead give focus to the 
already open window then silently exit.

The problem is that the initial example I used as a guide used poor practices 
in naming the mutex. That example, and Cryptnos in turn, used a rather generic 
name based on the application's name. This worked relatively well on my 
personal development machine, so it made its way into Cryptnos. Unfortunately, 
neither I nor the original example's author realized that this arbitrary naming 
would give the mutex a global scope.

This is where I think the problem surfaced on my work machine. With the 
restricted permissions enforced by a new corporate policy, I lost many of the 
administrative privileges I still enjoyed on my personal machine. Along with 
this likely went the ability to create and manage globally-scoped mutexes. When 
Cryptnos attempted to run under this tighter security and tried to create a 
global mutex, this caused a security exception. And since I blindly followed 
the original example, the creation of this mutex did not occur in a try/catch 
block, resulting in a crash. I don't think it should have caused the data 
corruption based on the flow of logic in the code, but I can't rule that 
possibility out.

I am making some changes to the Cryptnos code that should change the scope of 
the mutex to being local for the user. This should prevent an individual user 
from launching multiple copies at once, but many users could each run their own 
copy without problems (say, under Terminal Services). I have also improved the 
error handling during start-up, which should greatly decrease the likelihood of 
a crash and data corruption.

I am waiting on feedback from the other reporter of the problem, hoping that 
he'll be able to test the new code on his machine. Once I get some good testing 
in, I'll probably release this as a 1.3.3 patch.

Original comment by on 26 Sep 2012 at 7:54


This comment has been minimized.

GoogleCodeExporter commented Jun 26, 2015

Original comment by on 26 Sep 2012 at 7:55

  • Added labels: Milestone-1.3.3

This comment has been minimized.

GoogleCodeExporter commented Jun 26, 2015

This issue was updated by revision r57.

Tweaked mutex code in main program code to hopefully avoid issues pertaining to 
Issue 8. Still need feedback from the original reporter to have a better idea 
if it works.

Updated the GPFUpdateChecker library with some better error handling and 

Cryptnos should now always default to UTF-8 rather than the system default 
encoding if the user hasn't set a preference. While the original behavior 
mimicked the old way of doing things, it's really a Bad Thing(TM) in terms of 
cross-platform interoperability.

Tentatively bumping version number up to 1.3.3.

Original comment by on 26 Sep 2012 at 8:05


This comment has been minimized.

GoogleCodeExporter commented Jun 26, 2015

OK, I haven't heard from the original reporter in some time, so I have no 
confirmation either way that the proposed fix works for him. That said, I can 
report one what's happened on the workstation I use mentioned in the original 

I have been running the tentative 1.3.3 code on this workstation for some time 
now without encountering any loss of data. All site parameters and settings 
have remained intact. This has been somewhat difficult to test, however, since 
the locked down security has prevented some of my tests. Apparently our admins 
systematically remove "unapproved" applications as Cryptnos will no longer run 
if installed via the installer; I can only get it to run by copying the EXE and 
support files into a non-standard location and running it directly. That said, 
it *does* run and the parameters are still in place. I guess I'll take that as 
a good sign.

So I'm going to go ahead and make preparations to push out 1.3.3 as an official 
release, once I'm finished making changes for some other enhancements. I will 
close this issue as fixed once I push that out; if the problem resurfaces, I'll 
reopen this ticket.

Original comment by on 13 Mar 2013 at 3:42


This comment has been minimized.

GoogleCodeExporter commented Jun 26, 2015

Original comment by on 2 Aug 2013 at 8:28

  • Changed state: Fixed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment