Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to find the next file name? #1

Open
bvid34tgd opened this issue Jul 6, 2023 · 3 comments
Open

How to find the next file name? #1

bvid34tgd opened this issue Jul 6, 2023 · 3 comments

Comments

@bvid34tgd
Copy link

After deserialized a file, the left part is stored in another file. Then what's the relation between different file? How to find which file is needed?

@AppleSheeple
Copy link
Owner

A little bit of guess work is involved.

Maybe you know this already, but it's workable if you clear the storage first, and sort the cached encrypted files by creation time (e.g. using exa's -s created and -U arguments) to see the order by which the cached data was written.

You would use the decrypted files after that of course. Encrypted files are just used to check the order.

@bvid34tgd
Copy link
Author

Thank you for this feasible way !!!

And I also find some files with strange header:

00 00 00 00 14 00 00 00 40 00 00 00 

It looks like many int value.

Have you come across this kind of file? Do you have any idea about this.

@cybacolt
Copy link

cybacolt commented Aug 11, 2023

Regarding the serialization - there may be multiple tail parts in the serialized file. If there is more than one tail part, the penultimate parts may overlap with the end of the last slice file.

It is also possible to work out most of the file-sets and order by:

  1. making sure you play / buffer the video completely in Telegram
  2. sorting the decrypted files by the timestamps on the original cache files
  3. filter / remove mp4 file types (these are not serialized)
  4. the remaining files over 8388608 bytes are the initial serialized file
  5. all subsequent slice files until the next serialized file belong to the same file-set
  6. the resulting file-set should only have one file under 8388608 bytes (the last slice file)
  7. the file-set will be in contiguous order
  8. occasionally the last slice file is written out of sequence, and will need to be moved to the end of the file-set before concatenating deserialized head, slices file-set, and deserialized tail into one file

There may also by many small files outside of these identified file-sets in the media_cache. these can be discarded - I suspect they are auto-downloaded thumbnails/partials (depending on your settings), and don't seem to contain anything recognisable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants