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.
Since there are 28 = 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 c7 is
01010101, only an e7 of
01010010 will result in
00000111. The attacker can't know c7, but he or she can change e7 (since that's just the value of the byte in the request) until the server doesn't return an error.