95A31

Ragazzi, se qualcuno non ha di meglio da fare, potrebbe mettersi a programmare un bel editor hex specifico per eseguibili EPOC32, che aggiorna i vari campi dell'header nel binario in automatico a seconda delle modifiche fatte (Dimenzione, indirizzi export ecc). Oltre che per i Kastor potrebbe tornare utile anche per creare i file da mettere nelle cooked

Per chiarire una po le idee in modo molto semplice: Nel Fw 21 c'erano dei file che ora nel 30 non ci sono più, caso sospetto direte, chi ci garantisce che quei file servono agli effetti? Ce lo dice il fatto che il gestore dei temi li usa per gli effetti (Fw 21) e nel Fw 30 "casualmente" il gestore dei temi non è impstato per usarli. Creare un programma per le transizioni significherebbe farlo girare mentre il telefono è acceso portando ad un rallentamento del telefono (forse invisibile o forse tale da rendere il telefono inusabile non lo so). Implementanto i file mancanti e adattando il sistema a usarli invece, le transizioni avvengono in modo nativo senza appesantire il telefono (vedi chi le ha nel Fw 21 non nota rallentamenti).

Il programma si chiama PyTransition ma non fa tutte ste grandi animazioni. Nessuno riesce a farle andare xkè o non si ha la piu pallida idea di come fare o nn si ha tempo da perdere in queta causa.

Premetto di non essere informato sull'argomento, ma: 1) Il lavoro di adattamento che si dovrebbe fare per creare queste ROM con i Kastor non è simile (se non identico) a quello che si dovrebbe fare per creare una patch che sovrascrive i file inutilizzati con quelli necessari all'avvio dei Kastor? 2) Ammettendo di ottenere suddetta ROM come la si flasha nel cell?

Fai con comodo.. Mi premeva solo sapere se le avevano reintrodotte nativamente.. Il.Socio appena hai un po di tempo libero prova dare una controllata alle dipendenze (tanto per scrupolo, dubito fortemente che le abbiano reintrodotte)

Neanche file tfx* ? (Sopra era tfx* non gfx* scusate)

Qualcuno che ha gia installato il 35 può vedere questo?

Qualcuno che ha gia aggiornato al 35 puo controllare questi punti? 1) E' presente la voce Effetti tema? 2) E' presente la cartella Effects in c:/z:? 3) E' presente la cartella animdata in c:/z:? 4) Sono presenti dei file chiamati tfx*.dll in z:\sys\bin? 5) Sono presenti file *.kml in c:/z:? Grazie

In questo periodo stavo pensando di riprendere per mano questo progetto. Qualcuno si offre di collaborare per questa causa? Requisiti: - Conoscenza C/C++ - N95 Fw diverso dal 20/N95 8GB Fw diverso dal 21 - Tempo libero

Funziona solo sui firmware indicati

Io uso questo

In riferimento a questo ecco un'analisi non approfindita (ma sufficente allo scopo) delle differenze tra gli Header di gfxtrans.dll fw 21 e fw 30: public UInt32 iUid1; Uguale public UInt32 iUid2; Uguale public UInt32 iUid3; Uguale public UInt32 iUidChecksum; Uguale public UInt32 iEntryPoint; *Dall'indirizzo di inizio del file (ottenibile dall'output di DumpROM, da ora in poi IDR) differisce di 0x78 (Dimensione Header) public UInt32 iCodeAddress; Come * public UInt32 iDataAddress; Uguale public Int32 iCodeSize; **Dimensione del file (ottenibile dall'output di DumpROM) public Int32 iTextSize; Come ** public Int32 iDataSize; Uguale public Int32 iBssSize; Uguale public Int32 iHeapSizeMin; Uguale public Int32 iHeapSizeMax; Uguale public Int32 iStackSize; Uguale public UInt32 iDllRefTable; // TDllRefTable Uguale public Int32 iExportDirCount; Uguale public UInt32 iExportDir; ***Differenza tra IDR e quello a cui punta costante quindi ricalcolabile NB. Implica modificare anche gli indirzzi degli Export con lo stesso criterio public SSecurityInfo iS = new SSecurityInfo(); Uguale public TVersion iToolsVersion = new TVersion(); Diverso ma mantenere il più vecchio per eventuali controlli della versione da parte di altri eseguibili public UInt32 iFlags; Uguale public UInt32 iPriority; Uguale public UInt32 iDataBssLinearBase; Uguale public UInt32 iNextExtension; // TRomImageHeader Uguale public UInt32 iHardwareVariant; Uguale public Int32 iTotalDataSize; Uguale public UInt32 iModuleVersion; Uguale public UInt32 iExceptionDescriptor; Come *** NB. Implica modificare anche gli indirzzi delle funzioni che gestiscono gli errori con lo stesso criterio

Non è questione di porposte buone o cattive. Tutte le proposte sarebbero da provare. Il fatto è che qua si ha il cobice pronto. Basterebbe adattarlo... Questa è la via che a mio parere è + veloce e che garantisce i risultai mogliori, perciò sto seguendo quella. Se avete altre proposte proponete e postate i vostri risultati, nei limiti delle vostre capacità ovviamente. E' inutile (come facevo io e chiedo scusa) dire si potrebbefare questo o quello o quest'altro e scaricare il lavoro sugli altri.

@Il.Socio Grazie . Ultima cosa poi dell'Header dovrei essere apposto, iExceptionDescriptor che rappresenta?

@Il.Socio Grazie. Mi sadire anche iBuild della classe TVersion?

@Il.Socio Sai darmi indormazioni sulla voce iExportDir in reiferimento a questo? Oppure alla funzione nullsub_1 di IDA?

Come da titolo cerco qualcono che venda cover N95 di buona fattura, o che mi sappia indicare da chi acquistare.

Purtroppo non ho più tempo e diciamo pure anche voglia da dedicare al progetto perciò ne abbandono lo sviluppo (non il supporto). Penso cmq, che grazie a RP+ (ROMPatcher+) si possa fare qualcosa di più di quello che si è fatto fino ad ora.

@daniele 92 Gia.. @uccaa No non sono capace. Se no lo avrei gia fatto non credi? @Il.Socio Intendo dire che se nell'header c'è scritto che all'indrizzo XXXXX c'è una word e tu modifichi una funzione che richiama quell'indirizzo con un indrizzo "a caso" l'OS non trova più una word ma bit "a caso" può trovare opcode delle istruzioni un byte di bay o chissa che altro.. Cioè bisogna modificare sia header che indirizzi in modo sincorono e corretto se si vuole ottenrere qualcosa di funzionante.. almeno credo... N.B. So di ripetermi ma mi sembra di fare veramente poco.. Ragazzi mi dispiace spararela idee "a caso".. Ma più di così non so fare

Ok dato un occhio... allora.. modificando il 44 86 80 80 con hex edit e portandolo a 31 5A 09 00 ida lo interpreta con comando DCD e cono più come riferimento assoluto. Modificandolo a 45 86 80 80 mi diventa d_byte. Orami viene da pensare che il modificarlo così sia la strada corretta però bisogna fixare qualcoda nell'header (o qualchea altra parte) per cambiare l'indirizzo del valore assoluto. ES all'indirizzo 01234567 c'è il riferimento assoluto noi dobbiamo portarlo all'indirizzo76543210 allora modifichiamo i richiami da 01234567 a 76543210 e poi modifichiamo l'header da 01234567 a 76543210. Così facendo IN TEORIA itornerebbe tutto apposto. Quste sono le prime ideee che mi vengono ma è perfettamente possibile che l'header non centri nulla. Ora come sempre queste sno sempre ipotesi da verificare. Mi dispiace molto buttare giu solo idee e non dare un contributo pratico allo sviluppo.. Scusate

Io quei bytes non li vedo.. Bisogna spuntare qualche opzione? Io x vedere i vari riferimenti seleziono l'istruzion e poi vedo l'hex di ida..

@Il.Socio Mi sono perso tra immagazzinamenti di vaolri e salti.. Che valore dovremmo cambiare ? il valore delle XXXX in dword_XXXXXXX o proprio la definizione di dword_XXXXXXX ? Non è presente alcuna voce utile per le XXX di dword_XXXX nel file compilato, può darsi che la nokia\symbian adotti una codifica di immagazzinamento dei dati particolare o che il compilatore si diverta a ottimizzare il file binario rendedo il tutto illeggibile a livello esadecimale ma mi sembra strano anche perchè certi indirizzi (non so di cosa ) sono li belli in chiaro.. Dalla documentazione (generica) che ho visto fino ad ora sull'assembly ARM ho trovato solo accenni sull'opcode delle istruzioni, forse perchè bisognerebbe guardare la documentazione del processore specifico o perchè questa è disponibile solo a livello interno dell'azienda produttrice di cpu non so, fatto sta che farebbe comodo per decifrare i binari (anche se IDA è gia di per se un grandissimo aiuto). Altra possibilità è che le XXXX vengoano assegnate in automatico da IDA o definite nell'header in fase di compilazione (può essere alla voce iDataAddress?) Mi vergogno di me stesso...

provare questo? e come sempre Ancora una volta grazie x il tuo impeccabile lavoro che stai\stavi portando avanti. EDIT. Puoi dirmi una funzione con riferimenti assoluti che ci do un'occhio?

ROMPatcher lo ho all'ultima versione. No la tua non mi da problemi. Il le patch le ho sempre fatte con il tool di Alex_N70.

Per creare le patch ho visto che ROMPatcher non rognoa se le fai di lunghezza massima 32 o 1. In tutti gli altri casi non è stabile la cosa. Dalle prove che avevo fatto in passato, gfxransadapter così integrato mantiene gli indirizzi così originali del fw 21. E se modifichi gfxtrans.dll con gli indirizzi vecchi il cell si pianta o meglio non riesce + a eseguire nulla.