reynaudd a écrit 3 commentaires

  • [^] # Re: Malware

    Posté par  . En réponse à la dépêche OpenCL, en version 1.0. Évalué à 2.

    > pourquoi les slides disent qu'on ne sait pas analyser le PTX ?

    je ne l'ai pas mentionné dans les slides mais le bout de code PTX que je montre a été obtenu avec decuda justement. Le problème c'est qu'il s'agit d'un programme non officiel et virtuellement non maintenu. Au passage on peut noter l'effort héroïque de l'auteur qui s'est cogné le reverse d'un format propriétaire non documenté...


    > il suffit de lancer les utilitaires et de lire l'assembleur

    c'est un peu la seule option qui reste pour analyser le code en effet. Mais s'il est packé, on l'a dans l'os.
  • [^] # Re: Malware

    Posté par  . En réponse à la dépêche OpenCL, en version 1.0. Évalué à 4.

    > Hum, dans ce cas la partie H est un virus classique et je pense qu'il sera facile à identifier.

    Non pas forcément. H peut très bien être un interpréteur de commandes genre bash, et D peut être un programme dont la sortie est une liste de commandes. L'analyse de H ne révèle rien sur le comportement de H+D.


    > De toute manière, les pirates développent rarement des malwares très intelligents.

    C'est vrai mais on en trouve quand même de temps en temps des biens faits, genre Rustock.C. Dans tous les cas, c'est mon job de les étudier :)


    > en théorie le virus ultime est très effrayant car il serait totalement indétectable

    un virus totalement indétectable n'existe pas
  • [^] # Re: Malware

    Posté par  . En réponse à la dépêche OpenCL, en version 1.0. Évalué à 9.

    Bonjour,

    Je suis l'auteur de la présentation dont il est question donc je pense que je peux répondre à certaines questions qui ont été soulevées.


    > Je demande un exemple technique, une raison, même juste une théorie de fonctionnement d'un tel malware.

    Pas de problème. On ne peut pas exécuter de code directement sur le GPU, il faut que le code en question soit contenu dans un binaire classique pour la plate-forme cible. Quand on lance le binaire, on a donc:

    - un programme H qui tourne sur le CPU (la partie Hote)
    - un programme D qui tourne sur le GPU (la partie Device)
    - un canal de communication entre les deux (via l'API de CUDA/OpenCL/Larrabee/n'importe)

    Donc au lieu d'avoir un programme classique P sur CPU, on a deux programmes sur deux processeurs qui communiquent. On ne peut pas en faire plus ni moins qu'avant, mais si on peut programmer P pour être un malware, on peut aussi le faire avec H et D.

    Ce qui a pu provoquer une confusion, c'est que je ne m'intéresse ensuite qu'à la partie D mais elle ne peut évidemment pas s'exécuter toute seule, elle a besoin de H pour pouvoir se lancer.

    D'autre part, D ne peut pas faire d'appels système directement, il ne peut que demander à H de les faire pour lui. Donc c'est forcément H qui va exécuter la charge finale du malware (ouverture de sockets, vols de cookies, de mots de passe...). D'une certaine manière, le malware c'est juste H, mais c'est un H qui communique avec un truc, et ce truc m'intéresse.


    > une partie avec des bouts de malwares pour x86 donc non pertinent pour ce qui nous intéresse

    ce que je dis dans cette partie, c'est que ce bout de code x86 aurait été beaucoup plus difficile à analyser s'il avait été compilé pour le GPU.


    > une partie sur la retro ingenierie qu'il n'a pas faite (aucun détail sur le fonctionnement de la protection mémoire sur GPU, par exemple qui pourrait expliquer qu'on puisse faire des malware)

    on n'a pas besoin de savoir comment marche la protection mémoire sur GPU pour faire du reverse. Ce qu'on doit savoir, c'est comment désassembler le code, le débugger et l'émuler.


    > une partie sur le packing, encore une fois avec les principes de fonctionnement x86, et aucune idée sur comment le faire marcher sur GPU

    j'essaie de voir si on peut appliquer le packing à la x86 au code sur GPU. La réponse est: "la vache c'est pas gagné, le plus simple est encore de coder sa propre machine virtuelle sur le GPU".