Salut,

Dans l'absolu, la question "comment unpacker une DLL" est intéressante.
Néanmoins, ici, tu nous parles de cracker un jeu (Microsoft Flight Simulator X si j'ai bien suivi).
Quand bien même tu l'aurais acheté (ce sur quoi j'ai quelques doutes au vu du W7 64bits vs DLL 32bits + le fait que tu nous parles de DLL déjà crackée, mais c'est un autre sujet), c'est illégal.
En conséquence, il est peu probable que quelqu'un te réponde.

Bonne année quand même

Bonjour,

J'en suis à un certain point où le programme plante en me disant  :

sh: 1: }�������������������: not found

Je suis sur la bonne voie ou complètement à l'ouest ?

Je précise que je n'obtiens pas cette erreur par hasard, mais avec une adresse bien choisie et des heures de doc

Salut,

Qu'on te réponde "t'es sur la bonne voie" ou "t'es complètement à l'ouest" ça ne t'avancera pas plus.
Du coup je te propose autre chose : c'est pas normal qu'un programme se comporte ainsi.
Reste à savoir si tu peux en faire quelque chose, et ça tu le sais déjà puisque tu précises toi-même que tu n'obtiens pas cette erreur au hasard :p

++

Bonjour à tous,

Pas de TL;DR; désolé :p

Comme mentionné dans le titre, je vais ici parler de PLT, de GOT et de relocations dans des fichiers ELF.
Si vous êtes déjà perdu, voici un peu de lecture : https://www.segmentationfault.fr/linux/role-plt-got-ld-so/

Avant de commencer, un point important.
Dans ce qui va suivre, il y a des choses dont je suis certain, mais pour d'autres je ne serais pas aussi affirmatif...
En conséquence :

• à défaut de réponses à mes questions, toute confirmation (ou pas) est la bienvenue
• si vous pensez avoir appris quelque chose, lisez d'éventuels commentaires qui pourraient affirmer le contraire

Pour information, je vais me limiter au cas x86 et chaque fichier aura du contenu dynamique (sinon il n'y a rien à raconter).
Considérons donc un fichier ELF tout ce qu'il y a de plus basique. On va -potentiellement- trouver (en autres) :

• deux sections de relocations : .rel[a].dyn et .rel[a].plt
• deux sections PLT (la PLT "splittée" en deux) : .plt et .plt.got
• deux sections GOT (la GOT "splittée" en deux) : .got et .got.plt

Trois de ces sections vont ensemble : une relocation dans .rel.plt = une entrée dans .plt = une entrée dans .got.plt

Et là, il faut maintenant parler de lazy binding vs "now binding" (binaire compilé avec l'option "-Wl,-z,now") :

• lazy binding : les adresses sont résolues au runtime (premier appel = on résout l'adresse)
• "now binding" : les adresses sont résolues par le dynamic loader (ce qui permet de mettre la GOT en read-only mais c'est pas le sujet)

Revenons donc sur les six sections évoquées plus haut :

• .got.plt = la GOT pour les adresses résolues en utilisant le lazy binding
• .got = la GOT pour les adresses résolues en utilisant du "now binding" (potentiellement présente même si le fichier utilise le lazy binding)
• .plt = la PLT pour les imports de fonctions (dont les adresses seront résolues par lazy binding ou non)
• .rel.plt = les relocations liées à la section .plt
• .rel.dyn = les relocations liées à tout le reste (.got mais aussi .data, .bss, etc)

Dans le cas "now binding", il n'y a donc pas de .got.plt, ou plus exactement elle est "intégrée" dans .got.

Si vous savez compter et que vous me lisez avec attention (merci et bravo !), vous avez remarqué qu'il manque .plt.got dans la liste ci-dessus.
La raison est simple : c'est ici que je coince.
Le seul point donc je suis à peu près sûr c'est qu'elle est présente uniquement pour les fichiers ET_DYN, autrement dit en cas de position-independant code.

Regardons un simple "hello world" codé en C et compilé avec GCC (8.3.0 sur une Debian 10 64 bits) :

$ gcc -m32 -o hello_world hello_world.c

$ file hello_world
hello_world: ELF 32-bit LSB pie executable, Intel 80386, [etc]

$ readelf -S hello_world
[...]
  [ 9] .rel.dyn          REL             00000368 000368 000040 08   A  5   0  4
  [10] .rel.plt          REL             000003a8 0003a8 000010 08  AI  5  23  4
[...]
  [12] .plt              PROGBITS        00001020 001020 000030 04  AX  0   0 16
  [13] .plt.got          PROGBITS        00001050 001050 000008 08  AX  0   0  8
[...]
  [22] .got              PROGBITS        00003fec 002fec 000014 04  WA  0   0  4
  [23] .got.plt          PROGBITS        00004000 003000 000014 04  WA  0   0  4
[...]

$ readelf -r hello_world
[...]
Relocation section '.rel.dyn' at offset 0x368 contains 8 entries:
 Offset     Info    Type                Sym. Value  Symbol's Name
00003ef4  00000008 R_386_RELATIVE       
00003ef8  00000008 R_386_RELATIVE       
00003ff8  00000008 R_386_RELATIVE       
00004018  00000008 R_386_RELATIVE       
00003fec  00000106 R_386_GLOB_DAT         00000000   _ITM_deregisterTMCloneTable
00003ff0  00000206 R_386_GLOB_DAT         00000000   __cxa_finalize@GLIBC_2.1.3
00003ff4  00000406 R_386_GLOB_DAT         00000000   __gmon_start__
00003ffc  00000606 R_386_GLOB_DAT         00000000   _ITM_registerTMCloneTable
Relocation section '.rel.plt' at offset 0x3a8 contains 2 entries:
 Offset     Info    Type                Sym. Value  Symbol's Name
0000400c  00000307 R_386_JUMP_SLOT        00000000   puts@GLIBC_2.0
00004010  00000507 R_386_JUMP_SLOT        00000000   __libc_start_main@GLIBC_2.0

$ objdump -D hello_world | grep "\.plt\.got" -A 10
Déassemblage de la section .plt.got :

00001050 <__cxa_finalize@plt>:
    1050:   ff a3 f0 ff ff ff       jmp    *-0x10(%ebx)
    1056:   66 90                   xchg   %ax,%ax

Déassemblage de la section .text :
[...]

On va ignorer les sections .plt, .rel.plt et .got.plt (là-dessus, pas de problème) et s'intéresser pour commencer à .got.
On y trouve quatre entrées (les quatre R_386_GLOB_DAT).
Jetons un coup d'oeil sur ce qui se passe au runtime :

$ readelf -s hello_world | grep "\<_start\>"
    66: 00001060    54 FUNC    GLOBAL DEFAULT   14 _start

$ gdb hello_world
Reading symbols from hello_world...done.
(gdb) b _start
Breakpoint 1 at 0x1060
(gdb) r
Starting program: /home/pech/Bureau/hello_world

Breakpoint 1, 0x56556060 in _start ()
=> 0x56556060 <_start+0>:   31 ed   xor    ebp,ebp   # => la .got est en 0x56556060 - 0x1060 + 0x3fec = 0x56558fec (même segment que .text)
(gdb) x/4x 0x56558fec
0x56558fec:   0x00000000   0xf7e0fd20   0x00000000   0x56556199
(gdb) x 0xf7e0fd20
0xf7e0fd20 <__cxa_finalize>:   0x105e04e8
(gdb) x 0x56556199
0x56556199 <main>:   0x04244c8d

Résumons :

• "_ITM_deregisterTMCloneTable" et "__gmon_start__" ne sont pas résolus
• "__cxa_finalize" est résolu
• "_ITM_registerTMCloneTable" est résolu et son adresse est celle de... "main" oO

Disons qu'il ne s'est rien passé et faisons un petit aparté sur "__gmon_start__".
Si j'en crois mes recherches, il s'agit d'une fonction qui sert à démarrer le profiling (avec gprof).
Quand on compile avec l'option "-pg", elle est appelée dans "_init", sinon le symbole ne sert à rien.
Sauf qu'elle est alors dans la section .text et qu'il n'y a pas de relocations.

Bref, regardons maintenant la .plt.got : on n'y trouve qu'une entrée. Toute la question est : pourquoi ?
On remarque que c'est le seul symbole qui est importé parmi les quatre R_386_GLOB_DAT : peut-être est-ce un début de réponse ?
Oui, mais... peut-être pas :

$ readelf -r /usr/lib/x86_64-linux-gnu/libpthread-2.28.so
[...]
Relocation section '.rela.dyn' at offset 0x4e88 contains 69 entries:
[...]
000000000001bfb0  0000000800000006 R_X86_64_GLOB_DAT      0000000000000000 _ITM_deregisterTMCloneTable + 0
000000000001bfb8  0000000c00000012 R_X86_64_TPOFF64       0000000000000000 errno@GLIBC_PRIVATE + 0
000000000001bfc0  0000001100000012 R_X86_64_TPOFF64       0000000000000000 __resp@GLIBC_PRIVATE + 0
000000000001bfc8  0000002e00000006 R_X86_64_GLOB_DAT      0000000000000000 __libc_stack_end@GLIBC_2.2.5 + 0
000000000001bfd0  0000003400000006 R_X86_64_GLOB_DAT      0000000000000000 _rtld_global_ro@GLIBC_PRIVATE + 0
000000000001bfd8  0000004a00000006 R_X86_64_GLOB_DAT      0000000000000000 __libc_vfork@GLIBC_PRIVATE + 0
000000000001bfe0  0000004d00000012 R_X86_64_TPOFF64       0000000000000000 __h_errno@GLIBC_PRIVATE + 0
000000000001bfe8  0000005a00000006 R_X86_64_GLOB_DAT      0000000000000000 _ITM_registerTMCloneTable + 0
000000000001bff0  0000005e00000006 R_X86_64_GLOB_DAT      0000000000000000 _rtld_global@GLIBC_PRIVATE + 0
000000000001bff8  0000006100000006 R_X86_64_GLOB_DAT      0000000000000000 __cxa_finalize@GLIBC_2.2.5 + 0
Relocation section '.rela.plt' at offset 0x5500 contains 88 entries:
[...]

$ objdump -D /usr/lib/x86_64-linux-gnu/libpthread-2.28.so | grep "\.plt\.got" -A 10
Déassemblage de la section .plt.got :

00000000000065a0 <__cxa_finalize@plt>:
    65a0:   ff 25 52 5a 01 00       jmpq   *0x15a52(%rip)        # 1bff8 <__cxa_finalize@GLIBC_2.2.5>
    65a6:   66 90                   xchg   %ax,%ax

Déassemblage de la section .text :
[...]

Et c'est raté : où est "__libc_stack_end" par exemple ?

Une hypothèse qui pourrait casser tout ce que j'ai écrit : peut-être que le contenu du binaire que crée GCC à changé depuis je-ne-sais-quelle version (c'est le cas pour les program headers par exemple) ?

En résumé, je suis complètement perdu :'(
Pour reprendre l'exemple du "hello world" plus haut :

• c'est quoi cette histoire de "_ITM_registerTMCloneTable" qui est résolu en "main" ??
• y-a-t'il un quelconque intérêt à mettre des relocations inutiles ("__gmon_start__") ?

Pour ce qui est de "__gmon_start__", la relocation est d'autant plus inutile que quand l'option "-pg" est passée au compilateur, la fonction est copiée dans .text donc c'est quoi ce ... ??
Sauf que je l'ai aussi parfois vue dans .plt.got (une vieille version de libgcc_s.so.1 par exemple), d'où l'hypothèse d'un changement au niveau du fonctionnement de GCC.

Et enfin : qu'y a-t'il dans cette section .plt.got ? De manière plus originale, est-il possible de "deviner" son contenu sans désassembler (i.e. à partir de .rel[a].dyn, .dynsym, ou autre) ?

Si vous avez des explications, je suis preneur parce que là, je nage coule
++

Salut,

Tout d'abord, t'aider, pourquoi pas, mais je plussoie la réponse de the_lsd : c'est pas bien clair tout ça.
Parmi tout ce que tu as trouvé sur l'Internet, qu'est-ce que tu as essayé ?

Le "(null)" dans "gcc version (null)" est particulièrement étrange.
J'ai trouvé une seule réponse : https://communities.vmware.com/t5/VMware-Workstation-Player/Can-t-find-gcc-version-to-compile-linux-kernel-modules/m-p/2291605/highlight/true#M28807

Pour résumer ce que je viens de dire : en fait, j'en sais rien donc je ne peux pas t'aider
En conséquence, je ne te promet absolument rien en ce qui concerne le lien ci-dessus.

Bon courage...
++

Salut,

j’utilise l’éditeur OllyDbg (V1)

Je comprendrai jamais pourquoi certaines personnes restent sur la v1 (coucou the lsd ), mais passons.

J’ai donc commencé sur un logiciel ou les solutions basiques ne fonctionnent pas.

Lequel ? Quel type de logiciel (PE/ELF/...) ? Un seul fichier ou plusieurs ? (légal ?)
Quelles "solutions basiques" ?
Sans un minimum de détails ça va être compliqué de te répondre...

J’aimerais savoir s’il existe des programmes tiers permettant dans mon cas de m’indiquer ou s’ouvre certaines fenêtres (voir de pouvoir les éditer) qui sont masquées dans le code principale ainsi que leurs messages ? Difficile de mettre un BP sur des milliers de lignes pour trouver l’action qui ouvre tel ou tel fenêtre.

T'as déjà ResHacker (que tu cites plus haut) qui va te donner des infos.
Il existe aussi plein de tools spécifiques au langage de prog utilisé pour développer le logiciel que t'essayes d'analyser qui te simplifieront la vie.
Et pour savoir quel est le langage en question, certains détecteurs de packer arrivent à te donner l'info.

Ou pour les plus aguerris des conseils pour avancer dans ma démarche. Merci.

Pour pouvoir poser ces questions, tu t'es inscrit sur un site de challs où il y a une catégorie "Crackme" : pas besoin d'être aguerri pour te conseiller d'y jeter un coup d'oeil

++

Salut,

Je serais curieux de savoir comment ils font pour "entrer" dans le smartphone.
Ca me rappelle l'histoire d'il y a quelques temps aux USA où la justice voulait accéder aux infos dans un iPhone et Tim Cook leur a répondu fuck.

Hello, c'est clair qu'au début un vide juridique permettra le libre accès permettant les dérives ou investigation (tout dépendra du point de vue), mais rapidement la législation, fixera un cadre clair là dessus.

Et on l'appellera la loi sur le renseignement #2 ?
[troll mais pas tant que ça] Elle consistera à autoriser ce qui était déjà fait illégalement (mais faut pas le dire). [/troll]

++

**No Sms**,

Pouvez-vous m'indiquer quel décompilateur JAVA vous utilisez ?
J'en ai essayé 2 et ils me renvoient des erreurs à chaque tentative.

Merci

Salut,

Aurais-tu posé la même question dans "Tiens une applet" ?
Chall que tu as résolu depuis (voire même avant ton message, si j'en crois les heures affichées... bizarre ^^)

Bref, en ce qui me concerne, ça marche très bien avec un décompilateur open-source et gratuit.
En plus, c'est la première entrée dans Google et la deuxième dans DuckDuckGo. Google gagne :'(
Autrement dit, tu devrais réussir à le trouver.

++

Salut les jolitoutous,

Vous le savez sûrement (ou peut être pas), Newbie Contest est sponsor/partenaire/staff/whatever de RTFM et de l'événement SigSegV2.
Grâce à ça (et aussi parce que c'est nous qui avons les accès BDD de la billetterie ), on a pu voler avoir un token à vous offrir pour l'event !

Évidemment, on va pas juste le balancer ici comme des sales. Il va falloir que vous cherchiez un peu ! On a caché un token quelque part sur le site, et le premier qui le trouve et le poste en réponse à cette news aura le droit à un billet offert (et même signé par le staff NC si vous voulez). Afin d’éviter toute éventuelle tentative de triche, tout message contenant le token mais ayant été modifié sera ignoré.
Oh, et pas là peine de chercher une faille ou quoi pour le trouver, il est simplement affiché.

Pour les infos sigsegv2 : ça se passe de samedi 10h10, à dimanche 10h10, à epitech Kremlin, 24 Rue Pasteur, 94270, le Kremlin Bicêtre. (Malheureusement, on ne peut pas accepter les mineurs, désolé.)

Have fun

La team Newbie Contest

Salut,
Comme apparemment personne ne réagit, je prend : NC{SIGSEGv2_PrEmIeR_aRriVe_PrEmIeR_sErVi}
Vous avez quand même le droit de chercher où il est caché :p
++

Bonjour,

J'ai vu que dans le forum il était indiqué que le code azlchz fonctionnait.
Quand je calcule le sum de ce code, il me donne 3696618, et non 3696619 comme le code JS le demande.
C'est d'ailleurs plutôt normal puisque le sum ne peut être qu'un multiple de 2 ou de 5.
A quel endroit fais-je une erreur dans mon interprétation du code ?

Merci de votre réponse.

Salut,

T'expliquer pourquoi tu te trompes reviendrait à te donner la réponse...
Je te confirme qu'avec "azlchz" tu obtiens bien 3696619.
Disons donc juste que tu as zappé un "détail".
Peut-être que tu as commencé par la fin ?

Courage, tu es tout près
++

[il faut exécuter en admin.]

Salut,

Pourquoi tu fais ça lsd bon sang... Tu devrais t'occuper de bosser pour NCv6 plutôt...

Rien que pour ça je sais pas pourquoi je te répond :p

W10 [...] Olly 1.1 [...] Olly 2

Je viens de tester (oui, même avec Olly 1.1 ) et pas de problème.
Au premier lancement il m'a fait remarquer que les versions des DLL dataient de l'âge de pierre et après lui avoir répondu que j'étais au courant c'était tout bon.
Seule restriction : il faut exécuter en admin.

j'ai jamais eu confiance dans la v2

Pourquoi donc ?

++

(Edit) petite précision : j'ai vérifié que le binaire s'exécute, que je peux mettre des BPs, etc, mais je n'ai pas testé la résolution en elle-même

Salut,

Or le bit à 1 comme tu le dis nikost ne fait pas partie du padding il est toujours ajouté par sha1 quelque soit la taille des données utiles à hasher.

La longueur du message est également ajoutée dans tous les cas : seul le padding est optionnel.

Pour présenter d'une façon qui - selon moi - fait moins mal à la tête que celle de nikost (:p), ce que tu donnes en entrée à l'algorithme il le traite comme étant uniquement le message.
Autrement dit, il ne se demande pas si (0x80 [+ padding] + taille sur 8 octets) ont été ajoutés au préalable.
Et donc, ici, tu calcules le hash de deux messages différents.

Pech.

Salut,
C'est probable qu'il y en ait... mais comme la première partie de chaque challenge consiste à trouver la faille, n'espère pas qu'on te les liste :p
Va falloir tous les résoudre, bonne nouvelle non ?
En plus, tu vas "te frotter" à toutes sortes de failles donc c'est pas du temps perdu
Pech.

Salut,
Je vois pas trop l'intérêt de supprimer ton compte mais quoi qu'il en soit tu peux aller sur IRC / Discord (cf. "Liens utiles" en haut de chaque page) pour en parler.
Sinon, attends qu'un admin lise ton post et te réponde.
Pech.
PS : non, ce n'est probablement pas un bug. C'est juste que tu dois être le premier à le demander ^^

Quand j'exécute la commande donnée, j'ai une erreur "data type".

@ceux que ça peut intéresser :
Après discussion avec solden, ne faites pas les boulets comme moi.
Pour que ça marche il faut récupérer "Asm(" dans le menu "CATALOG" puis "prgmCRACKME" dans le menu "PRGM".

Salut,
Quand j'exécute la commande donnée, j'ai une erreur "data type".
Au vu du nombre de validations il semble évident que le problème vient de moi mais je vois pas du tout.
Quelqu'un aurait-il eu le même problème ?