"Malware developers may choose to use a rare programming language to avoid detection, as reverse engineers may not be familiar with Nim's implementation, or focused on developing detection for it, and therefore tools and sandboxes may struggle to analyze samples of it," the researchers said.
Je comprends pas ça. Qu’est ce qu’il y a de fondamentalement différent entre un logiciel écrit en C, en Rust, en Go ou en Nim une fois compilé ?
Spécifiquement sur le point de la détection (“or focused on developing detection for it”), à ma connaissance les antivirus fonctionnent globalement sur 2 modèles : détecter des signatures (ce fichier contient cette séquence de bits signalée comme étant le virus X dans ma base de données) et détecter des comportements (ce process tente d’ouvrir le fichier foo, après avoir appelé le syscall bar, c’est un comportement de cheval de Troie). En quoi Nim empêche ce genre de détection et pourquoi il faudrait coder des choses spécifique pour ce langage ?
Les antivirus détectent des "signatures" assez vagues finalement. Par exemple, la plupart des exécutables compressés sont détectés comme suspects. Avoir un compilateur qui utilise des instructions un peu différentes ou pas mises dans le même ordre peut alors être suffisant pour échapper à ce type de détection générique.
Mais je pense que l'argument est plutôt du côté des outils d'ingénierie inverse comme Ghidra. Ce genre d'outil connaît le fonctionnement des compilateurs courants, et permet par exemple de regénérer du code C++ à partir du binaire, en détectant les vtable car le code pour y accéder est facilement reconaissable. Si un hrogramme utiliseun autre langage, il faut développer les outils nécessaires dans Ghidra (ou équivalent) pour reconnaître les bouts de codes typiques et regénérer un code source lisible correspondant.
On doit pouvoir s'y retrouver à peu près sans ça (en générant un truc qui ressemble à du C) mais ça sera moins lisible. Par exemple il peut y avoir des pointeurs de fonctions dans tous les sens. Oubien des trucs qui ne se représe/tent pas bien en C, comme des coroutines.
Rien de vraiment bloquant, mais ça fait perdre du temps (ou gagner du temps pour l'attaquant).
Sur la page de Nim : «The Nim compiler and the generated executables support all major platforms like Windows, Linux, BSD and macOS.»… ça peut en effet être très intéressant pour écrire une vérole qui soit installable sur tous les OS.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
# Différence entre les langages
Posté par Anonyme . Évalué à 3.
Je comprends pas ça. Qu’est ce qu’il y a de fondamentalement différent entre un logiciel écrit en C, en Rust, en Go ou en Nim une fois compilé ?
Spécifiquement sur le point de la détection (“or focused on developing detection for it”), à ma connaissance les antivirus fonctionnent globalement sur 2 modèles : détecter des signatures (ce fichier contient cette séquence de bits signalée comme étant le virus X dans ma base de données) et détecter des comportements (ce process tente d’ouvrir le fichier foo, après avoir appelé le syscall bar, c’est un comportement de cheval de Troie). En quoi Nim empêche ce genre de détection et pourquoi il faudrait coder des choses spécifique pour ce langage ?
[^] # Re: Différence entre les langages
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 3.
Les antivirus détectent des "signatures" assez vagues finalement. Par exemple, la plupart des exécutables compressés sont détectés comme suspects. Avoir un compilateur qui utilise des instructions un peu différentes ou pas mises dans le même ordre peut alors être suffisant pour échapper à ce type de détection générique.
Mais je pense que l'argument est plutôt du côté des outils d'ingénierie inverse comme Ghidra. Ce genre d'outil connaît le fonctionnement des compilateurs courants, et permet par exemple de regénérer du code C++ à partir du binaire, en détectant les vtable car le code pour y accéder est facilement reconaissable. Si un hrogramme utiliseun autre langage, il faut développer les outils nécessaires dans Ghidra (ou équivalent) pour reconnaître les bouts de codes typiques et regénérer un code source lisible correspondant.
On doit pouvoir s'y retrouver à peu près sans ça (en générant un truc qui ressemble à du C) mais ça sera moins lisible. Par exemple il peut y avoir des pointeurs de fonctions dans tous les sens. Oubien des trucs qui ne se représe/tent pas bien en C, comme des coroutines.
Rien de vraiment bloquant, mais ça fait perdre du temps (ou gagner du temps pour l'attaquant).
# Multiplateforme…
Posté par lolop (site web personnel) . Évalué à 2.
Sur la page de Nim : «The Nim compiler and the generated executables support all major platforms like Windows, Linux, BSD and macOS.»… ça peut en effet être très intéressant pour écrire une vérole qui soit installable sur tous les OS.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.