lol Oui, c' est du présent mais cela décrit une action en train de se dérouler...
donc je traduis ça part : je suis en train de voir si j' arretes définitivement....
Merci madame Raveneau :lol:, ma veille prof d' anglais :drink:

Mais bon je suis pas un balèze en anglais non plus...

Edit : Cours de Présent progressif :lol: : http://www.e-anglais.com/cours/present.html

Ah ben ouais remarque. Bref :D

Merci :lol:

Salut à tous,

Phentex, ton idée de crypter les releases en RSA c'est pas du tout con, surtout que mettre en place une telle sécurité en cryptage/décryptage et un MD5 Check pour l'intégrité sur le fichier final ça prends quoi, 2 jours à bien programmer puis 2 minutes à mettre en place sur les fichiers ? (si bien sûr on utilise pas un programme cryptographique déjà fait).

Le seul problème, c'est qu'après, la page où il donnerait sa clé publique et le MD5 check par exemple, peut être piratée elle...
Mais enfin, c'est vraiment pas con, et j'y avais jamais songé...


Sinon, un grand merci (sincère) à tout les développeurs PSP (ainsi que certains de nos chers Metagamers (oui, le lua ça compte ;)) qui y contribuent) et bonne continuation Alex...

Espero que haras lo mejor, tanto para ti como para nosotros.
Adios,

A+

Edit: Merci alexnrok2, j'ai tapé ça en vitesse sans trop y réfléchir...

Perso je pense pas que les noobs qui se font avoir avec ces releases bidons ne sont pas du genre à vérifier le checksum des eboots...

tite correction ;)

Salut à tous,

Certes, il y en aura toujours qui se feront piéger, mais si l'on sait par exemple que pour utiliser un fichier venant directement de D_A il faut utiliser un décrypteur ne fonctionnant qu'avec une même et unique clé publique se trouvant seulement sur son site, cela peut inciter fortement à ne plus détourner ses programmes directement...
Imagines, pour utiliser ses programmes, on sait que l'on doit préalablement décrypter ses fichiers avec un utilitaire bien connu (exemple pour les textes: PGP) avec une clé publique qu'il fournit sur son site, identique à toute ses releases, il est impossible alors de recréer une même clé publique valide dans le programme de décryptage pour ouvrir une fausse archive (fake) cryptée à partir d'une autre clé privée (enfin, c'est possible en RSA 256, mais en RSA 1024 bonne chance...).

Enfin, disons que comme ça, ça sécurise nettement plus la chose. Et le MD5 c'est de l'optionnel, connaître l'intégrité d'un fichier c'est bien quand même non ? Surtout quand ça touche à la flash 0 de la PSP :D:D:D

A+

De toute façon d'ici 6 mois on saura décrypter la clé de Sony donc à nous les FW perso facile.(un gars a réussi à décrypter une clé de 512 bits en quelques milliémes de secondes).
Sinon oui c'est dommage que D_A parte mais de là à en pleurer comme certain... La PSP perdra un grand dévelloppeur.
Espérons qu'il y aura de la reléve (MPH; Booster ils sont morts?).

allé je remplace dark_alex... lol (c'est bon je sais que je suis un noob lol)

en tout cas je dit un grand merci pour tous le travail qu'il nous a fait!

Bonjour,

C’est dommage qu’une grande pointure tel que Dark_Alex se retire de la scène PSP, il faut attendre la confirmation et respecter sa décision.
Je dis un grand MERCI pour tout le travail qu’il a fourni (sans son downgrader 2.71-1.50 et custom firmware 2.71SE ma PSP serait encore dans un tiroir).

A+

http://mobiles.gx-mod.com/modules/ne...p?storyid=4351

Même pas un ptit merci a phantom pour la traduc ..

, la dessus j'ai un gros doute.

Non le chercheur qui a réussi cet exploit a dit qu'il ferait une conférence en Février pour montrer comment il a fait. Donc la petite clé dencryptage de Sony bah c'est rien. Même la CIA aurait peur c'est pour dire que le FW ça doit pas être aussi protégé qu'un secret défense. Quoique...

Oui encore faudrait-il qu'un gar comme ca s'interresse a la pauvre clé sony..

Non non non non et non, vous n'avez pas saisi ce dont je parlais concernant la crypto.

Je parlais de SIGNER ses releases pas de les CRYPTER (même si dans l'absolue ça revient au même).
Petit cours d'intro à la crypto, ça détendra l'atmosphère (et peut-être que certains apprendront quelque chose ce soir :)):

Notations:
M: message/ données en clair (lisible, pas crypté)
C: message / données cryptées (illisible, incompréhensible)
K1: clé d'encryptage
K2: clé de décryptage
E: algorithme d'encryptage
D: algorithme de décryptage

- une crypto classique de chez classique est à base d'algorithme de cryptage SYMETRIQUE. On a:
D = E^(-1) <--- D est l'algo "inverse" de E.
K = K1 = K2 <---- Même clé K pour crypter et pour décrypter

donc:
Encryptage d'un message M en cryptogramme C: C = E(M, K)
Décryptage d'un cryptogramme C et reconstitution du message M initial: M = D(C, K) = E^(-1) (C, K)

Le problème est qu'il faut garder K (le mot de passe) secret, sinon le message crypté C n'est plus en sureté. Pour transmettre des données à travers un réseau, ça oblige l'émetteur ET le récepteur à connaître le même mot de passe secret. => Problème de transmission du mot de passe + 2 fois plus de chance que le mot de passe soit compromis. Internet étant un réseau considéré très peu sûr, à cela s'ajoutent les risques d'interception de flux de données cryptées et les attaques de cryptanalyse pour "casser" l'algo & la clé utilisés.

Bien.

Passons aux choses intéressantes à présent:
Sans entrer dans des détails (passionnants pourtant) mathématiques, parlons de cryptage à clé publique.
Dans ce paradigme, D n'est pas la fonction réciproque de E, et K1 != K2. On a:

Encryptage d'un message M en cryptogramme C: C = E(M, K2)
Décryptage d'un cryptogramme C et reconstitution du message M initial: M = D(C, K1)

(K1, K2) est un couple de clés qui sont liées logiquement l'une à l'autre (ce ne sont pas 2 pauvres mots de passes choisis au pif selon l'humeur de l'utilisateur).
- L'une des deux clés (K1 par exemple) est dite privée, c'est à dire secrète, seul l'utilisateur propriétaire (appelons le Bob) du couple de clé (celui qui a généré cette paire (K1, K2)) la connait.
- L'autre (K2 en l'occurence) est dite publique, elle n'est pas secrète du tout, elle peut être librement partagée, donnée à tout le monde, et même disposée sur un serveur certifié de stockage de clefs publiques.

> Cela a pour conséquences que:
- Un personne lambda (appelons là Alice) pouvant librement connaitre K2, elle peut librement encrypter un message M, pour le transmettre à Bob.
- Bob, seul à connaitre K1, est LE SEUL au monde à pouvoir décrypter ce que Alice vient de lui envoyer sous forme cryptée.

> Par conséquent:
Si Bob et Alice veulent réciproquement communiquer ensemble de façon sécurisée, Bob doit avoir une paire de clés (K1, K2) en sa possession, Alice doit elle aussi avoir une paire de clés (K1', K2') en sa possession. Bob doit en outre connaitre K2'; Alice doit elle connaitre K2, ce qui n'est pas un problème.

Alors maintenant, passons à la signature:
Signer un message M sert à assurer son authenticité (comme un vraie signature quoi (même si une vraie signature est à mon goût la chose la plus insécurisée qui éxiste encore, bref)). Cela n'a pas pour but de rendre le message M illisible.
Reprenons le cas de Bob, qui possède sa paire de clé (K1, K2) (K1 secète, K2 connue du monde entier).
Si Bob encrypte M en cryptogramme C à l'aide de K1 (la clé normalement utilisée pour le décryptage, cf. explication précedente), alors n'importe qui peut décrypter C à l'aide de K2 (connue de tous).
Par contre, chose intéressante, Bob est LE SEUL à pouvoir encrypter M en C, i.e. il est le seul à pouvoir apposer sa signature sur M, à pouvoir AUTHENTIFIER M.

Voilà dans les grandes lignes comment ça fonctionne.

Pour ce qui est de la libre mise à disposition de la clé publique, effectivement, ça peut poser problème si un site qui l'affiche se fait hacké et si le pirate remplace la clé vraie clé publique K2 de Bob par la clé K2'' d'une paire (K1'', K2'') connue du pirate. Si le pirate en question y parvient, il peut par la suite signer des données truquées avec K1'' et Alice n'y verra que du feu.

Une solution toute simple pour éviter ce genre de désarrois:
il éxiste sur le net nombre de sites certifiés (Verisign,Veridis, etc...) permettant de déposer une clé publique associée à un nom/adresse mail dans une base de donnée sécurisée librement consultable (un annuaire en quelque sorte).

Il aurait donc suffit à D_A de se générer une paire de clés, de balancer sa clé publique sur un serveur de clés associer à Dark_Alex, et de signer ses releases pour éviter le gros bordel actuel.

J'espère que tout ceci vous aura été utile :)

merci pour l'explication , les clés de cryptage c'est un peu comme ce des clés wep ... une journer et demi pour decrypter une clé wep sa doit être 20 fois plus long pour une clé sony ...

Bah de toute façon, ya toujours moyen de cracker, c'est juste une question de persévérance. Dans le cas du firmware PSP, ya forcément une amorce non cryptée au départ (faut bien un bout de code binaire en clair au départ). Le reste est décrypté en cascade. Si on a la patience d'analyser le code en claire, on finit par y trouver les clés codées en dur d'une façon ou d'une autre. C'est pas comme essayer de casser de la crypto. Attention à l'amalgame.

Cloud78 > à la différence que le wep c'est du 128bits, et que si je ne m'abuse Sony utilise des clés de 1024bits. cracker une clé 128bits peut se faire en temps raisonnable, une clé 1024bits oublie tout de suite (même avec le plus puissant supercalculateur éxistant ça prendrait des milliers d'années).

uè je sais c'est pourquoi j'ai dit que sa prendrais 20 fois plus de temps !

à la louche :bedo:

uè je sais que sa dure beaucoup de temps mais 20000000.... c'est un peu abuzé

Tiens, le site dark-alex.com semble hérbergé en France, par Dedibox... (Ya du mouvement on dirait, la page vierge de ce site a dégagé)

Vous croyez que c'est le boulet de la derniere fois ? (ce WE) >_<

non, l' autre avez l' air d' être trop "boulet" pour faire ça :lol:. A moins qu' il fesait le faux mais j' en doute ça avait l' air authentique.

http://www.lemonde.fr/web/article/0,...-835781,0.html

Lien dudit chercheur.
Des news du côté de D_A?