SCEDoormat NoME, un encapsuleur ELF->KELF libre

[krHACKen]

Malgré toutes ces choses à faire qui m'accablent, il m'est venu une idée malsaine en mangeant ce soir, et je me penche sur cette idée en ce moment même. L'idée, c'est de coder un programme pour transformer n'importe quel fichier en KELF, à partir de blocs encryptés préfabriqués, et donc sans y intégrer l'émulateur du MechaCon. Un truc qui serait aussi légal que rageant pour $ONY:DD:fuck:.

 

C'est chose faite. $ONY prends ça DTC:D.

Voici une première version publique de cet encapsuleur libre de droit.

 

 

Pour l'utiliser, c'est simple :

Un glisser/déposer de votre ELF sur l'exécutable de SCEDoormat NoME

ou

en ligne de commande, SCEDoormat_NoME.exe VOTRE_ELF.ELF NOUVEAU_FICHIER.KELF

 

 

Le KRYPTO.KHN contenu dans ce package vous permettra d'encapsuler un fichier d'une taille max de 10485760 octets (environ 10 Mo). Le KELF qui sera produit est compatible PS2, MBR du HDD et débloquera le lecteur CDVD pour la lecture des DVDV. Il ne sera ni compatible avec la PSX, ni avec la TEST. C'est le type de KELF qui me semble le + approprié pour l'utilisateur final.

Considérez que cette première version est un proto qui peut recéler des bugs ou se heurter à des possibles restrictions du MechaCon auxquelles je ne me suis pas encore confronté.

 

 

Questions / Réponses :

 

Q : Mon ELF est plus gros que la limite des 10 Mo imposée par le KRYPTO.KHN. Est-ce que je peux l'encapsuler ?

----

R : Non. Deux solutions à ça. Compressez votre ELF ou faites une requête pour un KRYPTO.KHN qui tolère des ELF plus gros.

Sachez que + le KRYPTO.KHN accepte de tailles différentes, plus il enflera.

 

 

Q : Pourquoi faut il ce gros fichier KRYPTO.KHN ?

----

R : Pour ne pas avoir recours à un émulateur de MechaCon qui calcule et encrypte tout le bazar. L'inclusion de l'émulateur ferait que $ony se montre très menaçant et que la distribution du programme soit impossible. Le but de ce programme est justement de ne pas générer les données via l'émulateur, et donc de ne rien contenir de litigieux.

KRYPTO.KHN contient des portions de KryptoELFs prêtes à être rassemblées pour ne former que le KELF final. Il est conçu de façon privée avec l'émulateur. Tout ce qui est sensible reste privé, uniquement le résultat qui est clean est publié sans crainte de représailles.

 

 

Q : Peut on diminuer la taille du KRYPTO.KHN ?

----

R : Non. Du moins pas pour le moment. Il se pourrait que je sorte un autre programme ou que j'ajoute une fonction permettant d'alléger un KRYPTO.KHN qui n'utilise pas le taux de précision N°4, pour qu'il soit tronqué en taux de précision N°2, N°3 ou N°4...

... peut être pour dégrader la taille max par paliers aussi...

 

 

Q : Quels sont les taux de précision supportés par cette version de SCEDoormat ?

----

R : 4 taux.

+ N°1 = Le meilleur. La longueur totale des blocs décryptés est égale à la taille du ELF

+ N°2 = Bon. La longueur totale des blocs décryptés est arrondie au multiple de 4 supérieur.

+ N°3 = Moyen. La longueur totale des blocs décryptés est arrondie au multiple de 8 supérieur.

+ N°4 = Le pire. La longueur totale des blocs décryptés est arrondie au multiple de 16 supérieur.

Ce taux est unique par fichier KRYPTO.KHN. Il n'est donc pas possible d'en choisir un plutôt qu'un autre sans utiliser un autre fichier KRYPTO.KHN.

Plus le taux est bon, plus le fichier KRYPTO.KHN est gros.

Plus le taux est mauvais, plus le KELF produit risque d'avoir de l'excédent (un maximum de 15 octets de surplus dans la région décryptée, ce n'est pas dramatique non plus.)

Vous l'aurez compris, le taux de précision est surtout une variable d'ajustement de ce que KRYPTO.KHN bouffe en place sur votre HDD.

$ONY arrondit la plupart de ses KELFs au multiple de 16 supérieur, donc comme "le pire" taux supporté par SCEDoormat NoME. Le meilleur taux est juste un gadget pour forcené de l'esthétique qui fait gonfler la taille du KRYPTO.KHN de près de 16 FOIS par rapport au pire taux.

 

 

Q : Mon antivirus m'indique que SCEDoormat NoME est un virus ou qu'il est vérolé...

----

R : Vous pouvez ajouter une règle d'exclusion ou désactiver votre antivirus temporairement sans crainte. C'est un faux-positif, le fichier tel qu'il est téléchargé est sain. Les antivirus n'aiment pas ce que je code et m'offrent souvent mon brevet de mauvais développeur ou de hacker:shy2:. Preuve en est, cette pile de m*rde qu'est Avast s'est emballé à plusieurs reprises pendant le développement de cette version de SCEDoormat.

 

 

Q : Et si on fusionnait SCEDoormat NoME et ps3mca-tool ?

----

R : Mauvaise idée. En tout cas, je ne le ferais pas, pour trois raisons;

1) Ça rendrait la distrib du SCEDoormat hybride beaucoup plus risquée

2) Le concept de SCEDoormat NoME est justement de ne pas contenir d'éléments de ps3mca-tool

3) Si quelqu'un venait à retravailler ps3mca-tool pour qu'il vomisse des containers, il serait plus intelligent de faire en sorte que ce soit ps3mca-tool lui même qui les génèrent, et pas un truc qui remâche des monceaux de KELFs préfabriqués...

En tout cas je compte distribuer le code source de SCEDoormat NoME, une fois que j'aurais ajouté toutes les fonctionnalités que je veux dessus et que son efficacité sera démontrée. N'étant pas un fan des licences, quiconque l'aura en fera ce qu'il veut.

 

 

Q : Pourquoi utiliser SCEDoormat NoME plutôt que Dirty KELF Maker qui est 1000 fois moins lourd ?

----

R : Dirty KELF Maker ne forme le KELF qu'avec une en-tête générique et colle le ELF juste après. Vu qu'il ne colle pas les blocs hashés et cryptés indexés en Bit Table, sceSecrDownloadFile échouera. En d'autres termes, les KELFs produits par Dirty KELF Maker ne peuvent pas fonctionner en carte mémoire. Ce qui n'est pas le cas des KELFs produits par SCEDoormat NoME.

J'ai bridé la Bit Table du Dirty KELF Maker V2 à 2025312 octets si je me souviens bien. SCEDoormat NoME peut aller beaucoup plus loin rien qu'avec le KRYPTO.KHN fourni dans cette release.

 

 

Q : Je lance mon KELF en BREXEC-SYSTEM sur ma MC. Le lecteur CDVD ne répond pas, ma console est en Anglais, ça déconne de partout...

----

R : Si vous êtes développeur, documentez vous sur ces symptômes en (re)lisant les topics de développement de FMCB sur Metagames et PSX-Scene.

Si vous n'êtes pas développeur, installez plutôt Free McBoot:pouce:.

 

 

Q : La taille indiquée dans l'en-tête du KELF ne correspond pas du tout à la taille du KELF ou de mon ELF... WTF ?

----

R : Une des spécificités de KRYPTO.KHN à sa création est de tirer profit des largesses du MechaCon en terme de contrôle/vérification du container. Le MechaCon n'en a rien a cirer de la non-correspondance de cette valeur avec la taille réelle du contenu. Seule la Bit Table lui importe. Donc ni KRYPTO.KHN, ni l'exécutable de SCEDoormat NoME ne touchera à cette valeur:P.

 

 

 

Téléchargement(s) :

 

* Release 1, 2014/04/14

MEGA.co.nz

 

* Release 2, 2014/04/20

MEGA.co.nz

 

* Release 3, 2015/04/13

1fichier.com

Modifié le 8 juin 2019 par krHACKen
liens morts

[krHACKen]

22/04/2014, pour PS2 uniquement, DVDV et MBR, 10 MB max, précision 4 (était fourni avec la release 2)

 

About KRYPTO.KHN :

Hello Gontlomon,
I was build 2014/04/22 to be bundled with the SCEDoormat No ME Version release 2,
and I'm suitable for retail PlayStation 2...


KRYPTO.KHN properties :
Maximum Capacity of the Container     == 10485760 bytes (A00000h)
Precision Rate for Embedding Contents == 4 (WORST, round length to multiple of 16)
KELF Quantity                         == 655360
Length of the KELF Header             == 128 bytes (0x0080)
Hashed Blocks Quantity                == 1
Total Length of the MG Hashed Blocks  == 8 bytes

KryptoELF specs :
User Header is MechaCon Blacklisted   == False
Is a HDD Master Boot Record Container == True
Target Machine Type                   == PS2 (CEX Only)
Target Application Type               == DVDPLAYER
M@gicGate Zones                       == Japan+USA+Europe+Oceania+Asia+Russia+China+Mexico

1fichier.com

 

 

22/04/2014, pour PSX uniquement, DVDV, pas MBR, 10 MB max, précision 4

 

About KRYPTO.KHN :

This one is for the PSX (DVR).
It's not MBR flagged, so can the output KELF be run from xfrom ? IDK...
Anyway, it's OK for running your stuff from the XMB.
Want CARD binding ? The signature is ZEROed.

KRYPTO.KHN properties :
Maximum Capacity of the Container     == 10485760 bytes (A00000h)
Precision Rate for Embedding Contents == 4 (WORST, round length to multiple of 16)
KELF Quantity                         == 655360
Length of the KELF Header             == 128 bytes (0x0080)
Hashed Blocks Quantity                == 1
Total Length of the MG Hashed Blocks  == 8 bytes

KryptoELF specs :
User Header is MechaCon Blacklisted   == False
Is a HDD Master Boot Record Container == False (User Header of Type 0x01)
Target Machine Type                   == PSX
Target Application Type               == DVDPLAYER
M@gicGate Zones                       == Japan+USA+Europe+Oceania+Asia+Russia+China+Mexico

1fichier.com

 

 

13/04/2014, pour PS2, TEST, et PSX, clone de dnasload, 10 MB max, précision 4

 

About KRYPTO.KHN :

Dnas_WithHDD container... Reference 0E319097.
Worst MG block alignment for the sake of your HDD free space.

KRYPTO.KHN properties :
Maximum Capacity of the Container     == 10485760 bytes (A00000h)
Precision Rate for Embedding Contents == 4 (WORST, round length to multiple of 16)
KELF Quantity                         == 655360
Length of the KELF Header             == 128 bytes (0x0080)
Hashed Blocks Quantity                == 1
Total Length of the MG Hashed Blocks  == 8 bytes

KryptoELF specs :
User Header is MechaCon Blacklisted   == False
Is a HDD Master Boot Record Container == True
Target Machine Type                   == PS2 (CEX & DEX) + PSX
Target Application Type               == Dnas_WithHdd
M@gicGate Zones                       == Japan+USA+Europe+Oceania+Asia+Russia+China+Mexico

1fichier.com

 

Modifié le 8 juin 2019 par krHACKen
liens morts

[krHACKen]

La release 2 est postée.

 

Pas de grande nouveauté dans cette version. Seulement ça :

* Je me suis rendu compte que la TEST refuse aussi de décrypter les KELFs avec le flag APP_TYPE == 0x05 (KIRX du DVD Player pour la MC).

SCEDoormat affichera maintenant "PS2 (CEX only)" quand il aura à traiter un KRYPTO.KHN de ce type.

* Possibilité d'identifier un KRYPTO.KHN sans avoir à vomir un KELF.

Il suffit de faire un glisser-déposer du KRYPTO.KHN sur l'EXE, ou de ne spécifier que le KRYPTO.KHN dans la ligne de commande.

 

 

La build est datée du 2014/04/20, c'est normal.

Mon appli qui génère les KRYPTO.KHN a un bug critique. Elle ne hashe plus rien:grr:. J'ai perdu près de 2 jours à essayer de la bugfixer. Pas moyen. Du coup je me rabat sur une autre technique me permettant de ne pas avoir à invoquer directement le MechaCon + la HashKey. C'est merdique mais ça marche, en attendant de trouver le temps qui me manque pour corriger ça proprement. D'où le retard dans la release qui était dépourvue de KRYPTO.KHN jusqu'à ce matin. Je n'ai fait qu'un seul test (concluant) avec ce KRYPTO.KHN, j'espère qu'il fonctionnera sans problème...

 

Un KRYPTO.KHN pour les possesseurs de PSX va arriver, dans le 2ème post...

[krHACKen]

LOL. Bon, j'crois qu'on peut oublier le __mbr avec SCEDoormat. Apparemment, le bordel ne va pas jusqu'au bout si la taille totale de tous les blocs (en bit table) est supérieure à la taille réelle du contenu inscrite dans l'en-tête du KELF. Je viens de me rendre compte que ça foire en essayant d'upgrader le uLE HDD Edition de WIP6 à WIP7. Reste à déterminer quelle est la raison et quelles sont les limites exactes, par exemple savoir si ça passe avec un contenu de taille inférieure à celle indiquée...

 

EDIT 1 : Mon c*l. Oubliez ce que j'ai dit plus haut. J'ai balancé un autre ELF plus petit dans le container (mais toujours + gros que la taille en header), ça marche.

Ça se précise. Ou bien le lanceur n'aime pas la façon dont ma build de uLE est conçue (standard respecté : headerless et entrypoint à 0x00100000), ou bien y'a une limite de taille en MBR (mon uLE n'était PAS packé, et faisait un peu moins de 1 MB)... L'extinction est violente, comme si il ne seekait pas dans les secteurs...

 

EDIT 2 : BINGO ! La taille max du KELF acceptée en MBR est 0x6BD (1725 secteurs, 883200 octets).

Résumé des propriétés :

- Le ELF doit être sans header. Load address à partir de 0x00100000 et entrypoint à 0x00100000

- La taille du KELF ne peut excéder 883200 octets

- La user header du KELF doit avoir les deux flags suivants : premier byte == 0x01, quatrième byte == 0x04

 

Pour où écrire le KELF, aucune idée. $ony fout les siens aux secteurs 8192 (0x2000) et 8224 (0x2020). Perso, je les place au secteur 16 (0x10), ou bien à 262144 minus la taille de mon KELF en secteur (0x040000 - kelf_size).

 

Faudrait que je pense à mettre des warnings de tailles pour les partitions HDL et le MBR dans le prochain SCEDoormat. Aussi, le check des flags pour le MBR est incomplet; j'ai oublié l'inspection du 1er byte :facepalm: .

Modifié le 24 avril 2014 par krHACKen

[krHACKen]

Updates :

 

- Dans le post 1, ajout de la 3ème version de SCEDoormat_NoME.

Quelques changements cosmétiques ont été apportés, rien de très important. Oh, j'ai oublié d'implémenter le warning dont je parlais dans mon post précédent .

 

- Dans le post 2, ajout d'un nouveau KRYPTO.KHN.

C'est un clone de dnasload, donc les KELFs générés avec ce KRYPTO.KHN seront compatibles avec la PS2, la TEST et la PSX. C'est un must have. Il est aussi flaggés pour un usage en MBR. Perso c'est ce type de container que j'utilise pour toutes mes productions (dont les releases de POPStarter et le uLE que j'ai mis en MBR lol). L'inconvénient de ce KRYPTO.KHN, c'est que vu qu'il est flaggé Dnas_WithHdd, il ne débloquera pas la lecture des secteurs des DVD-Video. Inutile donc de faire des KELFs ESR ou du Lecteur DVD avec ce truc.

[krHACKen]

Code source ajouté au premier post, et aussi publié chez PSX-Place.

Ça trainait dans mon HDD et je me suis dit que quelqu'un en aurait peut être l'utilité... Il n'y a rien de compromettant dedans.

Vu que je ne fais presque plus rien sur PS2, autant le partager...