logreen888 Wrote:Si j'ai bien compris, les "syscalls" sont ce qui rend le lancement des homebrews aléatoire? Si oui il est possible de tomber 2 fois de suite sur le même syscall?
Si par exemple la rom de l'émulateur NES ne se lance pas, c'est un hazard? Ou bien c'est l'émulateur qui n'est pas encore compatible?
C'est un peu compliqué, il y a plusieurs raisons qui peuvent expliquer un problème de rom dans un émulateur:
1) peut etre que la Rom est endommagée
2) peut être que tu as mal installé l'émulateur (fichiers manquants)
3) peut etre que l'émulateur ne supporte pas ce jeu
4) peut être que l'émulateur fait des choses qui ne peuvent pas marcher avec le HBL (appels à des fonctions Kernel)
5) peut etre que l'émulateur essaie de charger des modules externes et qu'ils ne sont pas compatibles avec le HBL (modules kernel,...)
6) peut être que le HBL a échoué son estimation de certains syscalls.
7) peut être qu'il y a un bug idiot dans le HBL
Pour 1, 2 et 3, il suffit de tester ton installation sur une psp en CFW. Facile à dire... mais bon, en gros les problèmes 1,2, et 3 n'ont pas de rapport avec les devs du HBL, et ce n'est pas "notre" problème
Pour 4... si on avait un accès kernel, on ne coderait pas un HBL, mais un HEN. La seule solution à l'heure actuelle dans ce genre de cas est de contacter l'auteur du homebrew pour voir si il peut recoder les parties kernel en user.
Pour 5, je crois que m0skit0 travaille dessus en ce moment. Le chargement de modules depuis le homebrew a été rajouté très récemment (hier ? avant-hier ? et doit être testé)
pour 7... eh bien le fichier dbglog et les testeurs nous aident à trouver ces bugs.
pour 6, la partie "importante":
Pour appeler une fonction, un programme en mode user doit effectuer un "syscall". En gros il demande au kernel: donne moi accès à la fonction numéro 123 (123 est un exemple).
Seulement on ne connait pas ce numéro pour toutes les fonctions. On ne le connait que pour les fonctions déjà utilisées par Patapon. Par exemple, Patapon est capable d'ouvrir et de lire des fichiers sur la memory stick, donc on connait le numéro(syscall) de ces fonctions. Par contre Patapon n'est pas capable de demander la liste des fichiers dans un répertoire (il n'en n'a pas besoin, à aucun moment dans le jeu on n'a la possibilité de "choisir" des fichiers dans un répertoire).
Donc si on veut appeler cette fonction de "liste", on est obligés de "deviner" son numéro. Ce numéro est aléatoire et change à chaque fois qu'on lance Patapon.
Si on devine mal, on va appeler une fonction en croyant que c'est une autre. Imagine que je croie demander (dans l'émulateur) la liste des fichiers d'un répertoire, mais qu'à la place je demande le temps restant sur la batterie (c'est une autre fonction du firmware). Je m'attends à recevoir une liste de fichiers et à la place je reçois un chiffre. A ce moment là, 2 possibilités: soit on a du "bol", et l'émulateur va juste dire "je trouve pas de roms", soit on n'a pas de bol, et on va carrément avoir un crash (imagine quà la place de la liste des fichiers, je demande à la PSP de quitter le jeu, ou que sais-je...)
Voila...
donc l'idée c'est d'améliorer nos techniques pour deviner les syscalls...ce qui évidemment n'est pas facile.
Cela veut aussi dire qu'un jeu qui n'utilise QUE les fonctions utilisées aussi par Patapon devrait marcher 100% des fois
Cette liste se trouve ici:
http://code.google.com/p/valentine-hbl/ ... ader/sdk.SEdit: cette protection par la "syscalls aléatoires" est une techniques très répandue et appliquée sur les OS modernes (Linux, Vista, Mac OsX, ...) pour éviter les attaques de virus.
Il me semble que sony a commencé à appliquer cette technique aux alentours du firmware 2.80, après l'époque du eLoader de Noobz.