SSLV3.0 Poodle Man-in-the-Middle scenario

Question

I have gone through the answers in this thread SSL3 "POODLE" Vulnerability.

In the first answer,the following has been mentioned.

""The last ciphertext block thus gets decrypted, which yields a value ending with c7 XOR e7. That value is then XORed with the previous encrypted block. If the result ends with a byte of value 7 (that works with probability 1/256)""

Could you explain how could the last byte turns out as '7' with a probability of 1/256

--Added--

I understand that the 256 is the number of combinations of the last byte possible.

I am just not able to figure out what all ways can the client request be modified such a way that 1 in 256 times the result is 7 and the server will accept the request?

---

Answer 1

Updated to better explain what's going on after referencing the original paper.

Since it's block encryption and the attacker is tricking the user into sending requests, the attacker can force the requests to 1) have a full block of padding and 2) have a block where a specific byte of the secret cookie is at the end. Since the block cipher decryption is the same per block across a single stream, the attacker takes the whole block of padding and replaces it with the whole block ending with the specific cookie byte then sends it off to the server. If it gets accepted, the attacker knows that the last byte of the cookie block decrypted to 00000111, which (through some math on the encrypted values) allows the attacker to calculate the unencrypted byte of the cookie. If it doesn't work (which it won't 255 times out of 256), then the attacker needs to force the user to submit an entirely new request (which means an entirely different round of encryption, so it'll have completely different encrypted values even if it's the same unencrypted data). Only after it's accepted will the attacker change values, and what he/she will change will only be the part of the cookie that's in the last byte of the block he/she is swapping.

Old post:

Since there are 2⁸ = 256 different values a byte can be, and since the attacker can't predict what the output will be, he/she must guess until that last byte has the one value that is valid, namely a value of 7.

By the nature of the XOR operation, if one input is static then there is exactly one value for the other input that will produce a desired output. So if the c₇ is 01010101, only an e₇ of 01010010 will result in 00000111. The attacker can't know c₇, but he or she can change e₇ (since that's just the value of the byte in the request) until the server doesn't return an error.