With Electrum 1.x, the "message" being encrypted is 16 random bytes of information (the decoded seed)...
Actually that's not true.
The message being encrypted is a hex-encoded string of the 16 random bytes; it's 32 hex digits. On top of that, it's PKCS7 padded, which for a 32-byte string results in 16 bytes all of value 0xf being appended to the end of the string before encryption. This makes it very easy (and fast) to test passwords against Electrum 1.x wallets (with 2.x you can use a similar trick by trying to decrypt the master private key which is encoded in BIP32 xprv format before encryption).
If you would like to make a script that tests many passwords, you will first have to understand how to derive from the decoded seed to the master public key.
Source: I have done so....
https://github.com/gurnec/btcrecover so the only way to know whether you got the password correct or not is to do the following:
1. Decrypt with AES and your password attempt.
2. Hash the result with itself 100000 times.
3. Use that final hash as a private key and find the x and y values of the public key.
4. Compare the x and y values to your wallet's MPK (master public key) and if they are equal, then your passphrase was correct.
Out of all of the wallets btcrecover supports (roughly 10 depending on how you count), the
only wallet where I actually have to go so far as to derive a pubkey from a privkey to check if a password is correct is Armory. All of the others offer similar tricks to prevent having to doing so.
That's not to say that they're all insecure. Although it's true there are a surprising number of wallets with non-existent key stretching, there are a few that do it right (from a key stretching point of view, anyways, some of these have other encryption issues): Bitcoin Core, Armory, MultiBit HD, Hive for OS X (vanilla bitcoinj), and to a much lesser extent Blockchain.info's most recent version as of roughly late last year.