The signature and the cert are two different things -- the cert
contains the public key. If one could access the public key and sign
the network interactions with that then the system would be
insensitive to upgrades, vs the server having to keep track of every
signature ever released.
On Oct 3,
It is the binary certificates that the app is signed with. Hopefully you
are only signing with one cert, so there is only one Signature in the array.
As for how to use it -- well it is the raw cert. You can get it as the raw
binary data, or as encoded ASCII characters:
http://developer.android.c
I would really love a little guidance for how to use this. Maybe the
documentation team could write something up?
On Oct 2, 2:05 am, Dianne Hackborn wrote:
> On Fri, Oct 1, 2010 at 2:11 PM, DanH wrote:
> > What you really want to be sure of is that the application is signed
> > with your certif
That interface says "signatureS". How does one know which is which?
And is there a way to actually access the public certificate?
On Oct 2, 4:05 am, Dianne Hackborn wrote:
> On Fri, Oct 1, 2010 at 2:11 PM, DanH wrote:
> > What you really want to be sure of is that the application is signed
> >
On Fri, Oct 1, 2010 at 2:11 PM, DanH wrote:
> What you really want to be sure of is that the application is signed
> with your certificate. (Of course, I've not yet found a way to access
> that info.)
http://developer.android.com/reference/android/content/pm/PackageManager.html#getPackageInfo(
Well, until we figure out how to test against the signature, I used
the method for finding the crc here:
http://www.javafaq.nu/java-example-code-230.html
using getApplicationContext().getPackageCodePath() as the file name.
Fortunately, my app is 100% dependent on server data. So i just post
the
Yeah, that's essentially what I was saying.
On Oct 1, 4:45 pm, Kostya Vasilyev wrote:
> Regarding signature checking - I think having LVL check the signature
> against the correct one (known to Market) would be very useful in thwarting
> attacks on LVL based on modifying the application code.
>
>
Regarding signature checking - I think having LVL check the signature
against the correct one (known to Market) would be very useful in thwarting
attacks on LVL based on modifying the application code.
Pirates (hackers) don't have access to the developer's private key, so after
modifying the appli
In theory there's no need to checksum your apk file, unless you
suspect it's being dynamically modified. The apk was signed with your
private key, and can't be modified by anyone else without invalidating
the signature.
What you really want to be sure of is that the application is signed
with you
Might want to read about CRCs... to understand how it works:
http://en.wikipedia.org/wiki/Cyclic_redundancy_check
On Oct 1, 3:04 pm, Moto wrote:
> You do a CRC32 over the actual application file, *.apk. Open the file
> and get the byte stream. Now it's tricky to do that and than hardcore
> the
You do a CRC32 over the actual application file, *.apk. Open the file
and get the byte stream. Now it's tricky to do that and than hardcore
the CRC32 number in your app because it will change the value of the
app computed CRC32 value. That is why he suggested to store it in a
remote server...
Fo
11 matches
Mail list logo
