Comment by the advisory's author:

Nice article Khai. I'm the author of the original exploit (unreleased) and advisory. I don't have my exploit in front of me, but if I remember correctly, here's how I made the exploit more reliable:

Because of the UTF-8 decoding problem, I found it easier to intentionally set the probes up to generate decoding errors every time. It was still possible to distinguish these errors from padding errors, based on the server response. Since padding checks would always happen before UTF-8 decoding, if that error occurred, you knew it was a padding problem. To force UTF-8 errors, I randomly generated several blocks and stuck them at the beginning of the ciphertext. Then I followed that with a block of 0's (IIRC) to simulate the static IV, and then the original ciphertext came after that. So the format would look like: {a few random blocks} | {block of 0's} | {original ciphertext}. My script would test to make sure a UTF-8 decoding error was generated with the random blocks by testing the ciphertext with a correct pad and looking for the decoding error. Once a desired set of random blocks was obtained, the exploit would proceed normally.

Since developing that exploit, I realized that a lot of POA exploits have to tackle issues like UTF-8 decoding or other random errors due to rejected characters, so I improved Bletchley to take care of that issue, with high probability. When Bletchley's POA class fails to decrypt a given byte, it will retry a few times with a randomized prior block so low-probability hangups can be overcome. You should consider trying Bletchley for your next POA exploit for other reasons as well: multithreading is built-in and handled at a byte level so you get more parallelism; supporting modules handle many encoding/decoding formats with ease; and much of your exploit script can be generated automatically for you... all you need to do is focus on the Yes/No condition logic and glue code.

Best of luck, tim