Intéressant. Je ne savais pas que les priorités d’opérateur n’étaient pas normées dans tous les langages….



Concrètement si int x = 1; printf(” %d %d %d\n”, ++x, x, x++); peut donner 1,2,3 en résultat je me demande pourquoi il existe ++X et X++ ….



Quoi qu’il en soit, et si c’est avéré (mais là je demande des sources, parce que pour moi et mes 10 ans d’xp de dev les priorités d’opérateur c’est normé par langage…), je ne vois pas en quoi c’est impactant….



Le principe même d’un compilateur c’est de fournir du code machine, ce qui fait que tu n’auras jamais de sources dans un exe, hors même en admettant que le résultat de l’instruction ci-dessus soit 1,2,3 parce que le compilateur a décidé de dire fuck à 20 ans de normes de code, le résultat binaire effectivement analysé par l’anti-virus sera dans tous les cas bien différent….



Qu’on ne puisse pas analyser automatique la finalité d’un exe je veux bien, notamment parce que divers techniques d’obfuscation peuvent rendre les choses tordues… ou que le résultat va dépendre de l’architecture du processeur employé à la limite…. mais  que l’on me dise que c’est parce que les compilateurs font ce qu’ils veulent j’ai plus de mal déjà. J’aimerai plus de matériaux pour comprendre parce que là c’est contradictoire avec l’intégralité de mon expérience….

Z-os a écrit :



++x et x++ existent par ce que suivant la logique d’un algorithme on peut avoir besoin de l’un ou de l’autre. Il n’est pas pertinent d’avoir les deux dans une même instruction, généralement on suppose que le programmeûr ne fera pas n’importe quoi. Le cas n’étant pas attendu, il compilera au mieux suivant une mécanique précise, au pire prendra une des possibilités au hasard en fonction de son état interne.

   Peut-être un warning pour la plupart des compilateurs concernés ?

  Bah justement. Autant je conçois qu'un cout >> ++i++; soit complètement incompréhensible pour un compilateur (ça tombe bien ça compile pas), autant un int x=1;sprintf('%d%d%d', ++x, x, x++) pour moi c'est des instructions différentes (ou plutôt différées).        


           


  Plus simplement, traduit en ASM ça donne quelque chose comme :         


  \_enregistre la valeur 1 dans le registre X        


  \_enregistre une valeur char* valant %d%d%d dans le registre Y        


  \_Incrémente la valeur du registre X de 1        


  \_remplace le premier %d du registre Y par la valeur contenue dans le registre X        


  \_remplace le deuxième %d du registre Y par la valeur contenue dans le registre X        


  \_remplace le troisième %d du registre Y par la valeur contenue dans le registre X        


  \_incrémente la valeur du registre X de 1        

   Je suis pas spécialisé en compilateur mais ça me semble un cas assez simple....    

Pour être franc, ma spécialité c’est de l’interprété et j’ai vu des cas bien plus complexes que ça (certains où l’interpréteur se casse les dents d’ailleurs), mais j’ai aussi fait pas mal de compilé et je vois pas un compilateur se planter sur un cas aussi simple… je peux me tromper mais j’aimerais une source….

Edit 2 (c’est pas bien je sais) : à la limite j’aurais trouvé un cas comme int x=1;sprintf(‘%d%d%d’, x++ , x, x++); nettement plus tordu….

Sauf que tu stock pas des valeurs (ni des params) dans la pile mais des registres….



Et à partir de là, si tu utilises 3 fois la même variable c’est 3 fois le même registre appelé… donc une modif du registre en 1 va impacter le registre en 3…



Encore une fois, je suis pas spécialiste d’un niveau si bas… et hors théories et vieux souvenirs c’est médiocre pour rester gentil. Sauf que là je trouve ça illogique….





On va faire plus simple, j’aimerais un exemple concret de situation où cette instruction peut donner autre chose que 2,2,2…. Avec si possible les explications détaillées de ce qui se passe…

Ca me fait penser à la vieille légende du 3-2 = 2 possible par démonstration mathématiques… sauf que en plein milieu de la démonstration il y a un changement de référentiel….

127.0.0.1 a écrit :



Militons pour des OS qui utilisent nativement des sandbox applicatives.



La gestion de la sécurité par des “comptes utilisateurs” n’a pas vraiment de sens sur un PC. Une session de travail est typiquement mono-utilisateur, mais multi-application. Et la menace vient surtout des applications de la session actuelle de l’utilisateur, plutôt que des actions d’autres utilisateurs du PC.



La sécurité devrait se focaliser sur le cloisonnement des applications plutôt que sur celui des utilisateurs.





C’est le cas des OS modernes non ?



Genre windows 8 fait tourner tout le RT en sandbox de mémoire…

Gu0sur20 a écrit :



Pour revenir à la news, le but d’un anti-virus est de déterminer si un “programme” (script, exe, etc) est malicieux ou non ; sans pour autant l’exécuter parce ce que sinon la machine sera infectée. Or sur cette question là précise  on sait depuis longtemps qu’il n’est pas possible de savoir ce que fait un programme en lisant ses instructions. Du coup la seule option qui s’offre à un anti-virus est de faire du “best effort”, c’est à dire comparer les instructions du programme avec des modèles de programme reconnus comme malveillant : la fameuse base de signature.

Pour l'exemple ASM que tu me demandes, il suffit de jeter un œil à l'ABI Intel (ou AMD comme tu préfères). J'ai pris une instruction au hasard, mais regardes la description de l'instruction AAD. Déjà celle-ci n'est pas valide pour une exécution en 64 bits mais en 32 elle l'est. Ensuite, les registres  OF, AF, et CF sont dans un état non-défini après exécution, c'est à dire que si l'instruction suivante prend en entrée la valeur de l'un de ces registres, cela va faire quelque chose mais tu ne peut pas prédire quoi. Du coup la seule façon de savoir ce que ça fait c'est de faire une exécution.   

OK, différences de vocabulaire, peut être une légère confusion dur les relations entre haut et bas niveaux,  mais l’idée est là… tes termes initiaux étaient mal choisis (faut pas trop “vulgariser” - est ce que donner en exemple une suite d’instructions C c’est vulgariser ?  - ici ; après tu tombes sur des casses burnes comme moi ou brazonyma qui te demandent des comptes).



 En tous cas discussion très intéressante, j’ai beaucoup appris. Merci " />





PS : ceci étant il y a différents modèles d’antivirus, de mémoire un programme comme fsecure ne fonctionne justement pas sur ce principe de reconnaissance (mais j’avoue que j’ai aucune idée de comment il fonctionne).



PPS : finalement ce que tu dis c’est qu’il est impossible de prédire l’état d’un registre qui peut potentiellement contenir du code arbitraire qui sera éventuellement exécuté par le programme sans exécuter le dit-programme. Là on est parfaitement d’accord…. a la condition sine qua non que l’anti virus s’exécute dans le contexte de la sandbox. Si comme sur les OS modernes l’antivirus s’exécute tant au niveau applicatif que système (je hais la relation entre windows 8 et l’innoDB…), tu ne risques pas grand chose, car si la partie applicative sera certainement trompée, la partie système devrait détecter la tentative d’évasion… on est d’accord ?