[C] Port d'une appli sur plusieurs archs!

Marsh Posté le 16-10-2006 à 19:02:37

:hello:

Je vais faire bref mais complet. Je bosse acutellement sur le packaging Debian/Ubuntu d'ophcrack qui est un cracker de mot de passe MS Windows basé sur des Rainbow Tables. C'est assez hallucinant niveau performances.
Cependant je me heurte à un problème: ophcrack utilise deux petits binaires pour dumper les mots de passe depuis l'arborescence de Windows. Et c'est bien là que j'ai un problème:

Comme vous pouvez le voir sur screenshot les hashes des mot de passe trouvé sur amd64 et sur sparc bkhive n'arrive même pas à ouvrir le fichier...

Je demande vous propose donc, à vous qui savez codé en C et s'affranchir des problème d'endianess et de taille des registres de m'aider à porter ses applis sur toutes les archs.

Il est important de noter que c'est de très petits binaires, il n'y a peu de code mais le C reste encore très mistérieux pour moi

Je vous mets à dispo des fichiers sorti de mon arbo Windows ce qui vous permettra de tester le résultat :

Le fichier system: http://www.le-vert.net/divers/ophcrack-tools/system
Le fichier sam: http://www.le-vert.net/divers/ophcrack-tools/sam

Vous pouvez facilement tester ses deux applis en faisant:

bkhive /path/to/system /tmp/syskey
samdump /path/to/sam /tmp/syskey

Les hashes devraient s'afficher et doivent correspondre aux hashes obtenue sur la machine i386 (cf screenshot).

Les sources sont disponibles ici:

Bkhive: http://www.le-vert.net/divers/ophc [...] 0.1.tar.gz
Samdump2: http://www.le-vert.net/divers/ophc [...] 0.1.tar.gz

En vous remerciant d'avance... Toute contribution, la plus minime soit-elle est évidemment la bienvenue!

Merci! :jap:

Message édité par M300A le 16-10-2006 à 19:52:40

Reply

Marsh Posté le 16-10-2006 à 19:02:37

Reply

Marsh Posté le 16-10-2006 à 19:25:16

Interessant ton projet...

Je fait du c (plutot du c++ maintenant) et je me penche donc doucement sur ton probleme... mais attantion, j'ai pas vraiment de temps en ce moment... alors je ne pense pas faire beaucoup avancer les choses mais bon

La toute petite aide que je peut tout de suite apporter: pour compiler samdump2, il faut installer la librairie libssl-dev ... voilou, je suis sur ubunutu.

J'ai une chtite question concernant l'uilisation : j'imagine que /tmp/syskey, c'est le fichier de sortie ??? a priori si ce fichie n'existe pas le programme le cree???
Parce que j'ai des erreurs sur samdump2 : error reading from /tmp/syskey :heink:
Normal ce fichier existe pas !! ???

pour kbhive, il me sort : Error accessing key JD Wrong/corrupted hive??

J'imagine qu'il n'arrive pas a lire le fichier :-( saletes !! bah c'est bien tout ton probleme je crois...
JE regarderai mais enfin, deja sous ubuntu i686 dapper.. ca n'a pas l'air de marcher, pourtant c'est proche d'une debian !!

---------------
Un blog qu'il est bien

Reply

Marsh Posté le 16-10-2006 à 19:50:05

Oui il faut libssl en effet, j'ai des paquets Debian de prêt.

En fait voila la théorie du truc.

sam contient les hash des passwords. Il est crypté par une clef appelé syskey/bootkey. Bkhive decrypte cette clé dans le fichier system et la store dans /tmp/syskey.
Ensuite samdump decrypte le fichier sam avec la syskey que t'as extrait avec bkhive et dump les hashes des passwords.

Je vais essayer de voir pourquoi ca marche pas chez toi

Message édité par M300A le 16-10-2006 à 19:54:28

Reply

Marsh Posté le 16-10-2006 à 19:52:11

Oups excusez-moi c'est une erreur de typo, j'ai inversé les deux fichiers, j'édite :jap:

Reply

Marsh Posté le 16-10-2006 à 20:03:16

Citation :

Oups excusez-moi c'est une erreur de typo, j'ai inversé les deux fichiers, j'édite :jap:

Tu veut dire que mon Sam devrai d'appeler system ???
Parce que c'est ce que je viensde voir : le nom de la cle lue par bkhive (chez moi, avec moult printf) me renvoie un nom de type SAM... hmmm

Tu confirme : il faut que j'intervertisse mes deux noms de fichiers "cles", system et sam .???

[edit] apres test : j'ai fait manger mon fichier system a bkhive et ca me donne bien le bon type de cle...
Par contre, j'ai un magnifique sgfault !

[edit2] : j'ai une piste pour mon segfault :
Dans le fichier hive.cpp, ligne 106 environ (j'ai ajoute des printf, j'ai pas pile poil les meme numero que ceux telechargeables) :

Code :

if( !memcmp( t, n->key_name, n->name_len ) )

pour comprendre ce qu'il se passe, voila ce que j'affiche :

Code :

printf("t = %s\n",t);
printf("n->key_name = %s, n->name_len = %d\n",n->key_name, n->type);
if( !memcmp( t, n->key_name, n->name_len ) )

Dans la console, il me sort :

Code :

t = $$$PROTO.HIV
n->key_name = $$$PROTO.HI, n->name_len = 44
Erreur de segmentation

C'est logique : n->key_name fait 11 caracteres, et t 12... et n->name_len fait 44, donc il compare les 44 premiers octets entre t et n->key_name... !!!

Il y a donc un soucis au niveau de l'initialisation de n, effectue probablement (c'est la lecture que je fait du code hein je demande confirmation) par la fonction read_nk, appelee ligne 99 par cette meme fonction...

Elle est ou cette fonction ???? :heink: Je la trouve pas !!

Message édité par guepe le 16-10-2006 à 20:11:04

---------------
Un blog qu'il est bien

Reply

Marsh Posté le 16-10-2006 à 20:19:49

Tes fichiers sont bons, faut juste appelé system via bkhive et sam par samdump (j'ai éditer le premier post )

PS: Tu es sur quelle architecture ?

gandalf@hellscream:~/packaging/ophcrack-tools/bkhive$ rgrep read_nk *
bkhive-1.0.1/hive.h:#define read_nk( hive, offset ) ( (nk_hdr*) (hive->base + offset + 4) )

Reply

Marsh Posté le 16-10-2006 à 20:25:20

Desole.. un peut fatigue la pas trouve comme un idiot

Bon un petit uname -a :

Code :

Linux Xglurb 2.6.15-27-686 #1 SMP PREEMPT Sat Sep 16 02:13:27 UTC 2006 i686 GNU/Linux

voilavoila..

Sinon, je trouve le comportement de memcmp bizarre... la fonction _RegOpenKey est d'abord appelee une premiere fois dans le main, surement pour diverses init, pas trop fouille vu que ca passe, et puis ensuite elle est appellee dans une boucle effectuant 4 passages...
Donc vu ou sont places mes printf, je devrais avoir en tout 5 fois les fameuses infos que j'ai placees dans la fonction..
Hors j'ai ca :

Code :

Premiere fois //premeir appel de la fonction, la fonction sort sans planter
t = $$$PROTO.HIV
n->key_name = $$$PROTO.HI, n->name_len = 44
SalutDefault ControlSet: 001
Premiere fois //second appel (on est dans la boucle du main)
t = $$$PROTO.HIV
n->key_name = $$$PROTO.HI, n->name_len = 44 //comme on le voit les parametres sont EXACTEMENT les meme pour le memcmp ??
Erreur de segmentation //et hop : c'est ca qui plante, car le Salut n'apparait pas ??

[edit] Mon segfault n'est pas encore bien localise.. j'ai ajoute un autre debug a la sortie de la fonction... et celui-ci s'affiche !
D'ailleurs, la fonction renvoie 0, ce qui est bien (lecture reussie a priori)
Et mon segfault est donc plus loin : c'est probablement du au vidage du buffer de sortie qui ne se fait pas bien, et qui m'a trompe sur la source de l'erreur

Message édité par guepe le 16-10-2006 à 20:57:26

---------------
Un blog qu'il est bien

Reply

Marsh Posté le 16-10-2006 à 20:57:58

je pense qu'il faut être particulièrement attentif aux opérations sur les bits, le comportement n'est pas garanti il me semble d'une architecture à une autre, comme par exemple :

*len = v->data_len & 0x0000FFFF;

Message cité 1 fois

Reply

Marsh Posté le 16-10-2006 à 21:06:58

bkhive segfault pour moi sur i386...

Program received signal SIGSEGV, Segmentation fault.
0x08048e94 in main (argc=3, argv=0xbfdbf624) at bkhive.cpp:92
92 keyname = (char *) malloc( strlen( reglsa ) + strlen( kn[i] ) + 1 );

peut-être un problème avec les fichiers sam et system que tu propose ? peux-tu les mettre dans une archive ou donner un checksum pour vérifier que le transfert est ok ?

Reply

Marsh Posté le 16-10-2006 à 21:16:38

Citation :

bkhive segfault pour moi sur i386...

Program received signal SIGSEGV, Segmentation fault.
0x08048e94 in main (argc=3, argv=0xbfdbf624) at bkhive.cpp:92
92 keyname = (char *) malloc( strlen( reglsa ) + strlen( kn[i] ) + 1 );

peut-être un problème avec les fichiers sam et system que tu propose ? peux-tu les mettre dans une archive ou donner un checksum pour vérifier que le transfert est ok ?

Plantage au meme endroit pour moi... apres avoir enfin vide mon stdout ;-)

---------------
Un blog qu'il est bien

Reply

Marsh Posté le 16-10-2006 à 21:16:38

Reply

Marsh Posté le 16-10-2006 à 21:44:48

Ok j'ai ca en sortie de bkhive apres des modifs vraiment TRES etranges :

Code :

./bkhive ../system /tmp/syskey
bkhive2 from Objectif Securite
http://www.objectif-securite.ch
original author: ncuomo@studenti.unina.it
Default ControlSet: 001
Bootkey: bac86a81d53748b3b9b96881f35101fc

Cay bon ou pas??

[edit] ca a l'air d'etre pas mal : la sortie du samdump apres bkhive :

Code :

./samdump2 ../sam /tmp/syskey
Samdump2 ncuomo@studenti.unina.it
This product includes cryptographic software written
by Eric Young (eay@cryptsoft.com)
No password for user Administrateur(500)
No password for user Invité(501)
No password for user gandalf(1003)
user1:1004:e8fad36865dcc6ceaad3b435b51404ee:8b346463fab17243b56431ed125725be:::
user2:1005:8c9c9d8c3e4c60a2e20373766614591e:6a629696035ab802b7f2d74a5269f6db:::
user3:1006:f4d98660a18040d6aad3b435b51404ee:10639915d3803d6bcb4695cd57d835b8:::
user4:1007:b4b19b5134cc254eaad3b435b51404ee:7677b9791f5141c74ac724f968e779d9:::
No password for user user5(1008)
user6:1009:efed27cae4985e47aad3b435b51404ee:397ca7d9b7fd6e992e47e893fa45c090:::

Message édité par guepe le 16-10-2006 à 21:46:55

---------------
Un blog qu'il est bien

Reply

Marsh Posté le 16-10-2006 à 22:49:01

Voila mon fichier bkhive.cpp, j'ai modifie juste untruc : bizarrement l'acces aux deux premieres cases du tableau kn fait planter la lecture suivante de ce meme tableau !!!
Et uniquement les deux premieres cases :lol: si quelqu'un peut comprendre d'où cela vient !

Enfin, avec un hack à la con, chez moi ca fait marcher (apparemment) le programme bkhive... je n'ai pas d'erreur ) priori sur samdump

Code :

/* Bkhive
Extract Syskey bootkey from the system hive file
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
Copyright (C) 2004-2006 Nicola Cuomo <ncuomo@studenti.unina.it>
Improvments and some bugs fixes by Objectif Securité
<http://www.objectif-securite.ch>
*/
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include "hive.h"
int main( int argc, char **argv )
{
FILE *f;
/* hive */
struct hive h;
nk_hdr *n = NULL;
unsigned char *b;
int i, j, buf_len, control;
const char *kn[] = { "", "", "JD", "Skew1", "GBG", "Data" };
char kv[9];
unsigned char *buf;
char *keyname;
char regselect[] = "$$$PROTO.HIV\\Select";
char reglsa[] = "$$$PROTO.HIV\\ControlSet001\\Control\\Lsa\\";
// System\ControlSet001\Control\Lsa\ on some nt4 box
unsigned char key[0x10];
unsigned char pkey[0x10];
// int p[] = { 0x7, 0x3, 0xa, 0x8, 0xf, 0x9, 0x1, 0x2,0x4, 0xd, 0x5, 0x0, 0xe, 0xc, 0x6, 0xb };
int p[] = { 0xb, 0x6, 0x7, 0x1, 0x8, 0xa, 0xe, 0x0,0x3, 0x5, 0x2, 0xf, 0xd, 0x9, 0xc, 0x4 };
printf( "bkhive2 from Objectif Securite\nhttp://www.objectif-securite.ch\noriginal author: ncuomo@studenti.unina.it\n\n" );
if( argc != 3 )
{
printf( "Usage:\nbkhive2 systemhive keyfile\n" );
return -1;
}
/* Initialize hive access */
_InitHive( &h );
/* Open the system hive file */
if( _RegOpenHive( argv[1], &h ) )
{
printf( "Error opening hive file %s\n", argv[1] );
return -1;
}
/* Find the Default ControlSet */
buf = (unsigned char *)malloc(300*sizeof(char));
if (!_RegOpenKey(&h, regselect, &n))
if (!_RegQueryValue( &h, "Default", n, &buf, &buf_len)) {
if (buf_len == 4)
control = (int) *buf;
else
control = 1;
sprintf(reglsa,"$$$PROTO.HIV\\ControlSet%03d\\Control\\Lsa\\", control);
printf("Default ControlSet: %03d\n", control);
}
/* foreach keys */
for( i = 0; i < 4; i++ )
{
keyname = (char *) malloc( strlen( reglsa ) + strlen(kn[i+2]) + 1 );
sprintf( keyname, "%s%s", reglsa, kn[i+2] );
/* Access lsa subkey */
if( _RegOpenKey( &h, keyname, &n ) )
{
_RegCloseHive( &h );
printf( "Error accessing key %s\nWrong/corrupted hive??\n", kn[i] );
return -1;
}
/* Access the data */
b = read_data( &h, n->classname_off + 0x1000 );
// Quick hack for unicode -> ascii translation
for( j = 0; j < n->classname_len; j++)
kv[j] = b[j*2];
kv[8] = 0;
sscanf( kv, "%x", (int*) ( &key[i*4] ) );
free( keyname );
}
_RegCloseHive( &h );
/* Print the boot key */
printf( "Bootkey: " );
for( i = 0; i < 0x10; i++ )
{
/* Permute the class name */
pkey[i] = key[p[i]];
printf( "%.2x", pkey[i] );
}
printf( "\n" );
/* write the syskey bootkey to file */
if( ( f = fopen( argv[2], "wb" ) ) != NULL )
{
fwrite( pkey, 1, 16, f );
fclose( f );
}
else
printf( "error writing to %s\n", argv[2] );
return 0;
}

Message édité par guepe le 16-10-2006 à 22:52:43

---------------
Un blog qu'il est bien

Reply

Marsh Posté le 16-10-2006 à 23:44:46

ory: ils sont okay les fichiers, je l'ai retesté chez moi

:jap:

Merci pour le debug guepe, je teste ca sur la sparc !

Message cité 1 fois

Reply

Marsh Posté le 17-10-2006 à 00:00:12

Hum je pourrais pas toute de suite

Si vous êtes encore motivés il y'a le problème de samdump qui donne un résultat complètement pourri sur amd64

Message cité 1 fois

Reply

Marsh Posté le 17-10-2006 à 01:30:32

Je veut bien m'y essayer.. mais comment je peut faire ?? Je n'ai qu'un centrino x86 32 bits moi ??

Si y'a une methode quelconque, je suis preneur ... On peut "emuler" une plateforme en compilant d'une maniere particuliere un programme ?? c'est possible ca??? :pt1cable:

---------------
Un blog qu'il est bien

Reply

Marsh Posté le 17-10-2006 à 02:45:07

qemu?

Message cité 1 fois

Reply

Marsh Posté le 17-10-2006 à 04:53:00

Citation :

qemu?

OK, ce sera pas pour moi ;-) Chacun son tour !!!
Au fait, sur sparc ca donne quoi ?

---------------
Un blog qu'il est bien

Reply

Marsh Posté le 17-10-2006 à 08:30:39

M300A a écrit :

qemu?

dev only je crois

Reply

Marsh Posté le 17-10-2006 à 08:31:49

M300A a écrit :

ory: ils sont okay les fichiers, je l'ai retesté chez moi

:jap:

Merci pour le debug guepe, je teste ca sur la sparc !

je parlais pour le transfert vers quelqu'un d'autre que toi genre je télécharge ces fichiers binaires,comment je peux être sûr qu'ils sont bien passés, et donc que le segfault ne vient pas d'un fichier mal transféré ?

Reply

Marsh Posté le 17-10-2006 à 12:54:34

Bah heuu je peux te donner les md5 si tu veux.

Message cité 1 fois

Reply

Marsh Posté le 17-10-2006 à 13:15:21

M300A a écrit :

Bah heuu je peux te donner les md5 si tu veux.

oui, par exemple

Reply

Marsh Posté le 17-10-2006 à 13:31:31

M300A a écrit :

Hum je pourrais pas toute de suite

Si vous êtes encore motivés il y'a le problème de samdump qui donne un résultat complètement pourri sur amd64

Hello, j'ai un amd64, et ça a l'air de marcher sans modif du source :

/tmp> bkhive-1.0.1/bkhive system /tmp/syskey
bkhive2 from Objectif Securite
http://www.objectif-securite.ch
original author: ncuomo@studenti.unina.it

Default ControlSet: 001
Bootkey: bac86a81d53748b3b9b96881f35101fc

/tmp> samdump2-1.0.1/samdump2 sam /tmp/syskey
Samdump2 ncuomo@studenti.unina.it
This product includes cryptographic software written
by Eric Young (eay@cryptsoft.com)

No password for user Administrateur(500)
No password for user Invité(501)
No password for user gandalf(1003)
user1:1004:2b9fad8dc96ae24141c59a51b2af8dc6:df88a9ed5bc43a96c87969bf5d114b5e:::
user2:1005:a99d9fc623e6f4267cc83a29ab73b22b:7ccad3d687d2cf62dffd078d2b178ead:::
user3:1006:102ffcccada9d61a1e7879d76a0485ff:a623162395be1d1397df63093c5141ea:::
user4:1007:c2551753e626dce5cc7d784d1a10c6c7:18e01bd151603774b63bb61b50edda4d:::
No password for user user5(1008)
user6:1009:874d2698b0a11b67e5c9e8f268ad33aa:7c654dd91d73a0c250688f71263a1895:::

edit : au temps pour moi j'ai lu en diagonale, et je croyais que c'était censé planter ...
Bref, ça ne marche pas, les hashes sont bien incorrects.

Message édité par Riot le 17-10-2006 à 13:35:41

---------------
Be the one with the flames.

Reply

Marsh Posté le 17-10-2006 à 20:47:52

Citation :

edit : au temps pour moi j'ai lu en diagonale, et je croyais que c'était censé planter ...
Bref, ça ne marche pas, les hashes sont bien incorrects.

Allez zou au debug ;-)

Comme la dit ory, faudrait regarder les resultats intermediaires au niveau des operation binaires...
Faut se creer une sorte de 'trace' des differentes operations binaires(enfin de leur resultat) et comparer avec un 32 bits... ca permettrait de localiser la ou les operations qui foire(nt) .. Qu'en penses-tu ??

Je n'ai absolument plus le temps de coder quelques logs biens places... a quelqu'un d'autre !

Message cité 1 fois

---------------
Un blog qu'il est bien

Reply

Marsh Posté le 18-10-2006 à 01:43:17

ory a écrit :

je pense qu'il faut être particulièrement attentif aux opérations sur les bits, le comportement n'est pas garanti il me semble d'une architecture à une autre, comme par exemple :

*len = v->data_len & 0x0000FFFF;

J'ai un gros doute là... Les opérations binaires sont, il me semble, invariantes selon les plateformes. Ce qui varie, c'est l'ordre des octets.

Message cité 1 fois

Reply

Marsh Posté le 18-10-2006 à 08:25:40

guepe a écrit :

Citation :

edit : au temps pour moi j'ai lu en diagonale, et je croyais que c'était censé planter ...
Bref, ça ne marche pas, les hashes sont bien incorrects.

Allez zou au debug ;-)

Comme la dit ory, faudrait regarder les resultats intermediaires au niveau des operation binaires...
Faut se creer une sorte de 'trace' des differentes operations binaires(enfin de leur resultat) et comparer avec un 32 bits... ca permettrait de localiser la ou les operations qui foire(nt) .. Qu'en penses-tu ??

Je n'ai absolument plus le temps de coder quelques logs biens places... a quelqu'un d'autre !

un débuggeur quoi

Reply

Marsh Posté le 18-10-2006 à 13:48:01

eL_Shaman___ a écrit :

J'ai un gros doute là... Les opérations binaires sont, il me semble, invariantes selon les plateformes. Ce qui varie, c'est l'ordre des octets.

le problème c'est qu'il semble pour chacun de nous 2

Il faudrait réussir à mettre la main sur ce que dit la norme

Message cité 1 fois

Reply

Marsh Posté le 18-10-2006 à 16:17:58

Si vous voulez je fais le teste, dit moi juste quoi ajouter et à quelle ligne

Reply

Marsh Posté le 18-10-2006 à 16:45:53

J'ai enfin pu tester sur la sparc (free :fou: )

C'est toujours pareil :sweat:

gandalf@plutonium:~/bkhive/patched$ ./bkhive ../system /tmp/out
bkhive2 from Objectif Securite
http://www.objectif-securite.ch
original author: ncuomo@studenti.unina.it

Error opening hive file ../system

Reply

Marsh Posté le 19-10-2006 à 18:30:07

au fait, pas pour powerpc ?

Je vais y consacrer du temps, vu que ces problèmes d'endianess m'intéressent

Seule condition, je voudrais avoir un moyen de vérifier l'intégralité des fichiers system et sam que tu propose à télécharger (un md5 ou un sha1 par exemple), histoire de pas brasser du vent à cause d'un download foireux

Reply

Marsh Posté le 19-10-2006 à 18:54:08

J'ai pas de powerpc

Cependant je pense que t'auras le même blem sur sparc.

2b7526c3c155d3f32d90a9cef65ac1e3 sam
3714120da24e87a6ba2740b6dfe831ee system

Merci pour ton aide :jap:

Reply

Marsh Posté le 19-10-2006 à 21:49:20

Citation :

'ai enfin pu tester sur la sparc (free :fou: )

C'est toujours pareil :sweat:

M'etonne pas tellement... Mon "hack" est tellement foireux... Pourquoi donc est-ce que je ne peut pas acceder a ce fameux tableau (en tout cas les deux premieres cases) sans tout faire planter??
Je soupçonne que le probleme n'a rien a voir avec ce tableau ou son utilisation... Probablement une operation invalide ailleurs qui ressort d'une facon ou d'une autre, mais de maniere differentes selon l'architecture???

J'avoue que la j'ai plus le temps, j'avais juste une apres-midi...

---------------
Un blog qu'il est bien

Reply

Marsh Posté le 20-10-2006 à 03:42:17

ory a écrit :

le problème c'est qu'il semble pour chacun de nous 2

Il faudrait réussir à mettre la main sur ce que dit la norme

Bon, en fait, j'en suis sûr

http://fr.wikipedia.org/wiki/Endianness

Reply

Marsh Posté le 24-10-2006 à 15:10:06

bon, j'ai enfin un shell sur un amd64, j'essaye de trouver

Reply

Marsh Posté le 24-10-2006 à 15:11:52

Okay ^^

Merci :love:

Reply

Marsh Posté le 25-10-2006 à 20:49:30

bon, sur x86 j'ai trouvé la raison du sigsegv

// Quick hack for unicode -> ascii translation

en gros il y a corruption de données en mémoire, son hack fait que kn se retrouve écrasé au début (les premiers éléments)

Là j'essaye de trouver une solution pas trop cracra

Reply

Marsh Posté le 26-10-2006 à 03:32:19

Cool !

Reply

Marsh Posté le 26-10-2006 à 10:23:05

bon, déjà ca marche pour x86, je poste le patch ce soir après quelques validations

Message édité par ory le 26-10-2006 à 10:47:59

Reply

Marsh Posté le 26-10-2006 à 14:41:55

C'est bizarre votre blem sur x86, moi j'en ai aucun )

Le problème que j'ai c'est que bkhive n'arrive pas a ouvrir le fichier system sur la sparc :eek: et samdump trouve des hash miteux sur amd64. J'ai pas pu tester sur d'autre archis mais on aura sans doute des problèmes simlaires

Message cité 1 fois

Reply

Marsh Posté le 26-10-2006 à 18:08:36

M300A a écrit :

C'est bizarre votre blem sur x86, moi j'en ai aucun )

Le problème que j'ai c'est que bkhive n'arrive pas a ouvrir le fichier system sur la sparc :eek: et samdump trouve des hash miteux sur amd64. J'ai pas pu tester sur d'autre archis mais on aura sans doute des problèmes simlaires

moi je peux faire les tests pour powerpc et amd64, par contre pour sparc tout court j'ai rien sous la main, mais sparc64 si, j'ai une ultra5

Reply

Marsh Posté le 26-10-2006 à 19:50:32

Debian est pas encore porté en sparc64 donc c'est du sparc normal 32bits

Et ma sparc est aussi uen Ultra5 donc tu peux testé sans problème dessus :jap:

Merci beaucoup en tout cas, mes paquet attendent au chaud

Reply

Marsh Posté le

Reply

[C] Port d'une appli sur plusieurs archs!

Sujets relatifs:

Leave a Replay