Other than for app launch shortcuts, which should only be provided by the O/S, what are the legitimate uses of things like Windows keyboard hooks? It seems to me that we only have problems with things like key loggers because operating systems provide hooks to do things that should not be permitted by anyone under any condition except the O/S kernel itself.
EDIT: OK, so given some legitimate places where they may be required, should not the O/S provide a high level ability to globally turn them off, and only allow exceptions on a program-by-program basis?
I'm currently working on a mobile application platform / hardware abstraction layer for an enterprise client, and one requirement was that a screensaver would be brought up after a certain period of inactivity. Since mobile devices don't have mice to move, "activity" consists of key presses or screen taps. One of our devices doesn't have a touchscreen, and, to make a long story longer, the mobile hardware vendor didn't properly implement the Win32 API calls that would allow me to get the time since the last user input.
Since the hardware vendor was unwilling to implement the Win32 API properly, the next best way I knew of to ensure that my console application could trap key presses in any application on the system was to install a global keyboard hook.
That said, I agree that the average consumer scenario is very different from mine, and the OS should allow the user to whitelist activities like this.
Not true, there are environments where the owner of the computer may want to stop things such as Ctrl+Alt+Delete... example, a Kiosk, or... .... Best Buy?
For example I have installed two applications;
One maps Windows-V as paste unformatted text
Another one modifies how caps lock works
I think both of them require a hook.
I wrote an app that let me place virtual sticky notes on my monitor. I used an OS keyboard hook to bind a hotkey to it.
I had an option in settings to disable the hook.
There may not be a lot of legitimate uses. However, I'm of the opinion that you shouldn't intentionally limit the features of a system, simply to make it more secure.
Also, a key-logger isn't a bad thing if you know it's there and you installed it yourself.
Related
Hi everyone and sorry for my bad English.
I'm learning penetration testing.
After reconnaissance and scanning of my target, I have enough information to pass to next phase.
Some info I have is open ports with related running services, names of the services, service's versions, operative system of the device, firewalls used, etc.)
I launched the mfs console.
I should find the correct exploit and payload, based on the information collected to gain access. I've read the Metasploit Unleashed guide on offensive-security. I've learned the Metasploit Fundamentals and the use of mfs console.
But I don't understand the way to start all of this. Assuming that my target has 20 ports open, I want test the vulnerability using an exploit payload that do not require user interaction. The possibilities of which exploit and payloads to use are now reduced, but are always too. Searching and testing all exploit and payloads for each ports isn't good! So, if i don't know the vulnerability of the target, how do I proceed?
I would like to be aware of what I do. and do not try without understanding.
Couple of things:
We have a stack exchange for security! Check it out at https://security.stackexchange.com/
For an answer: you want to look for "remote exploits", as those do not require user interaction. you can find a curated list of exploits here: https://www.exploit-db.com/remote/
You can search the services on this page for something that matches the same service/version as your attack vector.
I've seen some documentation and videos from WWDC about data protection in iOS5 and it seems very nice since it can encrypt all your application data and keep it protected as long as your device is locked. However, I see 2 main problems with that system-wide data protection mechanism:
1- if somebody manages to steal my iPhone while it is not locked (which is typically what happens on a "steal-and-run" case), it can potentially plug my iPhone into a laptop and access my data unencrypted
2- it forces me to define a system-wide passcode, which seems natural to some users but is still cumbersome to a lot of users. And it seems abusive that I force my users to define a system-level passcode even though my app is the only one where encryption might really require it. And it's even more abusive as a four-digit password is not such a good protection against brute force attacks.
So my question is the following. Is there any simple way to encrypt my data with a passcode specific to my application, so that every time a user launches the app, they have to enter the passcode, but they don't have to define one on the system level? If not, can I at least plug into standard data protection API's with such an application-specific passcode? If not, is it worth it to write my own encryption layer on top of core data to enable such a scenario? Or is it something that might be added to future versions of iOS (in which case I'll probably stick with system-wide passcodes for now and upgrade it later)?
Several data protection api's on other operating systems (e.g. DPAPI on windows) allow developers to provide supplemental entropy for the key derivation process used to protect the data . On those systems, you could easily derive that data from a pin number. Without that pin, then you can't generate the key and read the data.
I looked and couldn't find anything to this effect on iOS, but I am not an objective c programmer so frankly , reading apple's documentation is a pain for me, and I didn't look too hard.
Depending on your use case you may want to enable data protection in your app, but if the user doesn't use a passcode it won't give you much protection. I don't know if enabling that entitlement will force a passcode.
You could take the path to require that the app have a pin code at launch and then use that pin code along with some other data data to generate a key for the common crypto functions.
https://developer.apple.com/reference/security
If anyone can help me with this, I'd be eternally in their debt.
Without getting bogged down in details, I'm trying to program an app so
that, for instance, while the application is currently launched, if I say the words,
"activate function A", a specific function which already exists in my app, is activated.
Have I explained myself clearly? In other words, on the screen of the phone is a button
which says "function A". When the software is "armed" and in listening mode, I want
the user to have the ability to simply say the words "activate function A",
(or any other phrase of my choice) and the screen option will be selected without requiring
the user to press the button with their hand, but rather, the option is selected/activated
via voice command.
My programmers and I have faced difficulties incorporating this new voice command capability,
even though it is obviously possible to do google searches with voice command, for instance.
Other voice command apps are currently in circulation, such as SMS dictation apps,
email writing apps, etc, so it is clearly possible to create voice command apps.
Does anyone know if this is possible, and if so, do you have advice on how to implement
this function?
QUESTION 2
Assuming that we are unable to activate function A via voice command, is it possible
to use voice command to cause the phone to place a call, and this call is received
by our server? The server then 'pings' the iPhone and instructs it to activate function A?
For this workaround to work, I would need the ability to determine the exact phrase.
In other words, the user can't be forced to use the word "call function A". I need the
ability to select the phrase which launches the function.
Hopefully I've been clear.
In other words, as a potential workaround to the obstacles we've been facing regarding
using voice command to activate a specific function within our app, is it possible
to harness the voice command capability already present in the phone? aka, to place
a phone call? And then this call is received by our server, and the server
accordingly pings the phone which placed the call, and instructs it to activate the function?
I obviously understand the necessity for the app to be currently launched, before it
would be possible for my application to receive the instruction from the server.
If someone can help me to solve this vexing problem, it is not hyperbole to say that
you would change my life!
Thanks so much in advance for any help one of you kind souls can provide!!!
Michael
I don't believe the iPhone comes with any built in speech recognition functions. Consider speaking to Nuance about buying and embedding one of their speech recognition engines. They have DragonDictate for iPhone, but they also provide a fair amount of other recognition engines that serve different functions. Embedded solutions is clearly one of their areas of expertise.
Your other path of pushing the audio to your server may be more involved than you expect. Typically this process involves end-pointing (when is speech present) and identification of basic characteristics so the raw stream doesn't need to be passed. Again, investigation into the speech recognition engine you intend to use may provide you with the data processing details you need. Passing continuous, raw voice from all phones to your servers is probably not going to be practical.
I have developed a software piece (with C and Python) which I want to protect with dongle so that copying and reverse engineering becomes hard enough. My dongle device comes with an api which provides these:
Check dongle existence
Check proper dongle
Write into a memory location in dongle
Read from a memory location in dongle etc. (I think the rests aren't that good..)
What I can do in the source code so that it becomes harder to crack. Dongle provider suggested that, I should check proper dongle existence in a loop or after an event, or I should use the dongle memory in an efficient way. But how? I have no idea how crackers crack. Please shed some light. Thanks in advance.
P.S: Please don't suggest obfuscating. I have already done that.
First of all, realize that the dongle will only provide a little bit of an obstacle. Someone who knows what they're doing will just remove the call to the dongle and put in a 'true' for whatever result that was called. Everyone will tell you this. But there are roadblocks you can add!
I would find a key portion of your code, something that's difficult or hard to know, something that requires domain knowledge. Then put that knowledge onto the key. One example of this would be shader routines. Shader routines are text files that are sent to a graphics card to achieve particular effects; a very simple brightness/contrast filter would take less than 500 characters to implement, and you can store that in the user space on most dongles. Then you put that information on the key, and only use information from the key in order to show images. That way, if someone tries to just simply remove your dongle, all the images in your program will be blacked out. It would take someone either having a copy of your program, grabbing the text file from the key, and then modifying your program to include that text file, and then knowing that that particular file will be the 'right' way to display images. Particulars of implementation depend on your deployment platform. If you're running a program in WPF, for instance, you might be able to store a directx routine onto your key, and then load that routine from the key and apply the effect to all the images in your app. The cracker then has to be able to intercept that directx routine and apply it properly.
Another possibility is to use the key's random number generation routines to develop UIDs. As soon as someone removes the dongle functionality, all generated UIDs will be zeroed.
The best thing to do, though, is to put a domain specific function onto the dongle (such as the entire UID generation routine). Different manufacturers will have different capabilities in this regard.
How much of a roadblock will these clevernesses get you? Realistically, it depends on the popularity of your program. The more popular your program, the more likely someone will want to crack it, and will devote their time to doing so. In that scenario, you might have a few days if you're particularly good at dongle coding. If your program is not that popular (only a few hundred customers, say), then just the presence of a dongle could be deterrent enough without having to do anything clever.
Crackers will crack by sniffing the traffic between your app and the dongle and either disabling any code that tests for dongle presence or writing code to emulate the dongle (e.g. by replaying recorded traffic), whichever looks easier.
Obfuscation of the testing code, and many scattered pieces of code that perform tests in different ways, as well as separating spatially and temporally the effect of the test (disabling/degrading functionality, displaying a warning etc.) from the test itself make the former method harder.
Mutating the content of the dongle with each test based on some random nonce created each run or possibly even preserved between runs, so that naively recording and replaying the traffic does not work, will make the latter method harder.
However, with the system as described, it is still straightforward to emulate the dongle, so sooner or later someone will do it.
If you have the ability to execute code inside the dongle, you could move code that performs functions critical to your application there, which would mean that the crackers must either rederive the code or break the dongle's physical security - a much more expensive proposal (though still feasible; realise that there is no such thing as perfect security).
How to maximize protection with a simple dongle?
Use API together with Enveloper if an enveloper exists for your resulting file format. This is a very basic rule. Because our enveloper is already equipped with some anti-debugging and obfuscating methods to prevent common newbie hackers to give up hacking the program. Only using enveloper is also not recommended, because once a hacker can break the enveloper protection in other program, they can also break yours.
Call dongle APIs in a LOT of places in your application. For example when first start up, when opening a file, when a dialog box opens, and before processing any information. Also maybe do some random checking even when there's nothing done at all.
Use more than one function to protect a program. Do not just only use find function to look for a plugged dongle.
Use multiple dlls/libraries (if applicable) to call dongle functions. In case one dll is hacked, then there are still other parts of the software that uses the functions from another dll. For example, copying sdx.dll to print.dll, open.dll, and other names, then define the function calls from each dll with different names.
If you use a dll file to call dongle functions, bind it together with the executable. There are quite some programs capable of doing this; for example PEBundle. 3
I have got this article on PRLOG and found it quite useful on maximizing protection with a simple dongle. Maybe this link may help you
Maximizing Protection with a Simple Dongle for your Software
You can implement many check points in your application.
I don't know if you use HASP, but unfortunatelly, dongles can be emulated.
You may want to look into using Dinkey Dongles for your copy protection.
It seems a very secure system and the documentation gives you tips for improving your overall security using the system.
http://www.microcosm.co.uk/dongles.php
Ironically, the thing you want to discourage is not piracy by users, but theft by vendors. The internet has become such a lawless place that vendors can steal and resell your software at will. You have legal recourse in some cases, and not in others.
Nothing is fool-proof, as previously stated. Also, the more complex your security is, the more likely it is to cause headaches or problems for legitimate users.
I'd say the most secure application is always the one tied closest to the server. Sadly, then users worry about it being spyware.
If you make a lot of different calls to your dongle, then maybe the cracker will just emulate your dongle -- or find a single point of failure (quite common to change one or two bytes and all your calls are useless). It is a no-win situation.
As the author of PECompact, I always tell customers that they can not rely on anything to protect their software -- as it can and will be cracked if a dedicated cracker goes after it. The harder you make it, the more of a challenge (fun) it is to them.
I personally use very minimal protection techniques on my software, knowing these facts.
Use smartcard + encrypt/decrypt working files through secret function stored in card. Then software can be pirated, but it will not able to open properly encrypted working files.
I would say that if someone wants to crack your software protection, they will do so. When you say 'hard enough' - how should 'enough' be interpreted?
A dongle will perhaps prevent your average user from copying your software - so in that sense it is already 'enough'. But anyone who feels the need and is able to circumvent the dongle will likely be able to get past any other scheme that you engineer.
I have a PS/2 touchpad which I would like to write a driver for (I'm just a web guy so this is unfamiliar territory to me). The touchpad comes with a Windows XP driver, which apparently sends messages to enable/disable tap-to-click. I'm trying to find out what message it is sending but I'm not sure how to start. Would software like "Syser Debugger" work? I want to intercept outgoing messages being sent to the PS/2 bus.
IDA Pro won't be much use to you if you want to find out what 'messages' are being sent. You should realise that this is a very big step up for most web developers, but you already knew that?
I would start by deciding if you really need to work at the driver-level, often this is the Kernel level. The user mode level may be where you want to look first. Use a tool like WinSpy or other Windows debug tool to find out what messages are getting passed around by your driver software, and the mouse configuration applet in control panel. You can use the Windows API function called SendMessage() to send your messages to the application from user mode.
Your first stop for device driver development should be the Windows DDK docs and OSR Online.
I suggest reading the synaptics touchpad specs (most of the touchpads installed on notebooks are synaptics') available here http://www.synaptics.com/decaf/utilities/ACF126.pdf
I believe on page 18 you'll find the feature you are looking for. At least you'll know what to expect.
So, very likely, the touchpad driver "converts" the command coming from user mode to this PS/2 command.
I don't know the specifics of the touchpad PS/2 driver but I see two major ways for the user mode panel to communicate with the driver:
- update some key in the registry (this is actually very common)
- the driver provides an alternate "channel" that the user mode app opens and writes specific commands to
You may want to try using the process monitor from sysinternals to log registry activity when setting/resetting the feature.
As for the options 2 you may want to try IRP tracker from OSR and see if there's any specific communication between the panel and the driver (in the form or IRPs going back and forth). In this case, kernel programming knowledge is somewhat required.
The windows kernel debugger may also be useful to see if the PS/2 driver has some alternate channel.
Have a look at IDA Pro - The Interactive Disassembler. It is an amazing disassembler.
If you want to debug, not just reverse engineer, try PEBrowse Professional Interactive from SmidgeonSoft