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

This library fails to decrypt some files in older accounts #218

Closed
Inoom-ms opened this issue Sep 20, 2024 · 15 comments · Fixed by #219
Closed

This library fails to decrypt some files in older accounts #218

Inoom-ms opened this issue Sep 20, 2024 · 15 comments · Fixed by #219
Labels

Comments

@Inoom-ms
Copy link

Screenshot from 2024-09-20 16-09-20

No matter what i've done, the thing still appear, i searched everywhere and nothing, i think this is megajs issue.

Chrome 128 Linux Ubuntu

const storage = mega({/* or new Storage */
  email: '[email protected]',
  password: 'example,'
});
@qgustavor
Copy link
Owner

qgustavor commented Sep 20, 2024

Well... can you provide a full example? Your example is just showing logging in, is in that part of the code it is failing? From the call stack you provided that's not the case. I don't even know which version you are using. I only know the following:

  • You are using the browser version on Chrome since you posted an error call stack from Chrome's developer tools.
  • It seems there is some error in some crypto handling code as I see it fails after decryptECB.

I could assume it might trying to decrypt a key and you provided an invalid key, but I cannot be certain if just this info.

@Inoom-ms
Copy link
Author

Inoom-ms commented Sep 20, 2024

i read the documentation and copied this into my index.html, nothing more just logging in.
I'm using megajs 1.3.1, tired the Module and the Cjs version, same issue.
as i said earlier i'm using chrome 128 64 bit on my linux machine.
by the way, this error appears even when HTTPS.
this is the whole code:

<script src="https://unpkg.com/megajs@1/dist/main.browser-umd.js"></script>
<script>
    const storage = mega({
  email: '***@***',
  password: '*****,'
});
</script>

@qgustavor
Copy link
Owner

Your code works completely fine with my account. The UMD build is minified, use a non-minified build instead so the error stack becomes easier to understand:

<script type="module">
import { Storage } from 'https://unpkg.com/[email protected]/dist/main.browser-es.mjs'
const storage = new Storage({
  email: '***@***',
  password: '*****,'
})
storage.on('ready', () => console.log(storage))
</script>

From your first stack trace it looks like the issue starts here. My guess at the moment: there is something corrupted in your account and the library is not handling that well. If your account works fine in the official web client, maybe there is something new with MEGA that the library is not handling well. Otherwise, if your account does work fine in the official web client and you are trying to use this library to recover it, sorry, it got corrupt, this library can't recover it.

@Inoom-ms
Copy link
Author

Screenshot from 2024-09-20 17-21-09
yeahhh and i created a new mega account and it worked! sorry for disturbing if so. the problem is with my account, maybe because it's old? anways thanks, and sorry.
Screenshot from 2024-09-20 17-34-34

@qgustavor
Copy link
Owner

Weird, I thought my account was old. Since I still have to fix #213 I guessed it was something related to a new change, not something related to old accounts.

Seems a file in your account have a corrupt key, so it tries decrypting the file key with your account key and it fails because it expects a 128-bit key but whatever is stored in your account have between 1 to 3 bytes, causing the range error when decrypting it.

I will keep the issue open so anyone (or me in the future) with time to check into this and implement a way to the library not crash completely in this case. Those files cannot be decrypted in any way, but at least people can delete those from their accounts and still access their other files.

@qgustavor qgustavor reopened this Sep 20, 2024
@qgustavor
Copy link
Owner

@Inoom-ms Can you use Chrome's debugger and set a breakpoint right on this line? What's the value of opt.k right before it crashes? Maybe it uses an old format.

@qgustavor qgustavor changed the title RangeError This library fails to decrypt some files in older accounts Sep 20, 2024
@qgustavor qgustavor added the bug label Sep 20, 2024
@Inoom-ms
Copy link
Author

{
    "h": "V2IWkIgL",
    "p": "1jIEBAwL",
    "u": "bMEGrnSg7fc",
    "t": 0,
    "a": "IiagGrbl5uI5QDT__NyA01wvcaUEcW8MB1zlHPMnR2Fjsifaod_KEOhQNPZfcCTzpZ0ftawCPYrCSGYg9byjjleUG41vLWWd_HYKfBw20fc",
    "k": "bMEGrnSg7fc:KDTsPuj4mFlbdwUZwTu-pP7HMqsh-HrQO13l_5ncj34",
    "s": 1097960,
    "fa": "823:0*oxHm_Vj41pw/922:1*1QVa4TwpMBI",
    "ts": 1567459972
}

@qgustavor
Copy link
Owner

qgustavor commented Sep 20, 2024

Are you sure is that the file causing the issue? The one right before it crashes? Because if you take the file key (Buffer.from('KDTsPuj4mFlbdwUZwTu-pP7HMqsh-HrQO13l_5ncj34', 'base64url')) it's 32 bytes, so it should work fine.

Here what's happening:

  • loadMetadata handles populating File and MutableFile proprieties from the object you sent above
  • From the object you sent I know it's a 1.09 MB file and seems to be a thumbnail to it (so it might be a big image or a small video)
  • You need the file key to decrypt attributes and the file itself, so this code takes that k value, splits it on : and take the last part, which is the encrypted file key in Base64-URL
  • It them try decrypting the file key with the account key here but calling key.readInt32BE(i) fails
  • If calling readInt32BE fails with RangeError is because the buffer it is reading (in the case, the key) is smaller than 4 bytes, but, because this part of the code only runs if it's larger than 1 byte (because of key.length in the for above), so this key should be around 1 and 3 bytes.

By the way, it should be fine you posting this object as I can't decrypt it without the account key. At worst, if you share this file somewhere, someone can know this file is from you from its handler, but in most cases that's not a problem.

@qgustavor
Copy link
Owner

@Inoom-ms Do you have more info on that?

@Inoom-ms
Copy link
Author

I actually didn't upload any file ، anything, just tried to log in since you said it's 1.09mb

@qgustavor
Copy link
Owner

I mean, the issue isn't with uploading, there is a file that is in your account which the library cannot decrypt. As MEGA is an application with end to end encryption, any client can store anything on the user data as the server can't verify anything due to encryption. The only restriction the server can impose is checking length and blocking clients which don't implement any encryption.

So I guess some client you used in the past corrupted the data from this file and that's why this library is failing to decrypt it. Or it uses some format I'm not aware of. The official web client or can handle this format or it just ignores this file.

Open Chrome's debugger tool, add a logpoint inside this function, logging opt.k and run the code which is crashing. Then, check what was the value of opt.k right before it crashed. Most opt.k from the files in your account should follow the format "[your user id (bMEGrnSg7fc in your case)]:[encrypted file key (43 characters)]" but there must be at least one that doesn't follow this format.

@qgustavor
Copy link
Owner

@Inoom-ms Hi... I'm waiting your reply. If you help me finding this issue with your account I hope that I can make the library decrypt your file, otherwise the only thing I can do is making the library ignore the file and mark it as "undecrypted file" (by setting file.key to null when it can't decrypt opt.k).

@Inoom-ms
Copy link
Author

Inoom-ms commented Sep 25, 2024

Hello, sorry for late answer.
i actually added a breakpoint on if (!aes || !opt.k) return
the function is being called more than one time, i pressed on it 22 times, each time the value of opt.k is changing.
on the 23rd, it crashes.
here's the value of opt.k at first is :

bMEGrnSg7fc:KDTsPuj4mFlbdwUZwTu-pP7HMqsh-HrQO13l_5ncj34

and fainlly right before crashing is:

bMEGrnSg7fc:CAApw3ELqwzNtpcrjPP2aAyEq4I41v4Hlfj5N8JMUHUIZJMCJSkIRO_DYaWy7ejoMa3JygCYpySOF5MzuyEtu7UYECWWBCwqd1MNw8OyjJA2Eos9efrt2U7RvxPwnQ-2SEozaBHZjJ3fkYJ-r1FuB-z2SSQl0QjfIOJGcI4AapxBxiMIj7z8Tig19VYVVubNIJ9LXU9wpi0tpZV7KJ3ovr4ljzo20ilO3hxjm2-7JQdN21DnacUFGX7OaRS1TJekKRwGSbuGGKcGiMQrcAcyfKwoot21HKRaE_WbVKIZnzzZw2Lo7-5nSCZQ1OgWJDqjP4mDAyJ6gJcznEhINfkQmble

You said that the key should be 43 characters right?

I did the same thing on my new mega account, all the values of opt.k were as you said. In addition, i kept pressing on next breakpoint for 50+ times.

@qgustavor
Copy link
Owner

Thanks!!! That's a HUGE key! So huge that I guess it might be a RSA encrypted key.

IIRC that MEGAdrop feature works by encrypting the file key with the user public key, so maybe it's just a matter of decrypting this huge key using RSA. Since the library already does RSA decryption to log in MEGA servers, that's not hard to implement.

I will try to reproduce this issue on my account. If I can't manage to reproduce then I will look into MEGA's code and try to find something about that.

@qgustavor
Copy link
Owner

I managed to reproduce it, it was a RSA encrypted key. It will be fixed in the next version.

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

Successfully merging a pull request may close this issue.

2 participants