algorithme de jarsign.

Bonjour,

Je suis en train de jouer avec le format APK d'Android, et actuellement je tente d'écrire une application Delphi capable réassembler les fichiers extraits d'une application Android.

je suis donc parti d'une application source "Hello World" que je compile à la main suivant ces étapes

1) aapt pour créer R.java
2) javac pour compiler les sources Java
3) dx pour créer classes.dex
4) aapt pour assembler le fichier APK
5) keytool pour obtenir un keystore
6) jarsigner pour signer l'APK
7) ZipAlign pour aligner l'APK

en dézippant l'APK final je retrouve ces fichiers:

Code:

---

1 2 3 4 5 6 7

META-INF/MANIFEST.MF META-INF/ANDROiDT.SF META-INF/ANDROIDT.RSA AndroidManifest.xml classes.dex res/drawable/mylogo.png resources.arsc

---

je sais faire un fichier ZIP aligné
j'ai trouvé comme générer les deux premiers fichiers (lien)
avant de passer à la compilation du XML en binaire (et la construction du .dex et .arsc) je m'intéresse à la signature.

J'ai compris la structure du fichier RSA et du Keystore (grâce à ce lien), mais il me manque une information capitale : le calcule de la signature !

j'ai cru comprendre qu'il fallait faire un SHA256 du fichier ANDROIDT.SF et lui appliquer RSA ...c'est à dire calculer : X = (P^e mod n), mais si P est le hash et X la valeur recherchée, d'où proviennent e et n...du keystore j'imagine...mais je sèche un peu pour calculer ces foutus 128 octets manquants !

Comme le problème n'est pas vraiment lié à Delphi et/ou Android et que je ne veux pas une solution qui s'appuie sur une lib Java, du coup je pose la question ici à tout hasard :D

Merci

bon j'ai avancé sur la question mais je n'ai pas encore la solution

le keystore contient la clé privée au format DER identifié par l'OID 1.3.6.1.4.1.42.2.17.1.1
dans ses données on trouve, toujours au format DER, l'OID 1.2.840.113549.1.1.1
et dans ses données on trouve 9 nombres qui forme la RSAPrivateKey

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

RSAPrivateKey ::= SEQUENCE { version Version, -- 0 modulus INTEGER, -- n publicExponent INTEGER, -- e privateExponent INTEGER, -- d prime1 INTEGER, -- p prime2 INTEGER, -- q exponent1 INTEGER, -- d mod (p-1) exponent2 INTEGER, -- d mod (q-1) coefficient INTEGER, -- (inverse of q) mod p otherPrimeInfos OtherPrimeInfos OPTIONAL }

---

cool, sauf que "(SHA256(ANDROiDT.SF) ^ e) mod d" ne me donne pas le résultat attendu :(

Salut,

Le calcul dans RSA ne se fait jamais sur la donnees de base (ca expose a tout un tas de vulnerabilites), mais sur la donnees + padding (AOEP ou PKCSv1.5). Il faut que tu saches quel algo de padding est utilise, et appliquer ca avant de calculer RSA.
Plus generalement, utilise une lib si tu peux, ca t'evitera pas mal de problemes.

j'ai enfin trouvé le site qui donne des explications pratiques claires sur le sujet :)

http://www.di-mgt.com.au/rsa_alg.html#signpkcs1

le hash est donc en effet encapsulé en DER avec un padding sur 128 octets !