Replay attack in ECB mode How do replay attacks work in ECB mode? 
I found this in Wikipedia:


  "ECB mode can also make protocols without integrity protection even more susceptible to replay attacks, since each block gets decrypted in exactly the same way. For example, the Phantasy Star Online: Blue Burst online video game uses Blowfish in ECB mode. Before the key exchange system was cracked leading to even easier methods, cheaters repeated encrypted "monster killed" message packets, each an encrypted Blowfish block, to illegitimately gain experience points quickly.[citation needed]"


But I want to know how a replay attack really works in ECB mode, and how the other block cipher operation modes (like OFB) avoid it.
A replay attack simply means that an attacker who intercepts a valid message can re-send that message as many times as they want.  If there's nothing in the message that could not be legitimately repeated, then the recipient will have no reason not to accept it as a valid message.

In general, all encryption modes are potentially vulnerable to replay attacks, depending on how they're used.  The usual way to defend against such attacks is to include some kind of unique identifier and/or a timestamp in each message, so that the recipient can detect repeated messages.  The messages should then also be protected against modification using a message authentication code (MAC) or an authenticated encryption mode, so that the attacker cannot simply change the ID or timestamp.

As the claim you quoted from Wikipedia lacks any references that would let me look at the details of that particular attack (or even verify that it really took place), all I can do to answer your question is offer some guesses as to how ECB mode might be more vulnerable to replay attacks, or how other block cipher modes could be made more resistant to them:


First of all, one weakness particular to ECB mode is that you can take two messages, cut them apart at cipher block boundaries and join the halves together again to get a valid message combining parts of the two original messages.  Depending on how the messages are constructed, this might allow an attacker to e.g. glue the contents of an old message to the ID and timestamp from a new message, which obviously defeats their purpose.
Second, other block cipher modes, such as CBC, CFB, OFB and CTR, all require a unique initialization value (IV) or a "nonce" (essentially a unique identifier).  While preventing replay attacks is not the primary reason why these IVs / nonces are required, since they're there and since they need to be unique anyway, they can also be used to detect duplicate messages.

A potentially convenient feature is that, for many (but not all!) modes, even in the absence of a MAC, trying to modify the IV / nonce will turn the entire message into random garbage when it is decrypted.  This is particularly true of the OFB and CTR modes, which are otherwise very vulnerable to ciphertext modification.  (Of course, this is still not a good substitute for a MAC in other respects.)
Finally, in some applications, it might not be necessary to transmit the IV / nonce at all, since it may be inferred from some external information (such as the number of messages or blocks seen before, if messages are transmitted in strict sequence on a supposedly reliable channel).  In some cases, all messages might even be encrypted and transmitted as a single continuous stream, essentially just one long message.

This obviously makes replay attacks on non-ECB modes difficult or impossible, since repeating an old message would just lead to the recipient trying to decrypt it with the wrong IV / nonce.  However, ECB mode still remains vulnerable due to the property described above, namely that, as each block is encrypted independently and in the same way regardless of its position in the stream, an attacker can shuffle (and delete or duplicate) blocks in any manner without affecting their decryption.


Still, I should note that all of these attacks only apply in the absence of authentication.  Even ECB mode, if combined with a MAC and with unique message IDs to detect duplicates, would be secure against replay attacks.  Of course, the same goes for no encryption at all, but just unique message IDs and a MAC, but at least adding ECB mode encryption to the mix wouldn't make things any worse.