Can someone crack my Blowfish encryption method

I have a Windows Monile app which I will eventually sell.  I have used the blowfish algorithm to tie the program to the serial number of the program.  It goes like this.

1. Program starts up and reads the serial no of the PDA.  The serial no will be 40 characters long like so: F4E2A85A47A093E4E72EE54F37E03B853016BDA5.
2. My program puts this serial no through the blowfish algorithm (using a secret key) and the result must match a licence key that is located in a text file on the Mobile Device.
3.  If they both match then the program runs else it shuts down.

Now I am responsible for generating this licence key using the blowfish algorithm and using the same secret key as the Windows Mobile program uses.  So to produce the licence key I do the following:

1. Get the serial no from the PDA.
2. Run it through blowfish algorithm using same secret key as the Windows Mobile Program uses.
3. Store the output in a licence file and copy it to the PDA.

I want to ensure that my method is not flawed and that users will not be able to crack it.  If a user sends me the serial no of the pda and I send them back a licence file, could they look at the two and somehow work out a way to crack it.

For example, here is a typical serial no from a PDA device:

and here is the resultant 'licence' file after it is blowfished:

Can my 'secret key' be cracked from the above two bits of data?

Thanks for any help
Who is Participating?
kind4meConnect With a Mentor Commented:
There are numorous ways to exploit software.  You will not be able to make your software hack proof.  It doesn't exist, ask Microsoft.  The way I had sujested went along the lines of the encryption, I was thinking how to get around that.  The best way would be for me to run your software on an emulation that mimics the platform and log all read / writes that go to the processor and memory.  I would than parse the logs for the license key or the PDA serial and look for random letters / numbers near it and try those as the secrect key.  I would keep inputing the serial and changing the key from the code I get from the logs until I see the correct output.  I guess this would take me between 1 and 40 hours depending on how lucky I was.

What DaveHowe suggested, and a more likely situation for hacking would be to find out what file was marked true after the key was authenticated on start up.  Once you know what line of code reads something like
If key equals pda serial after encryption then run program, if not than close.
Then remove that line or have it read for all values equal true.  (please ignore the moronic nature of my "code", it was just to explain my point).  

There are at least 2 other methods for hacking the software that come to mind as well.  The bottom line is that if you want even a single person to use it, it will be hackable.

For a good example of what DaveHowe is talking about you can see how Adobe Dreamweaver was hacked. It calls home after you put in the license to authenticate, so when apply the hack you need to disconnect your internet connection, then replace a file with the hacked file so that the osftware thinks it phones home and got an OK.

arnoldConnect With a Mentor Commented:
I think it can if your KEY consists on only encrypting the serial no of the PDA

Serial NO -> Blowfish processing -> key

Serial no -> + something + something else => one way encryption using random "salt" -> key

When your program runs it should have the something and something else that it adds to the PDA serial number than using the key as the salt to perform the one way encryption. The result must be the same as the key to work.

You should stay away from encrypt/decrypt mechanisms since you would run into a problem of always having to maintain the same secret with new version. Or you would need to handle the upgrade process.  I.e. take the existing key from the PDA decrypt it with the prior secrets, then reencrypt with the new version's secret.

kind4meConnect With a Mentor Commented:
Assuming you are using the most basic level of blowfish (128 bit), even using advanced cryptoanalysis it would require a minimum of 521 samples to generate the subkey and s box of your key.  

It is possible to break, everything can be broken, but I seriously doubt anybody would take the time / effort and expense to crack it.

Since you have not posted your code, nor should you, I will say that more often than not it is the code that is worked backward to vailidate the key.  The exploitable part of your license scheme is here:
My program puts this serial no through the blowfish algorithm (using a secret key).  

That means that the secret key is located someplace in the software.   Make sure that file is well protected and hidden as are calls to it's location.  If I was to try and hack your software it would be on the verification aspect.  

If I am reading this correctly, every time the program starts it will take the serial and run it through the key.  I would bet that if someone was so inclined the software can be run inside an emulator and the data to the processor / memory logged to find the key.  Again, I don't think that will happen.  

Good luck.
[Webinar] Kill tickets & tabs using PowerShell

Are you tired of cycling through the same browser tabs everyday to close the same repetitive tickets? In this webinar JumpCloud will show how you can leverage RESTful APIs to build your own PowerShell modules to kill tickets & tabs using the PowerShell command Invoke-RestMethod.

Dave HoweConnect With a Mentor Software and Hardware EngineerCommented:

For any sensible hacker who wants to be able to write a keygen, the first step will be:

1) extract hash generation code from program, use to generate a hash and upload to device.

of course, in the real world, first step would be:

1) locate bit of code that downloads file from device and checks its equal to mac, remove, hardcode return code to "true" and then distribute replacement exe on torrent site.
Wanting2LearnManAuthor Commented:
Thanks guys,
[QUOTE]That means that the secret key is located someplace in the software.   Make sure that file is well protected and hidden as are calls to it's location.  If I was to try and hack your software it would be on the verification aspect.   [/QUOTE]
I have this secret key hardcoded in my program, is this a potential security problem for me?

also this concerns me: [QUOTE]locate bit of code that downloads file from device and checks its equal to mac, remove, hardcode return code to "true" and then distribute replacement exe on torrent site.[/QUOTE]. Is this easy to do?

You see someone wants to be the 'sole' distributor or my app in a certain country so it would be worth their while to do something like this as they would now have the program for free.


Wanting2LearnManAuthor Commented:
the [QUOTES] didnt work sorry...
Wanting2LearnManAuthor Commented:
OK thanks, so I have now accepted that it is impossible to hack proof my code.  What I do want to do now is to make it a headache for anyone to try it.

Ok this may be a dumb suggestion but the line of code which goes:
"If key equals pda serial after encryption then run program, if not than close."

What if I put this line lots and lots of places throughout my code? say about 100 places. Would this take 100 times longer to crack?
Dave HoweConnect With a Mentor Software and Hardware EngineerCommented:
no, because the hacker doesn't actually see your source code, he steps though it at the machine-code level and watches what it does; when it gets to the point of comparing the value of the calculated data to the data file, they can just invert that result (so that it will only fail if it *does* get the right code) then put any old code in the file.
Wanting2LearnManAuthor Commented:
Oh I see now what you mean. Hmmmmmmmm.

Wanting2LearnManAuthor Commented:
One thought,
If I had several functions which I used to check the serial against the licence which all basically did the same thing but were different functions with different names.

Would this cause the hacker to do more work?  This way there would not be one single point of checking?

arnoldConnect With a Mentor Commented:

I think you seem to miss the point.
Does it really matter how many doors with different locks you put in?  Those who are intent on entering will break down every door and pick every lock if what is behind the last door is worth something to them.
I.e. make a crappy application with the worst validation scheme and no one will care enough to even try to break the validation scheme.
Make a good/great application with the most sophisticated validation scheme, someone will put in the time.

Additionally why not include as part of your application detection for the hardware type you are running on to make sure you are not in a VM?
Check the CPU you are running on. i.e. if you are on a PDA of a specific type, check whether the process is an ARM.
After a while all your application will be doing is confirming the platform it is on rather than performing the work you're designing it to do.

Wanting2LearnManAuthor Commented:
Good point. Thanks for that.

So now I need to confirm what platform it is running on.  Will I ask this in a seperate post?
kind4meConnect With a Mentor Commented:
I am not sure if arnold was being a little sarcastic on his last comment about verifiing the hardware.  If he was I agree with him (if not then I apoligize).  What I think he was saying is you can spend hundreds of man hours putting inplace things to prevent people from hacking your software and then you will have code that is 90% dedicated to stopping illegal copies and 10% doing whatever the app was meant to do.

If I may be very very blunt, your app is most likely not going to break records for sales.  It will most likely not make you more then you spend / have spent on creating hosting and promoting it.  If it is the best thing ever enough people will buy it.  Additionally the next app you come out with will sell like crazy too.  I hope I am wrong, but with the now millions (yes millions) of apps that have been produced by non-corporate non high buget people that have seen great success is very very slim.  

If you are really that concerned about someone else stealing it, then why don't you just release it for free and ask for donations?   That business model has seen a fair amount of success for both websites and software.  If the app is really that great people will pay for it, I know I have.  Or release a free version with limited features, or offer support to paying people etc.

And to expand once again on Dave's point, I have seen programmers pad data so that when the authentication comes in, it writes random data all over the program in addition to the license key.  Once again anybody who cares can just go over all the areas but it is more of a pain in the butt.

Hope this helps
Dave HoweConnect With a Mentor Software and Hardware EngineerCommented:
As a rule of thumb - for each programmer-manweek you spend adding DRM to a program, you will add one *hour* to the time it takes a 0-day cracker to break the code if they choose to do so, and around 10% to the support load for the program due to issues with it not correctly decoding legitimate users. You could also lose around 10% of your potential customers for each operation an end user has to perform, 20% if they have to perform an offline step (such as phoning you with a keycode) unless all your competitors are doing the same.

Note that a strong DRM solution for a program is considered a *challenge* by 0-day hackers.

about the only approach that works reliably is hideously expensive - you need to abstract some vital function or other into hardware, and supply the hardware as a dongle; this means the hackers must not only code around the dongle calls, but must duplicate the dongle code's functionality in software so that the program will fulfil its function - much harder than just hacking out your DRM. The other downside is that you will lock yourself out of some markets - lotus found this out the hard way, after the US Government removed them from the authorized supplier list (due to their "keydisk" drm) and microsoft got the spreadsheet contracts instead...
arnoldConnect With a Mentor Commented:
While a little sarcastic, I was trying to illustrate that once you start thinking of how to prevent someone from circumventing your validation mechanisms you put in place, all you remain doing is working on the mechanisms.
Because someone can always think of a more restrictive mechanism given in response to your question we have no consideration for the burden/load/complexity such a mechanism will be to the application.
I.e. for every operation the application would need to perform a task, it may have to run through the validation process such that the validation process will take 30% of the time while the actual task 70%.  If you take an average 8 hour day and the user uses your application, the tasks that would have taken 2 hours to complete with the added validation overhead now take 3+ hours.
While your application with the added overhead might be an improvement over the current amount of time used to perform the task, the overhead leaves room to someone else to step in and they only need a ten or fifteen percent improvement. With such an overhead in your application, the developer of the alternative does not have to improve or event meet the logic of your application, but only reduce the validation burden.

All Courses

From novice to tech pro — start learning today.