The confusion arose because your previous post said "Replace the code
that downloads the certificate and encrypts it", in this post you're
talking about the "download/decrypt code", the first is a combination
of client code (download) and server code (encryption), the latter is
client-only code.
Referring to the download/decrypt replacement, the problem here is the
amount of time it would take to find where the download/decrypt code
resides in a compiled app, replace it, and recompile it. If you had
the original source code then yes, you could do a drop in replacement,
but if you had the source code you could easily strip out any
protection mechanism.
Seriously, try it on a compiled application, you'll find it takes you
a lot longer than you think, and longer than many crackers would be
willing to spend on a low-cost app.
Al.
On Jul 24, 8:02 am, Kaj Bjurman <kaj.bjur...@gmail.com> wrote:
> What didn't you understand in my last reply? It is trivial unless I
> have misunderstood something.
>
> I guess you got unit tests? Now take the code below. Replace the
> download/decrypt code in your unit tests with something like what I
> posted previously:
>
> Properties license = new Properties();
> license.put("p", TelephonyMgr.getLine1Number());
> license.put("d", Settings.System.getString(getContentResolver(),
> Settings.System.ANDROID_ID);
> license.put("e", aDateInTheFuture);
>
> Then run your unit tests again. Downloading won't fail since we have
> _replaced_ the download code, and no decryption would fail, since we
> aren't decrypting anything. We replaced that code as well. You don't
> even need to find all license check snippets that the developer has
> springled his code with, since they all will check against our valid
> license that we created above.
>
> I really can't believe that you don't see this. Please tell me in what
> way it fails given my description above.
>
> On 23 Juli, 23:07, Al Sutton <a...@funkyandroid.com> wrote:
>
> > We're going to update the page, but we'd kind of assumed it was an
> > obvious thing to check.
>
> > As for your latest idea, the download code downloads an encrypted file
> > so an error would be thrown during decryption which would show up
> > problmes with a spoof server or modified download code.
>
> > I think you get my point. You may think it's trivial to circumvent,
> > but when you get down to it there are various things we've done to
> > make it a lot trickier than an initial inspection would make you
> > believe, which is why you've still not come up with a reproducable
> > system for cracking it. Even if you did crack a version of an
> > application, the steps you took wouldn't be easily reproduced for
> > other applications and even other versions of the application if the
> > developer moved the decryption/test code around.
>
> > Al.
>
> > On Jul 23, 5:54 pm, Kaj Bjurman <kaj.bjur...@gmail.com> wrote:
>
> > > Shouldn't the code on the page say that in that case, and it's still
> > > very easy to spoof. Replace the code that downloads the certificate
> > > and encrypts it with code that does this:
>
> > > Properties license = new Properties();
> > > license.put("p", TelephonyMgr.getLine1Number());
> > > license.put("d", Settings.System.getString(getContentResolver(),
> > > Settings.System.ANDROID_ID);
> > > license.put("e", aDateInTheFuture);
> > > ..
> > > ..
>
> > > and so on.
>
> > > I think you get the point. We have enabled all settings. Remember I'm
> > > not a hacker/cracker and I have already shown you that it's very easy
> > > to crack your system. You aren't protecting the code. Applications
> > > will still be pirated very easy, and it's even possible to write an
> > > application that does it automatically.
> > > Users of the applications will also be very frustrated if they for
> > > some reason can't contact your license servers, so the value that you
> > > are adding is about zero.
>
> > > On Jul 23, 5:38 pm, Al Sutton <a...@funkyandroid.com> wrote:
>
> > > > And doing what you say should cause the application to operate as if
> > > > no license is present (i.e. demo mode).
>
> > > > The demo code is to cover all bases for all types of license where the
> > > > properties in the license are unknown. If you know that you'll be
> > > > using a specific license property your app should enter demo mode if
> > > > that property isn't present.
>
> > > > Al.
>
> > > > On Jul 23, 1:45 pm, Kaj Bjurman <kaj.bjur...@gmail.com> wrote:
>
> > > > > 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
>
> ...
>
> read more »
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
