Can someone crack my Blowfish encryption method

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.

agreed.

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.

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.

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.

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.

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

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...