Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Being a victim of a Key Logger attack on android, I want to develop a solution for KeyLogger attacks for android. I know basic java and a little about android and very little about Information Security. I am also aware that whatever knowledge I have is not enough to figure out and to develop a solution. I just like to discuss my idea and to see if it is feasible.
Here is what I have:
An android application, which wants to secure user input, must provide a secret key(which can be obtained from server, for a specific user or session) when invoking the android keyboard.
Android keyboard will receive the secret key and use it to encrypt user input and broadcast KEYPRESS event(or whatever event android keyboard broadcasts) with encrypted value.
When an application receives KEYPRESS event, it decrypt's the value in KEYPRESS even to get the actual user input.
I just came to realize that, screenshot can be used to get what user types with latest image-2-text software's. But that is completely a different domain, IMHO.
So, what do you think about it? Is it possible to do it?
Update
I was completely wrong about my phone got owned. Actually, it was never got hacked. But, what really got hacked was me. Yes, I have something in my body, which just copies everything that my brain can receive. And it also capable of receiving and making my brain to do it. I still dont know, why I am able to write this update. May be, who ever put that thing in my body using me as a marketing material. Thanks for answers for my dumb question.
Not realistically.
Few programmers are dealing with low-level input themselves. That is usually handled by other things. Web developers, for example, rarely get involved on a keystroke-by-keystroke basis, even for finding out when those events occur (e.g., for real-time validation), let alone for manually processing that input (e.g., putting the next character typed after the cursor of the field and advancing the cursor by one position).
Moreover, users are not in the habit of changing their input methods frequently. I do not plug in a different USB keyboard when I am visiting Stack Overflow versus when I am visiting Tweetdeck, for example. In the world of Android, this means that the user is going to expect their input method editor to work on all apps and not have to keep changing input method editors just to make some people happy.
Furthermore, you cannot magically change the protocol between input method editor (a.k.a., soft keyboard) and the Android OS. Your keyboard will raise key events. You are welcome to say that your keyboard offers up substitutions for those events as an "encryption" mechanism, but that would be more of a crude substitution cipher (e.g., "whenever the user types A, send over ;"), as you cannot unilaterally decide to expand the key event space.
As a result, not only will you need to write your input method editor, but you will need to write your own custom ROM with a custom Android framework that can handle the "decryption". Or, you would have to force all the worlds' developers to rewrite their apps. And in either case, a keylogger could trivially detect that yours is the input method editor and note that fact, so whoever is using the logs can do some trivial decryption to convert ; back into A.
Now, if you are writing some app where you want to avoid a rogue input method editor, you are welcome to bake in your own data entry keyboard into that app. Then, you will merely anger many of the users of your app, as your in-app keyboard is not the one that they want to use, or lacks features that they are used to (e.g., support for blind users, support for their particular language).
Here is what I would do to implement a secure input method paradigm - as expressed in the question - for Android:
First of all, I am assuming that you have read and understood the "Security" section for InputMethodManager here:
InputMethodManager
So, what we need to develop is an Input Method (IME) which is an Android service, which, along wth the custom keypad view, implements two interfaces:
InputMethod
InputMethodSession
As per the security section in the documentation referred to above, the user need to willingly accept your IME as the system IME. Also, Android will make sure that only system will bind to your service and use the InputMethod interface which is used to show/hide the keyboard etc. So, here things are pretty secure for you and all apps that uses your keyboard.
Now, coming to the security framework that you want to implement:
Lets call it as Secure Input Method - SIM - and lets define our security domain as your IME and the applications that wishes to use your SIM. Here is the significance of the second Interface InputMethodSession
The most important - and often ignored method of this interface is the key of this solution and it is called: appPrivateCommand. This interface allows a private command sent from the application to the IME. As per the documentation, this method can be used to provide domain-specific features that are only known between IME and their clients - and this is exactly what you need for your SIM.
So, using this interface, the apps in your security domain can pass any security information (say, some form of credentials) they want to hand over to your IME. It is up to you to define a method where your service can communicate with a authentication server which processes the client app submitted credentials and approves it. Now if the encryption keys are derived by both your IME and the client, you have established a secure channel of communication between your SIM and its client app (say, via encryption using a derived key from these credentialsd).
You can even customize this whole mechanism by defining some key sequences (like Control+Alt+Del in Windows) which initiates the whole thing by user himself and you can even provide a visual indication (say, a shining green icon) on your keyboard that the input channel is secured... Possibilities are many :)
Hope this helps.
You can do this only if you are developing your own keypad and configure Android to use it. It is not that hard with some experience in Android programming.
Just search in Google for "custom keypad for android" for more inputs.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Is there any way to disable browser back button using Java code? Javascript is not reliable in all browsers.
Your both assumptions are wrong.
1) No one can disable browser back button (of course excluding the vendors :)).
2) Java plays on server side. Javascript plays on client side.
You might want browser onunload function to prompt user.
#Derek did a demo for what I mean : http://jsfiddle.net/DerekL/LZCj7/show/
Simple answer: Yes (for certain definitions of disable).
You are completely free to exercise whatever forms of navigation control on your website, and create a series of once-only urls, which must be accessed in a specific order, thus rendering the back button useless. (you could even cause re-visiting these urls to return to a pre-defined homepage)
Common misconceptions:
You can use javascript to control a browser on a client. - You can't, there's no two ways about it, the javascript is out of your control and can be modified by a 7year-old (this is a conservative estimate based on experience, not expectation.),
Preventing backwards navigation is always hacky and/or bad. Certain things should really attempt to do this better - Ever done an online quiz, or memory game?
Solution:
please note this will not disable the button, and will instead invalidate requests made to a 'previous' url
Include a key in every request (which changes for every subsequent request), and is associated with the HttpSession, this could then be included in form submission - bear in mind, someone who knows what they're doing can still extract this and use it to travel backwards, so it is also worthwhile ensuring that your key can only be used for a specific subset of pages from your entire site (those allowed). Many easy ways to do this, personally I am a fan of primes and hashes.
also note, refreshing a page with this could cause you grief if you have not considered your desired behaviour. Do so, and implement it.
You shouldn't try to disable the back button, as your website shouldn't extend beyond the limits of the viewport, but you should rather try to change your approach. I'm pretty sure that what you want to acheive can be done in another way! Why don't you tell us more about it?
JavaScript was designed to act on DOM elements, and unfortunately, the back button isn't part of them. Also, unlike what you think, JavaScript is reliable, and although the result may slightly vary from one browser to another, there are some libraries that are able to tackle this problem.
As for Java, you might be thinking of applets... But it's still not the right way to go, and in terms of cross-browser compatibility, the situation is much worse than it is with JavaScript.
So, in a nutshell, YES, there might be some workarounds to prevent the use of the back button, but NO, you should'nt try to do it, because it's considered a bad practice.
EDIT:
Here is a snippet of JavaScript (not Java) ode that can prevent the previous page from loading:
<script>
function preventBackButton(){window.history.forward();}
setTimeout("preventBackButton()", 0);
window.onunload=function(){null};
</script>
But remember, this is NOT a good practice. You should NOT use it. Why don't you tell us what you want to achieve so we can help you do it the right way?
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Is it a good practice to defensively check for null/empty inputs in client ? In the server this check is happening of whether or not input is null and an exception is thrown accordingly, should client also make a check in order to avoid a call to the webservice ?
Under the best circumstances, it is a performance improvement, and nothing else.
Under the worst circumstances, the client side checking can drift away from what the server accepts, actually introducing bugs due to inconsistent deployments.
In either case, you don't typically have control over the client environment, so you cannot assume the client-side check was performed. Malicious users can inject their own client-side code which will permit non-valid inputs to be sent to the server, so server-side checking is still strongly required.
I would recommend that you do client-side checks, but I would also recommend that you take the care to ensure that your client-side checks are synchronized with your server-side checks, such that your client doesn't start filtering inputs in a different manner than your server would. If that becomes too problematic, error on making the server side checking correct. It's the only real defense point.
It's good practice to do whatever you need to do to protect your server, whatever that may be.
Always do checking server side, you never know where data is going to come from.
Do checking client side if you have some reason for notifying the user of their mistake before sending data to a server. For example, a client-side validation of an integer input can, e.g., update a warning label as the user is typing without requiring round-trip validation to the server. Client-side checks are essentially a first line of action for displaying clear validation errors to the user, but really they are nothing more than UI performance improvements. If you don't want to do that, then you don't need to do that. If you only want to do that for certain values, you only need to do that for certain values.
Perhaps your server already generates reasonable information about validation errors, in which case you could display those to the client. It really depends on your situation and needs.
For example, lets say the client displays a series of dialogs asking for input before finally sending a request to the server. It's irritating for the user if they aren't notified of an invalid input until after they go through the entire series of dialogs. This is a good case for client-side validation at each step of the input.
Note that the cost of client-side validation is that you need to make sure to maintain it to match the actual server-side rules if they change.
It's also good practice to think a little about your specific requirements and choose an appropriate course of action to make sure those requirements are met, rather than asking vague questions about generic, situation-agnostic "good practice".
Personally, I try my best to have server-side validation report useful information, and I don't do any initial client-side validation. I then add client-side validation later, after higher priority work is complete and after determining that the UX would clearly benefit from it.
Yes, in order to keep the bandwidth and the server load as low as possible, you should always add client-side validation as well. Even a thin-client can do easy validations like null/empty-checks.
If you have some complex validation depending on many different inputs (cross-validation) or maybe complicated checksum calculations, you might skip the client-side validation and do it only on server side.
Server side validation is always needed though, because as you can see, the client cannot be trusted if you would now decide to not validate.
i am doing a project in which i have 3 classes (lamp, clock and TV) now,
i am making a GUI Application which will allow users to add lamps, tv's and clocks to a 3.3 grid panel,
in terms of validation, one of the constructors of the Clock class allows the user to initiate a Clock with hour minute and second parameters passed into it, as well as various setters
would it be best to have the validation inside these classes (i.e. ensuring user cannot make a clock which reads 24:01:01 etc) or is it advisable to have the validation at the GUI level i.e if asked to enter a time to initiate the clock, if it is wrong, simply display the panel again until valid input is applied.
based on experience, which is the best advisable way to do this?
(i am a first year Computer Scientist studying java, bare that in mind when responding as im not familiar with deep technical methods)
Thanks,
You would want validation on both levels.
You want validation on the model side (the Clock class) to avoid invalid data in your model.
However, to offer a good user experience you also want validation in the UI so that the user immediately sees that his/her input is invalid and not has to wait until his/her input reaches the model.
Compare it with a web application: you want validation on the front-end to offer quick feedback to your user. You also want server-side validation to avoid that somebody bypasses your UI and inserts invalid data in your model.
I couldn't come up with a better title, so allow me to elaborate:
There are programs such as JoyToKey, that allowed the user to map button inputs on any joystick to any key event and mouse event. To be frank, I do not know the real underlying implementation here, but it is like either JoyToKey "ubiquitously" sends these mapped inputs to whatever application the user is focusing, or it simply invokes global input events.
So the thing is this, in Java application, if we want to listen to any keyboard or mouse input, we can easily to do that with the KeyListener and MouseListener classes, but what I am talking here is if I want to create a Java application that listens to all of the user's specified inputs, (be it from joystick, touch screen, or whatever) regardless of which application has focus at the time and map these inputs to other inputs and macro. For instance, if I want to perform Hadoken in Street Fighter, I tell the program "hey, if I press 'P' or 'Joystick 1 Button 10', invoke the following keyboard events respectively 'down arrow' in the first (1/60) millisecond, 'down+right arrow' in the next (1/60) millisecond, 'right arrow' in the next (1/60) millisecond and finally 'Z' in the next (1/60) millisecond".
So what I am looking for here is different from JoyToKey in the following aspect:
I am looking for how to write a JoyToKey-like program in Java.
not limited to Joystick only. Allows user to map all sort of hardware inputs to any other hardware input as well.
Due to the nature of Java and we are invoking the OS directly, I am concern about the cross-platform capability. The underlying mechanism of each OS might be a little different, but anyway, is this possible in Java? If so, which Java's API should I be looking for? Are there some hardware-specific problems to be aware of?
If you're on Linux, check out the java-gnome bindings. The org.gnome.gdk package provides access to system-wide device events.
I am am new to mobile app development. But i would like to know if this is possible to intercept incoming calls on my N73 using code like Java or C++?
My second question is if this is possible then can we prevent the phone from ringing with a specified phone number from a black listed contact???
I've seen a lot of apps doing this task but i am interested in knowing if this is feasible & how this is accomplished.
Thanks in Advance.
In C++ you can use CTelephony from etel3rdparty. Use NotifyChange() to subscribe to EVoiceLineStatusChange events. On an EStatusRinging event you can call GetCallInfo() to retrieve the remote party information, including phone number, and then decide whether to reject the call or let it keep ringing.
As far as I know, the CTelephony API does not have a direct method of rejecting a call but you can achieve almost the same with AnswerIncomingCall() followed by HangUp(). Your executable will need the NetworkServices capability.
A more hackish way to reject the call could be to use RWsSession to simulate pressing the red key (end key): call SimulateRawEvent() to send TRawEvent::EKeyDown and EKeyUp events on EStdKeyNo, with some delay between the events. In this case your executable will also need the SwEvent capability.