Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Code from the FBI’s Anom encrypted messaging app

vice.com

Post reply on HN
Print view View original

31–40 of 107 posts

Re: Code from the FBI’s Anom encrypted messaging app

#31

Post by selykg »

criddell wrote: post #28
dmix wrote: post #23

Earlier quoted context omitted.

> Lots of "secure" messaging apps do this for intel and surveillance and not just the white hats. It's how Apple would do iMessage intercepts for the FBI.

I wonder if Messages will be available at all in lockdown mode? If Apple can be compelled to build in surveillance (and it's not clear to me that they can be), then it really should be.

I think they indicated it will be, for example, they indicated that link previews would not be available, if I recall correctly.

Re: Code from the FBI’s Anom encrypted messaging app

#32

Post by aaaaaaaaata »

bee_rider wrote: post #16
sneak wrote: post #3

> Last year, the FBI and its international partners announced Operation Trojan Shield, in which the FBI secretly ran an encrypted phone company called Anom for years and used it to hoover up tens of millions of messages from Anom users. What other services might be run, controlled, or surveilled by the US investigative authorities? What other services might have operators that can be extorted or blackmailed by those…

I'm not super informed on this topic, but I was under the impression that all the chat apps were somewhere between malevolent and incompetent, except possibly Signal.

Matrix and some forks of Signal are also cool.

But, yes, largely correct.

Re: Code from the FBI’s Anom encrypted messaging app

#33

Post by soulofmischief »

phendrenad2 wrote: post #27
jliptzin wrote: post #15

So what's the strategy moving forward? The operation clearly hasn't permanently solved crime, the next generation of organized crime bosses won't trust any apps to handle their secrets, so I guess their communication just moves offline again? Or maybe each develops their own methods in house that they know they can trust (such as shooting holes in a wall on call of duty)?

In my opinion the goal is similar to the MPAA's goals with movie piracy: Make it harder, and many people will stop doing it. Ultimately, that is what banks do when they put money into vaults. Someone could still steal the money, but it's insanely difficult.

But in many cases, movie piracy is faster, more convenient and more agreeable than consuming through locked down ad funnels like Netflix or Disney+ which don't let me outright own the content or the viewing experience, or Blu-rays which enforce DRM and specific region-locked devices.

Re: Code from the FBI’s Anom encrypted messaging app

#34

Post by tablespoon »

jliptzin wrote: post #15

So what's the strategy moving forward? The operation clearly hasn't permanently solved crime, the next generation of organized crime bosses won't trust any apps to handle their secrets, so I guess their communication just moves offline again? Or maybe each develops their own methods in house that they know they can trust (such as shooting holes in a wall on call of duty)?

> So what's the strategy moving forward? The operation clearly hasn't permanently solved crime, the next generation of organized crime bosses won't trust any apps to handle their secrets, so I guess their communication just moves offline again? Or maybe each develops their own methods in house that they know they can trust (such as shooting holes in a wall on call of duty)?

Maybe the strategy is just "get the win now, and tomorrow's another day." A lot of people seem to think it's a bad idea to use some technique that will motivate a counter-technique , like that counter-technique can be prevented by not using the technique (it comes up a lot when sanctions are discussed). However that's flawed assumption. Sometimes sitting on a technique will mean it becomes obsolete before you can realize advantage from it, and it's actually smarter to try capture that advantage while you still can.

Also, if organized crime stops trusting apps and goes back offline for communication, it could become far less efficient/effective, which would be a win for law enforcement.

Also, a sucker is born every minute. Maybe the Mob will shy away from encrypted apps due to institutional memory, but some upstart criminal orgs without that memory may still adopt "FBI 'Encrypted' Messenger 2.0."

Re: Code from the FBI’s Anom encrypted messaging app

#35

Post by aaaaaaaaata »

slickdork wrote: post #19
jeffbee wrote: post #17

Earlier quoted context omitted.

Yeah ... i mean ... everyone who uses protonmail non-ironically is a dupe. It is virtually certain that it is a front for state intelligence agencies.

I'm not sure why it is 'virtually certain'. It seems very likely to me that a company, which takes payments as a funding model, could exist with end 2 end and be a legitimate business. Do you have any source at all to back a claim like that?

Connections with big academia and their custom syncing thing are red flags, if only that.

Re: Code from the FBI’s Anom encrypted messaging app

#36

Post by AtNightWeCode »

GranPC wrote: post #13
gavinray wrote: post #8

The decompiler they used to view that code is not very good, that output is garbled. If you're going to take apart JVM bytecode, you're better off using Recafe or Quiltflower. https://github.com/Col-E/Recaf https://github.com/QuiltMC/quiltflower

The reason the output is "garbled" is because it was obfuscated with ProGuard - there's no real way around that except for manually renaming variables and classes. Any idea whether any of these two decompilers work with Dalvik bytecode?

You could always use dex2jar first. https://github.com/pxb1988/dex2jar

Re: Code from the FBI’s Anom encrypted messaging app

#37

Post by concinds »

xoa wrote: post #7
sneak wrote: post #3

> Last year, the FBI and its international partners announced Operation Trojan Shield, in which the FBI secretly ran an encrypted phone company called Anom for years and used it to hoover up tens of millions of messages from Anom users. What other services might be run, controlled, or surveilled by the US investigative authorities? What other services might have operators that can be extorted or blackmailed by those…

> We already know Apple has preserved a backdoor in the end-to-end cryptography of iMessage at the FBI's behest, as reported by Reuters. WhatsApp has always had the same backdoor (unencrypted backups to cloud services). The largest services are all unsafe for privacy. I don't agree with your characterization of that as a "backdoor" and I think that dilutes the term dangerously. There is no need to use Apple's backup…

I consider iCloud backups being enabled by default to be a backdoor to E2E encryption; however there's a "more real" backdoor in iMessage, which is that Apple can undetectably add new devices (i.e. an FBI iPhone) to conversations so that all forward secrecy is broken. This has not been fixed.

https://www.wired.com/2015/09/apple-fighting-privacy-imessag...

Re: Code from the FBI’s Anom encrypted messaging app

#38

Post by l33t2328 »

richbell wrote: post #25
drawkbox wrote: post #2

> The code shows that the messages were secretly duplicated and sent to a “ghost” contact that was hidden from the users’ contact lists. Lots of "secure" messaging apps do this for intel and surveillance and not just the white hats. Other areas that "secure" messaging apps have holes in is the anti-spam/moderation systems that need to view messages and in the clients themselves who have access to the unencrypted cont…

> Lots of "secure" messaging apps do this for intel and surveillance and not just the white hats. Lots of VPNs, too! "We don't keep any logs! We just pipe a direct feed to the government so they can keep logs!"

Do you have any examples?

Re: Code from the FBI’s Anom encrypted messaging app

#39

Post by natch »

nr2x wrote: post #11
xoa wrote: post #7

Earlier quoted context omitted.

> We already know Apple has preserved a backdoor in the end-to-end cryptography of iMessage at the FBI's behest, as reported by Reuters. WhatsApp has always had the same backdoor (unencrypted backups to cloud services). The largest services are all unsafe for privacy. I don't agree with your characterization of that as a "backdoor" and I think that dilutes the term dangerously. There is no need to use Apple's backup…

As long as iCloud backup is a) on by default, and b) isn’t clearly marked as being readable to Apple, it is a back door in practice, especially since the FBI is the reason that they did this. Let’s not even talk about Chinese users, as apparently Apple bending over to store all their data in CCP data centers doesn’t count.

Agree and it's not just Chinese users. Just talking about that one country (there are others, let's set that aside) it's Chinese users, and anyone who happens to be in China, and it would seem to be also anyone who, knowingly or unknowingly, anywhere around the world… in the US, the UK, the EU, etc… anywhere, has so much as a one-time interaction with such a user.

I feel like that paragraph would lose most people because it's a long chain of connections. It's hard to do a TL;DR but here, I'll try:

Basically "If you message someone in China, Apple sees to it that your identity and content is handed to the Chinese government."

I don't know this for a fact. But as far as I can tell (and they aren't saying anything) this is exactly what is going on.

Re: Code from the FBI’s Anom encrypted messaging app

#40

Post by xoa »

nr2x wrote: post #11
xoa wrote: post #7

Earlier quoted context omitted.

> We already know Apple has preserved a backdoor in the end-to-end cryptography of iMessage at the FBI's behest, as reported by Reuters. WhatsApp has always had the same backdoor (unencrypted backups to cloud services). The largest services are all unsafe for privacy. I don't agree with your characterization of that as a "backdoor" and I think that dilutes the term dangerously. There is no need to use Apple's backup…

As long as iCloud backup is a) on by default, and b) isn’t clearly marked as being readable to Apple, it is a back door in practice, especially since the FBI is the reason that they did this. Let’s not even talk about Chinese users, as apparently Apple bending over to store all their data in CCP data centers doesn’t count.

No, you're just wrong, even if your statements were right which they aren't either. Again, by your logic every single communication system on iOS is "backdoored" simply because iCloud Backup exists. Or for that matter any comms method on Linux or FreeBSD or macOS or Windows if someone makes unencrypted backups. That's horse shit, and it degrades the specificity and value of the term "backdoor" in the same way as "bricked" has become. Backdooring is a specific part of a given product/stack, a covert method of bypassing regular authentication. There is no convert status here, Apple clearly lays out exactly what components of iCloud are encrypted and how in their "iCloud security overview" [0]. And it's not as if E2EE backups have no downsides mass market, it means that users are fully responsible for their data with zero recovery possible. I still think Apple is wrong to not offer even the capability to do better wirelessly/networked and in fact that should be against the law, but it's not a "backdoor" and if there were options I'm sure lots of people would still pick the "recoverable in an emergency" one. Think, if it turns out there actually is a backdoor in iMessage, like a secret second key that can be applied to any MITM'd data to decrypt it, how would you even describe that pray tell as different from "choosing to use a non-E2EE backup method"? Or do you not think any differentiation there would matter, that such a thing would be identical to you saying right now that "Signal has a backdoor"? All that said:

>a) on by default

I've never seen it on by default, it's a toggle. I can't find anything to support this assertion, and Apple's docs seem to indicate too it must be turned on [1]. How would it even be possible for this to work? Apple only gives you 5GB by default, and backups absolutely count against the quota.

>and b) isn’t clearly marked as being readable to Apple

As I linked they do clearly convey that. If you think it should be some extra warning dialog on enabling it, maybe that's a criticism, but there's certainly no standard around that across software industry-wide including on computers. Whether something is E2EE or not is usually something those that care need to look up. Maybe that should change. But no, it's not a "backdoor in practice".

>Let’s not even talk about Chinese users, as apparently Apple bending over to store all their data in CCP data centers doesn’t count.

No let's not, and no it doesn't here. That's a case with a lot more complexity then tends to come out on HN where instead people like you use it as a lazy bit of whataboutism. Apple is in the wrong there, and the US for allowing/encouraging it as well, but not for the same reasons as with the FBI and the path away from it is very different and harder as well. They deserve major blame in both cases, but why they deserve blame differs, and that matters.

----

0: https://support.apple.com/en-us/HT202303

1: https://support.apple.com/guide/iphone/back-up-iphone-iph3ec...

Post reply on HN