Hacker News Reader

Comment by AnonC | Hacker News Reader

When I read the original blog post by Cellebrite, which is on archive.org [1], it left me scratching my head too. Signal is open source. They had access to the device to dump everything. Then they went through the source code to figure out how to decrypt the data. Just as this blog response says, they could’ve just opened the app and retrieved the contents (and even forwarded that to another device if they wanted).

So someone enthusiastically posted about wasting their time as if it was a technological achievement. Then someone (else?) realized that the long technical post sounded stupid and had it replaced.

And some people wonder where their tax money goes to — all these companies who are better at marketing themselves well as experts are getting free lunches!

[1]: https://web.archive.org/web/20201210150311/https://www.celle...

View on HN

> Cracking The Code

> [...] Once the decrypted key is obtained, we needed to know how to decrypt the database. To do it, we used Signal’s open-source code and looked for any call to the database. After reviewing dozens of code classes, we finally found what we were looking for

> [...] After linking the attachment files and the messages we found that the attachments are also encrypted. This time, the encryption is even harder to crack. We looked again into the shared preferences file and found a value under “pref_attachment_encrypted_secret” that has “data” and “iv” fields under it.

Today I learned that I can do code cracking too...

Only if you can review dozens of code classes, that is.

grep is now an evil code cracking tool.

Don't tell the FBI this, they won't know you're joking (see schwartz, manning, & wget).

It's not that they don't know, it's that they know most people, including most judges, don't know.

Can't wait to see the next LinkedIn profile buzzword soup:

"grep wizard who single handedly found the needle in the haystack"

No, people who review dozens of classes to find something are definitely not familiar with grep.

Use `ack -C8` when searching, adds a few lines of context helping identify the one class that matters.

I read "reviewed dozens" as "got lost in the code for a bit"

GNU grep has `-C` too (idk about POSIX)

bsdgrep [0] has it too. Apparently POSIX [1] does not, the spec is really minimalist.

[0] https://www.freebsd.org/cgi/man.cgi?query=bsdgrep&sektion=1

[1] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/g...

is the equivalent to calling oneself a lock picking expert because they had the actual key to the lock?

After opening the cabinet and the box with money we found is also locked. This time, the lock is even harder to crack. We looked again into every single coffee mug and bookshelf in the room, and found a keychain hanging on the second office desk drawer, that has the "key" on it...

I needed to get into my office so I asked my boss for a key. She gave me an entire key ring of keys. After trying dozens of keys against my office door I finally found the key that worked.

It's actually how you decrypt an anonymous OpenPGP message (e.g. in GnuPG, you can create one using --throw-keyids or --hidden-recipient) - Normally an OpenPGP message records its intended recipients in the header, so GPG knows which key to use right away. But when the message is anonymous, GPG must try all the private keys in the keyring one by one, until it sees a valid solution or fails. If you have multiple private keys, you'll go through many passphrase popups (and smartcard/USB swapping), the struggle is real!

Trial decryption. This is a potential server behaviour for Encrypted Client Hello (the current iteration of the work to encrypt SNI in TLS traffic) too

ECH will be GREASEd. To prevent those who might want the capability to stop ECH in the future from getting a head start while it's uncommon, implementations would always pretend to be doing it anyway.

So talking to any TLS server, even one that has no idea about ECH, the client says basically "Hi, here is a normal unencrypted TLS 1.3 Hello message for this.server.example, also, here's an Encrypted Client Hello message". If the server actually does offer ECH, there could be a real Client Hello, perhaps addressed to another.server.example, encrypted inside the Encrypted Client Hello, but if not there's just random noise. An eavesdropper doesn't have the key, so they don't can't tell which is the case.

Obviously if your server can't do ECH, the Encrypted Client Hello is just a mysterious unintelligible extension with noise inside it, no further inspection needed.

And in some setups the server knows how to tell easily which key would have been used for any valid ECH, so if that key doesn't work then it was just noise, and can be ignored.

But in other cases the server knows two or more keys that might be valid, yet the client either can't or has chosen not to be open about which (if any) was used, so the server has to try them all until it finds out.

This is Section 10.4 of the current draft:

https://tools.ietf.org/html/draft-ietf-tls-esni-09#page-28

Is there a worry that with enough potentially valid keys this will make a https DDOS any easier or will all the same mitigations be good enough?

Great comment! Thanks for telling me that ESNI is more interesting than I thought. /me TODO: read the ESNI spec from cover to cover.

How does it know that any given decryption is valid? A heuristic like "this is mostly ASCII"?

Simple, you just check whether the header, data structure, metadata, checksum, etc. in the trial-decrypted data in valid, no hack is needed. For example, something as simple as a 16-byte magic number can ensure a false positive rate of 1/2^128. Since any arbitrary binary data can be encrypted, "this is mostly ASCII" is unusable.

In GPG:

    /* if KeyID is empty... */
    if (!k->keyid[0] && !k->keyid[1])
    {
        log_info (_("anonymous recipient; trying secret key %s ...\n"), keystr (keyid));
    }

    err = get_it (ctrl, k, dek, sk, keyid);
    k->result = err;
    if (!err)
    {
        /* If get_it() succeeds */
        if (!opt.quiet && !k->keyid[0] && !k->keyid[1])
        {
            log_info (_("okay, we are the anonymous recipient.\n"));
        }
    }

And in get_it()...

    if (sk->pubkey_algo == PUBKEY_ALGO_ECDH)
    {
        /* Now the frame are the bytes decrypted but padded session key.  */
        if (!nframe || nframe <= 8
                || frame[nframe-1] > nframe)
        {
            err = gpg_error (GPG_ERR_WRONG_SECKEY);
            goto leave;
        }
    }
    else
    {
        if (padding)
        {
            if (n + 7 > nframe)
            {
                err = gpg_error (GPG_ERR_WRONG_SECKEY);
                goto leave;
            }
        }
    
        if (n + 4 > nframe)
        {
            err = gpg_error (GPG_ERR_WRONG_SECKEY);
            goto leave;
        }
    
        if (dek->keylen != openpgp_cipher_get_algo_keylen (dek->algo))
        {
            err = gpg_error (GPG_ERR_WRONG_SECKEY);
            goto leave;
        }
    
        /* Copy the key to DEK and compare the checksum.  */
        csum = buf16_to_u16 (frame+nframe-2);
        memcpy (dek->key, frame + n, dek->keylen);
        for (csum2 = 0, n = 0; n < dek->keylen; n++)
            csum2 += dek->key[n];
        if (csum != csum2)
        {
            err = gpg_error (GPG_ERR_WRONG_SECKEY);
            goto leave;
        }
    }

You get the idea.

BTW, did I just "break GPG encryption and deanonymize users" according to Cellebrite because I found the correct function in the code? And no, I didn't "review dozens of code classes", I just grepped the word "anonymous"... /s

Ah, I see, I didn't realize there was that much structure to the payload. Thanks!

What's it like to be an elite hacker?

Having the actual key to the lock, then using that to specially craft a pick made in the exact same shape and size as the original key. And then using that to "pick" the lock.

So maybe more like the person who works the key cloning machine at the hardware store.

"they could’ve just opened the app and retrieved the contents" is not really sufficient.

First, doing it manually through the app is not okay since it does not scale, you don't want to read a message, you want to retrieve and index all messages, and you might want to process many devices quickly.

Second, apps usually do not show the user all the information that's available - often there is extra metadata (which may be as important as the message contents) so you do want to decode the actual message database.

Third, doing it through the app might change things - the app may change state (for example, mark an unread message as read), send some notification to central servers, alter metadata, etc. So it potentially disrupts evidence, and that's not okay.

So the original blog post from Cellebrite makes all sense - if you do want to do forensics, then a tool that does all that is really a requirement, it's not wasting time.

As a forensic tool, it surely does, and such tools are both common and have their robust client base. I think the mistake in that article was to present a forensic tool as some kind of advanced code-breaking. I guess it sounds more exciting this way, but also kinda misleading - which is witnessed by the fact that BBC was totally misled about it.

Well starting a blog post by pointing out criminals are using it to communicate secretly and ending the post by concluding you can read it if you gain priviledged access to the device they're using to communicate is a bit of a let-down to be honest.

Now if they were able to break the Keystore itself then they might be on to something but as it is it requires convincing criminals to give up their phone and their password. If you translate this to a physical analogy people's reaction would be 'no shit', but because it's digital you can apparently get away with it.

You can make a copy before opening the app.

> "employs a proprietary open-source encryption"

A what?

I agree that both the original post and the media coverage of this is extremely misleading.

> So someone enthusiastically posted about wasting their time as if it was a technological achievement.

I think there's plenty of value and achievement in understanding a program's functionality, even when the source is fully available to you.

We all (presumably) agree that source code isn't self-documenting and that understanding someone else's work usually involves a lot of individual comprehension and context; I read this blog post as someone (diligently) describing their mental process as they tried to understand Signal's internal formats. As others have pointed out, there are oodles of "legitimate"[1] reasons for doing so.

[1]: From the perspective of LEO and the legal system, anyways.

I agree as far as the content of the article is concerned. I think the main problem with it was its tone. I think if they had approached it the way you described, someone just going into detail about how they analyzed an unfamiliar application, it would have been fine. As written, it feels like a new programmer bragging to his friends about how he got "hello, world" to compile.

One has to bear in mind that the typical digital forensic examiner is not a programmer and would therefore be impressed. Perhaps impressed enough to purchase Cellebrite's products instead of the equivalents from MSAB, Oxygen, Elcomsoft etc.

In the usecase I'm particularly familiar with (law enforcement, specifically of violent crimes), it's pretty valuable to minimize the amount of manual data handling investigators have to do. The State's Attorneys office/US Attorneys office/Prosecutor's office have finite resources and have to be selective about the cases they decide to spend resources on. Even if the correct suspect(s) has(have) been identified and arrested, the case can be rejected if the decision-making prosecutor thinks the evidence isn't strong enough or defending the evidence will be too difficult because evidence collection was done in a nonideal way. It may be possible to forward Signal messages to another device, but A) that just adds more links in the chain that can be challenged, and B) most detectives don't know that's an option or have any idea how to do it, so you'll regularly see sloppy stuff like photos taken by the detective of a phone displaying the messages of interest.

It's just a lot easier for the investigator to just plug the phone into a Cellebrite UFED analyzer and extract as much as is covered either by their search warrant or by the signed consent form of the phone's user(s), and it's a lot easier to defend in court, as it eliminates room for accusations that investigators cherry-picked messages and data that look incriminating out of context.

TL,DR: Even if it's not an impressive feature technologically, it's still a valuable feature to some of Cellebrite's main customers.

Having some familiarity, how often do you think " ... and extract as much as is covered either by their search warrant or by the signed consent form of the phone's user" is an accurate description of what actually happens in the field?

Does a UFED even have a way of selectively extracting only what's covered by a warrant?

Are warrants usually granted that would be considered outrageous fishing trips by the more privacy aware of us here?

> all these companies who are better at marketing themselves well as experts are getting free lunches

Better than us, I presume? But unless you or I are prepared to do this work (to parse data from Signal and every other application out there), for the police, for other investigation agencies, for corporate and private investigators, for lawyers, for data protection officers etc., the vast majority of whom aren't programmers or reverse engineers, what's the problem if someone else is?

>wasting their time

I agree with your post, except for this. It is NOT a waste of time to assert, once in a while, your power to examine, extract, and change anything running on your device.

> anything running on your device

Cellebrite isn’t meant for use with devices you own; it’s meant for use with devices seized by law enforcement. I’m not so sure that qualifies here.

> devices seized by law enforcement

Not exclusively[1].

[1] https://www.cellebrite.com/en/business-solutions/

Is it actually common for such hardware to be used in civil cases? I'm not sure I'm keen on someone crawling through all my data and potentially storing it indefinitely--including data with security implications (session cookies, partially-decrypted data from password managers, who knows what else) just because they managed to reach the discovery phase of a civil case.

I would expect the toolsets to converge over time. That is, I can't imagine a tool that a LEO would have access to that I would not. Nor can I imagine a tool they might have that I would not want to use myself.

That said, I think law enforcement has an intrinsic advantage in practical terms. They have the money to pay for a subscription to known exploits packaged and made easy to attempt, and b) lots of experience using that tool (as well as just ordinary persuasion and coercion) to crack into peoples phones in the real world.

I'm not entirely sure that makes sense here. If I understand correctly, Cellebrite mostly just provides an interface and degree of automation designed for law enforcement; you could, in theory, retrieve the same data on your own without Cellebrite, just without the LEO-centric UX. Depending on the device, I would think the tools to which you have access likely make more sense for a consumer's use case.

Even for someone getting a bit more technical and tinkering with their device, tools like `adb` are fairly powerful on their own.

Exactly. I've so far decrypted my own messages from two different apps because I needed some specific information that would've been too hard to find without RegExp-capable search. In both cases I was glad to find guides online explaining how to pull the database, get the decryption key and decrypt the database with the key.

It may seem trivial from a security perspective since it doesn't involve breaking any cryptography, just using a decryption key as intended, but in practice the ability to get a plain-text dump of all messages is very useful.

Using an example of hacking into data that is already directly available is silly.

It would be interesting if they did that to something restricted, like a Netflix movie.

+1. If what they were working on was not Signal but some proprietary applications (possibly with DRM), the hilarious blog post on their "code cracking" effort can actually be a legitimate one. In principle, the process is the same - break into something when you are root already. The only difference is the challenge of code obfuscation - which is a real one, unlike Signal.

I greatly look forward to hearing Cellebrite executives doing jailtime for DMCA violations stemming from Hollywood or the music industry going after them in court for removing encryption on copyrighted material...

(I can dream, right?)

Are there any real checks on government spending?

I mean, law enforcement has a budget just like anyone else. They can't just make up money, unlike a national bank.

Civil forfeiture... Not "making up money", but pretty much the same outcome...

Reply on news.ycombinator.com