Question:
Rétro-ingénierie d'un pilote Solaris
cb88
2013-03-20 03:51:02 UTC
view on stackexchange narkive permalink

J'ai plusieurs pilotes de l'ère Solaris 2.6 que j'aimerais faire de l'ingénierie inverse.

J'ai un désassembleur Sparc qui fournit des informations mais il n'est plus maintenu donc je pense qu'il ne me donnera peut-être pas tout le informations possibles.

Les pilotes sont pour un accélérateur graphique Sbus que je possède. À savoir le ZX aka Leo, l'un des premiers accélérateurs 3D.

Alors, comment puis-je procéder à l'ingénierie inverse de ce pilote? Je peux le démonter mais je ne sais pas quoi faire de la sortie. J'ai aussi Solaris bien sûr, donc peut-être que je peux faire des choses là-bas.

Le but final est d'avoir suffisamment d'informations pour concevoir un pilote pour un système d'exploitation. Il existe des pilotes pour NetBSD, bien qu'incomplets car la documentation matérielle qui existe (n'est pas libre d'accès) n'a pas le codage d'ID de fenêtre car il est manquant. De plus, comme le matériel utilise une interface Sbus sur une carte mezzanine double largeur, il serait impossible de l’utiliser sur autre chose qu’une SparcStation ou une ancienne machine UltraSparc.

Vous devriez probablement ajouter quel est votre objectif final. Voulez-vous utiliser la carte dans une autre machine? Créer un pilote pour un autre OS sur le même boîtier? Juste de la curiosité?
@Igor Skochinsky Bonne suggestion, je vous ai repris dessus! Et oui, juste pour la curiosité et le plaisir.
Si vous avez des pilotes pour NetBSD, je vous recommande de les regarder et d'essayer de trouver des correspondances avec ce que fait le pilote Solaris. Cela devrait accélérer le processus.
En effet, cependant, comme je l'ai dit ... le pilote NetBsd pour le ZX est incomplet et il ne couvre certainement pas la capacité opengl 1.1 du périphérique, donc je devrai presque définitivement obtenir une copie de l'IDA ou demander à un ami de vider le fichier. montage pour moi. J'ai aussi un pilote TGS opengl pour cela qui serait intéressant, je suis sûr, mais il nécessite une licence flexlm que je n'ai malheureusement pas.
J'ai également trouvé une sorte de [pilote Linux] (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/video/leo.c) qui pourrait être utile .
Oui peut-être cependant le pilote NetBSD est au moins travaillé de temps en temps, donc j'imagine qu'il est plus complet.
Un répondre:
#1
+10
Igor Skochinsky
2013-03-20 05:03:38 UTC
view on stackexchange narkive permalink

Eh bien, puisqu'il s'agit d'un pilote Solaris, vous devez d'abord trouver des documents sur la manière dont les pilotes Solaris communiquent avec le noyau (ou le noyau avec eux). Une recherche rapide a révélé ceci:

_init () initialise un module chargeable. Il est appelé avant toute autre routine dans un module chargeable. _init () renvoie la valeur renvoyée par mod_install (9F) . Le module peut éventuellement effectuer un autre travail avant que l'appel mod_install (9F) ne soit effectué. Si le module a effectué une configuration avant que la fonction mod_install (9F) ne soit appelée, alors il doit être prêt à annuler cette configuration si mod_install (9F) renvoie une erreur.

_info () renvoie des informations sur un module chargeable. _info () renvoie la valeur renvoyée par mod_info (9F) .

_fini () prépare un module chargeable pour le déchargement. Il est appelé lorsque le système veut décharger un module. Si le module détermine qu'il peut être déchargé, alors _fini () renvoie la valeur retournée par mod_remove (9F) . En cas de retour réussi de _fini () , aucune autre routine du module ne sera appelée avant que _init () ne soit appelé.

bel exemple de code ci-dessous.

Ce guide semble également pertinent.

Une fois que vous avez trouvé les points d'entrée, il suffit de suivre les appels et les pointeurs.

Voici à quoi cela ressemble dans IDA:

  .text: 00000000 _init:! DATA XREF: leo_attach + 5A8o.text: 00000000! leo_attach + 5BCo .... texte: 00000000 save% sp, -0x60,% sp.text: 00000004 sethi% hi (leo_debug),% i2.text: 00000008 ld [leo_debug],% o0.text: 0000000C cmp% o0 , 4. texte: 00000010 bl loc_38.text: 00000014 sethi% hi (leo_state),% o0
.text: 00000018 défini aLeoCompiledSS,% o0! "leo: compilé% s,% s \ n" .text: 00000020 défini a141746,% o1! "14:17:46" .text: 00000028 sethi% salut (aLeo_c6_6juin251),% l0! "leo.c 6.6 25 juin 1997 14:17:46" .text: 0000002C appel leo_printf.text: 00000030 mis aJun251997,% o2! "25 juin 1997" .text: 00000034 sethi% hi (leo_state),% o0.text: 00000038.text: 00000038 loc_38:! CODE XREF: _init + 10j.text: 00000038 set leo_state,% i1.text: 0000003C sethi% hi (0x1800),% l0.text: 00000040 mov% i1,% o0.text: 00000044 set 0x1980,% o1.text: 00000048 call ddi_soft_state_init.text: 0000004C mov 1,% o2.text: 00000050 orcc% g0,% o0,% i0.text: 00000054 bne, a loc_80.text: 00000058 ld [% i2 + (leo_debug & 0x3FF)],% o0 .text: 0000005C sethi% hi (0x14C00),% l0.text: 00000060 call mod_install.text: 00000064 set modlinkage,% o0.text: 00000068 orcc% g0,% o0,% i0.text: 0000006C be, a loc_80. text: 00000070 ld [% i2 + (leo_debug & 0x3FF)],% o0.text: 00000074 call ddi_soft_state_fini.text: 00000078 mov% i1,% o0.text: 0000007C ld [% i2 + (leo_de) bug & 0x3FF)],% o0.text: 00000080.text: 00000080 loc_80:! CODE XREF: _init + 54j.text: 00000080! _init + 6Cj.text: 00000080 cmp% o0, 4.text: 00000084 bl locret_9C.text: 00000088 nop.text: 0000008C set aLeo_initDoneRe,% o0! "leo: _init done, return (% d) \ n" .text: 00000094 call leo_printf
.text: 00000098 mov% i0,% o1.text: 0000009C.text: 0000009C locret_9C:! CODE XREF: _init + 84j.text: 0000009C ret.text: 000000A0 restore.text: 000000A0! Fin de la fonction _init  

À 0x60, vous pouvez voir mod_install être appelé avec un pointeur vers modlinkage , vous pouvez donc y suivre et voir ce que les champs pointent.

Mais vous n'avez même pas à faire cela tout le temps. Dans ce cas, les programmeurs ont très soigneusement laissé intacts tous les symboles et la sortie de débogage. Cela devrait vous aider dans votre travail :)

Selon la situation, vous pouvez passer directement aux fonctions utiles comme leo_blit_sync_start ou leo_init_ramdac . Personnellement, je préfère le premier moyen, de haut en bas, mais à chacun le sien.

EDIT : une chose plutôt simple que vous pouvez faire est de patcher le leo_debug variable au début de la section .data à 5 environ. Cela devrait produire beaucoup de sortie de débogage sur les opérations effectuées par le pilote.

Clairement IDA pro parle de lui-même :) ... cela dit que je ne peux pas me permettre une licence pour le moment. C'est un peu hors sujet, mais les licences par architecture pourraient être intéressantes pour des gens comme moi.
@cb88: Je pense que ce serait encore plus cher que vous ne le voudrez. L'IDA est unique. Le prix est juste, mais pas pour tout le monde. Ils ont cependant des licences d'étudiant. Mais je pense que vous avez besoin de quelqu'un pour vous connaître et se porter garant de vous (s'ils le font toujours). Dans le passé, trop de fuites ont causé des dommages financiers à DataRescue et plus tard Hex-Rays.
0xC0000022L 75 $ serait 3x ce qu'ils facturent par arcade dans le logiciel complet et si vous pouviez plus tard le mettre à niveau vers la version complète pour le prix total - le prix de l'arche unique serait assez juste mais je suppose que c'est trop demander. Je ne doute pas que chaque centime en vaille la peine.Je n'ai tout simplement pas besoin d'un cuirassé pour ma promenade en pédalo pour un travail: D


Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...