Saturday, April 18, 2020

Megadownloader 1.8 is out

Recently, MEGA made some changes and new links appear with a new format.

Instead of:

https://mega.nz/#!FILE_ID!FILE_KEY

new links have the format:

https://mega.nz/file/FILE_ID#FILE_KEY

This caused Megadownloader not to recognize the new links.
A manual workaround was possible, by modifying the links manually.

Version 1.8 has corrected this issue and now it supports files (and folders) in the new format.

It is already available, you can download the new version from the Download page.

Wednesday, November 18, 2015

MegaDownloader and Steganography

From version 1.7 onwards (click here to download it), MegaDownloader will add the option to hide MEGA links inside JPEG images using a technique called Steganography.

Steganography, according to the Wikipedia, "is the practice of concealing a file, message [...] within another file [...]. 
The word steganography combines the Greek words steganos (στεγανός), meaning "covered, concealed, or protected", and graphein (γράφειν) meaning "writing"."

Thanks to this technique, you will be able to hide, protect and share MEGA links directly from a JPEG image.

How will this option work?

MegaDownloader will allow these two options:
  • Create an image with hidden links.
  • Load links from the previous image and download them.

MegaDownloader will also allow to choose between saving the links in a visible way, or an "invisible" way, so the user that retrieves them will be able to download them, but not see them.

Moreover, links will be protected with a password (optional), so discover the hidden data will be very difficult (or directly impossible).

How does this feature work?


Steganography consists in two steps (normally it is referred as the first one, but in practice both are always applied):
  • Hide the data so an "attacker" doesn't know there is a hidden message.
  • Cipher the data so even if the "attacker" discover there is a hidden message, can't retrieve it.
This second step is easly achieved using cryptography (AES for example). The first step is more complex and depends on the image type.
For Bitmaps, normally the information is hidden in the LSB (less significant byte). A normal user won't be able to retrieve the data or notice there is something hidden. A stegano analyst will use "statistical attacks" in order to determine if there is a message hidden - normally with some degree of success.
However nowadays nobody uses Bitmaps... so what about JPEGs (the most common image format)?

The simpler way is to hide information after the EOF of the JPEG, or inside the EXIF or the comment markers (COM). These methods are trivial, a normal user won't see them easily but a stegano analyst will discover it immediately.

There are more complex techniques for JPEG. For example, hidding information in the DCT matrix.
This is how both Outguess and JSteg works. The bad side is that these methods are old and nowadays are considered broken - using statistical attacks it is possible to detect a message hidden.

A more recent technique called "F5" (an evolution of F3 and F4 algorithms) allow to hide information in the JPEG but makes it much difficult to an analyst to discover the message - it offers a good resistance to statistical attacks.
This algorithm can be broken in some cases using an statistical test called "Chi Square analysis". However, if the message is small enough compared to the container image, the probability of discovering a message is reduced.

So, to sum up, most of the steganographic algorithm are considered "broken", although F5 is one of the most secure. When we say "broken" we mean that an analyst can discover a secret message with a certain probability, but if it is ciphered, then he won't be able to deciphered it without the password - if the cipher algorithm is good, of course.

Which techniques implement MegaDownloader?


First, MegaDownloader uses the F5 algorithm to hide links inside the JPEGs. This ensures that will be very difficult, or even impossible in some cases, to discover a message in the image (the smaller message, the more difficult to discover).
It also distributes the message over the image, using a pseudo-random distribution based on a password, which difficults the analysis.

Second, the message is ciphered, using a 256 bit AES cipher, with a random IV generated with a CSPRNG (Cryptographically Secure PseudoRandom Number Generator).
The key is derived with a PBKDF2 function, using more than 25,000 SHA1 iterations with a salt.


Can this be tagged as "secure"? 
First, consider there is nothing 100% secure (specially for the NSA :p). Taking this into account, we have used some of the most advanced techniques to protect and hide the links inside JPEG images.
The security of the system is based on the password chosen for ciphering the data, so if the password is strong enough, it wouldn't be a mistake say that yes, it could be considered quite secure :)

Can I test it?


Of course! In this link you can download last version.

Want to try?
Download this image (or select the URL), put it into the Steganography window (Options/Retrieve links from an image) and enter the password "Megadownloader".

http://www.subeimagenes.com/img/output-1538992.jpg
If you find any problem or bug don't hesitate in posting it so we can help you :)

Thursday, March 19, 2015

MegaDownloader is no longer BETA! Version 1.0 released!!

A new version of MegaDownloader has been released, version 1.0!!

Instead of publishing version 0.93, we decided to release the version 1.0, leaving the "BETA" term.

The main reason for this decision is because MegaDownloader is mature enough to be considered "stable", not a BETA.

MegaDownloader was released on 1st February 2013.
It was the first application for downloading files from MEGA, and the first application that allowed the users to watch online video files.
For these two years, we have continued working on improving, fixing and developing MegaDownloader, and it is stable enough for everyday use.

The main changes of this version are:
- Fixed error when reading folder links
- Fixed filmaffinity and allocine Library support
- Added support for lix.in and adf.ly links

Of course, we will continue working on improving MegaDownloader even more ;)

Tuesday, January 27, 2015

New version v0.90 on the horizon!

A new version 0.90 will be released very soon!

Some changes:

- Support for Youpaste.co and encrypterme.ga

- Added a config backup - some users experimented data loss from an unexpected PC restart in some rare cases. Now the config file is saved twice in order to have a backup.

- Corrected some minor bugs with folders.

- Added support for http://mega.co.nz/#N!xxx links (links from a folder, they are not available through browser but can be downloaded with other managers).

- New mega:// encode (backward compatibility, but not forward; example, a link generated with 0.83 can be used in 0.90, but a link generated in 0.90 can't be used in 0.83). This will enhance link protection!

Keep up to date with the latest news! MegaDownlaoder will popup a reminder when the new version is available for download :)

Thursday, December 11, 2014

QUICKFIX - New version 0.83 to correct bug

MEGA is doing some changes in their SSL certificates. It seems that they are quitting SSL3 because of the POODLE bugs, so it causes problems with MegaDownloader 0.82

I am releasing version 0.83 in order to correct it.

If you want to try it, please download it here. If nobody reports connection problems, I will put it in the download page.

Thanks for your patience.

Monday, April 8, 2013

Integrating ELC into your community

Introduction


This article will explain how you can integrate the ELC system into your community - using MegaDownloader 0.8
For an overall view of the ELC system, please refer to the article: "Understanding mega:// links", section "ELC links".
Required knowledge: This article presupposes you have some knowledge about cryptography, hashing, BD, and HTTP protocol.

Server validation

ELC requires a server to perform two actions:
- Validate users, so only users of your community will be able to download the files.
- Encode or decode the internal password that will allow users to download the files.

Two pages are required:
- One page to show the users of your community HOW to configure their MegaDownloader/MegaUploader ELC account.
- One page to validate the data and perform the password encode/decode.

User validation

Each user will have two unique codes that will let them identify into your system. You have to provide them to your users using the first page.
The first code is the "Username", a public code that will identify which user wants to download the files.
The second code is the "API-Key", a private code that will validate the user as a valid member of your community.
Apart of that, you should also display to the user the URL of the second page (the one that validates the data).

This API-Key should NOT be the user's password. Using the user's password represents a security issue, because if you don't use SSL, the data will travel unencrypted.
The API-Key should be a code that validates the user for the ELC usage, and nothing else. If a third person gets the user's API-Key, he shouldn't be able to modify the user's account, or anything like that. An API-Key should also be regenerated when the user changes his password.

A good API-Key would be, for example, the hash generated from concatenating  the username and the hashed password stored in your system - normally you store a hash, not the plain password of the user. If the user changes his password, the API-Key will be changed, because the hashed password has been changed.
If you also add a random salt when generating the hash, then security is increased.
Normally communities use a CMS or forum, with their own tables where user data is stored.

For example, if your community DB has a table called "user", with two columns "username" and "password", you could do something like:
1) Get the value of the username and his (hashed) password.
2) Concatenate a random salt string to the username and the (hashed) password (optional but recommended).
3) Generate a hash (preferably a SHA256 or SHA512, it's longer but also more secure than MD5).

This final hash could be the API-Key.

Data process

So, in your first page, the one that displays the user's data to configure his ELC account, you should generate and display the API-Key. The page should also display the Username and the URL of the second page.

The second page will be used internally by MegaDownloader. You can find here a PHP example of this page.
Of course, if your system doesn't use PHP but another language (Java, .NET, etc) you should adapt the example to that language.
This page will receive HTTP POST petitions, so this page should not allow GET petitions - if a user puts this URL in his browser, an error should be displayed because this page is designed to be accesed with a POST petition.

Input
MegaDownloader and MegaUploader will send 4 POST parameters when generating an ELC or when reading an ELC:

- Parameter "USER": Will contain the user's code.
- Parameter "APIKEY": Will contain the user's API-Key.
- Parameter "OPERATION_TYPE": Two possible values: E or C.
- Parameter "DATA": a string containing the data to process.

The first two parameters are used for validating the user; the other two parameters are used for processing the data.


Output
The page will return, in all cases, a JSON response.

If there is an error (invalid user access, invalid data, etc), the page will return this structure:

{"e": "'ERROR DESCRIPTION", "d": ""}

If there is no error, the page will return this structure:

{"e": "", "d": "PROCESSED DATA"}

As you can see, only two parameters are returned: e (error) and d (data). One must be empty and the other filled.





The page will perform two different actions:

- First, it will validate the user by using the data contained in the "USER" and "APIKEY" parameters. If the user is not validated, then an error will be returned and the page won't continue with the second action.

- Once the user has been validated, then the page will process the data (by using the other two parameters "OPERATION_TYPE" and "DATA".

"OPERATION_TYPE" parameter will contain E or C (any other value will cause an error to be returned). E means Encrypt, and D means Decrypt. So basically, you will take the data contained in the "DATA" parameter, and will encrypt it or decrypt it depending on the value of "OPERATION_TYPE".
It's very important to emphasise that the input data of the E operation must be equal to the output data of the D operation, when the E output and the D input is the same. The encryption process must be simmetric!!

The way to implement the encryption/decryption process is up to you. But if you just want "something that works", then you can use the example provided previously.

The example page doesn't contain a "good" implementation of the first action: it just compares the USER and APIKEY values with a constant text. This is because depending on how your community works, you can make one implementation or another; the general idea of how it should work was provided in the previous paragraphs.

However, the second action is fully implemented. In the example, an AES cipher is performed to the data provided. You can use this example "as is", just changing the password at the beginning of the code.
If you prefer, you can implement the proces on another way. You can store the input data in your DB, and return the numeric ID of the inserted row. The decrypt process will receive the numeric ID, and you will retrieve the original information. It's perfectly valid - just take into account that this requires DB access, most resource consuming than performing an AES "on the fly".

How can you test this page?
The simplest way is by using Firefox  + an extension called "POSTER". You can also create a basic HTML form that POST the data to that URL, and open it with a browser. It's up to you.

Easy ELC configuration - Just click!

For users with little knowledge about computers, configuring the ELC can be confusing/difficult. For that reason, a "click once configuration" method has been created.

The idea is that the user click on a link, and MegaDownloader automatically configures the ELC account for the first time. That's all! The user has to do nothing else :D

In the page where you show the ELC information to the user, you should implement a mega:// link to do that. This mega:// link should be like this (copying the link also works if MegaDownloader is configured to detect links from clipboard):
mega://configelc?http%3A%2F%2Ftest.com%2Felc%3Fa%3D1%26b%3D2:User%20Name:Api%20Key:Account%20Alias

As you can see, it's a mega:// link with the "configelc?" code. After that, there should be 4 parameters, each one separated with a ":" character:
- Parameter 1: The ELC URL of your site, URI encoded (you can do it with Javascript using encodeURIComponent). In this example, the URL is "http://test.com/elc?a=1&b=2" (note you can use & or ? if you need it)
- Parameter 2: The user name of the user, URI encoded. In this example "User name" (note it supports spaces and other strange characters).
- Parameter 3: The API-Key of the user, URI encoded. In this example "Api key" (note it supports spaces and other strange characters).
- Parameter 4: This is an optional parameter, you can specify the Alias of the ELC account, URI encoded - in this example "Account alias".

When the user clicks on the link, MegaDownloader will ask the user if he wants to create/update the ELC account. If he says "Yes", then the ELC account configuration will be imported - and he has to enter no data at all!

Conclusion

For users, adding an ELC account should be easy - just clicking on a link.
For developers, creating the ELC pages should be also easy - the ciphering method is provided in the example, and only an user validation system has to be implemented.

Using ELC is a solid and robust system to protect your MEGA links so they can't be reported, and people outside your community can't download them.

Sunday, March 31, 2013

Understanding mega:// links

Introduction


From version 0.6, MegaDownloader supports mega:// links.
When you click on a mega:// link, MegaDownloader automatically opens and captures the link, so you can download them easily.
In this article, mega:// links will be explained and classified.

Mega links types

There are three basic types of Mega links:


Plain links.

These links contains the ID and the Key, similar to a normal mega link. For example, consider this link:
https://mega.co.nz/#!OFEQ0Y4Z!0123456789wVrs6n7Jyx8-9876543210nkI8MA5Gf4g

The mega:// equivalent link would be:
mega://#!OFEQ0Y4Z!0123456789wVrs6n7Jyx8-9876543210nkI8MA5Gf4g

You can generate your own plain mega:// links just replacing "https://mega.co.nz/" by "mega://".

Encoded links.

This links contain the ID and the Key encoded, and the URI has the form "mega://enc?xxx".
These links are generated by both MegaDownloader and MegaUploader, by going to "Options"/"Encode URLs", or by using the right click option "See links" and selecting the "Encode URLs" option.




You can share the encoded links, and MegaDownloader will grab them when you click on them or when you copy them (if you have activated the "Capture links from Clipboard" option).



What's the target of the encoded links? It was designed with the idea of offering a basic link protection, so the user can download the file but can't know the original link.

Please take into account that the level of security offered is not very high. Links are encoded using an AES password, but a high skilled user/hacker can retrieve it and get the original link. However most of the people will not be able to do it: At this moment it is even easier to decrypt a DLC than these encoded links ;)

ELC links.

ELC is the acronym of "Encoded Link Container".

This format, that will be released with MegaDownloader 0.8 and MegaUploader 0.7, is under development, but will offer two features:
  1. Link protection: Users won't be able to know the original link.
  2. Copy protection: Only authorized users will be able to access the file.

This is achieved by using a server to validate the user that tries to download the file. The idea is that each community (forum, etc) have a page to validate users.
When you create an ELC link, you have to select the community (previously configuerd) that will be have access to the links.
Once generated, only users with a valid account in that community will be able to download the files. In this way, even if someone pastes the Mega links outside the community, nobody without a valid account in that community will be able to download the files.

Interally files will be encoded using a random AES password, that will be recodified by the server. So without a valid account, nobody would be able to retrieve the original links, so security is guaranteed. The idea behind ELC is similar to the DLC, with the difference that DLC is public so anyone can download the links inside a DLC; ELC links will be private so only members of a community will be able to download the links.

ELC links can be found as a file (*.elc extension), or as a mega:// link, with the form "mega://elc?xxx".

For using the ELC, each community has to implement two webpages: (1) one for the user, so he can see the URL, user and API-Key he has to enter into MegaDownloader's configuration, and (2) another to validate the users and encode/decode the data.

Do you want to test ELC by yourself?
Well, first you have to download the test version of MegaDownloader 0.8. Then, you have to go to "Configuration", "ELC accounts", and create a new account with this data:
  1. Alias: Put anything you want, it's just an identificative name.
  2. URL: Put the community's URL for the ELC. For this test, use a demo URL "http://megadownloader.bugs3.com/ELC_Test/elc.php".
  3. User: Put "test".
  4. API-Key: Put "test".




Now you will have configured a "demo" ELC account, so you can download all ELC links generated for this community.

Do you want to try an example? Click on this link, and two files will be added - if you ELC account is correctly configured!
mega://elc?uXAAAACP5miGRF4WTvHQD_irXDUPmt2vLGBkl8suxITWNeXPUku3811CSgPTBkmqRL2Iw3PD4cp3Fyx5oDGZ0ESCkVlSYcS2WLDnCCGF095m5XGj-JAfpN63So4CzKXYZGJDXQ3QQ4v4--nrYoXqpjJZjn7BMABodHRwOi8vbWVnYWRvd25sb2FkZXIuYnVnczMuY29tL0VMQ19UZXN0L2VsYy5waHBAAGFPYkppTEUvK01acDI5cTVGZW81VkdkWVBUSExsWEhTSXM0cGx4eG5vK2F4SlhKVHFFYVUzVkhSZmdENEswcDI

A detailed article will explain it in depth, but meanwhile you can take a look at the source code of the demo page, available here. The encode/decode process is fully implemented (just change the password) but you will have to implement the user's validation.
Two fields will be sent on each petition: user and API-Key. The API-Key should be a code that identifies the user and only he should know it. For security, it should not be the user's password, but something like the hash of the nick + the hashed password stored in your DB, and should be shown on the first page we have commented (where the user sees the URL, user and API-Key, so he can configure MegaDownloader).

Conclusion
MegaDownloader and MegaUploader supports 3 types of mega:// links, with different levels of security, in order to use comfortably MegaDownloader and protect your Mega links :)


Link typeLink protectionCopy protection
Plain linksNoneNone
Encoded linksMediumNone
ELC linksHighHigh