Sorry to say, but there's a huge flaw in your examples. The snippet
below is taken from your link:
X509EncodedKeySpec keySpec = new X509EncodedKeySpec
(ANDAPPSTORE_APP_KEY);
KeyFactory factory = KeyFactory.getInstance("RSA");
PublicKey key = factory.generatePublic(keySpec);
Cipher cipher = Cipher.getInstance("RSA/ECB/PKCS1Padding");
cipher.init(Cipher.DECRYPT_MODE, key);
byte[] original = cipher.doFinal(LICENSE);
Properties props = new Properties();
props.clear();
ByteArrayInputStream bis = new ByteArrayInputStream(original);
try {
props.load(bis);
} finally {
bis.close();
}
Very few classes are using using e.g X509EncodedKeySpec, so it's very
easy to find all classes that are using it, and it's thus very easy to
find that section of code. Now replace all operands in the class file
with no operation instead, except this part:
Properties props = new Properties();
I.e. we are creating an empty license.
Now read all your other code snippets with this in mind.
E.g.
4(c)(i). Testing the phone number
String licensePhoneNumber = license.getProperty("p");
if( licensePhoneNumber != null ) { //Uh, uh. An empty license
returns null, we won't do any checks.
TelephonyManager TelephonyMgr =
(TelephonyManager) getSystemService(Context.TELEPHONY_SERVICE);
String devicePhoneNumber = TelephonyMgr.getLine1Number();
if(licensePhoneNumber.equals(devicePhoneNumber) == false) {
throw new RuntimeException("** Phone Number Check Failed **");
}
}
Remember that license now is an empty instance of Properties. The code
above will say that it is a valid license, and so will all of your
other tests as well.
On 23 Juli, 12:11, Al Sutton <a...@funkyandroid.com> wrote:
> We don't provice jars specifically for this reason.
>
> The code to decode a license is less than 15 lines long and uses
> standard java classes (i.e. nothing specific to the system or even to
> Android). The code to test license properties is less than 10 lines
> and again uses only java classes. You can see the code
> athttp://andappstore.com/AndroidApplications/licensing_4.jsp
>
> This means that each application would need to go through a full
> track, crack, and re-compile cycle (which as others have said is non-
> trivial and takes a fair amount of time), and developers are free to
> move the decrypt/test code around between versions of their app which
> would then require another full track, crack, and re-compile cycle
> before the new version could be made available, which, for a 99c app,
> is not going to be worth the effort for most crackers.
>
> This part is security by obscurity but it's layered in with secure
> cryptography in the license as an addition measure to make cracking
> harder than if we distributed pre-build jars which a cracker could
> swap out.
>
> Al.
>
> On Jul 23, 7:24 am, Kaj Bjurman <kaj.bjur...@gmail.com> wrote:
>
>
>
> > 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 <a...@funkyandroid.com> 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 <kaj.bjur...@gmail.com> 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 <mi...@ourmailbox.net> 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 <indodr...@gmail.com> 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 <medicalsou...@gmail.com>
> > > > > > 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 android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
