Kastor Su N95 Fw30

[Il.Socio]

Il.Socio sai indicarmi le dll che implementano le funzioni del TLS?

Se non erro dovrebbe essere Cone.dll, confermi?

In un recente progetto ho avuto modo di mettere mano da vicino a queste funzioni... Quindi ho recuperato il codice ed ho aggiornato i riferimenti al TLS, magicvalue e compagnia...

La funzione 0x80805A7A si occupa di recuperare dal TLS (Thread Local Storage) l'istanza singleton http://wiki.forum.nokia.com/index.php/Impl...s_in_Symbian_OS della classe dedicata alla gestione degli effetti (identificata con UID _MagicValue e contenuta sempre in gfxtrans.dll)

Dopo averne recuperato l'istanza, ne chiama qualche metodo in base ai parametri che sono stati passati alla funzione e restituisce il valore di ritorno.

Se non si chiama questa funzione, non sara' richiamato neppure il metodo appropriato per l'attivazione degli effetti.

Il costruttore presente all'indirizzo 0x808058BC si occupa della creazione dell'istanza relativa a _MagicValue e del suo inserimento nel TLS

---------------

In gfxtrans.dll c'e' sia il codice di inserimento nel TLS che quello di recupero... Inizialmente credevo erroneamente che l'inserimento nel TLS venisse effettuato da qualche altra .dll e che dunque il codice rilevante da analizzare fosse altrove...

Il costruttore CCoeStatic(uid) e' quello che si occupa di inserire l'istanza nel TLS, in accordo con questo documento:

http://wiki.forum.nokia.com/index.php/Impl...s_in_Symbian_OS

Il CCoeEnv::Static(uid) si occupa invece di recuperarne il valore.

Non so pero' quali metodi vengano richiamati su questa istanza dopo che e' stata recuperata dal TLS, ne' quale codice contengano...

Modificato 16 Luglio 2009 da Il.Socio

[Bl@ckJ@ck4IT]

In effetti quel UID (0x102822A6) è immediatamente successivo a gfxtrans (0x102822A4) e gfxtransadapter (0x102822A5)

[95A31]

Scusa.. Mi sono perso

Allora:

Psln.exe > pslnengine.dll > gxtrans.dll > UID 0x102822A6

Da quanto mi hai detto gxtrans.dll piazza l'UID 0x102822A6 nel TLS e poi se lo ripesca, xò agli indirizzi da te citati non trovo nulla, a quali file e di quale FW ti riferisci?

Io ho trovato che l'istruzione all'indirizzo 0x807F5258 (gxtrans.dll) richiama la funzione all'indirizzo 0x80731CB0 (cone.dll) che dovrebbe mettere nel TLS l'UID 0x102822A6. Perchè non troviamo gli stessi indirizzi (Io lavoro su FW 21)?

Ora sono un po arrugginito con le istruzioni assembly ma quando ho abbastanza tempo vedo di darci un'occhio. A prima vista, la cosa mi sembra andare sul complicatello.. Ma non potevano implementarlo in modo più semplice?

Ora mi viene da chiedermi: perchè, quando e chi gli dice a gtxtans.dll di caricare l'UID 0x102822A6 nel TLS?

Modificato 16 Luglio 2009 da 95A31

[Il.Socio]

I miei riferimenti sono per gli indirizzi del FW30...

[Killer Of Legend]

Si, penso anche io che lavorando in E sia molto più lento il cellulare. Però 128 MB di RAM non bastano? Se è così... pur di avere i kastor, potreste provare a vedere se riuscite a caricare i kastor da E. In questo modo potrete sia vedere come funzionano, o magari, dato che state "riscrivendo" il codice di programmi già presenti nel nostro smartphone, potete, dopo aver eseguito con successo la scrittura di un codice funzionante in E, riportare e riscrivere il codice di programmi che alla loro apertura richiamano i vari file per l'esecuzione di kastor, ma tutto in ROM. Non so se mi sono spiegato.

e di nuovo spero di non aver detto una cavolata...

Modificato 17 Luglio 2009 da Killer Of Legend

[Bl@ckJ@ck4IT]

Si, penso anche io che lavorando in E sia molto più lento il cellulare. Però 128 MB di RAM non bastano? Se è così... pur di avere i kastor, potreste provare a vedere se riuscite a caricare i kastor da E. In questo modo potrete sia vedere come funzionano, o magari, dato che state "riscrivendo" il codice di programmi già presenti nel nostro smartphone, potete, dopo aver eseguito con successo la scrittura di un codice funzionante in E, riportare e riscrivere il codice di programmi che alla loro apertura richiamano i vari file per l'esecuzione di kastor, ma tutto in ROM. Non so se mi sono spiegato.

e di nuovo spero di non aver detto una cavolata...

Purtroppo non possiamo solo fare i conti con la ram perché l'N95 classic non ne ha così tanta e finirebbe per trovarsi penalizzato inoltre, ammesso che si riuscisse ad implementare su memory card, le prestazioni sarebbero mooooolto rallentate e alla fine finiresti per disattivarli per esasperazione

[uccaa]

Purtroppo non possiamo solo fare i conti con la ram perché l'N95 classic non ne ha così tanta e finirebbe per trovarsi penalizzato inoltre, ammesso che si riuscisse ad implementare su memory card, le prestazioni sarebbero mooooolto rallentate e alla fine finiresti per disattivarli per esasperazione

bisogna vedere come li carica.. perchè se li carica la prima volta e li accantona in ram.. è un conto.. se li carica ogni volta da periferica.. beh.. la transflash porta più o meno 700kb/s.. non bastano per una animazione?

meglio attive e funzionanti che niente di niente

e poi n95-1 ha 30 mega di ram libera.. non bastano 30 mega per i kastor?

[95A31]

Il.Socio, l'sdk s60 ha qualche altra utility x decomprimere gli eseguibili? petran mi da errore su musucshoppapp.exe

[Bl@ckJ@ck4IT]

Il.Socio, l'sdk s60 ha qualche altra utility x decomprimere gli eseguibili? petran mi da errore su musucshoppapp.exe

Il.Socio aiutaci tu !

[Il.Socio]

Il.Socio, l'sdk s60 ha qualche altra utility x decomprimere gli eseguibili? petran mi da errore su musucshoppapp.exe

No, non che io sappia... Cmq. credo che i file della rom non siano compressi ma siano gia' "a posto"...

Ti risulta che sia compresso?

Modificato 20 Luglio 2009 da Il.Socio

[95A31]

Niente ragazzi speravo in un po di fortuna ma non riesco a implementare gfxtrans.dll in music app..

[Bl@ckJ@ck4IT]

Niente ragazzi speravo in un po di fortuna ma non riesco a implementare gfxtrans.dll in music app..

Dai non molliamo ragazzi :-) come possiamo aiutarti? quali sono le difficoltà nell'implementazione?

[95A31]

@ Il.Socio

Si scusa i file non sono compressi. Mi risultavano diversi perchè ho quardato solo i primi byte di IDA e primi dell'editor e risultavano diversi ma è dovuto al fatto che IDA naconde alcuni byte all'inizio del file che penso che siano una specie di preambolo alle istruzioni successive.

@Bl@ckJ@ck4IT

Se copio il file gfxtrans dentro musicapp viene visto correttamente dal symbian ma gli indirizzi purtoppo rimangono quelli del fw 21 quindi non conosco cosa sostituisco anche se fisicamente è in musicapp i byte che sovreascrivo possono essere ovunque.

Quindi gli indirizzi sono scritti al'interno del file.

Pensavo che fosse indicato solo il punto di partenza dal quale poi si ricavasse gli indirizzi delle funzioni successive, ma aimè ogni funzione ha il proprio indirizzo scritto nel file e visibile anche tramite editor esadecimale. Senza uno strumento automatico che cmq è di difficile realizzazione è da pazzi mettersi.. ci vorrebbero mesi solo x implementare gfxtrans... figurarsi le altre dll mancanti..

Inoltre x fare un qualcosa di un pò più serio di questo metodo empirico sarebbe da avere documentazione sul ciclo fetch-decode-execute delle istruzioni e della documentazione sulla struttura dei file. fare il reverse di quest'ultimo vuoi dire fare troppe ipotesi e per avere qualcoa di sicuro sarebbe necessario troppe sperimentazioni sarebbe un lavoro troppo lugoe dispendioso.

Modificato 22 Luglio 2009 da 95A31

[Il.Socio]

Se copio il file gfxtrans dentro musicapp viene visto correttamente dal symbian ma gli indirizzi purtoppo rimangono quelli del fw 21 quindi non conosco cosa sostituisco anche se fisicamente è in musicapp i byte che sovreascrivo possono essere ovunque.

Quindi gli indirizzi sono scritti al'interno del file.

Pensavo che fosse indicato solo il punto di partenza dal quale poi si ricavasse gli indirizzi delle funzioni successive, ma aimè ogni funzione ha il proprio indirizzo scritto nel file e visibile anche tramite editor esadecimale.

Non sono sicuro di aver capito bene...

Hai preso il gfxtransadapter.dll dal fw21 ed usando rompatcher l'hai piazzato nella rom di un fw30 sovrascrivendo la zona di musicapp?

In questo caso, devi rimappare tutti gli import di gfxtransadapter.dll perche' puntino alle locazioni di memoria corrette delle rispettive funzioni...

Ad esempio, sul FW21 la funzione importata "Pippo" e' mappata all'indirizzo 0x80AA, ma sul FW30 quella funzione e' mappata all'indirizzo 0x80BB

Dovrai modificare gfxtransadapter.dll sostituendo il riferimento a 0x80AA con 0x80BB

Per conoscere gli indirizzi delle varie funzioni basta che confronti i files .idc del fw21 e fw30

[Bl@ckJ@ck4IT]

Grazie ad entrambi per le info se poi lo spazio non bastasse potremmo sovrascrivere anche:

1) MyNokia

2) Download

3) Condivisione in linea

4) Lettore di codici a barre

5) Ricerca

6) Cf. Guidata

p.s. quanto mi piace sta storia di sovrascrivere i programmi inutili del firmware, almeno diventano utili a qualcosa oltre ad occupare spazio inutilmente .

p.s.2 Inoltre, se riusciamo a sistemare le varie funzioni mediante tale procedura e mettendo in autorun il MusicApp "fixato" si attivano automaticamente gli effetti

Ma torniamo coi piedi per terra per il momento forza 95A31 & Il.Socio!

Modificato 22 Luglio 2009 da Bl@ckJ@ck4IT

[Il.Socio]

non riesco a implementare gfxtrans.dll in music app..

Ora ora ho visto il tuo riferimento a gfxtrans.dll

Occhio che, mentre per gfxtrasadapter.dll puoi metterlo in una zona di memoria "a casaccio" e cambiare gli indirizzi degli import

Per gfxtrans.dll non potrai cambiarlo cosi' facilmente perche' ha degli export che vengono richiamati da altri eseguibili, quindi non puoi metterlo in una zona di memoria "a casaccio"... o meglio, se lo fai, dovrai occuparti di cambiare tutti gli eseguibili che dipendono da lui aggiornandone gli indirizzi degli import perche' puntino alla nuova locazione di memoria in cui l'hai messo (ovvero quella di musicshopapp)

Ad ogni modo, che mi ricordi, gfxtrans.dll dei 2 firmware era pressoche' uguale, quindi quello gia' presente nel fw30 dovrebbe andare bene, non dovrebbe essere necessario usare quello del fw21.

p.s.2 Inoltre, se riusciamo a sistemare le varie funzioni mediante tale procedura e mettendo in autorun il MusicApp "fixato" si attivano automaticamente gli effetti

lol... no, sicuramente no... per bene che vada, l'applicazione schianta e si chiude... se invece va male, si riavvia il cell.

Modificato 22 Luglio 2009 da Il.Socio

[95A31]

@Il.Socio

Quello che avevo in mente di fare era:

Prendo un generico file del FW 30 ES: MusicShoppApp.exe

Prendo un (o più) file del Fw 21 relativi ai Kastor ES: Gfxtrans.dll

MusicShoppApp.exe >= Gfxtrans.dll

Tramite hex editor copio Gfxtrans.dll dentro MusicShoppApp.exe (Sovrascrivendo i byte originali di MusicShoppApp.exe in modo da mantenere la dimensione costante)

A questo punto erroneamente pensavo che le funzioni aggiornassero il proprio indirizzo in base all'offset dall'inizio del file MusicShoppApp.exe (Questo è il problema che vi ho detto prima, gli indirizzi delle funzioni non partono dall'indirizzo di MusicShoppApp.exe ma mantengono i loro indirizzi del FW 21 e sostituirli nel file a mano, anche se sono scritti in chiaro, comporta calcolarne l'offset giusto ma il margine di errore è altissimo, inoltre il tutto mi è così complesso che mi perderei)

Ricavavo i nuovi indirizzi delle funzioni.

Tramite IDA controllavo e aggiornavo gli indirizzi delle chiamate interne di Gfxtrans.dll

Grazie al tuo file dependencies21 aggiornavo gli indirizzi delle chiamate verso file esterni

Tramite il tool di Alex_N70 creavo una DiffPatch per ROMPatcher di MusicShoppApp.exe.

Grazie al tuo file dependencies21 aggiornavo gli indirizzi di ogni file che puntava a Gfxtrans.dll

Tramite il tool di Alex_N70 creavo una DiffPatch per ogni file puntante a Gfxtrans.dll

Vedevo se fosse stato possibile riunire il tutto in una sola Patch, altrimenti applicavo

una "sbrodolata" di patch per rompatcher che non finisce piu'

e speravo che il cell non esplodesse..

Modificato 22 Luglio 2009 da 95A31

[Bl@ckJ@ck4IT]

Per gli indirizzi di memoria purtroppo secondo me succede perché stiamo agendo per via statica (a rom già compilata)...se lo facessimo prima di compilare la rom gli indirizzi si aggiornerebbero (correggetemi se sbaglio)..

Il.Socio conosci qualcosa che ci può aiutare riguardante il calcolo dell'offset?

Riguardo ai vari riferimenti ho il presentimento che, una volta caricato il processo Ewsrv: tfxserver il riferimento a gfxtrans possa rimanere lo stesso dell'originale nelle varie dll che ne dipendono (in parole povere fa il capriccioso prima di avviare il processo ma quando l'ha avviato non rompe più), potremmo provare ad agire così e a vedere cosa succede (w la speranza, spero di tenere lontano la legge di murphy )

Se vuoi che testi qualcosa sul fw31.0.0.17 chiedi pure

[Il.Socio]

@95a31, io supponevo che gli indirizzi fossero invece espressi direttamente con il loro valore assoluto non tramite offset...

Se fosse realmente cosi', rimpiazzarli risulta banale.

Ora devo uscire, ma quando torno verifico se e' cosi'.

EDIT: Ti diro' di piu'... Il mio tool per l'analisi della ROM e generazione dei file .idc gia' mette mano a quegli indirizzi di import/export quindi di sicuro sono espressi usando il valore assoluto in memoria... Rimpiazzarli non e' un problema, quando torno ti posto un piccolo esempio e capisci subito!

Modificato 22 Luglio 2009 da Il.Socio

[Il.Socio]

Allora... apro GfxTransAdapter.dll del FW21... prendo un import a caso:

User::After(TTimeIntervalMicroSeconds32)

Noterai che il suo riferimento nel codice punta alla locazione

807F7100 LDR PC, =0x8038065B

(*) Quel 0x8038065B e' l'indirizzo fisico in memoria in cui si trova il codice della funzione User::After(TTimeIntervalMicroSeconds32) nel FW21

Per cambiarlo, ti basta modificare i bytes presenti alla locazione

807F7104 DCD 0x8038065B

e sostituirli per puntare all'indirizzo in memoria in cui si trova la medesima funzione nel FW30

Dal file .idc del FW21 risulta che questa funzione sia mappata in memoria alla locazione 0X8038065A (in realta' il valore corretto e' 0X8038065B, ma per far contento IDA ho dovuto allineare leggermente alcuni valori... e qui nasce una complicazione a cui non avevo pensato prima)

Dal file .idc del FW30 risulta che questa funzione sia mappata in memoria alla locazione 0X8038D6FA (ma il valore corretto potrebbe essere 0X8038D6FB)

Per fare questo remapping i files .IDC non sono molto affidabili, perche' ahime' sono stati realizzati appositamente per IDA, non riportano il reale indirizzo in memoria delle funzioni, quanto piuttosto, quello aggiustato ed allineato che piace tanto a IDA e gli permette di risolvere correttamente i nomi.

La cosa piu' sicura che puoi fare e' prendere un qualsiasi eseguibile del FW30 che utilizza quella funzione e vedere qual'e' il reale indirizzo in memoria in cui si trova... vedi qui (*)

Modificato 23 Luglio 2009 da Il.Socio

[95A31]

@Bl@ckJ@ck4IT

Purtroppo abbiamo solo il compilato e dobbiamo lavorare su quello. Se avessimo il sorgente non sarebbe difficile mettere i Kastor gia da li equindi poi compilarlo e metterlo nel cell. In quel caso il problema non sarebbe + il porting del kastor ma il flashing del firwmare nel telefono che a mio parere è 10000 vole più riscioso (e complicato) x il cell che quello che stiamo facendo

Allora... apro GfxTransAdapter.dll del FW21... prendo un import a caso:

User::After(TTimeIntervalMicroSeconds32)

Noterai che il suo riferimento nel codice punta alla locazione

807F7100 LDR PC, =0x8038065B

E' giusto modificare 0x8038065B se non non trova la funzione, ma bisogna anche modificare 807F7100 se no una volta che rom patcher patcha, gli indirizzi rimangono quelli del FW 21 e non quelli del file che ho modificato.

(*) Quel 0x8038065B e' l'indirizzo fisico in memoria in cui si trova il codice della funzione User::After(TTimeIntervalMicroSeconds32) nel FW21

Per cambiarlo, ti basta modificare i bytes presenti alla locazione

807F7104 DCD 0x8038065B

e sostituirli per puntare all'indirizzo in memoria in cui si trova la medesima funzione nel FW30

Si quello che pensavo anche io

Dal file .idc del FW21 risulta che questa funzione sia mappata in memoria alla locazione 0X8038065A (in realta' il valore corretto e' 0X8038065B, ma per far contento IDA ho dovuto allineare leggermente alcuni valori... e qui nasce una complicazione a cui non avevo pensato prima)

Dal file .idc del FW30 risulta che questa funzione sia mappata in memoria alla locazione 0X8038D6FA (ma il valore corretto potrebbe essere 0X8038D6FB)

Per fare questo remapping i files .IDC non sono molto affidabili, perche' ahime' sono stati realizzati appositamente per IDA, non riportano il reale indirizzo in memoria delle funzioni, quanto piuttosto, quello aggiustato ed allineato che piace tanto a IDA e gli permette di risolvere correttamente i nomi.

Avevo notato pure io gli indirizzi differiscono disempre e solo di 1 Io una nprova la farei applicando questo accorgimento

La cosa piu' sicura che puoi fare e' prendere un qualsiasi eseguibile del FW30 che utilizza quella funzione e vedere qual'e' il reale indirizzo in memoria in cui si trova... vedi qui (*)

Il problema è che se una funzione non è chiamata da nessun eseguibile xkè interna al processo Kastor come si fa ?

[Il.Socio]

E' giusto modificare 0x8038065B se non non trova la funzione, ma bisogna anche modificare 807F7100 se no una volta che rom patcher patcha, gli indirizzi rimangono quelli del FW 21 e non quelli del file che ho modificato.

No, 807F7100 non credo che tu debba modificarlo... (*) puoi verificare che il risultato sia corretto applicando la patch, copiando il file MusicShopApp.exe sul pc e dandolo in pasto a IDA... Cosi facendo vedrai il tuo codice che e' stato inserito in MusicShopApp.exe cosi' puoi verificare se e' corretto o no.

Se lo fai, magari postalo qui sul forum cosi' ci diamo uno sguardo insieme.

(Con IDA, questa volta non potrai usare il file idc per risolvere gli import di MusicShopApp.exe patchato)

Avevo notato pure io gli indirizzi differiscono disempre e solo di 1 Io una nprova la farei applicando questo accorgimento

Non sempre, ma di tanto in tanto.

Se hai ancora la prima versione dei file .idc che avevo postato, quelli non erano allineati e li' trovi effettivamente l'indirizzo nudo e crudo...

Altrimenti, oggi vedo di rigenerarli senza allineamento cosi' da semplificare leggermente il lavoro.

Il problema è che se una funzione non è chiamata da nessun eseguibile xkè interna al processo Kastor come si fa ?

Se non e' richiamata da nessun eseguibile ma e' interna al processo Kastor, allora il riferimento ad essa, credo che sara' espresso tramite offset relativo, quindi dovrebbe funzionare senza nessun cambiamento.

Anche questo si puo' verificare cosi' (*)

Modificato 23 Luglio 2009 da Il.Socio

[Il.Socio]

Qui ci sono i files contenenti gli indirizzi delle varie funzioni importate / esportate per ciascun eseguibile della rom.

A differenza dei files .idc in cui gli indirizzi sono stati leggermente modificati per far contento IDA, questi sono nudi e crudi cosi' per come sono in rom, quindi possono essere usati per fare il remapping delle funzioni.

Dal file .txt del FW21 risulta che questa funzione sia mappata in memoria alla locazione 0X8038065B

Dal file .txt del FW30 risulta che questa funzione sia mappata in memoria alla locazione 0X8038D6FB

Modificato 5 Agosto 2009 da Il.Socio

[Bl@ckJ@ck4IT]

@95A31 si si non intendevo ricompilare la ROM, purtroppo la Nokia in questo si dimostra molto ermetica cercavo di aiutarti nel trovare una motivazione all'offset ti ringrazio comunque per la risposta

[95A31]

No, 807F7100 non credo che tu debba modificarlo... (*) puoi verificare che il risultato sia corretto applicando la patch, copiando il file MusicShopApp.exe sul pc e dandolo in pasto a IDA... Cosi facendo vedrai il tuo codice che e' stato inserito in MusicShopApp.exe cosi' puoi verificare se e' corretto o no.

ROMPatcher si blocca mentre tenta di applicare la DiffPatch Magari ho sbagliatoqualcora in fase di creazione della patch

21-gfxtran.dll: -gfxtran.dll del fw 21

30-MusicShopApp.exe: MusicShopApp.exe del fw 30

30-l-MusicShopApp.exe: MusicShopApp.exe modificato con all'interno 21-gfxtran.dll

Sviluppo_OverWrite.rar