Quand tu insères du code dans un binaire, ça décale tout le code de diffèrentes manières.
Je n'ai toujours pas compris.
Si je modifie la dll "machin.dll", et qu'il y a un bug dans la dll "truc.dll", comment "truc.dll" peut-il être décalé ? comment le débugage de truc.dll m'informe du contenu de machin.dll ?
Même si truc.dll renvoie des informations sur machin.dll, pourquoi est-ce que ces informations seraient traitées si le bug n'a rien à voir avec cette partie (d'autant plus que traiter ces informations ne servent à rien à la résolution du bug: quand je cherche à fixer un bug, j'identifie d'abord où il a lieu, je ne perds pas mon temps à vérifier que le code est le même ailleurs alors qu'a priori, il l'est)
Le code assembleur (et son ordre et sa taille), si je ne m'abuse, dépend aussi de l'état de la machine et du compilateur, qui peut optimiser différemment selon les cas (et l'optimisation change le contenu des instructions à l'intérieur d'une même fonction).
Du coup, je ne comprends pas trop cette histoire de lignes.
Si ton debugger à un moment te dit qu'il y a un appel de fonction, et tu vois une ligne de code disant "int a = 4+20;", tu sais qu'il y a qqe chose qui foire.
Tu me parles de correspondance de ligne dans le code source.
Mais:
1) le débuggeur, sans symbole de débuggage, n'est pas capable de retrouver la ligne.
2) avec symbole de debuggage, il suffit de modifier la source pour compenser le décalage (par exemple en écrivant plusieurs instructions sur une seule ligne: "int a = 4+20;int b = 5+20;..."). Évidemment, si le programmeur va voir la ligne correspondant à "int b = 5+20;", il verra le problème. Mais il ne va pas vérifier un à un tout les éléments (surtout qu'il part du principe qu'il n'y a pas eu de modification de code).
faudrait que le gars arrive à faire son changement dans l'intervalle entre la génération des binaires et leur signature
On parle d'une modification prévue dans le workflow. Le scenario n'est pas un méchant espion infiltré chez MS, mais une collaboration volontaire entre la direction et la NSA, par exemple.
Évidemment, la plupart des employés ne sont pas informé de ce workflow, tout comme les employés ne sont pas informé des fraudes fiscales prévues dans le workflow dans certaines entreprises.
Non du tout, c'est très différent. Si tu prends le cas de Microsoft, ou Amazon, ou Google, ... t'as des centaines et centaines (voire milliers selon les projets hein) de développeurs/testeurs, t'as quelque dizaines de managers de 1-2ème niveau, et au dessus c'est le "haut management".
Mais, c'est également le cas de tout ce qui concerne le département financier: il y a des tas de gens en charge de différent budgets, avec des tas de contrôle tout autour.
Mais on sait que ça n'a pas empêché dans certaines grandes compagnies des malversations financières.
En pratique, pour une personne interne, surtout si c'est en accord avec la direction, il y a toujours moyen de contourner le système.
D'un côté, on sait que, par exemple, la fraude fiscale en entreprise est une réalité, alors qu'elle requiert de contourner un système très très contrôlé par l'entreprise (vu que l'entreprise ne veut surtout pas qu'un employé lui vole son argent). Du coup pourquoi c'est impossible avec le code ? Et si c'est le cas, pourquoi les entreprises n'utilisent pas un système identique pour le département des finances (pour prouver qu'ils ne fraudent pas) ?
[^] # Re: Compléments
Posté par j-c_32 . En réponse au journal tor et la nsa. Évalué à 3.
Je n'ai toujours pas compris.
Si je modifie la dll "machin.dll", et qu'il y a un bug dans la dll "truc.dll", comment "truc.dll" peut-il être décalé ? comment le débugage de truc.dll m'informe du contenu de machin.dll ?
Même si truc.dll renvoie des informations sur machin.dll, pourquoi est-ce que ces informations seraient traitées si le bug n'a rien à voir avec cette partie (d'autant plus que traiter ces informations ne servent à rien à la résolution du bug: quand je cherche à fixer un bug, j'identifie d'abord où il a lieu, je ne perds pas mon temps à vérifier que le code est le même ailleurs alors qu'a priori, il l'est)
Le code assembleur (et son ordre et sa taille), si je ne m'abuse, dépend aussi de l'état de la machine et du compilateur, qui peut optimiser différemment selon les cas (et l'optimisation change le contenu des instructions à l'intérieur d'une même fonction).
Du coup, je ne comprends pas trop cette histoire de lignes.
Tu me parles de correspondance de ligne dans le code source.
Mais:
1) le débuggeur, sans symbole de débuggage, n'est pas capable de retrouver la ligne.
2) avec symbole de debuggage, il suffit de modifier la source pour compenser le décalage (par exemple en écrivant plusieurs instructions sur une seule ligne: "int a = 4+20;int b = 5+20;..."). Évidemment, si le programmeur va voir la ligne correspondant à "int b = 5+20;", il verra le problème. Mais il ne va pas vérifier un à un tout les éléments (surtout qu'il part du principe qu'il n'y a pas eu de modification de code).
On parle d'une modification prévue dans le workflow. Le scenario n'est pas un méchant espion infiltré chez MS, mais une collaboration volontaire entre la direction et la NSA, par exemple.
Évidemment, la plupart des employés ne sont pas informé de ce workflow, tout comme les employés ne sont pas informé des fraudes fiscales prévues dans le workflow dans certaines entreprises.
Mais, c'est également le cas de tout ce qui concerne le département financier: il y a des tas de gens en charge de différent budgets, avec des tas de contrôle tout autour.
Mais on sait que ça n'a pas empêché dans certaines grandes compagnies des malversations financières.
En pratique, pour une personne interne, surtout si c'est en accord avec la direction, il y a toujours moyen de contourner le système.
D'un côté, on sait que, par exemple, la fraude fiscale en entreprise est une réalité, alors qu'elle requiert de contourner un système très très contrôlé par l'entreprise (vu que l'entreprise ne veut surtout pas qu'un employé lui vole son argent). Du coup pourquoi c'est impossible avec le code ? Et si c'est le cas, pourquoi les entreprises n'utilisent pas un système identique pour le département des finances (pour prouver qu'ils ne fraudent pas) ?