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
. 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
.
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
.
SCEDoormat NoME, un encapsuleur ELF->KELF libre
.
.
.
KRYPTO.KHN de remplacement
. 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...
Fail D:
.
Mode linéaire
