When cracking passwords in general (not just login credentials) you have approximately three options:
1. Try every likely (or possible) password (generate passwords to try)
2. Try every possible key for the encryption
3. Find a flaw in the approach or algorithm (or potentially in physical security, as in find the password written down, or phish it, or whatnot)
So now we need to know something about how the data is encrypted. If the file is encrypted with AES (AES256 is this example), then it has a key. That key is (or should be) a 256bit random string of bits. It's nothing like a password, because it's binary, it would not be memorable unless converted to hex, and even then it wouldn't be especially memorable for a user. An example might be:
f2 f3 e2 0a cb f7 44 3f 61 8f aa 15 11 4f 51 68
b3 29 a3 53 ab 43 cd 9e a3 59 d3 91 4e e3 dd eb
In #2 above, the attacker would try 00......00 through FF......FF which is 2^256 possible values, and there just is no way this can ever done in less than billions of years. (Trust me on the math, but I've covered it before.)
In order for the user to have a chosen password, there needs to be a way to convert the password into the key. This is done with a secure hash, like SHA256. Now there are two possibilities. One is to use the result of the hash directly as the key (as they're the same size,) but this has a downside if you change your password, the entire encrypted data file needs to be re-encrypted with the new key derived from the new password. Since there really is no reason to ever change the key and re-encrypt the file, it's frequently the case that the key derived from the password is just used to encrypt the key used for the rest of the file.
Quality encryption is indistinguishable from random binary noise. So if you enter the wrong password, and no checking of the password is done, then it could be used to decrypt the file, and it would result in garbage, but it would go undetected. The traditional way to solve this problem, is to have some sort of "check value" be in the data (or a hash of the data) so that when the correct password is entered, the correct check value pops out, and the program can know you got your password correct.
So this is what the attacker must do for #1. They must generate plausible passwords, run them through all the steps, and then see if the password check passes. If it does not, then they try another password and so on. By putting PBKDF2 into the middle of all this password checking, the hope is to slow down this process to make it too inefficient to be able to check passwords, in hopes that no attacker would ever mount such an attack.
