Say we have a Windows application, which sends some packets over HTTPS.
We need to extract the content of this packets (unencrypted of course).
There is no way to get hands on server private certificate and MitM attack doesn't work (some MitM defense is used by this application).
So, decryption seems to be off the table.
The only choice (I suppose) is to extract these packets from the application before they get encrypted.
Application is well protected, it has no dependency on OpenSSL DLLs. However, we have a certain feeling that it uses OpenSSL (but, statically linked, may be OpenSSL source was even modified before compiling/linking).
Hooking a call to OpenSSL functions (like ssl_write()) is not simple, because the application's executable is packed and obfuscated. It also has a debugging protection, but a stealth debugger, which avoid this defense, is already found.
So, we can debug this application. However, the code, as seen during debugging, is a complete mess (obfuscated).
Even the system DLLs, being loaded by this application, are completely messed. Here is an example of how the send() function from WS2_32.dll looks like during debugging of this application:
http://s2.postimg.org/pjzaipx0p/image.png
For reference, here is how it looks like from normal (unprotected) application:
http://s21.postimg.org/3kzntkn93/image.png
So, it's very hard to understand how the function arguments are passed, moreover it looks like they can be passed via different ways (not sure, but looks so according debugging experiments).
This seems to be a quite common task, since there are many Windows applications which use HTTPS and statically linked OpenSSL.
Hopefully somebody have such experience and can share it.
Related
I'm building an application that will provide a service to other applications (let's pretend like it solves differential equations). So my DifEq service will be running all the time and a client application can send it requests to solve DifEqs at any point.
This would be trivial using sockets or pipes.
The problem is some applications nefariously want to send linear equations instead of differential equations, so I want to register applications that I know are sending proper DifEqs to my application.
Traditional sockets break down here, as far as I know.
Ideally, I'd like to be able to look at some information about the application that is making a request of me and (either through some meta-data on that application, through communication with my web site, or through some other, unkown method) determine it is an acceptable DifEq app. Furthermore, this ideal method would not be spoofable without a root/admin-level compromise of the underlying OS. If the linear equation app is also a root kit, I'll concede to being broken. :)
I need to be able to do this on Windows, OS X, and Linux (and maybe Android); but I recognize that it may not be the same solution on all platforms. So, how would you accomplish this (specify the platform you are focusing on, if appropriate)? I've done a lot of server-side development, but it's been way too many years since I've done any client-side development outside the browser and the world is very different today than it was then.
I think your question is a little confusing when it comes to talking about DifEQ vs LinearEQ.
It sounds to me like you are just looking for a routine way to verify that clients are authorized to connect. There is a lot to read up on this subject. Common methods would be to use SSL certificates to verify the identity of clients. You can also tunnel over SSH, or use OAUTH, etc, etc.
You'll have to do some more digging around the web to see what kind of authentication fits your scenario. You mention 'not spoofable'. I think that people generally end up compiling-in a certificate of private key into their application. This will stop all but the very dedicated and experienced hackers.
I can't find this on Google (so maybe it doesn't exist), but I basically'd like to install something on a web server such that I can run a site on Scheme, PHP is starting to annoy me, I want to get rid off it, what I want is:
Run Scheme sources towards UTF-8 output (duh)
Support for SXML, SXLT et cetera, I plan to compose the damned thing in SXML and -> to normal representation on at the end.
Ability to read other files from the server, write them, set permissions et cetera
Also some things to for instance determine the filesize of files, height of images, mime-types and all that mumbo-jumbo
(optionally) connect to a database, but for what I want to do storing the entire database in S-expressions itself is feasible enough
I don't need any fancy libraries and other things that come with it like CMS'es and what-not, except the support for SXML but I'm sure I can just find a lib for that anyway that I can load.
Spark-Scheme has a full web server. If you don't need that, it also has a FastCGI interface so that you can serve Scheme scripts from a web servers like Apache, Lighttpd etc. Spark-Scheme also seem to meet your requirements for database support, UTF-8, file handling and SXML. See the Spark-Scheme Programming Guide (pdf) for more information.
mod_lisp and FastCGI are the only two Apache modules I'm aware of that might work at this time. mod_lisp provides Scheme support because it's architecture is similar to FastCGI, where CGI like parameters are sent over a socket to a second process which remains running as the Scheme backend to the web server. Basically you use one or the other to send CGI like parameters across a socket to a running Scheme backend.
You can find some information about these solutions here. There was another FastCGI like effort called SCGI which demoed a simple SCGI receiver in Scheme called gambit. That code is probably not maintained anymore, but the scheme receiver might be useful.
Back in the Apache 2.0 days, there were more projects playing with scheme and clisp bindings. I don't believe that mod_scheme ever released anything, but if they did, odds are it is not compatible with the modern releases of Apache.
Did you come across Fermion (http://vijaymathew.wordpress.com/2009/08/19/fermion-the-scheme-web-server/)?
If you're looking for a lispy language to develop web applications in, I'd recommend looking into Clojure. Clojure is a lisp variant that's fairly close to scheme; here is a list of some of the differences.
Clojure runs on the Java virtual machine and integrates well with Java libraries, and there's a great webapp framework available called Compojure.
Check out Chicken Scheme's Eggs Unlimited. I think what you want is a combination of the sxml- packages coupled with the fastcgi package.
PLT Scheme has a web application server here: http://docs.plt-scheme.org/web-server/index.html
Im making an application in cocoa and wanted to see if some strings in it were easily accessible so I ran OTX on it and sadly all of my code was found. Is there a method I can use to make my code more "secure" or at least encrypt/hide the strings? The reason I want to encrypt the string is it's a password for a server. I don'd need it really secure I just don't want the password to be so easy to find.
Thanks for any help
You should never put a password into an executable.
This is like putting the password on a sticky note next to the monitor. If a malicious hacker has your application they can eventually extract the password regardless of what language or API you use to write it.
For example, if I know that your application connects to a password protected server but the application never ask for a password, then I know you've made the mistake of including the password. To find the password, I need only monitor the operation of the program to see what areas of code are active around the time it connects to the server. This will tell me where to focus the search for the password regardless of how big your application is. Then it is only a matter of time until I track the password down. Encrypting the password does no good because the encryption algorithm must also be in the app and I can unravel that as well.
Remember that there are many people out there who can unravel your code using only the raw machine code. For those people it doesn't matter what language or API you use because they all distill to machine code in the end. Those people are the scary skilled gods of programming and they laugh at mere mortals such as you or I. Unfortunately, some of them are evil.
Did I mention that you should never put a password into an executable? If I didn't, let me repeat that you should never put a password into an executable.
In your particular case, as novice programmer, you have no hope of hiding of the password from someone with even a little bit more experience than yourself. This is yet another good reason why you should never put a password into an executable.
1. Avoid ObjC in secure code.
Because ObjC's class system depends heavily on runtime reflection, the whole interface needs to be included alongside the executable. This allows tools like class-dump to easily recover the source #interface of the binary.
Therefore, the secure code functions should be written as a C function, not an ObjC method.
2. Use strip.
By default the compiler will keep all the private symbols (which allows stack trace to be more readable). You can use strip to delete all these symbols.
3. Obfuscation.
The above steps can only hide the code logic. But if the password is a constant string, it is immediately visible using the strings utility. You may obfuscate this by constructing the password in runtime (e.g. store the password encoded in ROT-13 in the file.)
4. Or just change your design.
No matter how good your protection system is, as the hacker have total control on their machine, given enough time, they always win. It's better to revise your design, like why the password must come with the executable? Or why a global password even needed?
My company is looking at implementing a new VPN solution, but require that the connection be maintained programatically by our software. The VPN solution consists of a background service that seems to manage the physical connection and a command line/GUI utilty that initiates the request to connect/disconnect. I am looking for a way to "spy" on the API calls between the front-end utilty and back-end service so that our software can make the same calls to the service. Are there any recommended software solutions or methods to do this?
Typically, communications between a front-end application and back-end service are done through some form of IPC (sockets, named pipes, etc.) or through custom messages sent through the Service Control Manager. You'll probably need to find out which method this solution uses, and work from there - though if it's encrypted communication over a socket, this could be difficult.
Like Harper Shelby said, it could be very difficult, but you may start with filemon, which can tell you when certain processes create or write to files, regmon, which can do the same for registry writes and reads, and wireshark to monitor the network traffic. This can get you some data, but even with the data, it may be too difficult to interpret in a manner that would allow you to make the same calls.
I don't understand why you want to replace the utility, instead of simply running the utility from your application.
Anyway, you can run "dumpbin /imports whatevertheutilitynameis.exe" to see the static list of API function names to which the utility is linked; this doesn't show the sequence in which they're called, nor the parameter values.
You can then use a system debugger (e.g. Winice or whatever its more modern equivalent might be) to set breakpoints on these API, so that you break into the debugger (and can then inspect parameter values) when the utility invokes these APIs.
You might be able to glean some information using tools such as Spy++ to look at Windows messages. Debugging/tracing tools (Windbg, or etc.) may allow you to see API calls that are in process. The Sysinternals tools can show you system information to some degree of detail of usage.
Although I would recommend against this for the most part -- is it possible to contact the solution provider and get documentation? One reason for that is fragility -- if a vendor is not expecting users to utilize that aspect of the interface, they are more likely to change it without notice.
I have a windows exe app that used to sends packets to a server in the clear. This app (lets call it the client app) is definitely close sourced, but some clever hacker hex-edited the binary, and made it send packets that are scrambled.
Now, obviously, those packets are scrambled in a way that is decipherable (otherwise the server would not be able to understand it), but what I wanted to do is to write an emulator that emulates this binary app, sending the same packets to the server, and being able to unscramble the response (if it is scrambled).
The hex-ed client required an extra dll in order to run, which the old client did not. I am assuming that somehow the hex-ed client managed to load that dll (lets call it client.dll) and the function of that dll is to implement the scrambling/unscrambling, by hooking into some windows api that rerouted all packets sent from the client.exe process.
If there are anyone who can direct me on how to even get started on working out how this all works, and how I can reverse engineer the scrambing, that would be really appreciated.
I have no idea what kind of information to provide, but if there is any lacking, just reply, and I will post with more details, and if anyone wants the binaries, I m happy to provide it.
binary download for any interested parties:
http://dl.getdropbox.com/u/46623/client.dll
http://dl.getdropbox.com/u/46623/newClient.exe
http://dl.getdropbox.com/u/46623/originalClient.exe
These wont run because the resource files are required - they are about 3 gigs, so too big to upload anywhere. Names have been changed to protect the guilty =) , but that probably doesnt protect the name of the dll...
I'm assuming that the person which coded this hook which adds encryption to the packet I/O for the aforementioned program has either hooked the relevant Windows' socket APIs (WSASend, send, etc) or hooked the internal program functions used to send/receive data.
This being said, I'd suggest you use a hook detection program (e.g. RkUnhooker) to find out what is actually being hooked. Once you know what APIs are hooked you should also know where these hooks are going and from there on in you'll have to manually reverse engineer the hook functions.
As for the subject of learning how to do this, I couldn't direct you to just one tutorial to teach you everything but I highly suggest you look at the Tuts4You site, it has a plethora of tutorials which would meet all of your needs.
If possible, upload a copy of the edited client & the hook DLL, if I have the time I'll code you replica encryption & decryption functions.
You need to hook the functions exported by the additional DLL and look into the functions being called and the parameters being passed to them. This is not going to be easy since you do not have type information (e.g. the function signatures for the DLL exports.)
Look here for some information on API hooking. You will also need a good debugger try Windbg from microsoft.
As far as I can see the only option you have here is black box testing ie give known input to both systems and compare the responses against each other to find the differences and similarities.
+--------------+
Input--------->| Original App |--------->Response1
+--------------+
+------------+
Input--------->| Modded App |--------->Response2
+------------+
Now once you figure out how to use the functions from the additional dll you can use it yourself in the same way the original app does.