[krHACKen]

Ouais. Faut copier tout l'ELF et le coller là où les zéros commencent, c'est à dire à l'offset 370h.
C'est ce que fait hdl_dumx avec un container interne et légal. Celui que j'ai foutu en Pastie est un KELF de $ony recyclé. Le principe du copier/coller reste le même.
Utiliser un container vide comme celui ci peut être une bonne alternative à la méthode embed/DVDELF pour deux raisons :
- Parfois certains ELFs injectés dans des DVDELFs ne se lancent pas; parce le payload se retrouvé écrasé durant la copie du code qu'il est sensé exécuter. C'est rare mais ça arrive.
- L'exécution d'un ELF à partir d'un container vierge (sans qu'aucun bloc encrypté ne soit traité) et bien plus rapide qu'avec un DVDELF jonché de blocs encrypté. Le MechaCon est lent. Le moins il décrypte de trucs, le + rapide c'est.


EDIT : Le KELF maker de AKuHAK ne traite pas le footer encrypté si je me souviens bien. Ça peut être problématique si la taille du ELF qu'il contient se rapproche trop du dernier bloc encrypté. Le MechaCon essaiera alors d'en décrypter une partie et échouera. D'ailleurs, si tu essaies de signer un KELF créé par le KELF maker pour ta carte mémoire, ça échouera à coup sur; vu que contrairement au SifLoadElfEncrypted qui se base en partie sur l'en-tête de l'ELF, les fonctions de libsecr/Secrman_Special/Secrman_for_Arcade traitent le KELF dans sa pleine longueur (qui est définie dans l'en-tête du KELF) avant d'acquérir la paire Kbit+Kc pour la MC.
En espérant que mon explication est compréhensible et pas trop barbante....