Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

Support attribute downloading #23

Closed
qgustavor opened this issue Jul 26, 2017 · 4 comments
Closed

Support attribute downloading #23

qgustavor opened this issue Jul 26, 2017 · 4 comments
Assignees

Comments

@qgustavor
Copy link
Owner

Currently only uploading attributes (thumbnail and preview images) are supported.

@qgustavor
Copy link
Owner Author

qgustavor commented Nov 8, 2018

Attribute handlers are stored on the .fa property returned by the server when listing files in this format: 123:0*aaaaaaaaaaa/456:1*bbbbbbbbbbb. It's a string represeting each attribute separated with /. The attribute with 0* is the thumbnail and 1* is preview image. I don't know what 123 and 456 represents.

Encrypted attributes can be downloaded by requesting their upload URL using {a: "ufa", fah: "attribute handler", ssl: 2, r: 1}. SSL parameter works similar to the one used when downloading files (setting it to 0 returns a HTTP URL, setting it to 2 returns a HTTPS URL). The URL is returned in .p property. The returned contents need to be decrypted using AES-CBC using the file decryption key.

Seems .fa is also used to stored video codec information on the *8 attribute. Stored info is FPS, width, height, audio codec name, video codec name, video duration, video container and "shortformat". Would be a good thing implementing parsing and updating this attribute?

Edit: video informations are stored encrypted with XXTEA. Why not AES? Maybe they wanted a smaller block size. Why not XSalsa20 (as MEGA already uses TweetNaCl)? I don't know...

@qgustavor
Copy link
Owner Author

Why not AES? Maybe they wanted a smaller block size. Why not XSalsa20 (as MEGA already uses TweetNaCl)? I don't know...

After working on this I know the answer: because XSalsa20 is not a block cipher, is a stream cipher.

Looks like they want to reduce the space used by the ciphertext, then they can't use a stream cipher because it would require to store a nonce and replace it every time otherwise information would leak. The same issue don't happens with block ciphers.

@qgustavor qgustavor self-assigned this Feb 19, 2022
@AlttiRi
Copy link

AlttiRi commented Feb 20, 2022

123 and 456 are bunch (group) number for the bulk downloading.
The thumbs/prevs with same bunch number can be requested within one download request.

You can debug a demo (node, or browser) of my unfinished library https://github.com/AlttiRi/meganz-api to investigate how it works.

Repository owner locked and limited conversation to collaborators Mar 24, 2022
@qgustavor qgustavor converted this issue into discussion #96 Mar 24, 2022

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Projects
None yet
Development

No branches or pull requests

2 participants