Can I encrypt a Visual Basic project so it can't be decompiled by dotPeek or any other software? I have done some research and I can't find anything.
The question you have asked is an excellent example of The XY Problem, where you have problem X, come up with solution Y, and then ask how to perform or implement Y. I shall answer Y first and advise you on X, which is what you really should have asked, e.g. "If I have an API key in my source code, how can I keep it safe?".
The answer to Y is kind-of yes. You can obfuscate your .NET assemblies in such a way that it becomes moderately difficult to determine exactly what the source code does. However, constant values, such as your API key, will be significantly easier to retrieve since it is a constant string value. The important thing to remember here is that obfuscation is not security, the API key most definitely can still be retrieved.
The answer to X (the question you should have asked), and the advice that you should follow, is to not store the API key in your application at all. Have an external server that you can send requests to that will in turn use the API key to retrieve relevant data and perform operations. Having your own server as a middle-man means that you can ratelimit requests and authenticate users yourself if you choose to. API keys should never be stored in client-side code (unless you have things like public and private API keys, which I believe Stripe, among others, use).
Related
I recently read about decompilation of iOS apps and I'm now really concerned about it. As stated in the following posts (#1 and #2) it is possible to decompile an iOS which is distributed to the App Store. This can be done with jailbreak and I think with copying the app from memory to hdd. With some tools it is possible to
read out strings (strings tools)
dump the header files
reverse engineer to assembly code
It seems NOT to be possible to reverse engineer to Cocoa code.
As security is a feature of the software I create, I want to prevent bad users from reconstructing my security functions (encryption with key or log in to websites). So I came up with the following questions:
Can someone reconstruct my saving and encryption or login methods with assembly? I mean can he understand what exactly is going on (what is saved to which path at which time, which key is used etc., with what credentials is a login to which website performed)? I have no assembly understanding it looks like the matrix for me...
How can I securly use NSStrings which cannot be read out with strings or read in assembly? I know one can do obfuscation of strings - but this is still not secure, isn't it?
This is a problem that people have been chasing for years, and any sufficiently-motivated person with skills will be able to find ways to find out whatever information you don't want them to find out, if that information is ever stored on a device.
Without jailbreaking, it's possible to disassemble apps by using the purchased or downloaded binary. This is static inspection and is facilitated with standard disassembly tools. Although you need to have a tool which is good enough to add symbols from the linker and understand method calls sufficiently to be able to tease out what's going on. If you want to get a feel for how this works, check out hopper, it's a really good disassembly/reverse-engineering tool.
Specifically to your secure log in question, you have a bigger problem if you have a motivated attacker: system-based man-in-the-middle attacks. In this case, the attacker can shim out the networking code used by your system and see anything which is sent via standard networking. Therefore, you can't depend on being able to send any form of unencrypted data into a "secure" pipe at the OS or library level and expect it not to be seen. At a minimum you'll need to encrypt before getting the data into the pipe (i.e. you can't depend on sending any plain text to standard SSL libraries). You can compile your own set of SSL libraries and link them directly in to your App, which means you don't get any system performance and security enhancements over time, but you can manually upgrade your SSL libraries as necessary. You could also create your own encryption, but that's fraught with potential issues, since motivated hackers might find it easier to attack your wire protocol at that point (publicly-tested protocols like SSL are usually more secure than what you can throw together yourself, unless you are a particularly gifted developer with years of security/encryption experience).
However, all of this assumes that your attacker is sufficiently motivated. If you remove the low-hanging fruit, you may be able to prevent a casual hacker from making a simple attempt at figuring out your system. Some things to avoid:
storing plain-text encryption keys for either side of the encryption
storing keys in specifically named resources (a file named serverkey.text or a key stored in a plist with a name which contains key are both classics)
avoid simple passwords wherever possible
But, most important is creating systems where the keys (if any) stored in the application themselves are useless without information the user has to enter themselves (directly, or indirectly through systems such as OAUTH). The server should not trust the client for any important operation without having had some interaction with a user who can be trusted.
Apple's Keychain provides a good place to store authentication tokens, such as the ones retrieved during an OAUTH sequence. The API is a bit hard to work with, but the system is solid.
In the end, the problem is that no matter what you do, you're just upping the ante on the amount of work that it takes to defeat your measures. The attacker gets to control all of the important parts of the equation, so they will eventually defeat anything on the device. You are going to need to decide how much effort to put into securing the client, vs securing the server and monitoring for abuse. Since the attacker holds all of the cards on the device, your better approach is going to be methods that can be implemented on the server to enhance your goals.
Basically, I think it's a good idea to version your REST api. That's common sense. Usually you meet two approaches on how to do this:
Either, you have a version identifier in your url, such as /api/v1/foo/bar,
or, you use a header, such as Accept: vnd.myco+v1.
So far, so good. This is what almost all big companies do. Both approaches have their pros and cons, and lots of this stuff is discussed here.
Now I have seen an entirely different approach, at Twilio, as described here. They use a date:
At compilation time, the developer includes the timestamp of the application when the code was compiled. That timestamp goes in all the HTTP requests.
When the request comes into Twilio, they do a look up. Based on the timestamp they identify the API that was valid when this code was created and route accordingly.
It's a very clever and interesting approach, although I think it is a bit complex. It can be confusing to understand whether the timestamp is compilation time or the timestamp when the API was released, for example.
Now while I somehow find this quite clever as well, I wonder what the real benefits of this approach are. Of course, it means that you only have to document one version of your API (the current one), but on the other hand it makes traceability of what has changed more difficult.
Does anyone know what the advantages of this approach are, so why Twilio decided to do so?
Please note that I am aware that this question sounds as if the answer(s) are primarily opinion-based, but I guess that Twilio had a good technical reason to do so. So please do not close this question as primariliy opinion-based, as I hope that the answer is not.
Interesting question, +1, but from what I see they only have two versions: 2008-08-01 and 2010-04-01. So from my point of view that's just another way to spell v1 and v2 so I don't think there was a technical reason, just a preference.
This is all I could find on their decision: https://news.ycombinator.com/item?id=2857407
EDIT: make sure you read the comments below where #kelnos and #andes mention an advantage of using such an approach to version the API.
There's another thing I can think about that makes this an interesting approach is if you are the developer of such api.
You have 20 methods, and you need to introduce a breaking change in 1 of those.
Using semver (v1, v2, v3, etc) you need a v2 api.
All your 20 methods now needs to respond to v2, but in reality, those methods aren't changed at all, aren't new.
Using dates, you can keep your unchanged methods as is, and when the request comes in, it just pick the best match.
I don't know how is this implemented, any information on that will be really welcome.
I used to work for a company that used date versioning (as in each api call had param of the API date desired ?v=20200630) and loved it.
It lets you be less strict than with the traditional versioning (v1, v2, v3) as client developers don't need to even care about the version number and just use the current build time. Everything else is pretty much the same as as with the traditional versioning + small benefit from seeing date checks in the server code - you can easily see how old this or that code path is.
I believe the situation would have been different if we had to support a number of external clients and for example fix a bug in ?v=20200630 - there is no elegant way to specify something like ?v=20200630.1. As you can see from Twilio's experience they were just changing what API version 2010-04-01 was - thus client couldn't be sure which version exactly it was seeing.
So my outcome from this:
date based version seems easier and more flexible when you are a typical startup or a small company with a few of apps (e.g. frontend, iOS, Android) and no or few 3rd party clients. Date-based versioning makes it a bit easier for client developers to "just write code" and since you control all the code, most of the time you can fix old API bugs by just releasing a new version and asking clients to switch to it
Once you start having the real need to maintain the old API versions (AKA when you have a number of important clients who are not likely to update quickly), then semver versioning becomes more reliable
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I have researched on each element or system that I am willing to implement into a generic software licensing system for my soon-to-be apps (irrelevant, as this should work, or be usable on all of my applications).
I have created a DLL with my licensing class in it.
It is as follows:
(1)
I have applied the InternalsVisibleTo() attribute main class (with child classes), which makes all of the internal classes, and their methods, which are declared Friend, visible to external assemblies with the sepcified PublicKey.
I have made the reference to the app name, and it's PublicKey. (Both the licensing, and the external assembly, are signed with the same key (.snk file)
(2)
All (where possible) members, properties etc. are delcared Friend or Private or just Dim...ed .
(3)
My licensing class has a String variable; declared:
Private Shared _Key As String = "H58N2-00V93"
This variable is the special password, if you will, of my DLL, and is required to access the methods in my DLL.
There is also a Public String variable (let's call it "AccessKey"), which should be initialized with the main class, like so:
Dim licDLL As New LicensingAssemblyName.LicensingMainClass With {.AccessKey="H58N2-00V93"}
(4)
Then, I have a Function (let's call it "CheckKey"), which checks whether the Public, initialized variable ("AccessKey" is equal to the pre-defined, Friend key ("_Key"), whereupon an exception will be thrown, if they are not equal - preventing method from continued/used.
(5)
At each first line of every Sub, Function etc., I have inserted a call to this function.
These are just the 'security' measures I've taken to prevent external assemblies from using my DLL in another app, to perhaps exploit the system or generate keys.
Now for the licensing measures.
(1)
I have a key generator (very basic), which generates codes upon a given format (Like: "#-$" for a number, a dash, followed by a letter.)
I have included an encryption class in this program, which uses Rijndaenal, and applies salt.
I have set the key generator to encrypt each separate key upon generation, then append it to a new line of a file, which we'll call "my_licenses.txt".
I use the same password for each one (obviously). It is quite long, and includes many different characters (if that makes ANY difference). I considered this to be a secure way since I didn't think ANYONE could decrypt a string without the password, until I was told by another programmer, who advised against using plain text encryption as a method to secure these keys. Please help me with this.
(2)
In my licensing DLL, I have a declaration:
Friend Shared Function IsKeyValid(ByVal KeyDB As String, ByVal Key As String) As Boolean
This function decrypts each key in the file (the specified database, using the same pass code used when encrypting them in the key generation program).
Then I do a For Each, Next loop to, determining whether the specified "Key" value equals any in the key 'database', "my_licenses.txt". But here's the catch.
I have an Function which returns a unique code for the computer it's running on (using hardware IDs etc.). This Function helps me protect against the use of the same key on multiple computers (unless I implement a system for allowing this, limited times) and is required as the last 5 characters of the "Key".
After checking, this Function returns a value of the result (True or False).
Finally (phew), each assembly (the licensing one, and any external ones which utilize it) are obfuscated -and likewise signed (all assemblies, with the same key (.snk) file)- by CodePlex's Confuser (A free, and highly recommended obfuscator for .NET).
I hope this hasn't been too long/not detailed enough/difficult to understand. (If so, tell me what you don't understand).
This is my first post/question of any kind, so be nice. Also thank you for reading.
I hope you can help.
And just to confirm, my question is this: Would this system be secure enough to protect against the average hacker?
P.S. I am only a beginner, so answers for a beginner would be especially appreciated ;)
*UPDATE: I have actually reduced the length of this question, and improved its understandability (believe it or not). So this is the best I can do.
That's an insane wall of text so you kind of lost me. And, to be honest I stopped reading seriously when I saw you had a hardcoded key inside the binary that you plan to distribute... But there are two questions you ought to ask yourself:
Is your application likely to be so successful that there is sufficient demand for it so that people with the appropriate skillset will be inclined to reverse it and release a keygen and/or pirated version?
And wouldn't your time be better spent adding cool features to the application instead of licensing code which does nothing to improve the application itself?
Don't get me wrong. I'm all for people getting paid for their work and I don't object to people licensing their software; as a matter of fact, one of the projects I worked on was a custom licensing engine which was tracking a little over 100,000 licenses last I checked. But make sure that if you decide to implement licensing that the effort you put into it doesn't exceed the effort you put into the actual software you're licensing.
With all that said, here's what I would do:
Generate a lot of licensing keys (using whatever format you want)
Hash those keys using something like SHA-256 or SHA-512.
Create an array (using whatever syntax is appropriate to your language of choice) that contains the key hashes.
Include the array inside your application.
With that setup, to verify a license, all you need to do is:
Hash the input using the same algorithm as before.
Iterate the array, comparing it with the result of the hash. If they match, the key is licensed. If they don't, continue.
If you get to the end of the table the key is not licensed.
Do not immediately exit the application if the key isn't licensed. Instead set a flag that prevents the use of important commands (e.g. "Save") or set a timer for 60 seconds plus a random number of to exit the application.
Compile and then digitally sign your application with Authenticode. Have the application itself validate the signature to try and discourage casual tampering.
If you are so inclined, you could even encrypt the hashes, although that is unlikely to help against the sort of attack that someone would mount against this scheme.
To be clear: this is not bulletproof (then again, no licensing mechanism is) and it's possible for someone sufficiently skilled to break it in a number of ways. But it's almost certainly going to be more than good enough for your project.
Security doesn't have an absolute value, it has to be measured against the payoff. If your app is holding some nuclear codes I'd say go pay a specialized consultant for this. If you're storing grandma's secret recipes - you're good to go.
I read the whole post and it's still not clear what's the purpose of the hard-coded key or how do you manage the individual encryption keys for each license: encryption is not just about how strong an algorithm you use or how long your password is; it's also about how do you hide your passwords, how do you transmit them, what do you do in edge cases (interrupted connection, failed decryption etc) and many other things.
From the looks of it I'd say you're in the "good to go" category only because your app doesn't sound like a high-profile target to crack and you mostly want to deter the casual cracking attempt from a frustrated developer who doesn't like your licensing scheme (: and the obfuscation alone would deter most when it comes to reverse-engineering your code. I'm not familiar with your code to tell if there's any other, easier ways to bypass licensing, such as the popular method of copying the licensing file itself if it's not tied to the machine or user profile...
There are many workarounds online, but only hashing system described here or something based on public key cryptography can be secure enough to serve licensing.
I personally prefer and use commercial product: http://www.treekslicensinglibrary.com - Treek's Licensing Library. It's cheap, easy to setup and really secure as it uses previously meant public key cryptography to work with license.
Edit: To compare with hashes of serial numbers - this solution does not require to predefine accepted serial numbers. 1000 hashes in apps = 1000 licenses, for more you need to update your app. Public key cryptography based license systems do not have this disadvantage.
You can use a .NET Obfuscate application to secure it. All .NET application may decompile with .NET Reflector, so search in your browser the application to obfuscate .net application. This will work as i know, everyone that want to decompile your application will prevent by the obfuscate
I want to send an out of band message (don't worry about how it gets there) to a program I've written on a distant machine. I want the program to have some confidence the message is legit by attaching a digital signature to the message. The message will be small less than 200 characters.
It seems a public key based signature is what I want to use. I could embed the public key in the program.
I understand that the program would be vulnerable to attack by anyone who modifies it BUT I'm not too worried about that. The consequences are not dire.
I've looked through the MSDN and around the web but the prospect of diving in is daunting. I'm writing in straight c++, no NET framework or other fancy stuff. I've had no experience including NET framework stuff and little luck during previous attempts.
Can anyone point me at some very basic resources to get me started?
I want to know
How to generate the public and private keys
How to sign the message
How to verify the signature
You could try looking at the Keyczar library. It provides a high level abstraction to cryptographic functions with the aim to make is easy for developers to do crypto correctly. As an added bonus it has c++ bindings.
There is also Cryptlib which has been around for a while, and NaCl. As with Keyczar these libraries aim to provide a high level abstraction for common crypto functions.
gpgme is a high-level cryptographic API for GnuPG, written in C, but with bindings for a number of languages. GnuPG has excellent docs and is easy to use, so you can play around 'manually' on the command line and get a feel for how the key operations work, then look up the functions you need for your code in the API.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I am planning on putting up a web service, or some other service exposed over the internet. I would like to create an API for applications to interact with this service. I would like the API to be usable in different languages, such as Java, C++, C#, or PHP. How can I maintain one code base for my API, but distribute nice packaged binaries for all these languages? Also, I may want to consider this could be cross platform as well.
Update 1
I'm early days on Web Services, but I
think one of the key points is that
lots of tooling supports the
implementation of clients based on the
description of the service like WDSL.
I've not delivered any client-side
software with anything I've done, I
expect any user to be able to build
their own clients suited to their
needs. --Brabster's Answer
I am not opposed to making it a straight web service then giving out a WSDL file. But what if I want the client API to do some logic, encryption, error checking or so on?
Update 2
As far as expecting the client that is
using your API to do anything, you
can't! There is nothing you will be
able to do to ensure that the consumer
of the API will do anything right.
That's why robust error handling is so
important. You must check and double
check any and everything that comes
from the client. You must always be
suspicious of it, and even assume that
it is malicious. There really is no
good way around that fact. --Ryan Guill's Answer
My original idea was to create a DLL or Assembly in .NET, then the client is making calls into this code that is running client side. This code may talk via any communications protocol back to the server, but my API would be running on their box. I guess REST does not really accomplish this. It seems like in REST everything is still an HTTP post. It is almost web services with out soap.
Update 3
I have accepted Ryan Guill's answer. I think the general idea is that I need to expose a network service of some sort, with the lowest barrier to the client. That way anyone can connect. Then just have all my code run on the server. That seems to be accepted as the only want to really achieve the platform and language independence I am after.
Thanks for all the input.
I would use a REST API, similar to the way Flickr's API works: http://flickr.com/services/api/
It is fairly simple to create and maintain, the biggest downsides are that it takes a lot of documentation (but pretty much any way you do an API will have this issue) and that robust error handling is a must.
But in my opinion, it's the best way to create an API that is the closest to cross platform/cross language.
More information here: http://www.xfront.com/REST-Web-Services.html
Update: The submitter added the following to the post:
I am not opposed to making it a straight web service then giving out a WSDL file. But what if I want the client API to do some logic, encryption, error checking or so on?
I personally do not like using SOAP (using a WSDL). There is a lot of inherent overhead to using SOAP, both on the server and the client. I think that is why you see more and more public API's being written using REST. It really lowers the barrier to entry to the lowest common denominator, allowing anything that can use basic HTTP (GET and POST (also PUT and DELETE for the "proper" way of doing it)) to use the API.
Some more examples of public API's written using REST: twitter, vimeo, Google
As far as expecting the client that is using your API to do anything, you can't! There is nothing you will be able to do to ensure that the consumer of the API will do anything right. That's why robust error handling is so important. You must check and double check any and everything that comes from the client. You must always be suspicious of it, and even assume that it is malicious. There really is no good way around that fact.
Update 2: the submitter added the following to the post:
My original idea was to create a DLL or Assembly in .NET, then the client is making calls into this code that is running client side. This code may talk via any communications protocol back to the server, but my API would be running on their box. I guess REST does not really accomplish this. It seems like in REST everything is still an HTTP post. It is almost web services with out soap.
You can certainly do this, but that is only going to work for .NET languages, meaning that your cross-platform and cross-language benefits are out the window. And still, in the end, are you really preventing anything? The developer is going to either use your remote API, or your local DLL or Assembly. Either way, he is going to have to know how to use it and use it right, otherwise you are going to throw an error. All you are really doing is changing where the errors get thrown from. Which may be important to you (if so, mention why) but really isn't changing anything in the equation.
But you are somewhat correct in saying REST is kind of like web-services without the SOAP. Technically REST is web-services too, its just that web-services have come to generally mean SOAP. It really is a different way of achieving the same thing. The biggest differences are though that it takes more programming and thought on your side (and potentially more programming on the client side) but you trade that for robustness, less overhead in both the consumer and the server, and the widest possible audience for the API. It really is the lowest common denominator.
I'm early days on Web Services, but I think one of the key points is that lots of tooling supports the implementation of clients based on the description of the service like WDSL.
I've not delivered any client-side software with anything I've done, I expect any user to be able to build their own clients suited to their needs.
If you check out the flickr API as suggested by one of your other answers, I don't think they supply client side code, other people have built and contributed client side stuff.
I suggest writing the API in the Haxe programming language so that the source code can be directly translated to all the programming languages you mentioned. The Haxe programming language can be translated (or "trans-compiled") to all of the programming languages that you mentioned in the original post, as well as a few others.
Simple answer, no.
Complex answer: create an API and compile it to a COM dll. Then, just build the wrapper code for the languages that can't handle that.
Simple answer #2, make the original service so trivial, or so universally acceptable, as to not require an API (I usually implemented this through server-side database polling. Ugly but any language that can access a database can utilize the program).