Case 2 doesn't hold. It's still a bit of "security by obscurity". There are several ways to remove what you describe. One way would be to run the program in the emulator/debugger and see where it fails. Then check what that method does and correct the logic. Run it again in the emulator to see if it still fails, then patch the next place. This is usually how programs written in other languages are cracked. (E.g. written i C/C++). Cracking in those cases is usually done in a debugger for assembler.
What I described in the scenario above is where they aren't using any code from you. I don't know what your code look like, or what it does. But I still guess that you have classes that others can use. It's in that case pretty easy to stub those classes out, and cracking all programs in your market would in that case mean that they just have to find out how your protection works, stub out code from you, and then apply it to all programs. Note that I'm not a hacker/cracker, but I'm curious, and I have myself tried to protect programs. On 22 Juli, 19:58, Al Sutton <[email protected]> wrote: > That form of approach is one of the main reasons the AndAppStore > system can download an encrypted license to the device which can be > stored and decrypted as neccessary. This means developers can; > > 1) Occasionally check the license is still valid by retrying to > download it, and if it doesn't download due to a network/server error > the app can use the locally cached copy. > > 2) Because the client code is open developers can embed it wherever > they want in their program logic as opposed to being a single library > which can be stripped out and replaced with an "always return true" > version. > > 3) Detect spoof servers because a spoof server will be unable to > return a properly encrypted file and thus developers can detect > decryption errors and mark them as spoofing attempts. > > Al. > > On Jul 22, 6:50 pm, Kaj Bjurman <[email protected]> wrote: > > > > > Correct, Removing the part that makes the requests, and just return > > "true" is what people usually are doing. > > > On Jul 22, 5:01 pm, Micah <[email protected]> wrote: > > > > The pirates will either strip out the licensing requests from the > > > application or they will spoof a licensing server. Meanwhile, your > > > legitimate users can't use your application when they don't have > > > access to the licensing server (it's down, they don't have internet > > > access, etc.). > > > > On Jul 22, 7:55 am, Android Development <[email protected]> wrote: > > > > > Maybe an activation licensing key for each binary may be the solution > > > > for > > > > this. But then again, its easier said than done. > > > > > On Wed, Jul 22, 2009 at 8:20 PM, Moto <[email protected]> wrote: > > > > > > I know that piracy will never end, I mean I'm a solo developer trying > > > > > to fight a war that multi-million companies have spent many millions > > > > > on protecting their content and still they get pirated... > > > > > > Well yes there could be some ugly side effect if google adds more > > > > > anti- > > > > > pirating features, so I guess I'm not too much for that... But I > > > > > believe there could be a better Android Market system that allows > > > > > anyone with a phone to purchase an app and put it on their SDcard. > > > > > Why not do the following? > > > > > > 1. User purchases app via Android Market. > > > > > 2. Phone sends unique ID IME? to server. > > > > > 3. Android Market server prepares application with encryption > > > > > according to given phone information. > > > > > 4. Application downloads to phone. "put it anywhere, SD card.. etc..." > > > > > 5. Application only installs on the correct phone. > > > > > > I know this method would soon or later be hacked but it's a better way > > > > > than current methods, since we still have those faulty Android version > > > > > that allow rooting.. > > > > > > -Jona --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
