[Info][Pareri] Thl T100

[Bokonon]

Interessa anche a Me , e penso a tutti i possessori di Android .

Ok, ma prima di iniziare serve una lunga e interessante premessa.
La prima è sapere cos'è l'init.rc e la directory /system/etc/init.d/
Per comodità riquoto un mio post recente.

Sostanzialmente si. Linux arriva già con una serie di scripts nella init.d che (come dici tu) permettono di attivare e stoppare determinati servizi.
In android non esiste questo servizio di default. Solo i boot customizzati (come tutti i boot di cyanogenmod per esempio) attivano questo servizio. Schematicamente funziona così:
A) dentro il boot ci sta il kernel e i vari moduli che governano tutto l'hardware del pc
B) al boot il sistema legge (fra gli altri) il file init.rc che contiene tutte le definizioni base per il funzionamento di ogni singolo servizio (come il bluetooth ad esempio)
C) init.rc è dentro il boot e poichè il boot non può essere montato, il file non può essere modificato (anche se ho letto che qualcuno attiva l'init.rc senza modificare il boot...francamente non ho approfondito quindi non so come fanno)
D) volendo è possibile decompilare il boot e customizzarlo in questo modo --> xda-developers - View Single Post - [GUIDE] How To Add Init.d Support to Your Kernel & Rom
E) una volta modificato e flashato il boot, basta creare la directory /system/etc/init.d/ e piazzare gli scripts che verranno letti al boot
F) attraverso gli script uno può modificare a piacimento le configurazioni hardware di default, per esempio overcloccare la CPU creando un apposito script

Ok, suona tutto molto bello ma è ovviamente pericoloso persino se uno sa cosa sta facendo. Inoltre questa operazione andrebbe rifatta ogni volta che si aggiorna il firmware con un nuovo boot aggiornato.

A proposito, al punto C) mi chiedevo come potessero attivare la init.d senza modificare la boot.img...beh ho scoperto che esiste questa Kitchen da usare sotto Linux e che fa anche questo --> xda-developers - View Single Post - [KITCHEN] ArchiKitchen - Android Kitchen (WIP) [Linux]
Ma il binario "debuggerd" non esiste nella ROM del T100S (o del mio, o del W200S o del T11), quindi non vedo come possa essere utlizzato questo metodo. L'idea di sfruttare un binario che viene eseguito al boot è comunque un'alternativa furbaal posto di eseguire uno script nella init.d. Vedremo un'idea analoga fra poco.

Sapete cos'è il file "install-recovery.sh"? Probabilmente qualcuno di voi lo sa...io non avevo la più pallida idea dato che ho posseduto solo uno smartphone finora. Ma chi ha avuto un Samsung o un Google Nexus sicuramente ci si sarà imbattutto. Fra le tante cose che i brand fanno per rendere impossibile la vita agli smanettoni (e ne ho lette di allucinanti per gli americani che comprano i cell. dai vari carriers!) questa è davvero divertente. In pratica hanno inserito un bash file nella /system/etc/ che esegue una verifica ogni volta che si reboota il cell.
Quale? Controlla se uno ha flashato una custom recovery e se il check è positivo fa partire una routine in pascal /system/recovery-from-boot.p che riflasha la stock recovery! Infatti è pieno di post begli anni di gente che impazziva perchè si ritrovava sempre al punto di partenza
In realtà è facilissimo rimuovere questa scocciatura ma non è questo il punto. Ciò che interessa è che il file install-recovery.sh da la possibilità di far girare un comando al boot esattamente come uno script nella init.d. E quindi, una volta ripulito, può essere sfruttato per fare cose altrimenti non possibili (una sorta di contrappasso: è stato creato per rendere difficile la vita e invece può essere sfruttato per il root come vederemo). Dopo aver scritto tutto questo, sappiate che la THL (come molti altri cinafonini) non ha mai inserito quella rottura di scatole e quindi non è presente questo potenziale "trucco".

Riassumendo il preambolo, se uno vuole far girare "qualcosa" al boot deve avere.
A) o un boot con l'init.rc modificato per attivare la init.d (e i boot della THL non ce l'hanno attivo di default)
B) oppure quel file binario di cui ho parlato, ma sappiamo che non c'è (l'ho cercato nella system del T100s e non l'ho trovato)
C) o infine usando il bash "install-recovery.sh", ma anche questo non c'è nei THL

Tenete a mente questi passaggi perchè nel prosismo post vi sarà più chiaro il preambolo.

[Bokonon]

Ok, riprendiamo dal post precedente.
Perchè ci interessa tutto questo?
La risposta è che finora nessun smartphone con chip MTK ha mai avuto l'upgrade a kitkat (che io sappia) e (pare) che presto la cosa cambierà (come ho scritto in precedenza).
Per rispondere pienamente alla domanda in grasetto è necessario sapere che dalla versione 4.3 di Android sono stati apportate delle modifiche enormi in termini di sicurezza --> Security Enhancements in Android 4.3 | Android Developers
In particolare sono stati rimossi i permessi setuid e setgid (--> setuid e setgid - Wikipedia ) che erano -e sono- esattamente i permessi assegnati al binary SU (quello che da l'accesso al root).
Inoltre hanno inserito SELinux --> Security-Enhanced Linux - Wikipedia , sviluppato dalla NSA americana negli anni 90 e inserito in Linux dal 2000 (se non ricordo male). Inoltre SELinux è stato inserito in Enforce Mode: cito le parole di uno sviluppatore.

In Android 4.4, SELinux has moved from running in permissive mode (which simply logs failures), into enforcing mode. SELinux, which was introduced in Android 4.3, is a mandatory access control system built into the Linux kernel, in order to help enforce the existing access control rights (i.e.permissions), and to attempt to prevent privilege escalation attacks (i.e. an app trying to gain root access on your device).

Tradotto:
In Android 4.4 (kitkat), SELinux è passato a girare dal permissive mode (che si limita a loggare i fallimenti) all'enforcind mode. SELinux, che è stato introdotto con Android 4.3, controlla il sistema tramite il mandatory access control (MAC) inserito nel kernel di linux per aiutare a rafforzare i diritti di controllo delle app (ovvero i permessi) e per tentare di impedire attacchi per scalare i privilegi (ovvero, un'app che tenta di ottenere lo stato di root sul vostro terminale).

Tutto ciò è molto bello in termini di sicurezza aggiuntiva...ma significa anche che per ottenere il root non è più sufficiente infilare 2 files nei posti appropriati e assegnare loro i privilegi. Con kitkat, verrebbero semplicemente ignorati in quanto non avrebbero uno straccio permesso di alto livello.

Ed eccoci al root con SuperSU via recovery...
Lo script in breve prende i binary e la .apk e installa tutto dove deve andare settando i permessi...ma poi installa anche il binario demonsu il cui scopo è essere lanciato al boot e trasformarsi in un demone Demone (informatica) - Wikipedia per potersi slegare dal sistema e restare residente in memoria (come un virus o un servizio autorizzato) e assegnare i necessari diritti per far funzionare il root.

SELinux can potentially control which activities a system allows each user, process and daemon, with very precise specifications. However, it is mostly used to confine daemons

Quindi il demone deve partire al boot affinchè possa ingannare il sistema e acquisire uno status di alto livello.
Come fare? Ma è semplice! Basta creare ed inserire un bash file nella init.d con il comando /system/xbin/daemonsu --auto-daemon &...ed è esattamente quello che crea lo .zip
Ma cosa accade se un boot non supporta init.d?
Facile, lo zip cambia anche la install-recovery.sh e inserisce lo stesso comando. Anche se il demone partisse due volte, solo il primo resterebbe residente.

E adesso arriviamo al punto: cosa succede se una ROM non ha il supporto init.d e nemmeno la install-recovery.sh?
Bella domanda, lo so...perchè l'ho posta a quelli di SuperSU ma non mi hanno risposto.
E' evidente che se non parte il demone, il root non funziona.
Come ho scritto sopra, le ROM THL non sono solo degli Android diversi (ma questo non dovrebbe inficiare nulla credo) ma non hanno nessuno dei due metodi per caricare il demone al boot.
L'unica soluzione sarà che qualcuno si prenda la briga scaricare il nuovo firmware, inserisca il supporto init.d (e magari già che c'è rimuova bloatware e installi roba utile) e inserisca tutti i file necessari per il root. Sicuramente accadrà, non abbiate timore. Io invece mi sa che dovrò fare da solo col W200.

Tutto questo vale se:
A) effettivamente non ci sono altri metodi per far partire il demone al boot...e io non ho visti altri finora
B) se la THL rilascierà un boot che non supporta init.d (probabile)
C) non escogiteranno metodi diversi

In generale, ogni ROM è a se stante. Per esempio ho letto negli Xperia con kitkat hanno tolto SELinux (chissà perchè!?!).
Infine, una volta rootati, sarà possibile cambiare lo status di SELinux da Enforce a Permissive usando un'app come questa https://play.google.com/store/apps/d...mrbimc.selinux oppure un modulo Xposed come Wanam (ma non è il vostro caso per le ragioni che sapete).
Fine.
Interessante no?

[Amianto]

È molto interessante, mi hai aiutato molto nel capire come mai questo telefono fosse poco supportato in generale.
La prossima volta che dovrò comprare un cellulare dovrò tenere a mente molte più cose.

[page64]

Molto interessante ma questo significa anche che rootare (in generale ... ) da KK in poi sarà più difficile e magari lo sarà di più per i processori MTK ?

[asproleo]

Confermo con soddisfazione che la stock deodexata ha il led di notifica abilitato di serie e funziona benissimo, è più luminoso che utilizzando l'app di xda.

Ti funziona anche con il calendario? Nel mio funziona tutto (telefonate, SMS, e-mail, WhtsApp, etc.) ad esclusione del calendario

[Bokonon]

Molto interessante ma questo significa anche che rootare (in generale ... ) da KK in poi sarà più difficile e magari lo sarà di più per i processori MTK ?

Se sono riusciti a rootare un Samsung con la protezione KNOX, non avranno problemi a rilasciare un custom boot.
Piuttosto significa che appena uscirà la nuova stock ROM con kitkat (quando mai uscirà...) se uno la flasha non riuscirà a rootarla con i metodi conosciuti. Tanto varrà aspettare un poco che esca un aggiornamento in formato .zip con tutto già sistemato.

[page64]

Se sono riusciti a rootare un Samsung con la protezione KNOX, non avranno problemi a rilasciare un custom boot.
Piuttosto significa che appena uscirà la nuova stock ROM con kitkat (quando mai uscirà...) se uno la flasha non riuscirà a rootarla con i metodi conosciuti. Tanto varrà aspettare un poco che esca un aggiornamento in formato .zip con tutto già sistemato.

Perfetto :-)

Comunque le uniche due app che mi danno problemi con la Stock Deodex del 25-2-2014 sono GPS FIX e Forsquare , la prima mi dà errore se la voglio aprire ,la seconda solo se voglio segnalare la mia posizione , per il resto funziona .

[Bokonon]

Per chi ha la stock (ma anche chi ha una custom ROM ed è curioso), c'è un metodo piuttosto semplice (per chi si sa muovere un poco) per sapere se la init.d è attiva.
Basta creare la directory system/etc/init.d e avere la busybox installata correttamente.
Poi basta scaricare questo .zip (http://forum.xda-developers.com/atta...mentid=1612958) e tirare fuori il file (è un file di testo con dei comandi) e piazzarlo nella init.d dandogli tutti i permessi (rwxrwxrwx) e infine rebootare il cell.
Lo script non fa altro che creare un file di testo chiamato test.log dentro la /data quindi se dopo il boot trovate questo file, allora init.d è attiva.

************************************************

C'è una cosa che mi piacerebbe sapere da chi ha la stock installata, rootata e infine ha un terminale (tipo terminal emulator che si trova gratuitamente nello store).
Se qualcuno è così gentile da aprire il terminale e scrivere:

su (dare INVIO)
cat /proc/dumchar_info > sdcard/rutto.txt (dare INVIO)

A questo punto dovrebbe prendere il file di testo rutto.txt creato nella root della SDCARD e inviarmelo oppure pubblicarlo qua con un copia e incolla.

[cybermod]

Domano studio tutto ma ormai sono, e mi duole ammetterlo, in balia della confusione. Ad ogni modo bokonon, ripristinato e non arrivato l'ultimo framework, tutto si è sistemato. Diversamente appaiono i crash.... Quindi, volente o nolente, xeposed mi da rogne. Che prove posso farti?
Secondo, vista e dimostrata la tua propensione allo spiegare, vorrei provare a ringraziarti dandoti le informazioni che vorresti. Se mi indichi quale ROM stock più ti aggrada (anche per non sbagliare) domani gli dedicherò il tempo necessario per farti questa prova. Attendo tue

[page64]

Per chi ha la stock (ma anche chi ha una custom ROM ed è curioso), c'è un metodo piuttosto semplice (per chi si sa muovere un poco) per sapere se la init.d è attiva.
Basta creare la directory system/etc/init.d e avere la busybox installata correttamente.
Poi basta scaricare questo .zip (http://forum.xda-developers.com/atta...mentid=1612958) e tirare fuori il file (è un file di testo con dei comandi) e piazzarlo nella init.d dandogli tutti i permessi (rwxrwxrwx) e infine rebootare il cell.
Lo script non fa altro che creare un file di testo chiamato test.log dentro la /data quindi se dopo il boot trovate questo file, allora init.d è attiva.

************************************************

C'è una cosa che mi piacerebbe sapere da chi ha la stock installata, rootata e infine ha un terminale (tipo terminal emulator che si trova gratuitamente nello store).
Se qualcuno è così gentile da aprire il terminale e scrivere:

su (dare INVIO)
cat /proc/dumchar_info > sdcard/rutto.txt (dare INVIO)

A questo punto dovrebbe prendere il file di testo rutto.txt creato nella root della SDCARD e inviarmelo oppure pubblicarlo qua con un copia e incolla.

Sulla ROM Deodex 25-02-2014 non crea il test.log ... .