Latest Tweets

It’s so dark, that it is not even implemented (yet) Part II

The DIME management record

According to the specs document, the DIME standard is based on “the DIME management record”. This record, set as a new sort of TXT record in a DNS domain server, will allow other DMTP-capable servers to communicate securely and privately with no information leakage. Its the cornerstone of the standard, so to speak. This record, of course, has only one mandatory field (POK), and a bunch of optional ones. The Public Organisational Key (POK for short) can be easily obtained by means of using the signet tool, as described in my previous POST. However, and according to the specs document, an additional TLS field must be provided in order to secure the channel. When using dnssec, it is possible to have a self-signed server certificate, but it is mandatory to provide the TLS field in the DIME management record; otherwise there is not going to be any valid TLS communication using the DMTP (DSMTP in this case) protocol.

Inside the dev/tools directory there is a tool called “genrec”. This is the tool you are supposed to use in order to generate this record for your DNS authoritative server. Well, as expected it did not work.


I had my new signet and my MAGMA server set up accordingly; next step I guessed was to generate my DIME management record. So I built the genrec tool and executed it:

../../genrec -k -c tls.localhost.localdomain.pem
Error: could not read ed25519 POK from keyfile.

Of course I should have generated a new TLS file (this file has the certificate and the private key), because my test domain was “”. However, this had nothing to do with the issue at hand. Again, I delve into the source code and I found this:

if (!(pemdata = _read_pem_data(filename, "ED25519 PRIVATE KEY", 1))) {
    RET_ERROR_PTR(ERR_UNSPEC, "unable to read ed25519 private key data from PEM file");

So, genrec was looking for a file with the tags “—–BEGIN ED25519 PRIVATE KEY—–” and “—–END ED25519 PRIVATE KEY—–“. Guess what? The private keys file that was generated using the signet tool had these ones instead: “—–BEGIN ORGANIZATIONAL SIGNET—–” and “—–END ORGANIZATIONAL SIGNET—–“. This is a clear example of forgotten left-overs!

So because I was a bit impatient, I made a copy of my file and then I changed the tags accordingly. Again, genrec complaint about not being able to read the key. So more code-delving! A bit later, I ended up here:

if (!(keys_bin = keys_file_serialize(filename, &keys_len))) {
    RET_ERROR_PTR(ERR_UNSPEC, "could not retrieve keys binary string");
key = keys_signkey_from_binary(keys_bin, keys_len);

The previous code snippet was reading a total of 73 bytes! Obviously, a valid key is 32-byte long (after being base64-decoded, of course). So I had a quick look at the way the signet tool was generating and reading the keys. Loaded with this useful information, I set about to modify the function _load_ed25519_privkey, the one performing the loading of the private keys file for genrec (the commented-out lines are mine):

ED25519_KEY * _load_ed25519_privkey(char const *filename) {
        ED25519_KEY *result;
        //unsigned char *keydata;
        //char *pemdata;
        //size_t klen;
        if (!filename) {
        /*if (!(pemdata = _read_pem_data(filename, "ED25519 PRIVATE KEY", 1))) {
                RET_ERROR_PTR(ERR_UNSPEC, "unable to read ed25519 private key data from PEM file");
        // TCG: proceed as the signet code; first read from the key file:
        if (!(result = dime_keys_signkey_fetch(filename))) {
                RET_ERROR_PTR(ERR_UNSPEC, "unable to read ed25519 private key data from PEM file");
/*      keydata = _b64decode(pemdata, strlen(pemdata), &klen);*/
//      _secure_wipe(pemdata, strlen(pemdata));
//      free(pemdata);
//      printf("Keylength: %zu\n", klen);
        /* Okay, something is really wrong here. The klen is 73 bytes!! */
//      if (!keydata /**/|| (klen != ED25519_KEY_SIZE)/**/) {
        if (!result) {
/*              if (keydata) {
                        _secure_wipe(keydata, klen);
                RET_ERROR_PTR(ERR_UNSPEC, "bad ED25519 key data was read from file");
/*      if (!(result = malloc(sizeof(ED25519_KEY)))) {
                _secure_wipe(keydata, klen);
                RET_ERROR_PTR(ERR_NOMEM, "unable to allocate space for ED25519 key");
        memset(result, 0, sizeof(ED25519_KEY));
        memcpy(result->private_key, keydata, sizeof(result->private_key));
        _secure_wipe(keydata, klen);
        ed25519_publickey_donna(result->private_key, result->public_key);*/
        return result;

After this change, I re-built the genrec tool and tried again:

../../genrec -k -c tls.localhost.localdomain.pem
ver=1 pok=E7gyvx3E6ksBVkg9CD5XBoXX18txj45iFSqtn9NLqjA tls=c2jM4G+EFZROQYNOyvwVSiQhgL5QW3UJN3CaIipR/Z4hjoSZoO72UlGXdKsAl1T1RQh+/h9rETD1+vaPbkIGCg pol=experimental sub=strict

This time it did work; I made sure the POK value was the same by calling signet: they matched up. So I added the DIME management record to my zone file and re-signed the entire zone: 120 IN TXT “ver=1 pok=E7gyvx3E6ksBVkg9CD5XBoXX18txj45iFSqtn9NLqjA tls=c2jM4G+EFZROQYNOyvwVSiQhgL5QW3UJN3CaIipR/Z4hjoSZoO72UlGXdKsAl1T1RQh+/h9rETD1+vaPbkIGCg”

dnssec-signzone -l -o -k

So far so good. But there’s still more to come! See you guys in Part III!

It’s so dark, that it is not even implemented (yet) Part I


DIME has been publicized a lot since last January. I’ve been reading the specs document (from 2015) and I have cloned the git repository in order to compile and test MAGMA, their open source server. This server, at least in theory, implements SMTP, IMAP, HTTP, MOLTEN, DMTP and DMAP. But of course, according to github:

The magma server daemon, is an encrypted email system with support for SMTP, POP, IMAP, HTTP and MOLTEN,. Additional support for DMTP and DMAP is currently in active development.

Anyway, I thought it would be interesting to test it because, although I suspected that maybe some parts would not be completely functional, the best part of the MAGMA server would. Otherwise, they would not be saying this (from their website:

What is Magma?

Magma is Lavabit’s open source, commercial-grade, and full-featured server ready for use with the Dark Internet Mail Environment. Magma is now ready for commercial implementation and will fundamentally change the way business transmits encrypted data. Whether you are an individual, SME, or corporate enterprise wanting your own DIME compatible server, the Lavabit technical team can assist with your implementation and development needs.

But no; unluckily for us all, MAGMA seems far from being “full-featured server ready for use with the Dark Internet Mail Environment”. This is the first of a series about my impressions on MAGMA and the DIME standard. Keep reading!

First thing that do not seem to work: its tools.


After being able to compile and run MAGMA, I wanted to delve into the concept of “signets” and the “DIME management record”. I read the specs document, dated from 2015, and after that I tried the “signet” tool under dev/tools. This tool can generate new signets,  sign the SSR files (sort of a CSR file) and dump some information about signets. Of course, it worked out-of-the-box, at least apparently. This is me generating a new organizational signet for my MAGMA test environment:

../../signet -g
Organization name: LUD.ORG
Organization address: ADDRESS
Organization country: COUNTRY
Organization postal code: POSTAL_CODE
Organization phone number: PHONE_NUMBER

After running the previous command, I had two files: the signet itself and the private keys file:

ls -l lud*
-rw——- 1 root root 176 mai 26 23:33
-rw-r–r– 1 root root 531 mai 26 23:34

Now some basic stuff, like getting some information from this new signet:

../../signet -d
— version: 1, size = 333, signet type = organizational
— 1 Primary-Organizational-Key -> QO3pMGOqP51Wz/Q8HRgLP4U0eIhYC+29kT0fDaSyX36B

Obviously, you don’t want to have the dime.localhost.localdomain.signet in your MAGMA testing environment. You want to test your own signets. So replacing these two server configuration lines with the ones pointing to my new signet and its private keys file counterpart only seemed natural at the time:

magma.dime.key = sandbox/etc/
magma.dime.signet = sandbox/etc/

Then, I re-started the MAGMA server and the first issue arose:

Unable to parse the PRIME organizational signing key.
Unable to initialize the privacy respecting internet mail environment. Exiting.
magma.init != shutdown {23 != 39}
Magma shutdown complete.

Of course, I was puzzled. This change seemed trivial at the time. So I looked for issues in the code, using the “Unable to parse the PRIME organizational signing key” as the starting point. Soon I realized that the main problem was that the MAGMA developers do not seem to follow their own specs document so close. With the signet tool,  the POK for this new organizational signet was 44-byte long, base64-encoded:


This is so in the specs document. On the other hand, the already provided dime.localhost.localdomain.signet POK is 43-byte long:

../../signet -d dime.localhost.localdomain.signet
— version: 1, size = 139, signet type = organizational
Primary-Organizational-Key -> h44kA4AXy2gFnlF+osucG2t4SOBeu8CA3WWxo6RLfIA

WTF? Following the code path, I ended up right here:

                serial_size = ED25519_KEY_SIZE + 1;
                if (!(serial_key = malloc(serial_size))) {
                        RET_ERROR_PTR(ERR_NOMEM, "could not allocate memory for serialized signing key");
                serial_key[0] = format;
                memcpy(serial_key + 1, key->public_key, ED25519_KEY_SIZE);

So the first byte of the key, that is, serial_ley[0] is 0x40 (SIGNKEY_DEFAULT_FORMAT). This is what makes the base64-encoded key 44-byte long. The magma server routines were expecting a 43-byte base64-encoded string instead! This was not what the specs document says at all! So I made this slight alteration:

//              serial_key[0] = format;
//              memcpy(serial_key + 1, key->public_key, ED25519_KEY_SIZE);
                memcpy(serial_key, key->public_key, ED25519_KEY_SIZE);

After that, I re-built the signet tool:

make signet
Building src/providers/dime/signet/signet.c
Constructing signet

And I generated a new signet, this time I made sure its POK was 43-byte long (base64-encoded):

../../signet -d
— version: 1, size = 287, signet type = organizational
— 1 Primary-Organizational-Key -> E7gyvx3E6ksBVkg9CD5XBoXX18txj45iFSqtn9NLqjA

This time, the MAGMA server ran with no issues at all:

00:21:05 – src/engine/context/process.c – process_start() – 343] = Magma initialization complete.

Signing SSR files

Of course, this small alteration broke the signing of SSR files:

../../signet -s “” -r -k
The signet is not a valid SSR.

After going through the code once again, I ended up here:

       //switch (serial_key[0]) {
                // This not applies here anymore!
/*              if (key_size != ED25519_KEY_SIZE + 1) {
                        PUSH_ERROR(ERR_UNSPEC, "invalid signet signing key size or format");
                        key = NULL;
                //key = _deserialize_ed25519_pubkey(serial_key + 1);
                key = _deserialize_ed25519_pubkey(serial_key);
                key = NULL;
                PUSH_ERROR_FMT(ERR_UNSPEC, "unsupported format specifier for signing key: %u", serial_key[0]);
        if (!key) {
                RET_ERROR_PTR(ERR_UNSPEC, "could not convert signet serial format key to object");
        return key;

The lines commented out are mine, of course. With this yet another small alteration, and after re-bulding the signet tool, now the singing of SSR files are working and the MAGMA server runs and everything looks great …. right?

../../signet -s “” -r -k
User name: Test MAGMA
User address: ADDRESS
User country: COUNTRY
User postal code: POSTAL_CODE
User phone number: PHONE_NUMBER

ls -lt test*
-rw-r–r– 1 root root 609 mai 27 00:50
-rw-r–r– 1 root root 156 mai 27 00:24
-rw-r–r– 1 root root 271 mai 27 00:24

Not quite. More on MAGMA soon! In the meantime, if you happen to be a MAGMA developer, I emailed and I have opened a new issue on github about this, so please let me know any improvements about these issues if possible, that would be great!

Extract valuable information from binaries with radare2


Radare2 is a powerful reverse engineering framework widely used for reverse engineering binaries meant for different architectures. I came across it while dealing with some vulnerabilities of my TENVIS T6812 IP Camera. Later on I started using it on a regular basis for almost everything. I have yet a lot to learn from it, of course! One thing I enjoyed doing was to extract some valuable information from the main server binary of my TENVIS Ip Camera.

Tenvis T6812 Camera.

This IoT device is full of flaws. I have yet to perform more tests, but I found at least two different vulnerabilities: a buffer overflow issue affecting the ipc_server binary in charge of interfacing with the camera and the web server and some information disclosure (a directory named /tmpfs, accessible from the browser and holding the ipc_server binary itself along with some libraries and configuration files).

The ipc_server binary

After being able to download this binary from the tmpfs directory using my browser, I used radare2 in order to analyse it:

r2 tmpfs/ipc_server
[0x00026df0]> aaaa

The authentication method for this particular camera is  based on the HTTP Header “Authorization”, of type basic. Therefore, I was expecting to find the “.htpasswd” string somewhere within the binary:

[0x00025420]> iz~.htpasswd
vaddr=0x000efd50 paddr=0x000e7d50 ordinal=2839 sz=10 len=9 section=.rodata type=ascii string=.htpasswd
vaddr=0x000f0d94 paddr=0x000e8d94 ordinal=3021 sz=55 len=54 section=.rodata type=ascii string= mongoose -A <htpasswd_file> <realm> <user> <passwd>\n

So there were two strings holding the value “.htpasswd”. The second one at 0x000f0d94 was, in fact, a call to the “mongoose” program. I looked for the string “mongoose” inside the binary:

[0x00025420]> iz~mongoose
vaddr=0x000ef440 paddr=0x000e7440 ordinal=2754 sz=18 len=17 section=.rodata type=ascii string=websvr/mongoose.c
vaddr=0x000f0d94 paddr=0x000e8d94 ordinal=3021 sz=55 len=54 section=.rodata type=ascii string= mongoose -A <htpasswd_file> <realm> <user> <passwd>\n
vaddr=0x000f0dcc paddr=0x000e8dcc ordinal=3022 sz=26 len=25 section=.rodata type=ascii string= mongoose <config_file>\n
vaddr=0x000f0de8 paddr=0x000e8de8 ordinal=3023 sz=32 len=31 section=.rodata type=ascii string= mongoose [-option value …]\n
vaddr=0x000f0e30 paddr=0x000e8e30 ordinal=3026 sz=78 len=77 section=.rodata type=ascii string=See for more details.\n
vaddr=0x000f0e80 paddr=0x000e8e80 ordinal=3027 sz=50 len=49 section=.rodata type=ascii string=Example:\n mongoose -s cert.pem -p 80,443s -d no\n
vaddr=0x000f0efc paddr=0x000e8efc ordinal=3031 sz=14 len=13 section=.rodata type=ascii string=mongoose.conf

So, apparently, the ipc_server was using mongoose. I decided to browse, extracted from the binary itself. I got an HTTP 403 error. This gave me proof that this mongoose implementation was obsolete indeed. I browsed the main project’s page instead:

And so, I’ve discovered what mongoose was meant for:

Mongoose is an embedded HTTP and WebSocket library that can turn anything into a web server in 5 minutes by adding a few lines of C/C++ code

Getting mongoose version

So I downloaded the latest available version of mongoose from, and I started looking around with cscope. I found out that all the callable functions started with mg_, like mg_version (I found that thanks to the win32 dll definitions):

cat win32/dll.def

I got back to my radare2 session and enumerated functions starting with mg_:

[0x00025420]> afl~mg_
0x0007bed8 3 56 sym.mg_get_option
0x0007d73c 17 584 sym.mg_md5
0x0007c19c 20 688 sym.mg_read
0x0007c414 1 56 sym.mg_write
0x0007c980 1 92 sym.mg_printf
0x0007d500 40 568 -> 844 sym.mg_get_var
0x0007be6c 1 28 sym.mg_GetMediaServerHandle
0x000c61ec 3 56 sym.img_dsp_set_aaa_static_frequency
0x000bbcfc 1 4 -> 60 sym.img_set_aaa_frequency
0x0007e7ec 17 528 sym.mg_modify_passwords_file
0x0007bf20 7 112 sym.mg_get_header
0x0007ea18 12 60 -> 156 sym.mg_stop
0x0007becc 1 8 sym.mg_get_valid_option_names
0x0007ea54 1 40 sym.mg_pause
0x0007be8c 1 28 sym.mg_GetRtspOverHttpHandle
0x0007be0c 1 16 sym.mg_RegisterSnapChn
0x0007bdf8 1 16 sym.mg_RegisterHttpPort
0x0007be38 1 16 sym.mg_RegisterGetUserPass
0x0007be20 1 20 sym.mg_RegisterHttpAuth
0x0007bdc0 1 52 sym.mg_RegisterDistribLink
0x0007bf14 1 8 sym.mg_version
0x000c4e98 12 4 -> 444 sym.img_dsp_set_video_mctf_ex
0x0007be4c 1 28 sym.mg_GetHttpPort
0x0007beac 1 28 sym.mg_GetPlayBackHandle
0x0007ea80 56 1548 sym.mg_start

Indeed; mongoose was being used by ipc_server. In fact, this library was linked statically within the binary. Therefore, I got the sym.mg_version function at address 0x0007bf14.  So I jumped into that function and disassembled it:

According to the previous assembly code snippet, ipc_server was linked against mongoose 3.0:

0x0007bf14 00009fe5 ldr r0, [pc] ; [0xef5cc:4]=0x302e33 ; LEA str.3.0 ; “3.0” @ 0xef5cc

[0x0007bf14]> ps @0xef5cc

Mongoose 3.0 well-known vulnerabilities

Apart from the buffer overflow I have already found, I googled mongoose 3.0 vulnerabilities and this came out:

So this camera ships with another buffer overflow vulnerability as well. This one is a well-known vulnerability, with at least one working exploit for some vendor implementing it here:

And now …

I have contacted TENVIS in order to let them know about my findings and this already reported vulnerability. So far, no answer. I’ll be toying with my camera a lot more, so stay tuned for upcoming posts!