Tout est à prendre en compte, et il ne faut pas réfléchir en mode "choix indépendant". Le verre X pris au 4ème bar influence l'ordre des bars précédents. En effet, il y a plus de chance que le bar 3 soit près d'un bar qui a un verre X pas cher, et que le bar 2 soit proche de ce bar 3 etc.

Bref, faut tout prendre en compte.

Allez, bon courage !

Ou bien C est-il plus probable parce que X y a la meilleure proba de la carte

Euh la proba en B est meilleure qu'en C

[fait]

Et bien un exemple

3 Bars A B C donc les distances les uns aux autres sont :
(A,B) = 1
(A,C) = 2
(B,C) = 3

2 boissons X,Y dont les prix dans les trois bars sont :
A (X=1000€, Y=1€)
B (X=1€,    Y=1000€)
C (X=1000€, Y=1€)

L'énoncé dit que le mec en partant de A a pris d'abord Y puis X. (Ça, c'est un fait, c'est l'énoncé, c'est immuable).

On voit bien que le mec n'a probablement pas fait A->B (avec une boisson à 1000€) puis B->A (Avec une boisson à 1000€).  Pourtant c'est le chemin le plus probable indépendamment des boissons.
Il a plus probablement fait A->C (avec une boisson à 1€) puis C->B (Avec une boisson à 1€)

Donc comme quoi, c'est pas juste dépendant des distances. A toi de mettre tout ça en place

Hello,

La liste des boissons qu'il a consommées est importante. En effet, s'il fait l'aller retour entre deux bar, on risque de souvent avoir des choix de boissons très improbables. En revanche, il peut aller dans un bar un poil plus loin pour ensuite choisir une boisson qui, dans ce bar, est bien plus probable.


Par ailleurs, lorsqu'il est expliqué que d'abord il choisit de bouger, ça ne veut pas dire qu'il va forcément aller au bar le plus probable.

e deuxième bar qu'il fréquentera sera probablement le plus proche

Probablement, oui, mais pas certain.

Ensuite, quel que soit le prix de la boisson, le choix du troisième bar devrait se faire de la même façon

Ben il a une plus grande probabilité d'aller au bar le plus proche. Mais encore une fois, le choix des boissons est imposé, donc il faut tout prendre en compte pour la probabilité globale.

Hello,

Il aurait fallu poser un sondage avec deux options seulement: IRC ou 2017. Là les trois premières solutions se partagent les votes mais sont pourtant similaires.

On y a pensé, mais on s'est dit qu'on allait avoir cette information également avec ce type de sondage. Après réflexion, effectivement c'est un peu biaisé. On a cependant pas mal de résultats intéressants à sortir.

Pourquoi?
Je ne vois pas le mal à avoir deux solutions. Ne serait-ce que temporairement le temps de voir comment les nouvelles solutions évoluent.

Parce que le but du changement, ce n'est pas de diviser la communauté.

De mon point de vue, avoir deux canaux de diffusion, c'est très risqué. Mettons qu'on décide de mettre les deux solutions en place, et que des nouveaux arrivent sur Discord. Il y aura les "vieux" sur IRC, les "nouveaux" sur Discord (évidemment c'est pas du 100% mais l'idée est là). Comme personne ne veut diviser, il y aura une synchro entre les deux, mais elle sera approximative (via le relais d'un bot, ça va devenir un vrai chaos, puisque le bot parlera au nom de chacun). Du coup, ça va saouler un peu tout le monde.

Et puis, sur quel(s) critère(s) on se base pour décider de la meilleure solution, après X temps ? Il y aura tous ceux sur Discord qui diront "on garde discord", et ceux sur IRC pour IRC.

Je suis très peu confiant quant aux bénéfices que peut apporter une "double solution temporaire". Pour moi, ça va tuer ce qui existe, c'est pourquoi j'ai donné cet avis.

Salut,

En plus de ce qui a été dit, j'ajoute une précision

Si changement il y a, c'est changement radical. J'entends pas là qu'on ne sera pas dans un état mi-irc mi-autre (et re mi-ours derrière). On change complètement ou on ne change pas du tout (exception faite des challenges se basant sur IRC of course).

Gardons en tête également que IRC reste une référence dans le monde geek/sécu. Les CTFs proposent toujours un chan IRC (rarement slack/discord/autre), python par exemple propose de discuter sur irc mais pas sur les autres plate-formes. Par ailleurs, les clients sont très légers, c'est vieux mais établi (je ne serais pas étonné que slack ou discord ou autre disparaissent dans 3+ ans, au profit d'une autre solution -- js-like --).

De l'autre côté, un discord/slack/mattermost apporte le backlog pour tout le monde, le partage de fichiers ou encore l'audio, et ces + sont indéniablement sympathiques.

Donc changer, c'est souvent bien, mais il est important d'avoir ces éléments en tête lorsqu'on donne son avis pour des décisions importantes comme celle-là.

Plop, non. Refused == problème de FW en général

$ ssh -p 22222 level01@wargame.newbiecontest.org
level01@wargame.newbiecontest.org's password:
Linux wargame 3.2.0-4-686-pae #1 SMP Debian 3.2.89-2 i686
[...]

Bon, oook j'étais un peu rapide.

Tu peux tester différents trucs :
https://itunes.apple.com/us/app/search-by-image-extension/id1199066779?mt=8
https://reverse.photos/
http://bfy.tw/Ephf

Bon courage

Oui, quitter iOS

Et malheureusement, ce n'est pas une réponse troll. (Parce que non, je n'ai pas de solution à ton problème, et je ne pense pas que ce soit possible sans avoir jailbroken ton appareil)

Hello, tout à la main si tu as toutes les cartes en main. Have fun !

Grave erreur et oubli de ma part. C'est fixed !

Bon du coup comme ce sujet m'a beaucoup intéressé, et que j'y ai passé pas mal de temps, je me suis également fendu d'une analyse technique.

http://beta.hackndo.com/krack/

http://beta.hackndo.com/buffer-overflow/

Meilleur site du monde.

My bad, problème de paragraphe :

On reception of Message 3, the STA_P silently discards the message if the Key Replay Counter field value has already been used or if the INonce value in Message 3 differs form the INonce value in Message 1. Otherwise,
a) The STA_P verifies the Message 3 MIC using SKCK key in SMKSA. If the calculated MIC doesnot match the MIC that the STA_P included in the EAPOL-Key frame, the STA_I silently discards Message 3.
b) If the MIC is valid, the STA_P checks that the RSNIE bit-wise matches that from the 4-Way Handshake Message 2. If these are not exactly the same, STA_P silently discards the message and deletes existing 4-Way Handshake states.
c) If they do match, the STA_P constructs Message 4. It also compares the Key Lifetime value fromKDE with value in its SMKSA. If value in SMKSA is less, it discards the value received in Message 3. Otherwise, it updates the value in SMKSA with value in Message 3.

Donc si le KRP a déjà été used (mais c'est pas le cas parce que l'AP l'incrémente) ou si le nonce diffère du message 1 (ce qui n'est pas le cas non plus), le message doit être discard, sinon, il doit être traité.

[EDIT]

EDIT : Mauvais paragraphe. cf. Message suivant avec la bonne citation de la spec

Sauf que... je n'ai pas réellement trouver d'information sur la manière de réagir lorsque ce message est retransmis, et donc ré-analysé par le client.

Dans la spec, on trouve ça :

On reception of Message 4, the Authenticator verifies that the Key Replay Counter field value is one that it used on this 4-Way Handshake; if it is not, it silently discards the message. Otherwise:
a) The  Authenticator  checks  the  MIC.  If  the  calculated  MIC  does  not  match  the  MIC  that  the Supplicant included in the EAPOL-Key frame, the Authenticator silently discards Message 4.
b) If the MIC is valid, the Authenticator uses the MLME-SETKEYS.request primitive to configure the PTK into the IEEE 802.11 MAC.
c) The Authenticator updates the Key Replay Counter field so that it will use a fresh value if a rekey becomes necessary

Donc sauf sans le cas où le KRC n'est pas valide, il ne doit pas le discard si je comprends bien.