Discussion :

[Invité]

Man In The Middle.

Oui c'est ce que tu as utilisé avec ton système de proxy pour te faire passer pour un faux serveur et intercepter mes données. (Car seul un proxy peut réutiliser la même adresse avec un port différent)
Tu as donc voulu avec ton système, pirater des données de mon PC (le client) avec le vpn qui allait vers ton raspberry qui lui même était relié au proxy dans le seul but de contourner mon parefeu. ^^

Je cherche toujours comment lutter contre ce type d'attaque, la seule solution que j'ai pu trouvé c'est de ne faire confiance à personne et surtout pas à quelqu'un qui a un serveur proxy d'un côté avec une connexion vpn de l'autre côté!

Et comment va-t-il récupérer la clé publique du serveur vu que sa clé privée est re-généré aléatoirement ?
Comment, une fois récupéré, peut-il s'assurer que c'est bien la clé publique du serveur ?

L'échange de la clé publique du serveur ne se fait que lors de la 1ère transaction et celle du client lors de la seconde, donc, si les clés publique et privée du serveur changent ce n'est pas bien grave.
Car j'utilise un système hétérogène. (RSA + AES)
La clé publique du serveur n'est plus utile pour le client une fois que la signature (la clé publique du client) a été transmise.
Par contre je peux très bien renvoyer la nouvelle clé publique du serveur à tout les clients si je veux changé la signature de tout les clients connecté tous les x temps.

Tu comprends ?

Je mettrai un délai d'attente entre chaque connexion d'ailleurs pour éviter les attaques de "flood net.". (Car si la clé change il ne faut pas qu'un utilisateur se connecte pendant se délai ce qui pourrait posé problème)

Et bien sûr trop de connections d'un coup ça surcharge le serveur et ça pose problème également.

Bref, si tu trouves une faille je t'invite à m'en faire part, mais je pense que le problème se situera plutôt maintenant au niveau des attaques par géo-position ou encore avec ls keyloggers (logiciel utilisant ta webcam à des fins d'espionnage) dans les années à venir.
Il faudra arriver à imiter ma carte bancaire et ma signature, bonne chance. ^^

Et l'autre type d'attaque est celle par proxy et par vpn pour contourner le parefeu. Mais ça, ça n'aura aucun effet, tu ne pourras jamais me piquer de l'argent IRL avec ça.

Bien essayé mais c'est raté.

PS : et par conséquent ce nouveau système me protégera également des attaques par mémoire cache et par proxy, car si la clé change tout le temps elle ne sera plus valable après un certains temps.

Donc même si quelqu'un utilise un faux serveur il va avoir du mal, car le client ne pourra plus se connecter au faux serveur dans un bref délai, car la clé aura changé et seul le vrai serveur pourra envoyer la nouvelle clé au client via un cryptage RSA dans l'autre sens! (et donc de serveur vers client cette fois)

La faille se situe belle et bien à ce niveau là.

[Neckara]

avec le vpn qui allait vers ton raspberry

Je fais encore plus fort. Pour éviter que mon raspberry ne soit attaqué en retour, je ne l'ai pas connecté à internet et je l'ai même mis hors tension.

Car seul un proxy peut réutiliser la même adresse avec un port différent

Tu parles de mon proxy IRC ?
Proxy qui te permet de te connecter à mon serveur IRC que j'héberge moi-même ?

Alors oui, un proxy IRC se fait passer pour un serveur et oui il reçoit tes données IRC. Données qui sont ensuite envoyée à mon serveur IRC, que j'héberge moi-même. Donc de toute façon, je reçois ces données et elles sont loggées comme pour tout serveur IRC.
Le proxy est bip et le serveur IRC inspircd.

Je cherche toujours comment lutter contre ce type d'attaque, la seule solution que j'ai pu trouvé c'est de ne faire confiance à personne et surtout pas à quelqu'un qui a un serveur proxy d'un côté avec une connexion vpn de l'autre côté!

Un VPN ?

Mais oui, faut beaucoup te méfier des serveur IRC, non seulement ils récupères tes données que tu leur envois, mais en plus, ils les envoient à tous les hackeurs qui sont sur le même salon que toi !
J'ai aussi entendu parler du virus Skype, lui c'est encore pire, non seulement tes données sont récupérées, mais en plus, il récupère les données de ton micro et de ta caméra. Pour tromper ta vigilance, ils se font passer pour des proches, ton père, ta grand-mère, et les imitent très bien !
Mais ne te laisse pas te faire tromper par ces imitateurs, ce n'est que tromperie !

L'échange de la clé publique du serveur ne se fait que lors de la 1ère transaction et celle du client lors de la seconde, donc, si les clés publique et privée du serveur changent ce n'est pas bien grave.

Donc c'est ce que je dis, n'importe qui peut se faire passer pour un serveur ou un client et tu n'as aucun moyen de vérification.
Il suffit d'envoyer des clés publiques frauduleuses qui sont automatiquement crue.

Car j'utilise un système hétérogène. (RSA + AES)

SSL ?

La clé publique du serveur n'est plus utile pour le client une fois que la signature (la clé publique du client) a été transmise.
Par contre je peux très bien renvoyer la nouvelle clé publique du serveur à tout les clients si je veux changé la signature de tout les clients connecté tous les x temps.

Donc il suffit d'envoyer une clé publique à un client pour devenir le nouveau serveur ?
Quelle sécurité !

Car si la clé change il ne faut pas qu'un utilisateur se connecte pendant se délai ce qui pourrait posé problème

Faut que tu proposes un nouveau code d'erreur HTTP :
518 : Server Key is changing.

Et si tu as déjà des clients connecté quand tu fais ton changement de clé, ça plante ?
Laisse moi deviner, tu attends qu'ils se déconnectent tous pour pouvoir changer de clé ?

Bref, si tu trouves une faille je t'invite à m'en faire part

Je t'invite à lire la RFC de SSL.

Il faudra arriver à imiter ma carte bancaire et ma signature, bonne chance. ^^

Est-ce que tu as la moindre idée du fonctionnement d'une carte bancaire ?

Alors je t'apprendrais qu'une carte bancaire a des certificats et des clés privées qui ne sont pas régénéré régulièrement.

Et l'autre type d'attaque est celle par proxy et par vpn pour contourner le parefeu. Mais ça, ça n'aura aucun effet, tu ne pourras jamais me piquer de l'argent IRL avec ça.

C'est pas ce que dit mon compte en banque.
J'ai réussi à piquer tout l'argent que tu envoyais par IRC.

Maintenant, je recherche à aller plus loin en essayant de piquer l'argent dès que tu le scan.

PS : et par conséquent ce nouveau système me protégera également des attaques par mémoire cache et par proxy, car si la clé change tout le temps elle ne sera plus valable après un certains temps.

Moi j'ai une meilleure idée, tu génères une nouvelle clé pour chaque octet que tu envois/reçoit, comme ça même si l'attaquant réussi à intercepter la clé, il ne pourra déchiffrer que un seul octet et ne pourra en aucun cas déchiffrer le message complet.

Donc même si quelqu'un utilise un faux serveur il va avoir du mal, car le client ne pourra plus se connecter au faux serveur dans un bref délai, car la clé aura changé et seul le vrai serveur pourra envoyer la nouvelle clé au client via un cryptage RSA dans l'autre sens! (et donc de serveur vers client cette fois)

La clé aura changé ? Et comment tu va donner la nouvelle clé au client ?

[Invité]

Donc c'est ce que je dis, n'importe qui peut se faire passer pour un serveur ou un client et tu n'as aucun moyen de vérification.
Il suffit d'envoyer des clés publiques frauduleuses qui sont automatiquement crue.

Mais tu sais en RSA même avec la clé publique, tu ne peux pas décrypter les messages, car il faut aussi que tu aies la clé privée qui est stockée côté serveur, et pour éviter la découverte de la clé privée par attaque par proxy ou par mémoire cache (faux serveur donc), je compte changer les clés (publique et privée) régulièrement, ainsi, la signature ne sera plus bonne pour les faux clients qui auront réussi à récupérer la clé privée.

Donc c'est ce que je dis, n'importe qui peut se faire passer pour un serveur ou un client et tu n'as aucun moyen de vérification.
Il suffit d'envoyer des clés publiques frauduleuses qui sont automatiquement crue.

Oui, le problème se situe bel et bien à ce stade là!

N'importe qui pourrait se faire passer pour un faux serveur ou un client.

D'où l'intérêt de changer régulièrement les clés et la signature.

SSL ?

Oui SSL!

Faut que tu proposes un nouveau code d'erreur HTTP :
518 : Server Key is changing.

Et si tu as déjà des clients connecté quand tu fais ton changement de clé, ça plante ?
Laisse moi deviner, tu attends qu'ils se déconnectent tous pour pouvoir changer de clé ?

Non ça ne plantera pas, si le message apparaît suffit de recharger la page un peu plus tard.

Je t'explique le principe :

Supposons que le serveur soit Bob et le client Alice.

-Alice envoie un message à Bob pour demander de se connecter.
-Bob lui envoie la clé publique pour le chiffrement en RSA.
-Alice reçoit la clé publique et demande alors la signature pour le chiffrement en AES avec la clé que lui à envoyé Bob précédemment.
-Alice reçoit la signature pour le chiffrement AES.

Le problème ce situe à ce niveau-ci : quelqu'un peut très bien essayer de se faire passer pour une fausse Alice, en cherchant à récupérer la clé privée de Bob via une attaque par proxy par exemple et ensuite utiliser la signature de Alice pour intercepter les messages et les décrypter.

Donc je pense changer les clés publiques et privées de bob régulièrement ainsi que la signature de Alice, ainsi, Bob enverra à interval régulier une nouvelle clé publique pour le chiffrement RSA à Alice, via sa nouvelle clé privée, et Alice demandera une nouvelle signature à Bob à chaque octets.

Donc l'attaquant ne pourra pas tout décrypter, ni récupérer la clé privée de Bob pour récupérer les signatures de Alice via des attaques de type MITM.

Avec un sélector.wait il est facile d'établir un interval de temps entre chaque connections, donc, je compte me servir de cet interval de temps pour changer les clés de Bob, et envoyer la clé publique à Alice qui elle même demandera une ou plusieurs nouvelles signatures à Bob mais avec la nouvelle clé publique de Bob cette fois!

Et alice et bob se serviront de ses nouvelles signatures pour crypter les x octets suivants!

Tu comprends ?

Ton virus ne pourra plus rien faire.

C'est pas ce que dit mon compte en banque.
J'ai réussi à piquer tout l'argent que tu envoyais par IRC.

Maintenant, je recherche à aller plus loin en essayant de piquer l'argent dès que tu le scan.

Un jour, je te retrouverai! Niark, niark, niark.

[Neckara]

Mais tu sais en RSA même avec la clé publique, tu ne peux pas décrypter les messages, car il faut aussi que tu aies la clé privée qui est stockée côté serveur, et pour éviter la découverte de la clé privée par attaque par proxy ou par mémoire cache (faux serveur donc), je compte changer les clés (publique et privée) régulièrement, ainsi, la signature ne sera plus bonne pour les faux clients qui auront réussi à récupérer la clé privée.

La clé publique est associé à la clé privée.

Si tu change la clé privée, tu changes aussi la clé publique.
Il faut donc transmettre ta nouvelle clé publique à tes clients.

Oui, le problème se situe bel et bien à ce stade là!

N'importe qui pourrait se faire passer pour un faux serveur ou un client.

D'où l'intérêt de changer régulièrement les clés et la signature.

…

C'est parce que tu change régulièrement les clés que n'importe qui peut se faire passer pour un faux-serveur.

Non ça ne plantera pas, si le message apparaît suffit de recharger la page un peu plus tard.

Ce serait mieux si le changement de clé était transparent à l'utilisateur non?

Le problème ce situe à ce niveau-ci : quelqu'un peut très bien essayer de se faire passer pour une fausse Alice, en cherchant à récupérer la clé privée de Bob via une attaque par proxy par exemple et ensuite utiliser la signature de Alice pour intercepter les messages et les décrypter.

Déchiffrer*

Parce que maintenant, Bob envoie sa clé privée sur le réseau ?

Donc je pense changer les clés publiques et privées de bob régulièrement ainsi que la signature de Alice, ainsi, Bob enverra à interval régulier une nouvelle clé publique pour le chiffrement RSA à Alice, via sa nouvelle clé privée, et Alice demandera une nouvelle signature à Bob à chaque octets.

Et si c'est l'attaquant qui envoie une nouvelle clé publique à la place de Bob, Alice fait quoi ?

Avec un sélector.wait il est facile d'établir un interval de temps entre chaque connections, donc, je compte me servir de cet interval de temps pour changer les clés de Bob, et envoyer la clé publique à Alice qui elle même demandera une ou plusieurs nouvelles signatures à Bob mais avec la nouvelle clé publique de Bob cette fois!

Changement des clés en cours, veuillez patienter 24h afin que nous puissions procéder à l'échange de tout le jeux de clé de notre parc et de nos clients.
Merci de votre compréhension.

Et alice et bob se serviront de ses nouvelles signatures pour crypter les x octets suivants!

Chiffrer.

Tu comprends ?
Ton virus ne pourra plus rien faire.

http://i.imgur.com/xVyoSl.jpg



Sinon, parlons sérieusement, tu comptes faire comment pour la latence temporelle de ta DMZ dû à tous tes changements de clés ? Sans parler du ping asynchrone de ton certificat à clé publique…
De plus, les cartes réseaux ont des routines particulières, je parie que tu vas provoquer une erreur du buffer de Kant à changer les clés aussi régulièrement et contre du quel tu ne peux rien et vice et versa.

[skeud]

Mais mais mais, lolilolight a trouvé LA solution contre les pirates, c'est dingue, grace à lui on aura plus peur d'eux, enfin un monde sécurisé grâce à lui .

Pour résumé, à l'origine tu voulait créer un nouveau moteur graphique, et là tu en es rendu à créer un moteur graphique, une lib de rendu, des driver, une lib de chiffrement, moi je dis, à quand le système d'exploitation?

[Invité]

La clé publique est associé à la clé privée.

Si tu change la clé privée, tu changes aussi la clé publique.
Il faut donc transmettre ta nouvelle clé publique à tes clients.

Oui!

…

C'est parce que tu change régulièrement les clés que n'importe qui peut se faire passer pour un faux-serveur.

Je ne comprend pas très bien cette phrase.

Ce serait mieux si le changement de clé était transparent à l'utilisateur non?

Oui!

Déchiffrer*

Parce que maintenant, Bob envoie sa clé privée sur le réseau ?

Non! seule la clé publique est transmise sur le réseau.

Et si c'est l'attaquant qui envoie une nouvelle clé publique à la place de Bob, Alice fait quoi ?

Seul le vrai serveur (Bob) peut envoyer des clés publiques RSA et seul les vrais clients peuvent recevoir les signatures chiffrées qui elle même chiffreront chaque octet qu'enverra chaque client au serveur et inversément.
Et comme ces clés changent régulièrement et que les signatures cryptée sont différentes pour chaque octet chiffré.

Si quelqu'un sniffe le réseau et essaye d'envoyer une fausse clé publique RSA via un proxy pour récupérer la clé privée et se sert ensuite d'un faux client pour essayer de décrypter un message, cette clé deviendra fausse au bout d'un moment et donc il ne pourra pas tout déchiffrer.

C'est juste une question de ne pas pouvoir tout déchiffrer, non pas une question de ne pas se faire attaquer par un faux serveur ou un faux client, ça je sais que c'est toujours possible!

De toute façon, cela ne fonctionnera pas car seul le vrai serveur et le vrai client auront les bonnes clés chiffrées pour déchiffrer un octet à un temps T, une fois que les octets seront lu, les clés et les signatures changeront.
Le problème se situe principalement au niveau de la rapidité, si quelqu'un possède une machine plus rapide que l'autre, il est de toute façon facile de casser un code, mais si on chiffre chaque octet avec une signature différente qui elle même sera chiffré avec une clé privée de manière transparente à l'utilisateur, alors là, je suis sûr que ça sera plus sécurisé.

Pour le moment je fais ceci :

-J'envoie la clé publique RSA du serveur vers le client à la connection. (Vous savez le fameux certificat SSL)
-Ensuite, j'envoie un message au serveur demandant la clé publique pour le chiffrement en AES.
-Le serveur chiffre le clé publique AES et l'envoie au client.
-Ensuite tout les messages sont chiffré et déchiffré avec la clé AES que j'appelle aussi la signature.
En plus de cela, cette signature est hachée.

C'est la base du protocole SSL.

Mais je ne suis pas sûr que cela soit suffisant au niveau sécurité, à cause de l'attaque que j'ai subit récemment, il y a toujours possibilité de s'introduire dans la mémoire cache du vrai serveur, et de déchiffrer l'ensemble de la transmission. (Avec faux serveur proxy, faux client vpn et une application en javascript qui traduit du code c++ en javascript)

SSL est devenu obsolète il me semble, et il y a un nouvel OS avec un nouvel algorithme de chiffrement qui est sorti il y a pas longtemps. (FreeBSD)

[Neckara]

Seul le vrai serveur (Bob) peut envoyer des clés publiques RSA et seul les vrais clients peuvent recevoir les signatures chiffrées qui elle même chiffreront chaque octet qu'enverra chaque client au serveur et inversément.
Et comme ces clés changent régulièrement et que les signatures cryptée sont différentes pour chaque octet chiffré.

Chiffré*

Comment fais-tu pour empêcher un faux serveur d'envoyer des clés publiques ?

Si quelqu'un sniffe le réseau et essaye d'envoyer une fausse clé publique RSA via un proxy pour récupérer la clé privée

WoW WOW What ????
Comment veux-tu qu'il récupère la clé privée en envoyant une fausse clé publique ?

cette clé deviendra fausse au bout d'un moment et donc il ne pourra pas tout déchiffrer.

Ben il lui suffit de renvoyer une autre fausse clé.

mais si on chiffre chaque octet avec une signature différente qui elle même sera chiffré avec une clé privée de manière transparente à l'utilisateur, alors là, je suis sûr que ça sera plus sécurisé.

Mais le problème, ce n'est pas l'algorithme de chiffrement des clés, mais l'algorithme d'échange des clés publiques.

-Ensuite tout les messages sont chiffré et déchiffré avec la clé AES que j'appelle aussi la signature.

Rien à voir, mais absolument rien à voir.

C'est la base du protocole SSL.

Sauf que dans SSL, la clé publique est certifiée.

Mais je ne suis pas sûr que cela soit suffisant au niveau sécurité, à cause de l'attaque que j'ai subit récemment, il y a toujours possibilité de s'introduire dans la mémoire cache du vrai serveur, et de déchiffrer l'ensemble de la transmission. (Avec faux serveur proxy, faux client vpn et une application en javascript qui traduit du code c++ en javascript)

Il existe une solution. Il te faut un CPU qui accepte les jeux d'instructions no-memory ainsi aucune donnée n'est mise en mémoire cache et RAM, impossible alors de récupérer les clés dans la mémoire.

Après, pour afficher les données sensibles, je préconise une carte graphique Secure Access compliant.
La seule faille qui reste, serait si une personne regarde par ton épaule. Pour cela tu peux butter tous tes voisins en prévision.

SSL est devenu obsolète il me semble, et il y a un nouvel OS avec un nouvel algorithme de chiffrement qui est sorti il y a pas longtemps. (FreeBSD)

Il y a plusieurs versions de TLS et de SSL.

[Invité]

Ok, de toute façon tôt ou tard il va falloir que je change de PC, là, j'attends juste la sortie de Vulkan (Je ne parle pas de l'enfer hein ) histoire de pouvoir m'amuser un peu plus et ne plus être contraint de devoir subir toutes ses attaques, en étant d'autant plus fort limité au niveau du rendu graphique due à l'ancienneté de mesa. :/

Je prendrai sûrement un processeur AMD vu que le processeur intel n'est plus suffisamment sécurisé, et comme carte graphique j'essayerai d'en trouver une comme tu m'as dis.

Je vais noter tout ça pour plus tard, ça me sera utile!

Au fait, c'est quoi une clé publique certifiée ? Car apparemment c'est ça qui pose problème.

C'est une clé publique fournie par un tiers ?

Comment est ce que je peux en avoir une ?

PS : faut que je me trouve un endroit ou il n'y a pas de voisins. ^^

Bah ici chez moi c'est parfait, mais, je ne pense pas rester chez papa et maman jusqu'à ce que je sois vieux, tout du moins, j'espère.

A moins que quelqu'un aie scellé ma maison car, à chaque fois que je veux déménager, il y a un événement qui vient tout faire foiré. :/

Bon, je m'arrête là, je ne voudrais plus rentrer dans mes délires et hors sujets sinon tout le monde va encore me prendre pour un fou qui se drogue à l'héroïne et qui a des hallucinations. Pour plus de compréhension, il suffit juste de regarder poltergeist.

[skeud]

Je prendrai sûrement un processeur AMD vu que le processeur intel n'est plus suffisamment sécurisé, et comme carte graphique j'essayerai d'en trouver une comme tu m'as dis.

Donc en gros tu veux faire un moteur que personne n'utilise et qui fonctionne uniquement sur AMD? car intel n'est pas sécurisé? ça devient un peu gros là non? Tu te rends pas compte de toute les portes que tu fermes au fur et à mesure que tu parles.

Je comprends mieux pourquoi tu ne trouves pas de boulot si tu réagis pareil aux entretiens ^^.

[Invité]

Pour ma part je suis fort déçu de IBM (l'inventeur du microprocesseur), je pensais qu'ils m'aideraient malheureusement la dernière fois que j'ai été chez eux et que je leur ai parlé de mon moteur, ils ont plutôt eu tendance à faire l'inverse. :/

PS : si un jour je peux faire une nouvelle game de processeurs plus écologique à électricité statique je ne dirai pas non. x)

D'ailleurs je me demande si quelqu'un à déjà essayé.

Je crois que je vais m'éloigner de mon PC pour le moment car j'ai l'impression que ce n'est pas trop bon d'être trop prêt du processeur. :/

[skeud]

Euh c'est une blague, t'es allé chez eux pour leur demander de l'aide sur ton moteur? Oo

[Jbx 2.0b]

Pour ma part je suis fort déçu de IBM (l'inventeur du microprocesseur), je pensais qu'ils m'aideraient malheureusement la dernière fois que j'ai été chez eux et que je leur ai parlé de mon moteur, ils ont plutôt eu tendance à faire l'inverse. :/

A mon avis ils ont fait semblant de rien sur le moment, et maintenant ils sont tous à fond en train de coder un nouveau moteur graphique basé sur OpenCL (haha pourquoi ces gros naabs de Khronos n'y ont pas pensé !). Pour les retrouver ça va être chaud, ils se sont installés au milieu des montagnes pour éviter toute forme de shoulder-hacking, un peu trop en vogue en ce moment.

[Invité]

Non je n'ai pas été chez eux pour leur demander de l'aide pour mon moteur, mais, pour un entretient d'embauche car ils ont dit qu'ils engageraient beaucoup de personne à Lille il y a à peu prêt un an, là, je leur ai parlé de mon moteur utilisant SFML car le recruteur (un japonais) m'a demandé si j'avais déjà réalisé des projets connu, mais je ne leur ai pas demandé de l'aide évidemment.

Comme je m'y attendais l'entretient c'est conclut par un mail avec une réponse négative.

Bref, je pense qu'ils doivent toujours être aussi mauvais qu'auparavant. :/

De toute façon la boîte ne me convenait pas, ils recherchent plutôt de la standardisation sûrement dans le but de faire comme le célèbre créateur de microsoft c'est à dire contrôler le marché du PC à eux seul hors que moi je recherche plutôt de la collaboration et la concurrence car j'ai vraiment besoin de ça pour pouvoir avancer mieux.

Et puis l'époque ou on utilisait des écrans avec des tubes et lampes de poches et révolue, maintenant tout est devenu beaucoup plus microscopique et complexe.

PS : oui je sais que les sites de AMD sur openCL se sont fait attaquer à un moment, je l'ai remarqué avec mon navigateur.

IBM ce n'est pas une boîtes plutôt à mentalité soviétique ça ?
Tandit que AMD, plutôt à mentalité Américaine ?

Je sais de part le passé que ces deux type de mentalité ne colle pas très bien ensemble. :/
Et quand tu y rajoutes des japonais ça devient encore pire.

PS 2 : N'oublions pas Apple et le faux système de monnaie, la bourse ainsi que le fameux Steve qui se croyait milliardaire à 25 ans.

Malheureusement dans la logique des choses ça ne se passe pas comme ça, le monde n'est contrôlé que part une poignée de programmeurs qui le défende communiquant avec une super intelligence (par télépathie ?) et non pas par des marchés.

Il me semble que Bill Gates à quand même fini par le comprendre et aurait bizarrement ouvert son cœur ses dernières années.

Je pense qu'il a peur qu'à la mort son âme (information) se dématérialise pour se re-matérialiser ailleurs, dans un pays pauvre, d'ou l'importance de pouvoir s'y retrouver dans son code après plusieurs siècle pour les générations futures.

[Zirak]

Zirak was here.

Ce topic vend du rêve, et tomber dessus un vendredi, c'est juste du bonheur.

C'est comme si on avait réuni tous les trolls de dvp, et qu'on les avaient fusionnés dans le but d'en faire un super troll schizophrène.

@Neckara tu es mon héros du jour, quel courage !


Désolé de l'interruption, vous pouvez reprendre vos "activités".

[skeud]

Bref, je pense qu'ils doivent toujours être aussi mauvais qu'auparavant. :/

Si par mauvais tu entends une entreprise avec plusieurs dizaine de milliard de chiffre d'affaire ......

PS 2 : N'oublions pas Apple et le faux système de monnaie, la bourse ainsi que le fameux Steve qui se croyait milliardaire à 25 ans.

Le faux système de monaie? La bourse? Tu veux dire quoi?

Se croyait milliardaire? Il était miliardaire, il a juste créé une des plus grosses entreprise de ce monde à 20 Ans .....

Malheureusement dans la logique des choses ça ne se passe pas comme ça, le monde n'est contrôlé que part une poignée de programmeurs qui le défende communiquant avec une super intelligence (par télépathie ?) et non pas par des marchés.

Une poignée de développeur? rappel moi les effectifs de microsoft/apple/ibm/intel ....?

Il me semble que Bill Gates à quand même fini par le comprendre et aurait bizarrement ouvert son cœur ses dernières années.

C'est sur tu le connais personnellement, du coup tu sais ce qu'il ressent.

Je pense qu'il a peur qu'à la mort son âme (information) se dématérialise pour se re-matérialiser ailleurs, dans un pays pauvre, d'ou l'importance de pouvoir s'y retrouver dans son code après plusieurs siècle pour les générations futures.

Réincarnation des âmes mélanger avec du process informatique, tu vends du rêve ><.

lolilolight serait-il le fils caché de vandamme?

[mintho carmo]

Moi, je crois en toi, Lolilight. Je suis sur que tu vas finir par réussir un projet...

[Sunchaser]

Moi aussi j'ai subi une attaque insolite ce soir: j'ai mangé une saucisse ce soir .. ah non ! Deux. Très bonne les saucisses.
D'habitude, le problème chez nous, c'est que les saucisses, elles sont a l'oignon.
Côté digestion, pas top.
Mais la, très bonnes, les saucisses; pas de soupcon de surdose souffreuteuse d'oignon.
Mais c'était un piège !
L'oignon, il devait être masqué. Une sorte de cheval de Troie a l'oignon quoi. Une fois installée dans le bide, la saucisse virale délivre son venin, c'est trop tard ! Le programme "oignon-indigeste.exe" s'execute, et il est trop tard. A moins peut être de faire un dump en urgence de tout son bol alimentaire dans les toilettes, mais je n'ai pas eu le courage.
Maintenant, je suis coincé.
Je vais passer la soirée a roter et péter, et peut être le virus sera encore la demain .... terrible destin.

[Escapetiger]

IBM ce n'est pas une boîtes plutôt à mentalité soviétique ça ?

Probablement quant à leur culture d'entreprise ....

" IBM est probablement l'une des structures qui a développé le plus fortement et précocement le principe de culture d'entreprise. Durant la majeure partie du XXe siècle, l'uniforme, constitué d'un costume bleu, d'une chemise blanche et d'une cravate foncée, y était de rigueur pour les commerciaux. Ces codes ont commencé à s'assouplir à la fin des années 1970, puis l'ont été considérablement dans les années 1990. À ses débuts, IBM faisait aussi chanter à ses salariés des hymnes à la gloire de l'entreprise. " (...)
Source : http://fr.wikipedia.org/wiki/Interna...0.99entreprise

Bon, de là à dire qu'ils auraient copié l'URSS avec un (des)plan quinquennal secret.

[Invité]

Bon la discussions ayant dévié, je continue :

Réincarnation des âmes mélanger avec du process informatique, tu vends du rêve ><.

lolilolight serait-il le fils caché de vandamme?

J'ai déjà vu deux salles, je ne dormais pas, je fermais juste les yeux...

La 1ère contrôle le flux de la pensée et est capable de prendre des décisions et une autre, le climat, mais dans mes sois disant rêve il y avait plusieurs salle et pas que une, je plains ceux qui ont du déplacer toutes les machines.

J'ai vu aussi un tas de tunnels et de fils et de ventilos.

Bref moi j'étais content, je me suis dis, elle existe, la machine universelle.

Et je pense qu'elle ne doit pas être très loin d'ici.

[Invité]

Au centre du soleil.