logo

Knowledge Is Power

 
 

- Reinit des nouveaux posts -

- Recherche -

Messages Privés - Derniers posts
S'enregistrer - Login - Liste des membres
Vous logger : Login Pass

Reverse Engineering >> Unpacker pour Mew 10 et Mew 11 - Unpacking generique Newtopic | Reply
1 | 2 | Page suivante
poster txt
elooo
Inscrit le 19-05-2003
Avatar
Posté le 19-10-2004 16:14

Hello !

J'ai constaté qu'il n'existait pas (à ma connaissance) d'unpacker pour Mew, aussi bien pour la version 10 que la 11, donc j'en ai codé un en asm.
Etant donné que l'unpacking manuel de Mew n'est pas de ce qu'il y a de plus compliqué (loin de là), je doute qu'il soit d'une grande utilité, mais ça m'a occupée, et puis ça permet d'être un peu plus fainéant dorénavant

Il est dispo là :
http://elooo.fff.free.fr/tools/UnMEW.zip

Allez-y doucement sur les rapports de bugs
Je tacherai de le mettre à jour par la suite, avec les évolutions du packer s'il y a [ Ce Message a été édité par: elooo le 2004-10-27 22:31 ]

[ Ce Message a été édité par: tweakie le 2004-11-05 14:37 ]
profil | mail | Website | edit | quote
DooMeeR
Inscrit le 14-08-2004
Avatar
Posté le 19-10-2004 17:29

Et quand est-ce qu\'on aura droit à un programme qui unpacke tous les packs classiques? =)

(j\'y connais rien en packing, je dis ça comme ça )
_________________________
DooM shall never die, only the players. ©Ray Davis
profil | Website | edit | quote
elooo
Inscrit le 19-05-2003
Avatar
Posté le 19-10-2004 20:40

Les unpackers génériques ça existe déjà, va faire un tour sur protools tu verras En général ils utilisent la dll d\'ImpRec pour rebuilder la table d\'imports, et parfois encore d\'autres sources pour récupérer l\'OEP. Je trouve plus interessant de faire tout soit même. Mais bon après chacun fait comme il préfère !

Ceci dit j\'avais déjà un truc de ce genre de commencé, enfin c\'était pas générique, à terme ça aurait du être un unpacker \"plusieurs en un\". Si ça me dit, je le finirai pitêtre
Niveau practicité, ça devient interessant, c\'est certain.
profil | mail | Website | edit | quote
DooMeeR
Inscrit le 14-08-2004
Avatar
Posté le 19-10-2004 22:07

Oui c\'est sûr qu\'à utiliser c\'est pas très intéressant, mais à fabriquer ça doit être sympas
Moi quand j\'en ai marre de programmer toujours la même chose, je me fais un programme qui fait le travail à ma place. Par exemple j\'en avais marre de faire des parseurs alors j\'ai fait un compilateur de parseurs (ben oui paske utilisez ceux qui existent déjà c pas drole non plus)
Mais là je change un peu trop de sujet
_________________________
DooM shall never die, only the players. ©Ray Davis
profil | Website | edit | quote
tweakie
Inscrit le 01-02-2002
Posté le 26-10-2004 20:34

En tout cas, merci d\'avoir fait un unpacker pour MEW juste au moment ou j\'en avais besoin


Sinon, comment faire un unpacker vraiment generique (i.e. pas un truc qui soit un catalogue d\'unpackers connus)?
En reperant ce qui ressemble a un \"startup code\" classique (les bouts produits par les compilos standards) et en arretant l\'execution une fois qu\'elle atteint ce bout de code ? Le probleme, c\'est que ca ne peut marcher que si le prgramme initial a ete\' compile\' avec un compilo standard...

Alors comment font-ils ?
profil | Website | edit | quote
elooo
Inscrit le 19-05-2003
Avatar
Posté le 27-10-2004 13:00

Pour choper l\'OEP génériquement, je dirais qu\'il est difficile de trouver une méthode \"universelle\", bien que certaines doivent certainement être plus fiables que d\'autres.
Je n\'y ai jamais trop réfléchi, donc je vais peut-être dire des bêtises, et surtout ma réponse sera incomplète mais déjà les idées qui me viennent à l\'esprit sont par exemple :
- Détecter le moment où on accède à la section code.
- Vérifier si la section a bien été complètement décryptée.
- On peut utiliser ton idée aussi tweakie, le problème c\'est qu\'en cas de stolen byte ou de compilo non standard par exemple, ça risque d\'être incorrect, comme tu l\'as souligné.
- S\'aider des fonctions d\'api appelées
...
Bref je dirais grossièrement en utilisant toutes les techniques utilisées lors d\'unpacking manuel, mais en automatisant la tache (ce qui sous-entend que la recherche se fera de toutes façons par tracing).
Je pense que quelqu\'un qui aurait davantage d\'expériences en unpacking que moi saurait donner une réponse plus élaborée

Sinon, si tu te sens curieux, sur le site de Mackt,il y a les sources complètes d\'un unpacker générique (celui de Christoph Gabler, qui ne marche plus du tout sous XP, mais ça reste interessant à consulter niveau code tout de même), aussi bien pour la recherche de l\'OEP (codé en asm), que pour la dll ImpRec (source en C++).
L\'archive est dispo là :
http://wave.prohosting.com/mackt/projects/guw/guw32b8.zip

L\'inconvénient des unpackers génériques, c\'est qu\'il y aura toujours des cas particuliers ou des packers qui ne seront malgré tout pas gérés à mon avis. Par contre ça pourrait être un sacré bon projet (aussi bien prise de tête, \'faut pas le cacher ) d\'essayer d\'en recoder un sans utiliser des sources déjà existentes.
_________________________

profil | mail | Website | edit | quote
tweakie
Inscrit le 01-02-2002
Posté le 27-10-2004 16:25

> Détecter le moment où on accède à la section code.

Oui, j\'y pensais aussi hier soir.

> Vérifier si la section a bien été complètement décryptée.

A mon avis, le bon truc c\'est de se dire qu\'au moment de l\'execution :
- Le packer modifie des zones memoires (ecrit le code decrypte/unpacke\')
- Puis il execute ces zones.

Une premiere estimation est de dire que l\'executable est decrypte\' quand plus aucune instruction destinee a etre executee n\'est modifiee (bien entendu, ce dernier point depend largement de l\'application qui est packee).

Il faudrait donc stocker, lors de l\'emulation, pour chaque octet :
- La \"date de derniere modification\" (\"date\" == decompte des instructions depuis le debut de l\'emulation).
- La \"date de derniere execution\" (if any : tous les octets modifies ne sont pas destines a etre executes).

Puis, pour tous les octets ayant etes modifies _et_ executes (\"octet execute\'\" == octet appartenant a une instruction qui est executee), rechercher la date de modification la plus recente et l\'instruction correspondante. Si tout se passe bien, cette instruction devrait se trouver peu avant l\'OEP. En relancant l\'emulation et en la stoppant a cet endroit, tout devrait etre decrypte\'/packe\' correctement, non ?

> Sinon, si tu te sens curieux, sur le site de Mackt,il y a
> les sources complètes d\'un unpacker générique

Ha. C\'est exactement ce que j\'ai cherche\' hier soir sans parvenir a le trouver (je n\'avais que l\'executable et les fichiers textes), merci.
profil | Website | edit | quote
Gbillou
Inscrit le 23-02-2004
Posté le 27-10-2004 20:01

hihi j\'aime bien cette idée d\'unpacker générique
a mon avis, la meilleur solution pour trouver l\'oep c\'est effectivement de détecter quand est-ce que la section .tet est accédée en execution. Donc suffirai de coder de quoi placé un breakpoint on range et c\'est tout bénef
Et heu pour ça j\'pense que le mieu c\'est un pageguard sur la section code comme ça le debuggueur est prévenu a chaque accés, suffit de vérifier si eip est dans cette section et si oui c\'est l\'oep. Par contre si zavez d\'autres idée pour un oep finder automatique j\'suis preneur

Gbillou
profil | Website | edit | quote
analyst
Inscrit le 19-04-2002
Avatar
Posté le 29-10-2004 04:11

ya plus simple et plus efficace
_________________________

profil | edit | quote
Gbillou
Inscrit le 23-02-2004
Posté le 29-10-2004 14:13

en ring3?
profil | Website | edit | quote
tweakie
Inscrit le 01-02-2002
Posté le 29-10-2004 17:08

Quote:

Le 29-10-2004 04:11, analyst a écrit :
___________________________________________________
ya plus simple et plus efficace




Arf. Ca, c\'est simple a dire. Tu pourrais pas developper un tout petit peu ?

Plus simple que les techniques evoquees (1er acces de .text (ou equiv.) en execution/startup code/date de modif la plus recente/...) pour trouver l\'OEP de maniere generique ?
Plus simple que tracer l\'execution du code via SEH/single stepping ?

D\'ailleurs, dans la technique de single stepping utilisee par Christoph Gabler, il dit emuler les fonctions succeptibles d\'affecter le trap flag (POPF) et, je suppose, celles susceptibles d\'etre utilisees pour detecter le fait que le programme est entrain d\'etre trace\'. J\'imagine que c\'est assez commun, comme truc. Mais comment ca marche si la protection installe son ou ses propres gestionnaires d\'interruption ? Ca peut pas foutre le bronx ? Je comprends pas completement le fonctionnement de la chose...
profil | Website | edit | quote
elooo
Inscrit le 19-05-2003
Avatar
Posté le 29-10-2004 21:20

Bah en fait quand tu as des SEH de mis en place, si le programme est executé \"normalement\", c\'est le programme lui-même qui gère les exceptions.
Si ton programme est debuggé par ton unpacker ou par un debugger tout simplement, les exceptions ne seront plus gérées par le programme lui-même mais seront envoyées au debugger.
A partir de là, si ton unpacker est un debugger (ce qui sera forcément le cas si tu décides de faire du single step par exemple ou de poser des breakpoints pour trouver l\'OEP), c\'est à toi de te démener avec tout ça

Quote:
il dit emuler les fonctions succeptibles d\'affecter le trap flag (POPF) et, je suppose, celles susceptibles d\'etre utilisees pour detecter le fait que le programme est entrain d\'etre trace\'


D\'ailleurs la détection de tracing/debugging par le Trap Flag existe. Je l\'ai utilisée dans mon WTF_Crackme
_________________________

profil | mail | Website | edit | quote
Gbillou
Inscrit le 23-02-2004
Posté le 31-10-2004 02:40

la technique consistant a tracer tout le loader en single stepping a surement l'air attirante, mais c'et kan meme super long... Faut faire du single stepping super propre et quoi qu'il en soit kan on tombe dans des boucles comme la boucle servant a décrypter tel ou tel section dans le loader, un single stepping va prendre 3 décénies (un peu moins j'avou lol mais bon... ça done l'impression d'etre sur un 2mhz).
Donc meme en faisant des "step-over" par dessus les call apis, j'pense pas que ce soit la meilleur technique pour un oep finder générique. Bon apres évidement sur certains packers ça va marché, mais sur d'autre on a le temp d'aller se prendre 1 café et sa douche avant de choper l'oep ^^

et pour paraphraser elooo, la technique la plus utilisée pour détecter un single stepping c'est de mettre le trapflag a 1 avec un truc genre :
pushfd
or [esp+100h],1
popfd
nop
nop
et là le second nop génerera une exception single step. Si il n'y a pas de debuggueur c'est le seh mis en palce qui gerera l'excpetion si il y a un debugueur qui est de plus en trian de tracer cette partie de code, il croira que c'est lui meme qui a généré cette exception, elle ne sera donc pas géré par le seh mis en place par le programme.

voilu ct pour résumé un peu l'histoire (oui ce post est inutile lol)
Gbillou

PS: en anti single stepping il y a le fameu cpuid/rtdsc. qui marche bien et qui demande lui aussi a etre évité par le debuggueur ce qui sur un check simple est facile mais sur un check plus complexe est presque infaisable (si on asume que rtdsc est executé une fois puis une seconde pour comparé c'est passable, mais il peu etre utilisé une fois pour rien puis 2 fois ensuite pour comparé etc.. et dans ce cas un debuggeur se fait détecté en single stepping).
profil | Website | edit | quote
tweakie
Inscrit le 01-02-2002
Posté le 04-11-2004 13:20

Quote:

, j'pense pas que ce soit la meilleur technique pour un oep finder générique.



Alors c'est quoi la meilleure technique ? L'emulation (ca risque de prende du temps aussi) ?

Quote:

et pour paraphraser elooo, la technique la plus utilisée pour détecter un single stepping c'est de mettre le trapflag a 1 avec un truc genre :



C'est pour ca que les instructions manipulant explicitement EFLAGS (pushfd/popfd) sont emulees plutot que d'etre executes dans l'unpacker de Christof Gabler.

Quote:

en anti single stepping il y a le fameu cpuid/rtdsc. qui marche bien et qui demande lui aussi a etre évité par le debuggueur ce qui sur un check simple est facile mais sur un check plus complexe est presque infaisable (si on asume que rtdsc est executé une fois puis une seconde pour comparé c'est passable, mais il peu etre utilisé une fois pour rien puis 2 fois ensuite pour comparé etc.. et dans ce cas un debuggeur se fait détecté en single stepping).



Et en emulant aussi ces deux instructions ? Le bleme etant qu'il faudrait dans ce cas maintenir son propre compte des cycles CPU en parallele de l'execution du programme et le mettre a jour a chaque step (bon, bien sur, faut avoir une table de correspondance instructions/nombre de cycles et pas avoir peur des usines a gaz).



[ Ce Message a été édité par: elooo le 2004-11-04 21:32 ]
profil | Website | edit | quote
elooo
Inscrit le 19-05-2003
Avatar
Posté le 04-11-2004 21:34

Quote:

Alors c'est quoi la meilleure technique ? L'emulation (ca risque de prende du temps aussi) ?


Bah pour le moment je dirais (en attendant de trouver mieux, 'faudrait se creuser le cerveau), comme ça a déjà été énoncé au-dessus : trouver un moyen de mettre un break-on-access en excution sur la section code .text (avec un break on range debut de la section code/fin de la section code), mais sans se faire détecter.
L'émulation, en principe c'est beaucoup plus rapide que le tracing en single step oui, et je pense que ça pourrait être une bonne méthode aussi, mais tout de suite plus lourd à coder à mon avis. Pour moi un émulateur va charger le code dans une zone mémoire confinée (mémoire virtuelle) puis étudier les instructions et leurs significations. Il ne va pas accéder systématiquement au Context, réinitialiser l'eflag etc. Ceci dit j'ai jamais codé d'émulateur

Quote:

C'est pour ca que les instructions manipulant explicitement EFLAGS (pushfd/popfd) sont emulees plutot que d'etre executes dans l'unpacker de Christof Gabler.



Une petite explication sur la détection de single-step par le Trap Flag :

Code:

;--------------------------------------------------------------------
Installation du nouveau SEH
;--------------------------------------------------------------------
004017DC $ 33C0 XOR EAX,EAX ; eax = 0
004017DE . 64:FF30 PUSH DWORD PTR FS:[EAX] ; sauve l'original SEH sur la pile
004017E1 . 33C9 XOR ECX,ECX ; ecx = 0
004017E3 . 64:8920 MOV DWORD PTR FS:[EAX],ESP ; notre nouveau SEH ( = addr de retour de
notre call)
;--------------------------------------------------------------------

;--------------------------------------------------------------------
Tentative de detection de debugger par le trap flag
;--------------------------------------------------------------------
00401809 > 9C PUSHFD ; sauvegarde les flags registers
0040180A . 804C24 01 01 OR BYTE PTR SS:[ESP+1],1 ; met le trap flag sur Eflags (lancera
l'exception single step et notre new SEH sera appele uniquement si pas tracing, sinon le debugger devra se
débrouiller pour gérer l'exception, vu que l'exception sera envoyée au debugger)
0040180F . 9D POPFD ; restore les flags registers et exception
single step executée
00401810 . 90 NOP ; le nop est parcouru et le xhandler est
appele s'il n'y a pas tracing
;--------------------------------------------------------------------

;---------------------------------------------------------------------------------
Xhandler (appelé uniquement s'il n'y a pas tracing avec un debugger en pas à pas)
;---------------------------------------------------------------------------------
004017D3 . FE05 4C324000 INC BYTE PTR DS:[40324C] ; met le repere a 1
004017D9 . 33C0 XOR EAX,EAX ; eax = 0
004017DB . C3 RETN
;----------------------------------------------------------------------------------

;--------------------------------------------------------------------
On sort du SEH, et on teste si debugger actif ou pas
;--------------------------------------------------------------------
00401811 . 64:8F00 POP DWORD PTR FS:[EAX] ; on remet le SEH precedent
00401814 . 5A POP EDX ; on reequilibre la pile
00401815 . FE0D 4C324000 DEC BYTE PTR DS:[40324C] ; on decremente notre repere
0040181B . 0F88 94000000 JS WTF_Crac.004018B5 ; si le repere = -1, debugger car xhandler
; non appele
00401821 . EB 22 JMP SHORT WTF_Crac.00401845 ; sinon goodboy et on jmp en 00401845



En très résumé, le fait de mettre le trap flag à 1 va déclencher volontairement une exception single-step. Si le programme n'est pas débuggé, il va la gérer seule et donc passer par l'xhandler, sinon ça sera au debugger d'émuler le fonctionnement "normal" du SEH posé dans le programme.

Quote:

Et en emulant aussi ces deux instructions ? Le bleme etant qu'il faudrait dans ce cas maintenir son propre compte des cycles CPU en parallele de l'execution du programme et le mettre a jour a chaque step


Je connais pas encore assez la detection par cpuid/rtdsc, enfin je vois comment ça peut être utilisé pour de l'anti-debugging, mais la detection "sadique" dont parle GBillou je m'y suis jamais trop penchée encore. Par contre ton idée me paraît excessivement lourde Tweakie
GBillou, une solution ?

---- edit ----
Boulette réparée. Merci beaucoup Tweakie
_________________________

profil | mail | Website | edit | quote
burnze
Inscrit le 05-11-2004
Posté le 05-11-2004 16:47

Hello,

L'instruction CPUID, autre le fait qu'elle donne des informations sur les instructions exploitable par la CPU, permet d'exécuter tout les instructions en cours dans le CPU (les instructions sont exécutées en parallèle, pour celles pairables, dans deux pipelines U et V, blablabla..., architecture superscalaire, blablabla..., out of order execution, blablabla..., manuel).
RDTSC quand à lui donne le nombre de cycle CPU exécutés par la CPU depuis son hard reset. Ce compteur est incrémenté quoi qu'il arrive, donc les cycles d'execution debugger viennent s'y ajouter. En faisant un delta en deux résultats donnés par rdtsc, on peut dire si la CPU s'est "lost in translation".

Voilà le concept pour le couple cpuid/rdtsc. Il me semblait, elooo, que tu avais utilisé ça dans un de tes crackme. Je fais peut-être des crackmes même quand je rêve.

[ Ce Message a été édité par: burnze le 2004-11-05 16:51 ]
profil | Website | edit | quote
tweakie
Inscrit le 01-02-2002
Posté le 05-11-2004 18:15

Quote:

Bah pour le moment je dirais (en attendant de trouver mieux, 'faudrait se creuser le cerveau), comme ça a déjà été énoncé au-dessus : trouver un moyen de mettre un break-on-access en excution sur la section code .text (avec un break on range debut de la section code/fin de la section code), mais sans se faire détecter.



Ben oui. Sans se faire detecter, c'est la que le bat blesse. Je suis loin de tout capter (promis, je vais me documenter), mais j'ai cru comprendre que "cacher" un BPM, ca n'est pas forcement trivial non plus...

Quote:

L'émulation, en principe c'est beaucoup plus rapide que le tracing en single step oui, et je pense que ça pourrait être une bonne méthode aussi, mais tout de suite plus lourd à coder à mon avis.



Je disais ca parce qu'il semblerait qu'au moins un antivirus (NOD32, pour ne pas le nommer) utilise cette methode (l'emulation) pour unpacker les malwares.

Quote:

[...]
Ceci dit j'ai jamais codé d'émulateur



Moi non plus, mais il existe des emulateurs open-source comme Bochs qui pourraient peut-etre servir de base (oui, je sais, c'est pas en assembleur )

Quote:
Par contre ton idée me paraît excessivement lourde Tweakie



Ouais. Je suis l'homme des solutions lourdes et bourrines

profil | Website | edit | quote
Gbillou
Inscrit le 23-02-2004
Posté le 05-11-2004 18:18

put111111
J'ai passé 40min a répondre et pendant un c/c ça a chargé une autre page et j'ai perdu tout ce que j'avais écrit, donc je v résumer mais ça me fait chier j'avais répondu a tout le monde et tout >:'(

j'avé confirmé ce qui disais burnze
j'avais repris elooo sur ses commentaires en speed ça donné
pushfd ; pousse l'eflag sur la pile
or [esp+100h],1 ;met le bit 8 de l'eflag (c'est a dire le trap flag) a 1 -> on passe donc en single step
popfd ;pop ce qu'il y a sur la pile dans l'eflag
et j'avais fait une explication de 3 pages sur l'eflag, comme quoi dans le post a elooo la notion d'eflag n'était pas tres claire, que l'eflag est un registre comme un autre mais qu'on ne peu pas manipuler directement un peu comme eip (au sens que mov eip,xxx n'existe pas).
et que le code plus haut pouvais etre interprété comme ça :
push eflag
or [esp+100h],1
pop eflag
et si l'eflag pouvais etre manipulé ainsi on ferai un simple
or eflag,100h pour mettre le trap flag a 1.

ensuite pff j'c plus ce que je disais :'(
c'était a propos de l'emulation de pushfd/popfd. J'me la jouais a mort en faisant style que j'avais lu la doc intel que le cycle ne réprésenté plus grand chose pour les nouvelles architectures de porcesseurs, et que chaque instruction n'executé pas le meme nombre de cycle selon les architectures. Que par consequent pour une vrai emulation de cette instruction ct quasi impossible, mais ct aussi inutile car un simple incrementage a partir d'un nombre de cycle fictif de départ marcherai parfaitement, vu que les check par rtdsc ne pouvais pas se permettre de demander un delta précis. (delta=rtdsc2-rtdsc1)
donc que oui l'idée de tweaki était bonne et réalisable si l'onreste dans le cadre d'un single stepping
hmmm /me a un trou de mémoire... ha si y'a aussi un mal-entendu entre emulation et single stepping, là on parle d'emulation d'instruction pendant un single stepping, donc ce n'est pas plus rapide au contraire, ça aurai tendance a ralentir le single stepping (de check a chaque nouvelle isntruciton est-ce que c'est un rtdsc ou bien un pushd/popfd).

Bon j'ai du oublier des trucs et mon post d'origine était 2 fois plus long donc désolé si y'a des trucs mal dit ou autre.

Gbillou
profil | Website | edit | quote
tweakie
Inscrit le 01-02-2002
Posté le 05-11-2004 20:26

Quote:

ha si y'a aussi un mal-entendu entre emulation et single stepping, là on parle d'emulation d'instruction pendant un single stepping, donc ce n'est pas plus rapide au contraire, ça aurai tendance a ralentir le single stepping (de check a chaque nouvelle isntruciton est-ce que c'est un rtdsc ou bien un pushd/popfd).



Heu. Non, en fait, ca depend, on parle de deux choses differentes :
- D'emulation pendant un single-stepping pour eviter que celui-ci soit detecte' (ce qui ralentit le processus, comme tu le dis plus haut)

- D'emulation de bout en bout, sans single stepping dans le cadre de la question "theorique" : "quelle est la meilleure technique a employer pour un unpacker generique" ? Et la, c'est plus confortable parce que le code ne peut pas detecter les BPM "de l'interieur". Mais d'un autre cote' il peut detecter qu'il est emule' (cf. le trick de l'adresse de l'IDT pour le challenge securitech, si j'ai bien compris, mais il doit y avoir plein d'autres manieres de faire ca je suppose).
profil | Website | edit | quote
Gbillou
Inscrit le 23-02-2004
Posté le 05-11-2004 21:04

ouai j'ai pas vu où est-ce qu'on parlait de l'emuation dans ce thread mais c'est pas grave ^^

Mais c'est clair qu'on pourrai (et je n'invente rien on m'en a parler recement) faire un emulateur x86. Alias de quoi émuler l'execution entiere d'un executable, sans pour autant l'executer, ça permettrai d'avoir un controle total au niveau des breakpoint des registres de la mémoire etc.. etc..
sans se faire détecter pour autant... mais c'est un travail énorme, limite gigantesque ^^ M'enfin pour un truc qui tienne la route bien sur...
quoiqu'il en soit je pense mais je me trompe peut-etre, que personne n'a le niveau et la patience necessaire pour coder un tel truc, donc je pense qu'on peu mettre de coter cette solution, a moins que...
Gbillou
profil | Website | edit | quote
Newtopic | Reply 1 | 2 | Page suivante

Online : ijuguzis, MarkExpob, olusihad, udifoxc, ugavibuuces, uxtivebukesze et 50 Guests


Retour Index NewFFR Repository : http://taz.newffr.com
Cagades à Stick : http://alcane.newffr.com
Forum HTML et Archive -> ici
ForumFR Sql/Xml (2006/04) (SF pas à jour du tout...) - Alive since 2001 Newffr.com
Pour toute plainte ou problème -> Contacter Borax, Hyatus, Tweakie ou Stick par message privé (ou Gueulez sur le forum :) )
Retour haut de page