On peut compiler les logiciels Microsoft: Ballmer.
21 réponses
GP
En fait, ce sont les gouvernements qui le peuvent selon lui:
«On the particular issues that you highlighted, we have heard the concern, for
example, on national security from a number of governments.We do license our
source code to governments. Governments can look at that source code, see that
source code.»
Titre: What, exactly, did Microsoft's CEO say about Linux and patents? Here's
the transcript.
Mais bon, C'est bien beau d'avoir le code source, si on ne le compile pas, on
ne peut pas savoir si l'exécutable est bien compilé à partir de ce code.
Alors quoi, on y est, là? Les gouvernements peuvent employer les logiciels de
Microsoft en les compilant à partir du code? Est-ce que quelqu'un a déjà
entendu parler de ça?
Mais le passage qui a mis tout le monde du libre en furie, c'est celui-ci:
«There was a report out this summer by an open source group that highlighted
that Linux violates over 228 patents. Some day, for all countries that are
entering WTO (World Trade Organization), somebody will come and look for money
to pay for the patent rights for that intellectual property. So the licensing
costs are less clear than people think today.»
How sweet! La menace est directe. Adoptez Linux et, ou vous payerez des prix
de fou pour des brevets bouffons, ou vous ne pourrez participer au WTO.
Sauf que le WTO, ça profite à qui? J'ai l'impression qu'il y a plusieurs pays,
entre autres, en Asie, qui s'en passeraient volontiers si seulement une
organisation vraiment égalitaire prenait sa place.
Au sujet du WTO:
The restructuring of the world economy under the guidance of the
Washington-based international financial institutions and the World Trade
Organization (WTO) increasingly denies individual developing countries the
possibility of building a national economy. The internationalization of
macroeconomic policy transforms countries into open economic territories and
national economies into "reserves" of cheap labor and natural resources. The
state apparatus is undermined, industry for the internal market is destroyed,
national enterprises are pushed into bankruptcy These reforms have also been
conducive to the elimination of minimum wage legislation, the repeal of social
programs and a general diminution of the state's role in fighting poverty.
http://www.mtholyoke.edu/acad/intrel/chossu.htm
On excusera mon soi-disant manque d'objectivité, mais Microsoft me fait gerber.
Disons, selon ma - très courte - expérience des contrats sensibles, que celà doit être exposé dés le départ, et qu'une liste *exhaustive et limitative* des personnes ayant un accès au code figure dans le contrat.
Quant au code, tu ne m'as toujours pas dit si on pouvait le compiler pour obtenir le logiciel.
Non. Microsoft donne juste accès au code, «à des fins d'audit» et même à mon avis il faut se déplacer sur un site de Microsoft, qui organise une «Data Room». C'est comme ça qu'on procède pour les audits financiers, les audits Juridique (audit des contrats, fréquent lors de fusions ou cessions d'acifs), lors des contrôles fiscaux ...
Écoute, je débarque, là! Cette esbrouffe n'a aucun sens.
Ben oui, c'est du marketing : «avec nous aussi on peut auditer le code source».
Ouais, on regarde mais on touche pas ...
Désolé, Fred. Si tu ne peux pas compiler le code, tu ne sais pas si l'exécutable correspond au code fourni.
Ton expérience en contrats sensibles doit effectivement être très courte. Plus courte que la mienne, ce qui n'est pas peu dire.
GP
Fred wrote:
Le 04-12-2004, GP <gilpel@inverse.nretla.org> a écrit:
Disons, selon ma - très courte - expérience des
contrats sensibles, que celà doit être exposé dés le départ, et qu'une liste
*exhaustive et limitative* des personnes ayant un accès au code figure dans
le contrat.
Quant au code, tu ne m'as toujours pas dit si on pouvait le compiler pour
obtenir le logiciel.
Non. Microsoft donne juste accès au code, «à des fins d'audit» et même à mon avis
il faut se déplacer sur un site de Microsoft, qui organise une «Data Room».
C'est comme ça qu'on procède pour les audits financiers, les audits Juridique
(audit des contrats, fréquent lors de fusions ou cessions d'acifs), lors des
contrôles fiscaux ...
Écoute, je débarque, là! Cette esbrouffe n'a aucun sens.
Ben oui, c'est du marketing : «avec nous aussi on peut auditer le code source».
Ouais, on regarde mais on touche pas ...
Désolé, Fred. Si tu ne peux pas compiler le code, tu ne sais pas si
l'exécutable correspond au code fourni.
Ton expérience en contrats sensibles doit effectivement être très courte. Plus
courte que la mienne, ce qui n'est pas peu dire.
Disons, selon ma - très courte - expérience des contrats sensibles, que celà doit être exposé dés le départ, et qu'une liste *exhaustive et limitative* des personnes ayant un accès au code figure dans le contrat.
Quant au code, tu ne m'as toujours pas dit si on pouvait le compiler pour obtenir le logiciel.
Non. Microsoft donne juste accès au code, «à des fins d'audit» et même à mon avis il faut se déplacer sur un site de Microsoft, qui organise une «Data Room». C'est comme ça qu'on procède pour les audits financiers, les audits Juridique (audit des contrats, fréquent lors de fusions ou cessions d'acifs), lors des contrôles fiscaux ...
Écoute, je débarque, là! Cette esbrouffe n'a aucun sens.
Ben oui, c'est du marketing : «avec nous aussi on peut auditer le code source».
Ouais, on regarde mais on touche pas ...
Désolé, Fred. Si tu ne peux pas compiler le code, tu ne sais pas si l'exécutable correspond au code fourni.
Ton expérience en contrats sensibles doit effectivement être très courte. Plus courte que la mienne, ce qui n'est pas peu dire.
GP
nicolas vigier
On 2004-12-04, GP wrote:
Emmanuel Florac wrote:
Quant au code, tu ne m'as toujours pas dit si on pouvait le compiler pour obtenir le logiciel.
NOn, c'est absolument interdit. Tu n'as que le droit de le lire
Hé, s'ils fournissent le code, ou une partie du code, à /certains/ niveaux de gouvernements, je suppose que c'est pour le lire, non?
Ha mais ils font deja l'effort de leur fournir le code par ce que ca fait bien, tu voudrais pas en plus qu'ils en autorisent la lecture ?
Écoute, je débarque, là! Cette esbrouffe n'a aucun sens.
Ben oui, c'est du marketing : «avec nous aussi on peut auditer le code source».
Ouais, on regarde mais on touche pas ...
Désolé, Fred. Si tu ne peux pas compiler le code, tu ne sais pas si l'exécutable correspond au code fourni.
J'en suis très conscient, cela dit, on «tire des plans sur la comète», la vérité est qe personne ici ne sait exactement si oui on non les personnes admises à auditer les codes sources de Microsft on le droit ou non de le compiler. Si ça trouve, ils en on le droit.
Ton expérience en contrats sensibles doit effectivement être très courte. Plus courte que la mienne, ce qui n'est pas peu dire.
Mais, mais ,mais ... serais tu /vieux/ et moi /jeune/ ?
GP
Fred
-- [11:39] <Arold>: 8h [11:39] <obionedtc>: 18h putain [11:39] <Arold>: euh oui 18h -+- : in Guide du Petit Joueur: t'as quelle heure, toi ? -+-
Le 05-12-2004, GP <gilpel@inverse.nretla.org> a écrit:
Fred wrote:
Le 04-12-2004, GP <gilpel@inverse.nretla.org> a écrit:
Écoute, je débarque, là! Cette esbrouffe n'a aucun sens.
Ben oui, c'est du marketing : «avec nous aussi on peut auditer le code source».
Ouais, on regarde mais on touche pas ...
Désolé, Fred. Si tu ne peux pas compiler le code, tu ne sais pas si
l'exécutable correspond au code fourni.
J'en suis très conscient, cela dit, on «tire des plans sur la comète»,
la vérité est qe personne ici ne sait exactement si oui on non les
personnes admises à auditer les codes sources de Microsft on le droit
ou non de le compiler.
Si ça trouve, ils en on le droit.
Ton expérience en contrats sensibles doit effectivement être très courte. Plus
courte que la mienne, ce qui n'est pas peu dire.
Mais, mais ,mais ... serais tu /vieux/ et moi /jeune/ ?
GP
Fred
--
[11:39] <Arold>: 8h
[11:39] <obionedtc>: 18h putain
[11:39] <Arold>: euh oui 18h
-+- : in Guide du Petit Joueur: t'as quelle heure, toi ? -+-
Écoute, je débarque, là! Cette esbrouffe n'a aucun sens.
Ben oui, c'est du marketing : «avec nous aussi on peut auditer le code source».
Ouais, on regarde mais on touche pas ...
Désolé, Fred. Si tu ne peux pas compiler le code, tu ne sais pas si l'exécutable correspond au code fourni.
J'en suis très conscient, cela dit, on «tire des plans sur la comète», la vérité est qe personne ici ne sait exactement si oui on non les personnes admises à auditer les codes sources de Microsft on le droit ou non de le compiler. Si ça trouve, ils en on le droit.
Ton expérience en contrats sensibles doit effectivement être très courte. Plus courte que la mienne, ce qui n'est pas peu dire.
Mais, mais ,mais ... serais tu /vieux/ et moi /jeune/ ?
GP
Fred
-- [11:39] <Arold>: 8h [11:39] <obionedtc>: 18h putain [11:39] <Arold>: euh oui 18h -+- : in Guide du Petit Joueur: t'as quelle heure, toi ? -+-
GG
Désolé, Fred. Si tu ne peux pas compiler le code, tu ne sais pas si l'exécutable correspond au code fourni.
J'ai accès aux sources de Microsoft et il me semble que je peux en parler en connaissance de cause. http://www.01net.com/article/221480.html j'en parle même officiellement de cause j'ai fait une presentation aux journées Sécurité de Microsoft pour la quincaille voir : http://download.microsoft.com/download/b/d/f/bdf4b3a6-071b-4c22-bf38-276068234c94/Shared_Source_Initiative.ppt
3 précisions : Premierement on peut parfaitement savoir si le code source auquel on a accès est le bon ou non, a l'aide du Windbg.exe le débogueur kernel de Microsoft si le code source ne correpond pas au binaire on ne peut pas suivre le code pas a pas avec le debogueur, il nous le signale, j'ai déja fait l'experience d'essayer de suivre du code XP en pointant sur du code 2003 on n'aperçoit que de l'assembleur. Il faut imperativement que le code corresponde donc Microsoft ne peut pas nous faire prendre des lanternes pour des vessies :-) même chose pour les services pack et les patch de sécurité.
Deuxiement au niveau du code on a accés a presque tout ce qui se trouve sur les CD OS que l'on peut acheter dans le commerce. Certains modules ne sont pas disponibles, mais sur simple demande on peut recevoir ces routines sur CD pour travailler spécifiquement sur ces parties de code, dans ce cas là il faut installer ce code source livré sur la machine, cela se passe sans soucis, cela concerne essentiellement les fonctions de cryptage et quelques autres fonctions sensibles.
Troisiemement, on peut sur demande aussi recompiler le code pour faire les modifications que l'on souhaite mais effectivement Microsoft nous informe explicitement qu'il ne supporte pas ces bidouilles chose que l'on doit accepter.
Par ailleurs si vous êtes developpeur et que vous souhaitez utiliser un point d'entrée ou une fonctionnalité non documentée, on doit en demander l'avis a Microsoft mais c'est simplement informatif avec un retour de conseils sur la pérénité de ce code ou pas et avec un engagement de notre part si ce code n'est plus disponible dans les autres versions a ne pas attaquer Microsoft, chose encore une fois qui me parait tres acceptable et un engagement de notre part a documenter en interne pour Microsoft la façon donc on utilise cette partie non documentée.
Voilà, j'espère avoir repondu aux bruits de couloir et aux fausses idées reçues.
-- Cordialement GG.
Désolé, Fred. Si tu ne peux pas compiler le code, tu ne sais pas si
l'exécutable correspond au code fourni.
J'ai accès aux sources de Microsoft et il me semble que je peux
en parler en connaissance de cause.
http://www.01net.com/article/221480.html
j'en parle même officiellement de cause j'ai fait une presentation aux
journées Sécurité de Microsoft pour la quincaille voir :
http://download.microsoft.com/download/b/d/f/bdf4b3a6-071b-4c22-bf38-276068234c94/Shared_Source_Initiative.ppt
3 précisions :
Premierement on peut parfaitement savoir si le code source auquel
on a accès est le bon ou non, a l'aide du Windbg.exe le débogueur
kernel de Microsoft si le code source ne correpond pas au binaire
on ne peut pas suivre le code pas a pas avec le debogueur, il nous le
signale, j'ai déja fait l'experience d'essayer de suivre du code XP
en pointant sur du code 2003 on n'aperçoit que de l'assembleur.
Il faut imperativement que le code corresponde donc Microsoft ne
peut pas nous faire prendre des lanternes pour des vessies :-) même
chose pour les services pack et les patch de sécurité.
Deuxiement au niveau du code on a accés a presque tout ce qui
se trouve sur les CD OS que l'on peut acheter dans le commerce.
Certains modules ne sont pas disponibles, mais sur simple demande
on peut recevoir ces routines sur CD pour travailler spécifiquement
sur ces parties de code, dans ce cas là il faut installer ce code
source livré sur la machine, cela se passe sans soucis, cela
concerne essentiellement les fonctions de cryptage et quelques
autres fonctions sensibles.
Troisiemement, on peut sur demande aussi recompiler le code
pour faire les modifications que l'on souhaite mais effectivement
Microsoft nous informe explicitement qu'il ne supporte pas ces
bidouilles chose que l'on doit accepter.
Par ailleurs si vous êtes developpeur et que vous souhaitez utiliser
un point d'entrée ou une fonctionnalité non documentée, on doit en
demander l'avis a Microsoft mais c'est simplement informatif avec
un retour de conseils sur la pérénité de ce code ou pas et avec
un engagement de notre part si ce code n'est plus disponible dans
les autres versions a ne pas attaquer Microsoft, chose encore une
fois qui me parait tres acceptable et un engagement de notre part
a documenter en interne pour Microsoft la façon donc on utilise
cette partie non documentée.
Voilà, j'espère avoir repondu aux bruits de couloir et aux fausses
idées reçues.
Désolé, Fred. Si tu ne peux pas compiler le code, tu ne sais pas si l'exécutable correspond au code fourni.
J'ai accès aux sources de Microsoft et il me semble que je peux en parler en connaissance de cause. http://www.01net.com/article/221480.html j'en parle même officiellement de cause j'ai fait une presentation aux journées Sécurité de Microsoft pour la quincaille voir : http://download.microsoft.com/download/b/d/f/bdf4b3a6-071b-4c22-bf38-276068234c94/Shared_Source_Initiative.ppt
3 précisions : Premierement on peut parfaitement savoir si le code source auquel on a accès est le bon ou non, a l'aide du Windbg.exe le débogueur kernel de Microsoft si le code source ne correpond pas au binaire on ne peut pas suivre le code pas a pas avec le debogueur, il nous le signale, j'ai déja fait l'experience d'essayer de suivre du code XP en pointant sur du code 2003 on n'aperçoit que de l'assembleur. Il faut imperativement que le code corresponde donc Microsoft ne peut pas nous faire prendre des lanternes pour des vessies :-) même chose pour les services pack et les patch de sécurité.
Deuxiement au niveau du code on a accés a presque tout ce qui se trouve sur les CD OS que l'on peut acheter dans le commerce. Certains modules ne sont pas disponibles, mais sur simple demande on peut recevoir ces routines sur CD pour travailler spécifiquement sur ces parties de code, dans ce cas là il faut installer ce code source livré sur la machine, cela se passe sans soucis, cela concerne essentiellement les fonctions de cryptage et quelques autres fonctions sensibles.
Troisiemement, on peut sur demande aussi recompiler le code pour faire les modifications que l'on souhaite mais effectivement Microsoft nous informe explicitement qu'il ne supporte pas ces bidouilles chose que l'on doit accepter.
Par ailleurs si vous êtes developpeur et que vous souhaitez utiliser un point d'entrée ou une fonctionnalité non documentée, on doit en demander l'avis a Microsoft mais c'est simplement informatif avec un retour de conseils sur la pérénité de ce code ou pas et avec un engagement de notre part si ce code n'est plus disponible dans les autres versions a ne pas attaquer Microsoft, chose encore une fois qui me parait tres acceptable et un engagement de notre part a documenter en interne pour Microsoft la façon donc on utilise cette partie non documentée.
Voilà, j'espère avoir repondu aux bruits de couloir et aux fausses idées reçues.
-- Cordialement GG.
batyann811
GG wrote:
Premierement on peut parfaitement savoir si le code source auquel on a accès est le bon ou non, a l'aide du Windbg.exe le débogueur kernel de Microsoft si le code source ne correpond pas au binaire on ne peut pas suivre le code pas a pas avec le debogueur, il nous le signale, j'ai déja fait l'experience d'essayer de suivre du code XP en pointant sur du code 2003 on n'aperçoit que de l'assembleur. Il faut imperativement que le code corresponde donc Microsoft ne peut pas nous faire prendre des lanternes pour des vessies :-) même chose pour les services pack et les patch de sécurité.
Vu que tu as accés au source tu peux me dire en quoi sont écrits les sources de windows ? S'ils sont en C ou C++ je vois pas bien comment tu peux comparer les sources avec ce que te montre un débogueur. A moins d'y passer les 25 prochains sciècles ou bien sûr que tout soit compilé avec les informations de débogage ce qui expliquerait la lourdeur de l'animal.
GG wrote:
Premierement on peut parfaitement savoir si le code source auquel
on a accès est le bon ou non, a l'aide du Windbg.exe le débogueur
kernel de Microsoft si le code source ne correpond pas au binaire
on ne peut pas suivre le code pas a pas avec le debogueur, il nous le
signale, j'ai déja fait l'experience d'essayer de suivre du code XP
en pointant sur du code 2003 on n'aperçoit que de l'assembleur.
Il faut imperativement que le code corresponde donc Microsoft ne
peut pas nous faire prendre des lanternes pour des vessies :-) même
chose pour les services pack et les patch de sécurité.
Vu que tu as accés au source tu peux me dire en quoi sont écrits les
sources de windows ? S'ils sont en C ou C++ je vois pas bien comment tu
peux comparer les sources avec ce que te montre un débogueur. A moins
d'y passer les 25 prochains sciècles ou bien sûr que tout soit compilé
avec les informations de débogage ce qui expliquerait la lourdeur de
l'animal.
Premierement on peut parfaitement savoir si le code source auquel on a accès est le bon ou non, a l'aide du Windbg.exe le débogueur kernel de Microsoft si le code source ne correpond pas au binaire on ne peut pas suivre le code pas a pas avec le debogueur, il nous le signale, j'ai déja fait l'experience d'essayer de suivre du code XP en pointant sur du code 2003 on n'aperçoit que de l'assembleur. Il faut imperativement que le code corresponde donc Microsoft ne peut pas nous faire prendre des lanternes pour des vessies :-) même chose pour les services pack et les patch de sécurité.
Vu que tu as accés au source tu peux me dire en quoi sont écrits les sources de windows ? S'ils sont en C ou C++ je vois pas bien comment tu peux comparer les sources avec ce que te montre un débogueur. A moins d'y passer les 25 prochains sciècles ou bien sûr que tout soit compilé avec les informations de débogage ce qui expliquerait la lourdeur de l'animal.
Michel Billaud
"GG" writes:
Désolé, Fred. Si tu ne peux pas compiler le code, tu ne sais pas si l'exécutable correspond au code fourni.
3 précisions : Premierement on peut parfaitement savoir si le code source auquel on a accès est le bon ou non, a l'aide du Windbg.exe
Non, on ne peut pas.
le débogueur kernel de Microsoft si le code source ne correpond pas au binaire on ne peut pas suivre le code pas a pas avec le debogueur, il nous le signale, j'ai déja fait l'experience d'essayer de suivre du code XP en pointant sur du code 2003 on n'aperçoit que de l'assembleur. Il faut imperativement que le code corresponde donc Microsoft ne peut pas nous faire prendre des lanternes pour des vessies :-) même chose pour les services pack et les patch de sécurité.
On peut rétorquer l'argument du Trojan dans les compilateurs : il se peut très bien que le débuggeur reconnaisse certains executables, et vous mène en bateau dans ce cas là. Vous ne savez que ce que le fabricant du débugger veut bien vous faire voir.
Pour en être sur, il faut un débugger construit de façon indépendante. L'idéal est que le source en soit libre, et compilable sur une large variété d'autres plateformes avec des compilateurs surs (donc non fournis par Microsoft).
MB
-- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
"GG" <news@nospam.assysm.com> writes:
Désolé, Fred. Si tu ne peux pas compiler le code, tu ne sais pas si
l'exécutable correspond au code fourni.
3 précisions :
Premierement on peut parfaitement savoir si le code source auquel
on a accès est le bon ou non, a l'aide du Windbg.exe
Non, on ne peut pas.
le débogueur
kernel de Microsoft si le code source ne correpond pas au binaire
on ne peut pas suivre le code pas a pas avec le debogueur, il nous le
signale, j'ai déja fait l'experience d'essayer de suivre du code XP
en pointant sur du code 2003 on n'aperçoit que de l'assembleur.
Il faut imperativement que le code corresponde donc Microsoft ne
peut pas nous faire prendre des lanternes pour des vessies :-) même
chose pour les services pack et les patch de sécurité.
On peut rétorquer l'argument du Trojan dans les compilateurs : il se
peut très bien que le débuggeur reconnaisse certains executables, et
vous mène en bateau dans ce cas là. Vous ne savez que ce que le
fabricant du débugger veut bien vous faire voir.
Pour en être sur, il faut un débugger construit de façon indépendante.
L'idéal est que le source en soit libre, et compilable sur une large variété
d'autres plateformes avec des compilateurs surs (donc non fournis
par Microsoft).
MB
--
Michel BILLAUD billaud@labri.fr
LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792
351, cours de la Libération http://www.labri.fr/~billaud
33405 Talence (FRANCE)
Désolé, Fred. Si tu ne peux pas compiler le code, tu ne sais pas si l'exécutable correspond au code fourni.
3 précisions : Premierement on peut parfaitement savoir si le code source auquel on a accès est le bon ou non, a l'aide du Windbg.exe
Non, on ne peut pas.
le débogueur kernel de Microsoft si le code source ne correpond pas au binaire on ne peut pas suivre le code pas a pas avec le debogueur, il nous le signale, j'ai déja fait l'experience d'essayer de suivre du code XP en pointant sur du code 2003 on n'aperçoit que de l'assembleur. Il faut imperativement que le code corresponde donc Microsoft ne peut pas nous faire prendre des lanternes pour des vessies :-) même chose pour les services pack et les patch de sécurité.
On peut rétorquer l'argument du Trojan dans les compilateurs : il se peut très bien que le débuggeur reconnaisse certains executables, et vous mène en bateau dans ce cas là. Vous ne savez que ce que le fabricant du débugger veut bien vous faire voir.
Pour en être sur, il faut un débugger construit de façon indépendante. L'idéal est que le source en soit libre, et compilable sur une large variété d'autres plateformes avec des compilateurs surs (donc non fournis par Microsoft).
MB
-- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
Thierry Boudet
On 2004-12-12, GG wrote:
Premierement on peut parfaitement savoir si le code source auquel on a accès est le bon ou non, a l'aide du Windbg.exe le débogueur kernel de Microsoft si le code source ne correpond pas au binaire
Est-ce toi qui a compilé ce Windbg.exe ?
-- _/°< coin
On 2004-12-12, GG <news@nospam.assysm.com> wrote:
Premierement on peut parfaitement savoir si le code source auquel
on a accès est le bon ou non, a l'aide du Windbg.exe le débogueur
kernel de Microsoft si le code source ne correpond pas au binaire
Premierement on peut parfaitement savoir si le code source auquel on a accès est le bon ou non, a l'aide du Windbg.exe le débogueur kernel de Microsoft si le code source ne correpond pas au binaire
Est-ce toi qui a compilé ce Windbg.exe ?
-- _/°< coin
GG
Est-ce toi qui a compilé ce Windbg.exe ?
Pire encore, je l'ai décompilé pour mourir moins bête. -- Cordialement GG.
Est-ce toi qui a compilé ce Windbg.exe ?
Pire encore, je l'ai décompilé pour mourir moins bête.
--
Cordialement
GG.
Pire encore, je l'ai décompilé pour mourir moins bête. -- Cordialement GG.
GG
Michel Billaud wrote:
"GG" writes:
Désolé, Fred. Si tu ne peux pas compiler le code, tu ne sais pas si l'exécutable correspond au code fourni.
3 précisions : Premierement on peut parfaitement savoir si le code source auquel on a accès est le bon ou non, a l'aide du Windbg.exe
Non, on ne peut pas.
le débogueur kernel de Microsoft si le code source ne correpond pas au binaire on ne peut pas suivre le code pas a pas avec le debogueur, il nous le signale, j'ai déja fait l'experience d'essayer de suivre du code XP en pointant sur du code 2003 on n'aperçoit que de l'assembleur. Il faut imperativement que le code corresponde donc Microsoft ne peut pas nous faire prendre des lanternes pour des vessies :-) même chose pour les services pack et les patch de sécurité.
On peut rétorquer l'argument du Trojan dans les compilateurs : il se peut très bien que le débuggeur reconnaisse certains executables, et vous mène en bateau dans ce cas là. Vous ne savez que ce que le fabricant du débugger veut bien vous faire voir.
Pour en être sur, il faut un débugger construit de façon indépendante. L'idéal est que le source en soit libre, et compilable sur une large variété d'autres plateformes avec des compilateurs surs (donc non fournis par Microsoft).
MB
-- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
-- Cordialement GG.
Michel Billaud wrote:
"GG" <news@nospam.assysm.com> writes:
Désolé, Fred. Si tu ne peux pas compiler le code, tu ne sais pas si
l'exécutable correspond au code fourni.
3 précisions :
Premierement on peut parfaitement savoir si le code source auquel
on a accès est le bon ou non, a l'aide du Windbg.exe
Non, on ne peut pas.
le débogueur
kernel de Microsoft si le code source ne correpond pas au binaire
on ne peut pas suivre le code pas a pas avec le debogueur, il nous le
signale, j'ai déja fait l'experience d'essayer de suivre du code XP
en pointant sur du code 2003 on n'aperçoit que de l'assembleur.
Il faut imperativement que le code corresponde donc Microsoft ne
peut pas nous faire prendre des lanternes pour des vessies :-) même
chose pour les services pack et les patch de sécurité.
On peut rétorquer l'argument du Trojan dans les compilateurs : il se
peut très bien que le débuggeur reconnaisse certains executables, et
vous mène en bateau dans ce cas là. Vous ne savez que ce que le
fabricant du débugger veut bien vous faire voir.
Pour en être sur, il faut un débugger construit de façon indépendante.
L'idéal est que le source en soit libre, et compilable sur une large
variété d'autres plateformes avec des compilateurs surs (donc non
fournis
par Microsoft).
MB
--
Michel BILLAUD billaud@labri.fr
LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792
351, cours de la Libération http://www.labri.fr/~billaud
33405 Talence (FRANCE)
Désolé, Fred. Si tu ne peux pas compiler le code, tu ne sais pas si l'exécutable correspond au code fourni.
3 précisions : Premierement on peut parfaitement savoir si le code source auquel on a accès est le bon ou non, a l'aide du Windbg.exe
Non, on ne peut pas.
le débogueur kernel de Microsoft si le code source ne correpond pas au binaire on ne peut pas suivre le code pas a pas avec le debogueur, il nous le signale, j'ai déja fait l'experience d'essayer de suivre du code XP en pointant sur du code 2003 on n'aperçoit que de l'assembleur. Il faut imperativement que le code corresponde donc Microsoft ne peut pas nous faire prendre des lanternes pour des vessies :-) même chose pour les services pack et les patch de sécurité.
On peut rétorquer l'argument du Trojan dans les compilateurs : il se peut très bien que le débuggeur reconnaisse certains executables, et vous mène en bateau dans ce cas là. Vous ne savez que ce que le fabricant du débugger veut bien vous faire voir.
Pour en être sur, il faut un débugger construit de façon indépendante. L'idéal est que le source en soit libre, et compilable sur une large variété d'autres plateformes avec des compilateurs surs (donc non fournis par Microsoft).
MB
-- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
-- Cordialement GG.
GG
Non, on ne peut pas.
Oui on peut.
Pour en être sur, il faut un débugger construit de façon indépendante.
Tout a fait. Avec Winice deboggueur developpé par une société indépendante de Microsoft (ex Numega) on peut parfaitement suivre le code pas avec ce deboggueur noyau. :-)
L'idéal est que le source en soit libre, et compilable sur une large variété d'autres plateformes avec des compilateurs surs (donc non fournis par Microsoft).
J'ai même essayé avec cc qui se trouve dans SFU en gnu est cela fonctionne parfaitement, on rentre dans du code Linux/Unix on appelle le driver NTFS avec ces symboliques ont fait du pas a pas dans le driver en C NTFS et on ressort vers la routine en C. Magique et sous winice et sous windbg. :-)
-- Cordialement GG.
Non, on ne peut pas.
Oui on peut.
Pour en être sur, il faut un débugger construit de façon indépendante.
Tout a fait. Avec Winice deboggueur developpé par une société
indépendante de Microsoft (ex Numega) on peut parfaitement
suivre le code pas avec ce deboggueur noyau. :-)
L'idéal est que le source en soit libre, et compilable sur une large
variété d'autres plateformes avec des compilateurs surs (donc non
fournis par Microsoft).
J'ai même essayé avec cc qui se trouve dans SFU en gnu est
cela fonctionne parfaitement, on rentre dans du code Linux/Unix
on appelle le driver NTFS avec ces symboliques ont fait du pas
a pas dans le driver en C NTFS et on ressort vers la routine en
C. Magique et sous winice et sous windbg. :-)
Pour en être sur, il faut un débugger construit de façon indépendante.
Tout a fait. Avec Winice deboggueur developpé par une société indépendante de Microsoft (ex Numega) on peut parfaitement suivre le code pas avec ce deboggueur noyau. :-)
L'idéal est que le source en soit libre, et compilable sur une large variété d'autres plateformes avec des compilateurs surs (donc non fournis par Microsoft).
J'ai même essayé avec cc qui se trouve dans SFU en gnu est cela fonctionne parfaitement, on rentre dans du code Linux/Unix on appelle le driver NTFS avec ces symboliques ont fait du pas a pas dans le driver en C NTFS et on ressort vers la routine en C. Magique et sous winice et sous windbg. :-)
