Sviluppo e hacking smartphone mediatek

[ilmich]

Ciao a tutti, so che questo post esula parecchio dai soliti argomenti affrontati su questo forum, e di sicuro slackware è giusto il sistema host di riferimento. Ma visto che qualcuno puo' esserne interessato ho deciso di aprire questo topic relativo agli smartphone con soc mediatek.

L'idea del topic è quella di condividere informazioni e risorse utili per i possessori di questi device.

[rik70]

ma quindi pure a te spflash non funziona su slackware..

A me non funziona perché nonostante scarichi il pacchetto per linux 32-bit il binario è a 64-bit

Codice: Seleziona tutto

$ ./flash_tool.sh 
./flash_tool.sh: line 13: ~/[...]/SP_Flash_Tool_Linux_v5.1520.00.100/./flash_tool: cannot execute binary file

$ file ./flash_tool
./flash_tool: ELF 64-bit LSB  executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), BuildID[sha1]=4f33fd6864cc5905f3e6736d00cf2d07122d39d9, not stripped

Quindi mi tocca per forza passare per il cascione con XP.

[ilmich]

A me non funziona perché nonostante scarichi il pacchetto per linux 32-bit il binario è a 64-bit

che dal mio modo di vedere sarebbe stato meglio visto che a me invece si avvia (io ho però un picci a 64bit) ma mi da un errore che non sono riuscito a capire

Ti volevo chiedere una cosa.. che versione di twrp stai utilizzando!?!? Dove l'hai recuperata!?!? Te lo chiedo perchè ho compilato l'ultima versione 'stabile'.. la 3.0 ma ho avuto un sacco di problemi con il reboot(sostanzialmente non lo faceva). Alla fine spulciando il sorgente ho visto che potevo richiamare degli script e cosi' ho fatto
A te risulta?!? Se spacchetti il ramdisk della tua recovery trovi anche tu questi file!? Oramai è piu' una curiosità che altro visto che ho risolto, però non l'ho visto fare per nessun altro smartphone.

[rik70]

Versione 2.8 e qualche cosa. La trovi qui.

No, non c'è nessuno script per il poweroff. Da quello che ho capito fanno tutto da init.rc. Comunque queste recovery "cucinate" da terzi, anche se fanno il loro lavoro, non sono perfette. Nelle 2 che ho provato appaiono messaggi tipo "non posso s/montare /misc|/emmc" e simili. O è normale?

Per compilarmela devo tirare giù tutto il repo di CM?

[ilmich]

No, non c'è nessuno script per il poweroff. Da quello che ho capito fanno tutto da init.rc.

sni, in realtà mi sembra di aver capito che vengono fatte delle chiamate verso il kernel.. comunque a sto punto mi sa che ho qualche problema in questo senso.

Comunque queste recovery "cucinate" da terzi, anche se fanno il loro lavoro, non sono perfette.

è questo il motivo per il quale io ho iniziato quest'avventura/incubo. Tieni conto anche che, ad esempio, sul mio smartphone oltre alla sd esterna, ne sta una emulata. L'emulazione avviene mappando la directory /data/media con i percorsi canonici. Se non correttamente compilate le recovery, quando viene richiesto il wipe, formattano la partizione /data con la conseguente cancellazione di questo tipo di storage, invece di fare una semplice rm ignorando quel percorso.

Nelle 2 che ho provato appaiono messaggi tipo "non posso s/montare /misc|/emmc" e simili. O è normale?

si, o meglio alcune recovery cercano la directory /misc per salvarsi alcune cose. Purtorppo sul mio mediatek la partizione misc è di tipo emmc e di conseguenza non è montabile tramite fstab. Questo perchè questo tipo di partizioni non hanno un filesystem vero e proprio e vengono lette scritte come fossero dei device a caratteri... io di fatto la ignoro completamente.

Per compilare solo la recovery segui questa guida. Io ho il source tree completo, ma all'interno della guida trovi i riferimenti ad un repository ridotto. Fai attenzione perchè mi sembra di aver capito che tu abbia un sistema a 32bit. Quando inizializzi il repository vengono scaricati anche delle toolchain precompilate e qualcuna di queste mi sa che è a 64bit. Non so se sia possibile usarne altre(credo di si).. a me non è servito

[ilmich]

ritornando al discorso della partizione misc.. guardando il sorgente della recovery che dovresti avere anche tu, questo è il pezzo che in avvio monta la partizione /misc

Codice: Seleziona tutto

TWPartition* misc = PartitionManager.Find_Partition_By_Path("/misc");
		if (misc != NULL) {
			if (misc->Current_File_System == "emmc") {
				set_misc_device("emmc", misc->Actual_Block_Device.c_str());
			} else if (misc->Current_File_System == "mtd") {
				set_misc_device("mtd", misc->MTD_Name.c_str());
			} else {
				LOGERR("Unknown file system for /misc\n");
			}
		}

sostanzialmente dovresti avere un fstab con una riga tipo cosi'

Codice: Seleziona tutto

/misc  emmc  /dev/misc

[rik70]

Allora, tanta carne al fuoco. Innanzitutto grazie

Molto di quello che hai scritto erano dubbi che mi volevo togliere e quindi chiedo.
Inizio da qui:

Tieni conto anche che, ad esempio, sul mio smartphone oltre alla sd esterna, ne sta una emulata.

Da dove lo vedi? Qui dando un mount da `adb shell` vedo questo:

Codice: Seleziona tutto

tmpfs /storage/emulated tmpfs rw,seclabel,relatime,mode=755,uid=1023,gid=1023 0 0

/dev/fuse /mnt/shell/emulated fuse rw,nosuid,nodev,relatime,user_id=1023,group_id=1023,default_permissions,allow_other 0 0

Il primo mi sembra innocuo, mentre il secondo....

Per compilare solo la recovery segui questa guida.

Sì sì, ero già sul pezzo da tempo ^^: ma come mai raccomandano di compilare con Omni 4.4 o 5.0? Tu hai il tree di CM e hai rimpiazzato la parte recovery con quella omniroom come suggerito nella guida?

Quando inizializzi il repository vengono scaricati anche delle toolchain precompilate e qualcuna di queste mi sa che è a 64bit.

Ti riferisci al repo ridotto o...? Comunque l'hw che voglio usare per la compilazione è un portatile dual core intel. Non ricordo se è a 64-bit e su c'è una archlinux-32bit, ma non ho problemi a rasarla per metterci la slack a 64bit. Se riesco sto fine settimana lo tolgo dalla paraffina

Chiudo con l'ultima domanda e poi ti rispondo sulla faccenda fstab in un altro post:
boot.img in pratica è la root, giusto? Se io apro una shell adb e do

Codice: Seleziona tutto

ls /

vedo il contenuto del ramdisk di boot.img?
Se è corretto, se io modifico il file default.prop - ho visto che c'è qualche hack per la videocamera - e riflasho l'immagine di boot cambia qualcosa o le modifiche apportate vengono ignorate?

Ah, poi ti devo chiedere una cosa sull'immagine di sistema android, ma anche questo lo faccio a parte.

[ilmich]

Da dove lo vedi? Qui dando un mount da `adb shell` vedo questo:

Codice: Seleziona tutto

tmpfs /storage/emulated tmpfs rw,seclabel,relatime,mode=755,uid=1023,gid=1023 0 0

/dev/fuse /mnt/shell/emulated fuse rw,nosuid,nodev,relatime,user_id=1023,group_id=1023,default_permissions,allow_other 0 0

Il primo mi sembra innocuo, mentre il secondo....

lo vedi nell'init.rc dove vengono creati dei collegamenti simbolici alla directory /data/media verso i percorsi che poi ti ritrovi montati. in teoria è strano che siano montati tramite fuse. So che per le sdcard esterne viene fatto un mount particolare per consentire la gestione dei permessi su un filesystem fat32. Comunque per maggiori info leggi qui.

, tieni presente che sono anche io abbastanza 'inesperto'

Per compilare solo la recovery segui questa guida.

Sì sì, ero già sul pezzo da tempo ^^: ma come mai raccomandano di compilare con Omni 4.4 o 5.0? Tu hai il tree di CM e hai rimpiazzato la parte recovery con quella omniroom come suggerito nella guida?

considera che questa guida è ancora valida, ma è di un po' di tempo fa quando la twrp era la recovery ufficiale di questa custom rom. Io ho scaricato il sorgente della cyanogenmod nella sua interezza eppoi ho sostituito la recovery originale con la twrp.

Chiudo con l'ultima domanda e poi ti rispondo sulla faccenda fstab in un altro post:
boot.img in pratica è la root, giusto? Se io apro una shell adb e do

Codice: Seleziona tutto

ls /

vedo il contenuto del ramdisk di boot.img?
Se è corretto, se io modifico il file default.prop - ho visto che c'è qualche hack per la videocamera - e riflasho l'immagine di boot cambia qualcosa o le modifiche apportate vengono ignorate?

Ah, poi ti devo chiedere una cosa sull'immagine di sistema android, ma anche questo lo faccio a parte.

Si esatto... se fai una qualsiasi modifica al ramdisk presente nel bootimg e la riflashi le vedi applicate al successivo riavvio.

[rik70]

Per la faccenda del 'fuse':
ho trovato un file 'init.fuse.rc' nella ramdisk dell'immagine di boot.

Dacci(dateci) uno sguardo:
http://pastebin.com/uwuKrq9F

A me sembra che si limiti a creare delle directory e dei link simbolici che trovano riscontro nell'output del mount che ho postato sopra, e infine a lanciare dei demoni/servizi 'fuse'. Credo abbia a che fare con quanto descritto qui.

Tu hai qualcosa di simile?

[ilmich]

A me sembra che si limiti a creare delle directory e dei link simbolici che trovano riscontro nell'output del mount che ho postato sopra, e infine a lanciare dei demoni/servizi 'fuse'. Credo abbia a che fare con quanto descritto qui.

Il mio init rc della stock è molto simile (anche se il tuo è molto piu' ordinato e commentato)
Quindi anche tu hai una scheda emulata, per questo assicurati che la recovery quando faccia il wipe dei dati non elimini la directory /data/media.

[rik70]

Quindi anche tu hai una scheda emulata, per questo assicurati che la recovery quando faccia il wipe dei dati non elimini la directory /data/media.

Oh ca....volo.
Praticamente /data/media è come se fosse la sdcard interna. Ho trovato questo riguardante proprio la TWRP:
https://twrp.me/faq/datamedia.html

Che dici: ne discutiamo? Perché io a comprendonio inizio a perdere colpi e non vorrei fare ca..volate. Vedo che c'entra in qualche modo anche l'accesso multiutente allo storage.

Edit:
e infatti ora grazie alla recovery twrp riesco ad accedere all'archivio interno via MTP da slackware:



Sbaglio o l'articolo dice che le TWRP recenti quella directory non la toccano?

[ilmich]

Sbaglio o l'articolo dice che le TWRP recenti quella directory non la toccano?

direi proprio di si.. tra l'altro leggendo quest'articolo ho capito perchè sull'altro telefono che ho.. che ha solo lo storage interno... non è possibile montarlo come hard disk esterno.. perchè essendo emulata sistemi tipo windows chiederebbero di formattarlo perchè non sono in grado di montare l'ext4 e non c'avevo mai pensato

grazie perchè questa disccusione mi sta tornando molto utile.. io sto facendo tutto un po' da zero e lungi da me essere un esperto

EDIT: comunque nn per toglierti la soddisfazione di farlo in autonomia, ma visto che abbiamo lo stesso soc posso caricare la recovery che ho compilato sul mio spazio github, se ti interessa mi potresti aiutare a testarla.. non ho ancora gestito la scheda sd esterna e l'usb-otg (perchè non ho a portata di mano un cavo per i test)

RI-EDIT: se hai fatto il root del telefono puoi usare i MobileUncle Mtk Tool per flashare la recovery (e altro) direttamente a sistema operativo acceso

[rik70]

Allora, vediamo di capire come vanno le cose in concreto.

Qui ho incollato il log della recovery (/tmp/recovery.log).

A occhio mi sembra tutto a posto per quanto riguarda la faccenda dei dati descritta nell'articolo:

Codice: Seleziona tutto

I:Setting up '/data' as data/media emulated storage.
I:Created '/sdcard' folder.
I:mount '/data/media' '/sdcard' process ended with RC=0
I:mount '/data/media/0' '/sdcard' process ended with RC=0

Codice: Seleziona tutto

Partition Logs:

/data | /dev/block/mmcblk0p7 | Size: 12988MB Used: 698MB Free: 11905MB Backup Size: 698MB
   Flags: Can_Be_Mounted Can_Be_Wiped Can_Be_Backed_Up Wipe_During_Factory_Reset Wipe_Available_in_GUI IsPresent Has_Data_Media Can_Encrypt_Backup Use_Userdata_Encryption Is_Storage Is_Settings_Storage
   Symlink_Path: /data/media/0
   Symlink_Mount_Point: /sdcard
   Primary_Block_Device: /dev/block/mmcblk0p7
   Display_Name: Data
   Storage_Name: Internal Storage
   Backup_Path: /data
   Backup_Name: data
   Backup_Display_Name: Data
   Storage_Path: /data/media/0
   Current_File_System: ext4
   Fstab_File_System: ext4
   Backup_Method: files
   MTP_Storage_ID: 65537

(da notare che il backup viene fatto col comando 'cp' e non 'dd'.

Questo è il twrp.fstab che, come mostra il log, va a sovrascrivere /etc/recovery.fstab:

Codice: Seleziona tutto

# mount point	fstype		device			[device2]

/boot           emmc            /dev/bootimg
/cache          ext4            /emmc@cache
/data           ext4            /emmc@usrdata
/misc           emmc            /dev/misc
/recovery       emmc            /dev/recovery           flags=display="Recovery";backup=1
/system         ext4            /emmc@android
# /preload        ext4            /emmc@preload           flags=display="Preload";backup=1;wipeingui
/external_sd    vfat            /dev/block/mmcblk1p1    flags=display="External SD-card";storage;wipeingui;removable
# /usb-otg        vfat            /dev/block/sda1 /dev/block/sda       flags=display="USB-OTG";storage;wipeingui;removable
/nvram          emmc            /dev/nvram              flags=display="Nvram";backup=1
/uboot          emmc            /dev/uboot              flags=display="Uboot";backup=1
/logo           emmc            /dev/logo               flags=display="Boot Logo";backup=1

E qui balzano agli occhi alcune cose interessanti:
- la parte USB-OTG è commentata;
- idem per il preloader;
- la presenza dei flag 'wipeingui' che permette di "giocare" su cosa vogliamo che sia resettato/cancellato.

In ultimo la faccenda del /dev/misc.
Perché lo mettono? Nello schema partizioni del mio dispositivo vedo questo:

Codice: Seleziona tutto

Part_Name	Size	StartAddr	Type	MapTo	Region
preloader    0x0000000000040000   0x0000000000000000   2   /dev/misc-sd     BOOT_1

[...]
Part_Name:Partition name you should open;
Size:size of partition
StartAddr:Start Address of partition;
Type:Type of partition(MTD=1,EMMC=2)
MapTo:actual device you operate

Quindi '/dev/misc-sd' anziché '/dev/misc' e filesystem 'emmc'(e torna). Sarà questa la causa di quegli errori di cui dicevo sopra? Ma poi: perché tentare di montare il preloader?

visto che abbiamo lo stesso soc posso caricare la recovery che ho compilato sul mio spazio github, se ti interessa mi potresti aiutare a testarla.

Bho sì, non ci sono problemi ma funzionerà col tuo kernel? C'è un modo per testarla anche senza flashing: fastboot. Hai provato? Comunque fammi sapere prima cosa pensi sul poema che ho appena scritto, perché ho visto su github il tuo recovery.fstab e non mi torna l'ultima riga - nel senso che non la capisco.

RI-EDIT: se hai fatto il root del telefono

Il "bello" è che è già rootato anche se non ho alcuna app che gestisce le autorizzazioni. Mi basta attivare l'accesso root su simple-explorer e ho il pieno controllo. Oppure anche via adb shell con '/system/xbin/su'.

[rik70]

Allora giusto 2 righe: sono su con i sorgenti di cm-11.0 e ho iniziato a "preparare" l'ambiente.

Ho scoperto per caso come fare ad utilizzare i tool "canonici" per scompattare il boot.img "non convenzionale" di Mediatek. In pratica bisogna saltare i primi 512 byte dell'archivio gzip contenente l'initram.
Ho quindi modificato questa stringa di 'build/tools/device/mkvendor.sh'

Codice: Seleziona tutto

gunzip -c ../$BOOTIMAGEFILE-ramdisk.gz | cpio -i

in:

Codice: Seleziona tutto

dd if=../$BOOTIMAGEFILE-ramdisk.gz bs=512 skip=1 | gunzip -c | cpio -i

Ora lanciando

Codice: Seleziona tutto

build/tools/device/mkvendor.sh [vendor] [codename] [file_boot.img]

vengono create le directory che ci si attende e questi file:

Codice: Seleziona tutto

├── AndroidBoard.mk
├── AndroidProducts.mk
├── BoardConfig.mk
├── cm.mk
├── device_a806.mk
├── kernel
├── recovery.fstab
└── system.prop

Ho alcuni dubbi sul contenuto di BoardConfig.mk:
1)

Codice: Seleziona tutto

# fix this up by examining /proc/mtd on a running device
BOARD_BOOTIMAGE_PARTITION_SIZE := 0x105c0000
BOARD_RECOVERYIMAGE_PARTITION_SIZE := 0x105c0000
BOARD_SYSTEMIMAGE_PARTITION_SIZE := 0x105c0000
BOARD_USERDATAIMAGE_PARTITION_SIZE := 0x105c0000

ovviamente quei valori vanno sostituiti, ma sempre in notazione esadecimale?
Non è un problema, dato che si possono leggere nel file '/proc/dumchar_info', ma giusto per sapere.

2)

Codice: Seleziona tutto

BOARD_FLASH_BLOCK_SIZE := 131072

da dove lo prendi quel valore?

Dènchiu.

[ilmich]

rieccomi, allora riguardo al discorso della partizione /dev/misc ti allego un articolo che finalmente mi ha tolto un po' di dubbi

http://donandroid.com/android-partitions-sdcard-boot-recovery-cache-data-system-misc-1043

Quindi '/dev/misc-sd' anziché '/dev/misc' e filesystem 'emmc'(e torna). Sarà questa la causa di quegli errori di cui dicevo sopra? Ma poi: perché tentare di montare il preloader?

io ho la tua stessa situazione, nel senso che anche io ho un device /dev/misc-sd che corrisponde al preloader, ma ho anche /dev/misc infatti sono riuscito a farla rilevare correttamente.

ovviamente quei valori vanno sostituiti, ma sempre in notazione esadecimale?
Non è un problema, dato che si possono leggere nel file '/proc/dumchar_info', ma giusto per sapere.

io, sarà pure che utilizzo il ramo della cm-12.1 e non la cm-11.1 le ho in decimale. Comunque penso sia indifferente, segui lo standard che hai trovato, queste misure dovrebbero servire fra le altre cose a bloccare la build se, ad esempio, la recovery che viene fuori andrebbe a sforare la dimensione della partizione

da dove lo prendi quel valore?

bella domanda guardando un po' i device tree di altri smartphone ho trovato la formuletta BOARD_KERNEL_PAGESIZE * 64.. che nel nostro caso coincide con il valore che viene impostato (deduco che lo faccia lo script visto che la variabile BOARD_KERNEL_PAGESIZE la trovi sempre nel BoardConfig.mk)

Ho scoperto per caso come fare ad utilizzare i tool "canonici" per scompattare il boot.img "non convenzionale" di Mediatek. In pratica bisogna saltare i primi 512 byte dell'archivio gzip contenente l'initram.

non male

Io sono riuscito ad ottenere una recovery twrp quasi perfetta (il quasi è d'obbligo perchè alcune scelte che ho fatto sono soggettive) e la uploaderò sul mio spazio github. Pensandoci bene se la volessi usare dovresti esploderla e inserire il tuo kernel(perchè il mio potrebbe crearti dei problemi col touch).. oltre a verificare per bene che le partizioni che ho io siano compatibili.. inoltre io ho dovuto fare un po' di hack perchè ad esempio il mio telefono supporta la modalità guanti (touch supersensibile) e mi sono dovuto inventare un magheggio per disattivarla nella recovery. In fin dei conti visto che ci sei quasi non ne vale la pena usare la mia, ma sarà piu' divertente compilarla da solo Ovviamente puoi prendere spunto, ad esempio io ho scoperto che la twrp cerca, e se esistono esegue, degli script bash all'avvio.. magari ti possono tornare utili per qualcosa.