I'm thinking of implementing a keystroke dynamics (authenticating people based on their typing patterns) application for Linux. As I see it, I have two alternatives:
Extend the Linux logon to support keystroke dynamics
Create a desktop-locker program which "locks" the screen and can only be unlocked by a typist with a particular typing pattern
Is alternative 1 possible? Windows supports extending the logon process via msgina.dll, does Linux support something of the sort?
For altenative 2, is is possible to disable the mouse and keyboard?
libpam has plugin ability. so yes, totally possible, like the (in)famous msgina :)
locking the screen is mmm rather touchy - who is responsible? window manager, X server, session manager, the screen saver process, ?
I'm afraid different desktop environments (Gnome, KDE...) might have different opinions. Although these days, I'm pretty positive all of them will share some kind of FreeDesktop dbus interface to coordinate this type of functionality.
Assuming this is more than just a toy (in other words, if you plan to distribute), be sure you think about how to get around the typing pattern analysis when things go wrong. My typing patterns probably change quite a bit over time, as I've got wrist problems that flare up now and then. When they do, my typing probably changes markedly. I wouldn't be too surprised if my typing changes somewhat from morning to night even, as I am more or less tired and/or caffeinated.
Hey, Linux is open source, you could do anything you want :-)
It is very likely that you don't need to modify the kernel. For example, terminal login is controlled by the login program. Changing the source and rebuilding it will definitely allow you to do what you need to, although how difficult it is I've no idea :-)
Graphical login is taken care of by the window manager, so which program to change depends on which window manager you use.
EDIT: On a second thought, I'm not sure if login is executed early enough to catch the keystroke dynamics. Besides, it is a bit risky because if your version of login fails, it could make it difficult to login and fix the problem. You might need to take a look at getty and see how it invokes login. If you do it in a graphical interface it might be easier since you can always fall back to text terminal to fix any problem.
The proper way to do this would probably be through a PAM authentication module. Check out the module writers guide here: http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/Linux-PAM_MWG.html
Basically you can just add your module to the PAM stack, have it do its keystroke analysis, and then pass either success or fail to the system. This lets you integrate it with the console login process, and even SSH if PAM is enabled there. I'm not quite sure how it would work with a graphical login such as KDM or GDM. I know you can use PAM modules with those, but of course the interaction is done through the GUI textbox.
Related
I am writing an application that will occasionally save data. The Problem is now, when a user logs out of X11 and my application did not yet save the changes, is there a way to detect the logout and write the changes to disk? I tried inmplementing a signal handler for SIGHUP and SIGQUIT without success. Is there a signal that gets emitted or is there a way to lsiten for a logout?
Read ICCCM and EWMH (both are quite large specifications that you should read carefully).
In practice, your X11 application is likely to use some existing GUI toolkit like e.g. Qt or GTK (be sure to use at least GTK3). Then that toolkit should have support related to sessions.
For Qt: look into QSessionManager.
For GTK: see GtkApplication
(if you are stuck with GTK2 - e.g. with lablgtk -, you'll spend months or one or two years of efforts to implement EWMH sessions in your code; porting it to GTK3 -or even to Qt5- should be wiser and might be less work) Since GTK (both GTK2 and GTK3) is free software, you could study the source code (and perhaps be inspired by it, or adapt it to your needs, and/or make an educated guess of the amount of efforts to rewrite it).
Remember that X11 is a network protocol, and the server and the client (and the window manager) could run on different machines (e.g. thru ssh -X). Sending SIGTERM through the network has no sense (and that could explain why EWMH don't mention it).
A workaround might perhaps be to save the state periodically (e.g. every two minutes; then only two minutes of work is lost).
Basile's recommendation of looking at your toolkit's relevant classes (QSessionManager and GtkApplication) is good. I'm thankful he posted that because it helped me find the specific stuff I was looking for.
But if it's as you say, and your toolkit doesn't have built-in session management support, the relevant specification is not EWMH, but rather XSMP. There's a small amount of additional information included in ICCCM that you should also watch out for.
This is far from being a couple years of work. The relevant client-side portions of the session manager protocol should only take a few hours, maybe a couple days if you're unfamiliar with integrating low-level X11 protocols into an existing application stack.
To give a brief backstory to bring things up to my current position / reason for my question:
I originally wanted to use sendkeys to send keyboard presses to a Citrix Xenapp Remote Terminal Application (VT320 Emulator).
This does not work.
After some investigation it became apparent that this has been a reasonably common issue.
I eventually found a work-around that involved opening the windows 'On-Screen Keyboard' application and sending mouseclicks using VBA to the OSK app itself. The key transmissions would be successfully received in the remote terminal application.
This solution is a rather awkward and not very practical solution as it relies on many factors e.g. screen resolution, co-ordinates / current position of the OSK etc.
With the above in mind, I am looking to achieve a more full proof method and here's my thoughts:
Rather than using simulated mouseclicks I would ideally like to be able to either 'embed' the OSK app into the excel instance and reference each key
or hide the app and find a way to make the application receive the VBA keys requested.
I'm aware that Sendkeys has its limitations so I have also tried using SendInput via a Keyb_Event and this also didn't work.
To any half experienced expert, I'm clearly a beginner so I'm suffering from a lack of knowledge here perhaps.
If anyone can point me in the right direction for solving this issue, I'd really appreciate it!
Many thanks.
EDIT
I've looked into this a little more and found this post:
Finding the class name of the On-Screen Keyboard?
Which would suggest that if I know the class of the on screen keyboard, I could use its commands within excel VBA?
I did try to use the code within the question but couldn't get it to work.
So hopefully my question is a little easier to answer?
Can I use the class name of the on-screen keyboard app / declare an API function that will allow me to send simulated key functions as if it's the OSK app being clicked by the mouse?
Hopefully someone can help!!
Trying to automate apps locally can be quite fiddly. Doing it through a Citrix HDX connection is just painful.
Do you have any say over the Citrix environment? If so I'd try writing an automation app that actually runs on the Citrix server in the same session as the published app you're trying to automate. This has the advantage that you're effectively automating a local app which would make life easier.
Depending on how your automation works you may need to communicate between your automation app running in the Citrix session and your client. You could use WCF to bridge the two together.
So that's how I would try and do, as regarding your specific question I've provided some thoughts below...
OSK automation thoughts
I've done some limited automation of the OSK. There are actually two OSKs if you're using Win8. Osk.exe is the old one which has been around a while. TabTip.exe is the new Win8 specific OSK.
One problem to keep in mind is that both of these processes run as high integrity processes which means normal (medium) integrity processes have very limited abilities to automate them. So while I could automate some stuff, many messages would just get ignored. So this maybe why you are finding the OSK is not responding like you expect.
You can work around this by running your automation app as a high integrity process, but this generally means you need local admin (or local system) privilege to start the high integrity process. I never looked into the specifics of how you create high integrity processes. I know there's a command line tool you can use to force a process to run at a certain level (icacls.exe), e.g.
https://msdn.microsoft.com/en-us/library/bb625960.aspx
I imagine there would be APIs to do this as well.
Okay, here's a complicated one I've been breaking my head over all week.
I'm creating a self service system, which allows people to identify themselves by barcode or by smartcard, and then perform an arbitrary action. I run a Tomcat application container locally on each machine to serve up the pages and connect to external resources that are required. It also allows me to serve webpages which I then can use to display content on the screen.
I chose HTML as a display technology because it gives a lot of freedom as to how things could look. The program also involves a lot of Javascript to interact with the customer and hardware (through a RESTful API). I picked Javascript because it's a natural complement to HTML and is supported by all modern browsers.
Currently this system is being tested at a number of sites, and everything seems to work okay. I'm running it in Chrome's kiosk mode. Which serves me well, but there are a number of downsides. Here is where the problems start. ;-)
First of all I am petrified that Chrome's auto-update will eventually break my Javascript code. Secondly, I run a small Chrome plugin to read smartcard numbers, and every time the workstation is shutdown incorrectly Chrome's user profile becomes corrupted and the extension needs to be set up again. I could easily fix the first issue by turning off auto-update but it complicates my installation procedure.
Actually, having to install any browser complicates my installation procedure.
I did consider using internet explorer because it's basically everywhere, but with the three dominant versions out there I'm not sure if it's a good approach. My Javascript is quite complex and making it work on older versions will be a pain. Not even mentioning having to write an ActiveX component for my smartcards.
This is why I set out to make a small browser wrapper that runs in full screen, and can read smartcard numbers. This also has downsides. I use Qt: Qt's QtWebkit weighs a hefty 10MB, and it adds another number of dependencies to my application.
It really feels like I have to pick from three options that all have downsides. It really is something I should have investigated before I wrote the entire program. I guess it is a lesson learnt well.
On to the questions:
Is there a pain free way out of this situation? (probably not)
Is there a browser I can depend on without adding tens of megabytes to my project?
Is there another alternative you could suggest?
If you do not see another way out, which option would you pick?
My logic of APT (Anti-Paching Technology) is as follows...
1) Store on the MSSQL server the md5 hash of the executable for protection.
2) Perform an md5 comparison (within my application startup) the hash found on the server, with the executable itself.
3) If comparison fails exit application silently.
And all these above before it is finally pached!
I mean what is your best way to protected a file from being patched?
Without using ready tools (.net reactor, virtualizer etc)
Edit: Something else just came into my mind.
Is there any way of checking the application integrity on server side?
I mean my app works only online. Could i execute something on the server (my domain) that could check the application integrity?
The thing is a cracker would patch the application precisely on step 2, removing the hash check code.
So I wouldn't call that very effective against serious crackers.
EDIT: I guess your best bet is defense in depth, given that your app has to be online I'd:
Require authentication: Authenticate users, hopefully via a cryptographic key, and require a key check to receive/send data.
Obfuscation: It makes things harder for crackers.
Continued checks: Besides checking who is sending data, validate the application each time a request is sent.
These all can still be circumvented, but they make things a lot harder and might disuade some if your app is not worth that much to them.
A patched application means the 'cracker' has complete control over the machine the code is running on (at least enough control to patch the executable). So patch prevention however smart it might be is working against the flow of control.
Complicating your binary file might be enough to discourage patching so obfuscators are propably your best bet.
you can't. once someone else has your file they can do what they like with it - first thing would be to patch out your anti-patching code.
If the application is running on someone else's machine, you cannot prevent them from patching it. You can make it harder, but it's a shell game: you cannot win. Regardless of how complicated you make it, some guy somewhere will see it as an interesting challenge to break your protection, and he will succeed. Then, everyone else just has to download his version. The most extreme form of patch-protection today is Skype (that I know of). It's insanely complicated, and yet it has been broken.
Since your application apparently runs online, you can ask yourself why you want to prevent patches in the first place (maybe it's to prevent the user from entering some bad values? Or to prevent them from seeing some information that's present in the program?), and then architect your program so that whatever you want to keep hidden or checked happens on the server.
For example if it's a game and you want to prevent players from hacking the game to know where the other players are: change the server so it only sends coordinate information for the players that you can already see.
Another example: if it's an online store and you want to make sure users don't submit purchase orders with incorrect prices, check the prices at the server.
The only exception there is if you control the hardware that the program's running on. But even there, it's very hard to do it right (see: XBox, PS3, and the many other consoles that tried to do that and failed). It's probably still better to leverage the client/server architecture rather than betting on "trusted computing".
Crackers nowadays don't bother patching your executable file; they simply change your program's variables in-memory to make its behaviour more amenable to their requirements. Defending against this is very difficult and reasonably pointless; most games' crack-protection works only by searching for signatures of known crack programs (like an AV engine does).
Everyone nailed it, you can't stop someone but you can make it harder for them, you could even go off the deep end and make some in-memory validation stuff like World Of Warcrafts Warden system.
If you tell us what language you are writing in we might be able to suggest some simple obfuscation methods.
Supposing I was developing a fairly graphically intensive application (C++ or C#, graphics API undecided) for which most of the usage will be by remote users over RDP (either terminal server sessions or remote access to a single-user machine). It's obvious that non-essential "eye-candy" effects and animations should be avoided. My questions are:
What should I be careful to do/avoid doing to make most efficient use of the RDP protocol ? (e.g I have an idea RDP can remote some graphics drawing primitives straight to the client... but is that only for GDI ? Does using double-buffering break such remoting and force a bitmap mode ? Does the client-side bitmap cache "just work" or does it only cache certain things like fonts and icons ?)
Is there any sort of RDP protocol analyser available which will give some insight into what an RDP stream is actually transporting (in particular, bitmaps vs drawing primitives) ? (I can imagine adding some instrumentation to the rdesktop source to do this, but maybe something exists already).
In my experience I'd be careful when it comes to animations - especially fade up/down controls that can seriously kill performance over RDP.
Double-buffering might also cause some problems, however I personally haven't had to do too much in the way of workarounds for this - the article by Raymond Chen explains the possible pitfalls quite well.
Essentially, it's a good idea to check in code whether it's running in a remote sessions (RDP, Citrix, etc). Take a look at: GetSystemMetrics( SM_REMOTESESSION ) - you can then decide at runtime whether to enable or disable certain features.
My idea is that the optimization work made on RDP already cover 90% of the problem you're describing, so I would not worry about optimizing for RDP, you're already removed the eye-candy stuff, you know that the application will be used via RDP so I suppose you'll avoid operations that involves continuous redrawing of form, I believe that sould be enough.
Our application was never designed with RDP in mind, we had the same worries you have when a customer told us that all its client will be used via RDP (Citrix, in that specific case) from remote locations but also if we didn't change a single line of code the customer never called with slowlyness problems due to RDP.
Remember... Premature optimization is evil.