Bidouiller l'OS pour accepter les Flash Apps non signées ? - Page 3

Yaurait pas moyen de faire tourner le compilo sans la flashapp avec un prog qui prend peu ou pas de RAM...

Genre un prog qui prend quelques octets de RAM pour exécuter des instructions archivées (charger seulement quelques instructions à la fois en RAM)

L'execution en flash est possible...mais comme soulignée par PpHd et Pollux : Dangereuse! (Imagine qu'un bug cause une ecriture sur tes certifs --> calc a la poubelle)
C'est ca qui fait reflechir Pollux quand j'en avait parlé avec lui

./60 > Markiiii!! C'est noté! ^^

Ah bon ?

(Apres relecture : Ah oui d'accord j'ai compris ^^' )

Un bug peut causer une déprotection accidentelle, dixit PpHd, mais la déprotection accidentelle pourrait très bien être déclenchée par du code s'exécutant en Flash.
(En revanche, l'écriture accidentelle par-dessus le code étant plus difficile en Flash, je dirais qu'il y a plutôt moins de risques de faire n'importe quoi accidentellement)

Je me suis demandé exactement la même chose.

> Et je ne sais pas si on peut quantifier ça, à partir du moment où un programme part en live, il peut se passer vraiment n'importe quoi de totue façon
Evidemment ^^
Je voulais signifier que si ça commence à partir dans le décor, un programme en RAM sera plus facilement modifié (effacement du code par des données, etc.) qu'un programme en Flash (good luck pour appeler par hasard EM_write/FL_write avec les bons paramètres ^^).

C'est quoi qui est dangereux alors dans le fait de lancer un programme en Flash ?

Rien.

Bon ben alors ?

Oui ma question est justement : Pourquoi les méthodes d'exécution en Flash sont jugées dangereuses ?

(Vous m'avez paumé ^^'
Au debut je croyais que c'était que l'execution en flash qui était protegée. Apres, l'ecriture. Mais maintenant, j'ai l'impression qu'il y a les deux protections )

Oui, il y en a 2.

(Merci Thibaut )

Thibaut (./73) :
Oui ma question est justement : Pourquoi les méthodes d'exécution en Flash sont jugées dangereuses ?

Pas plus qu'en RAM à mon avis (et les Flash Apps tournent comme ça de toute façon...).

Kevin Kofler (./56) :
Le code n'est pas de lui, il ne peut pas changer la licence. GTC est une adaptation d'un compilateur existant.

A mince, Pollux baisse (q'un ptit peu hein ) dans mon estime.

C'est une sacré adaptation. Il y a plus de changements entre CC68 et GTC que de changements entre GCC et TIGCC.

ExtendeD (./77) :

Thibaut (./73) :
Oui ma question est justement : Pourquoi les méthodes d'exécution en Flash sont jugées dangereuses ?

Pas plus qu'en RAM à mon avis (et les Flash Apps tournent comme ça de toute façon...).

Mais alors pourquoi personne n'ose publier une méthode ou un outil pour permettre l'exécution de code logé en ROM ? Ca rendrait tant de services

http://membres.lycos.fr/extended/FlashROM_exec_protection.txt ? (mars 2003)

(Pour la V200 ajouter la portion débloquée par Xpand qui n'existait pas à l'époque)

PpHd sait comment faire, il le fait pour PedROM (j'en déduis que ce n'est pas si dangereux que ça). Est-ce qu'on peut envisager que la prochaine version de PreOS vire la protection lors de son installation ?

A ce moment là, Pollux pourra faire de GTC un programme classique, mais en deux parties (64 ko + 42 ko), qui seront exécutées depuis la ROM (enfin est-ce que c'est simple de demander à TIGCC de créer un programme de ce genre ?). Finie la contrainte des certificats.

Enlever toute la protection (i.e. pas utiliser les hacks pas très pratiques de ./79) demande une déprotection de flash. Mais faire un patch d'AMS à envoyer avec FreeFlash est pas bien compliqué à réaliser.

Bon, j'essaie de me trouver un peu de temps ce w-e (enfin si quelqu'un est motivé pour porter GTC évidemment).

Tant qu'à hacker l'OS, on peut peut-être essayer de trouver l'endroit où s'effectue la vérification des signatures et la shunter. Mais on serait nettement dans une grande illégalité. Enfin bon, est-ce que Texas Instrument en a quelque chose à cirer ?

ben c'est dans le boot ça non ? (enfin je dis ça, je n'en sais rien)

Thibaut (./78) :
C'est une sacré adaptation. Il y a plus de changements entre CC68 et GTC que de changements entre GCC et TIGCC.

Oui, mais c'est quand-même une adaptation.

Thibaut (./80) :
PpHd sait comment faire, il le fait pour PedROM (j'en déduis que ce n'est pas si dangereux que ça). Est-ce qu'on peut envisager que la prochaine version de PreOS vire la protection lors de son installation ?

Un OS (un vrai, pas un "kernel") a le "droit" de modifier la zone protégée, il n'a pas besoin de contourner quoi que ce soit. (Il doit juste faire attention à ce que le code de déprotection soit dans la bonne plage d'adresses.) Le contournement, c'est pour permettre à un programme en dehors de l'OS d'y toucher.

Oui, et ?

Et : pas besoin de se prendre la tête avec un hack si on écrit l'OS soit-même

Ah OK.... Fallait deviner où il voulait en venir. Je pensais qu'il répondait à la question posée dans ce qu'il cite.

Qu'en penses-tu ?