[MOD][KERNEL] Kernel E2 4.2.2 stock 1.023/1.030 Debuggable & ADB Insecure

[t-minik]

Salut à tous.

 

Les bidouilleurs en rom stock auront peut être remarqué que le kernel d'origine du E2 ne permet pas d'utiliser pleinement ADB ou le debugger DDMS.

Voici donc de quoi résoudre le problème, un kernel Stock "décompressé", modifié et recompressé par mes soins pour le rendre plus souple pour les développeurs et autre bidouilleurs.

 

Ceci n'est d'aucune utilité pour ceux qui ne bricolent pas en profondeur leur téléphone android préféré ni, à priori, pour ceux qui utilisent les rom stock Déodexée de Spanish, Androlum de LeMatx et la MIUI V5 de Superdroid.

 

les bases sont les kernels du E2 Duo 4.2.2 des mises à jour 1.023 et 1.030 acer DOUBLE SIM.

je ne peux pas confirmer que ça fonctionne sur la version simple Sim ou les versions antérieures à la 1.023

 

Ne jouez donc pas trop avec le feu 

Si il vous faut un Boot.img spécial, assurez vous d'abord que c'est nécessaire (ADB ou DDMS non fonctionnel) envoyez moi un MP avec un lien pour récupérer votre boot.img original et les infos sur votre rom, je le ferais et le posterais ici.

 

Zip flashable en recovery.

 

 

Version 1.023 :

Boot_1023_E2_Duo_insecure

 

Boot_1023_E2_Duo_Original

 

 

Version 1.030 :

Boot_1030_E2_Duo_insecure

 

Boot_1030_E2_Duo_Original

 

joyeux débogage d'applis ou ADB push/pull sur la partition /system ;)

 

 

EDIT // à défaut on peut utiliser l'appli adbd insecure du fameux ChainFire, ça n'active pas le débogage DDMS mais permet d'utiliser l'adbd en vrai root shell.

Modifié 8 novembre 2013 par t-minik

[Lannig]

En fait, cela correspond-t-il au fait d'avoir un shell root direct par "adb shell" ou est-ce que je suis à coté de la plaque ?

[t-minik]

C'est ça, mais d'origine le root shell ne permet quand même pas de faire des adb push sur system par exemple.

[Lannig]

Je ne comprends pas pourquoi il faut un nouveau kernel pour cela ?

Normalement le fait qu'"adb shell" donne un shell root direct ne dépend que du default.prop dans le ramdisk de boot, non ?

Ou c'est une histoire de /system monté en r/o ?

[t-minik]

et pourtant depuis JellyBean il y a une modification du fichier binaire que l'on trouve dans le ramdisk.

celui présent dans le kernel du E2 est une version verrouillée, il ne va même pas voir dans le default.prop la valeur ro.secure=x, c'est dans sa chair numérique s'il est compilé verrouillé, il est verrouillé.

 

http://forum.xda-developers.com/showpost.php?p=33412504&postcount=4

 

je l'ai donc remplacé par une version non verrouillée et ai passage j'ai activé la fonction débogage.

 

essaie de faire un push /system/*** ou push /data/*** tu verras que même les traditionnels su ou mount -o remount,rw /system n'y font rien.

[Lannig]

Ah OK, tu me l'apprends. Merci.

Mon E2 n'est pas encore rooté (oui je sais, je sais... :) ) donc je ne pourrai pas faire le test, mais je le ferai sur une tablette JB 4.1.1 et 4.2.2, pour voir.

Mais ça n'explique toujours pas pourquoi le kernel recompilé ?

 

P.S. moi en général je fais un push vers la SD puis je déplace au bon endroit par des commandes shell... trop prudent pour faire un push direct vers /system :P

[t-minik]

ah oui, pourquoi la compile/décompile ...

 

à ce que j'ai compris l'adb se décompose en 3 parties, pour faire simple, tu me reprends si je dis des c*****ies

- client : celui qui envoie les commandes

- serveur : celui qui fait transiter les commandes

- daemon : celui qui exécute les commandes

 

le client on le trouve sur le PC

le serveur (binaire adb) on le trouve dans /system/bin

mais le deamon ... ou qu'il est le binaire adbd ? et bien lui il se cache dans le ramdisk ..

 

.

 

donc au final ces histoires d'adbd c'est surement au bon vouloir du constructeur.

Modifié 21 août 2013 par t-minik

[Lannig]

Hmmm... pour moi c'est le daemon adbd qui exécute directement les commandes qui viennent du client connecté (le PC .. sur lequel il y a aussi un daemon qui tourne d'ailleurs, ça transite par lui de la command adb.exe au terminal).

Enfin qui les passe à un shell en sous process, sauf pour certaines commandes (reboot...)

 

Mais euh... soit j'ai vraiment le cerveau lent ce soir, soit on ne se comprend pas : qu'est ce que cela a à voir avec le kernel ? le ramdisk, oui, je veux bien, mais le kernel ? tu veux dire que tu as recompilé les centaines de fichiers *.c pour regénérer un kernel ? pourquoi ? ou en fait tu ne parles que d'extraire le ramdisk, le modifier et le regénérer (en quel format je ne sais pas, sur mes tablettes A10 ou RK3066 c'est une archive cpio compressée, sur cette plateforme je ne connais pas)

Modifié 21 août 2013 par Lannig

[t-minik]

Ah voilà, c'est moi qui suis dans les choux tu vois.

C'est ça de pas être formé, on est pas précis des que c'est un peu technique.

En fait j'extrais le ramdisk et le décompresse (cpio aussi), change l'adbd pour un non sécurisé et recompresse le tout pas plus.

Désolé pour le malentendu.

[Lannig]

Aaaahhhhh OK ça y est je comprends.

Précis ou pas précis, peu importe. L'important c'est de l'avoir fait !

Merci à toi.

[t-minik]

Salut

Tu peux decompacter le ramdisk avec ça http://forum.xda-developers.com/showthread.php?t=2036528

Par contre decompiler le kernel à proprement parler c'est impossible.

Acer V370 & tapatalk

[sos_k91]

Vous me faites peur tout les deux...

Ou rêver ça dépend !

En vous lisant je me rends compte de mes faiblesse

Qu'est-ce que j'aimerais apprendre mais c'est long et fastidieux !

[t-minik]

Mise a jour avec le Kernel de la 1.030 ;)