Does AES CTR mode store header information in encrypted files? According to the movable-type.co.uk website,


  In the ‘counter mode’ used in this implementation, a counter which changes with each block is first encrypted, and the result is bitwise xor’d with the plaintext block to get the ciphertext block (so the plaintext is not actually directly encrypted). A unique ‘nonce’ is incorporated in the counter to ensure different ciphertexts are always generated from the same plaintext every time it is encrypted; this number is stored at the head of the ciphertext to enable decryption. A combination of seconds since 1 Jan 1970, a millisecond-timestamp, and a sub-millisecond random number gives a very effective nonce. (To resist cryptographic attacks, the nonce does not need to be secret or unpredictable, but it is imperative that it is unique). In this implementation, the initial block holds the nonce in the first 8 bytes, and the block count in the second 8 bytes…


So, it says that the “nonce is stored in the cipher text to enable decryption”. Is that true for every AES CTR mode implementation? And if we want to decrypt a certain block from the middle, do we first have to extract the nonce from the first 8 bytes and the block count from the following 8 bytes?
I would like to ask if that is true for every AES CTR mode implementation?, 


Doesn't have to be. You can store the nonce anywhere. You could even send it to the recipient via a different channel (e.g., email the ciphertext and use SMS to transmit the nonce). Storing it at the beginning has its advantages. For example, if streaming the data, you can begin decrypting immediately.


  and If we want to decrypt a certain block from the middle, we first have to extract the nonce from the first 8bytes and block count in the second 8 bytes ?


Yes, if you want to decrypt a particular block in the middle, you must extract the nonce first, and figure out what the proper counter value should be. Then you can decrypt.