Cracking lowest plaintext bit in Padding oracle attack with PKCS#5 I have been working on a C implementation of padding oracle attack on a block encryption algorithm using CBC mode of operation. I understand the concept fine but I can't seem to find an answer to the following question(despite looking up similar questions on stackoverflow and this site):

When we send a Ciphertext block concatenated at the end of a block we manipulate to the padding oracle, why do we assume that first success means that the XOR operation produced a 1 and not 2,3,4,5,6 or 7 for that matter?

To add more information for those not in the know, PKCS#5 is a padding scheme for plaintexts of blocksize 8 bytes where the last block contains n number of padding bytes each containing the value n. So, lets say we send (C1||C2) where C2 is the original Ciphertext and C1 is a block whose lowest byte we vary from 0 to 255 so as to get a successful validation from the padding oracle. A successful validation, in my opinion, means that the padding is correct, i.e. the resultant plaintext byte is 1 if there were just 1 padding byte and 2 if there were 2 and so on... 

Why do all the implementations of this attack assume that the first success from Oracle means we got a 0x01 in the last byte from the oracle? Is it because the probability of getting a 0x02 in the last byte and the penultimate byte while only varying the last byte is lower? If yes, does that mean there may be instances where this algorithm would fail to decode ciphertext?
Why do all the implementations of this attack assume that the first success from Oracle means we got a 0x01 in the last byte from the oracle? Is it because the probability of getting a 0x02 in the last byte and the penultimate byte while only varying the last byte is lower?


Largely, yes.  Remember, our general assumption is that an attacker is happy with an attack that only works most of the time.  In this case, assuming that the attacker has no initial information about the plaintext block under attack, then a random C1 that causes us to have valid padding would correspond to an 01 padding byte with probability circa $1 - 1/255$ of the time.

In addition, if you find a C1 that might reveal the last byte, and might have a longer padding pattern, there's a very easy test; try C1 with the penultimate byte modified; the resulting decryption will still have valid padding if it had an 01 padding byte, and have invalid padding if it was anything else; hence it would be easy to catch.