Is there a practical way to crack an AES encryption password? I heard that the fastest method to crack an AES-128 encryption, or and AES-256 encryption is by brute force, which can take billions of years. But I can't help thinking there's got to be a faster way. 
Because the AES encryption scrambles the data contained in a zip file, the password could be found by unscrambling that data correctly. Say if a portion of the data in the file is known, for example a string at the end of a file, or a header containing an expected sequence of bytes in a known file type.
 Then by comparing the scrambled bytes with the 'expected' unscrambled bytes, the password can easily be determined by computing an algorithm that converts those bytes because both the scrambled bytes and the unscrambled bytes are known. Only the formula is unknown. 
However, the condition for this type of cracking is that the zip file contains known file types which have a determined data format and places certain data in certain locations in the file. For instance, a 3ds file always starts with a header containing the bytes "4D4D".
Hence a list of possible passwords to rearrange the sequence begin to be narrowed down as the cracking progresses. 
So is this method plausible? or is there something wrong with it,  like maybe the actual address of the bytes in the zip is different from the address in the unzipped file.
Yes, in the question's situation, a password-recovery attacks is entirely reasonable.

The question considers a (partially) known plaintext attack, where e.g. some header of the encrypted file(s) is known, for a file encrypted with AES, where the key has been determined from a user-supplied password. In this scenario, it is not important to consider the expected number of AES operations for brute-force search of the AES key ($2^{127}$ for AES-128, $2^{255}$ for AES-256) because that's not the best (nor a credible) attack strategy.

The reasonable attack strategy is password cracking: try passwords, approximately from most to least likely to have been chosen, and for each attempt decryption up to the point where known plaintext is reached, and move on to the next password if this test fail. Attack cost will depend on:


How the password was chosen. Users vary widely on that, and 123456 will be easier to find than MdSm2aZ!t&amp;5u*Z5. That varies widely with the context, and motivation of users. See the obligatory XKCD.
How the password is transformed into an AES key. A password-based key derivation function should be used here, parametrized so that it adds a sizable cost.


The cost for an attack grows roughly as $2^E$ times the cost of the PBKDF (assuming that dominates the cost of testing a password), where $E$ is the password entropy in bits. For example, if the password is 6 random decimal digits ($E=\log_2(10^6)\approx19.9\,\text{bit}$), and the PBKDF + plaintext testing uses 0.1 second of CPU time (300000 CPU cycles @3GHz), a competent attacker will use an average of $10^6\times10^{-1}/2=50000\,\text{s}&lt;14\,\text{h}$ of CPU time to find a password, that is less than 2 hours of wall clock time with a single 8-core PC, minutes for a powerful adversary.