But how do we find the offsets? What values do we give to ssl_read_offset and ssl_write_offset?
[ REDACTED ]
I had a nice little section on how to find the offsets here. When I first wrote it I was convinced that publishing two addresses couldn't possibly get me sued for reverse engineering. Some of the people who read the draft of this post changed my mind about it though, and it is 2020 after all so it is not a good time to be optimistic.
So, how would you find these offsets? Anyone know?
It's probably the most interesting part of the post.
There's a "hypothetical" paragraph afterwards, but if anyone wants to actually do this with Zoom and post the results, you'd probably earn lots of cred.
In particular, the exact arguments to the objdump command would help.
It is sad they felt the need to do this. This step is not hard, but censuring it because of hypothetical legal issues speaks a lot about the state of affairs on computing.
I miss the good old times where knowledge were freely published without fear.
I might misunderstand the fundamental point, but zoom doesn’t seem to be making new laws. Existing contract law is perfectly capable of handling two adults agreeing to a mutually beneficial set of restrictions.
Lots of things that are legal we’ll be restricted in contract agreements - free speech is a fundamental right, but mutual non-disclosure agreements still exist and can result in (civil) legal action if reneged on to one party’s detriment.
> Existing contract law is perfectly capable of handling two adults agreeing to a mutually beneficial set of restrictions.
I think you'll find that most people - and a number of leading law experts - don't consider click through EULAs for valid binding contracts and clicking next is not the same as signing.
You'll also find that many (most? I stopped reading EULAs years ago) contains something about "the following might not be applicable in your jurisdiction".
Besides, just think of it: can a click on a button, placed in a way that makes it easy to click through for someone who accepts the defaults, can such a click really be considered a meeting of minds?
And do we really think people can be expected to read a number of pages of dense legalese? I remember one EULA filling 13 A4 pages with text in a small font after I gave up and printed it two decades ago when I was young and still believed they were valid.
Besides: Expecting non lawyers to read and understand legalese is as crazy as expecting non programmers to read basic Java or Python: within reach for many after basic self study, but still not something I'd bet much money on random people being able to do on the fly.
> I think you'll find that most people - and a number of leading law experts - don't consider click through EULAs for valid binding contracts and clicking next is not the same as signing.
If you feel like you're potentially a target of a lawsuit, the only opinion that should matter to you are your lawyer's and the the court's. Some EULA restrictions are not enforceable, but some definitely are. No US court has ruled on whether EULAs are binding, or not - so there is no precedence.
What's the point of giving people rights when companies can just force you to relinquish them via contracts? That obviously leads to these "you can't exercise your rights" clauses becoming standard in every contract.
People should be able to do things that hurt a company's business interests, especially reverse engineering. They do not deserve any protection. Actually, it should be encouraged since it leads to better products for consumers.
When you sign a contract, very often you are waiving some of your rights. There are rights which cannot be waived by you—I’m not sure the right to reverse engineer is one of them
There is a certain asymmetry in it, but you can also sue and have shit like that declared illegal. Thing is it would threaten most bizniz-models of the bullshit economy, so it doesn't happen that much.
I'm expecting that this finally changes for the better, at least in some parts of the world, where the parts which don't adapt to that change spiral further down.
No idea why you're being downvoted but this is 100% factually correct in the US: you'll get sued by a company that has a very salaried legal team.
Even if Zoom is in the wrong/has no case, all it takes to "win" in the US is enough of a bankroll to troll someone via the legal system. It's pay-to-play here and Zoom likely has the budget to run an independent researcher into the ground financially with legal defense fees alone.
I get that HN wants to have it's "hacker" ideals and all, but, I would expect to cause myself legal troubles for publishing security details on such a service (unless done anonymously with reasonable opsec).
Sure, but if your 1000 person company uses Zoom and Zoom only bans your account I don’t think you can convince a company to switch clients. That said I find that specific scenario unlikely.
ToS aren't important if they're not enforceable, which is the case with a prohibition on reverse engineering. That said, if I published something like this I'd do it under a pseudonym under a domain and a vps that I paid for using an untraceable currency. Companies are evil and even if you'll eventually win, they'll make your life miserable. Why take the chance?
We know the exact version of openssl they’re using, so we can just build the same version ourselves, get the address of the functions, and look for the same pattern of instructions in the Zoom binary. Not sure if LTO could break this or not though.
That seems pretty unreliable. The specific version of the compiler used, as well as flags passed to the compiler, could easily change the instructions used, no?
Based on how the OP described finding the offsets, it sounds like this is exactly what they did, perhaps there are some obvious sentinels that make it easy. I’m not a C expert, but I think a function call w/ args has a pretty standard way of being executed and if you know the types of the arguments it’s possibly even easier?
It's pretty reliable in reality, C compilers are actually quite predictible. The only meaningful changes compilation flags do is add/remove basic blocks.
That's also mainly how malware reverse manages to "hunt" APT families, by finding meaningful little patterns in the instructions and look for code reuse in other binaries :D
Generally it's a little bit more manual than "pass flags to objdump"–I'd look for strings and such used by the function in the open-source release and then cross-reference that.
I was surprised to see hooking code like this being written in Rust. I've come to expect C sample code for purposes like these, so it's nice to see that there are actually alternatives when it comes to intercepting function calls and extracting data from a process.
The people from Cilium (the k8s service mesh) launched this website[0] recently that lists a few tools from the landscape, and I also had the same pleasant surprise to find these things out this week
I thought we were still tied to `bcc` and that python frontend thingy, but I'm glad the ecosystem has evolved significantly while I was not paying attention! It's kinda like finding a $20 in your back pocket that you didn't know was there when you put your pants on...
I think what makes redbpf stands out is that the other libraries allow you to write the user-space code in Python or Lua etc, but then the kernel code must still be written in C and gets compiled with clang.
In redbpf we let you write the kernel code in Rust as well, and then we have our own LLVM based toolchain to compile that to BPF bytecode.
bpftrace is similar to redbpf in approach, in that it lets you use a DSL instead of C.
That's most of what lua's purpose is: to be a reasonably pleasant and featureful language that is dead easy to embed in larger systems that want some kind of scripting or macros.
When you get past the layers of old and dead documentation around it, the eBPF subsystem is fairly easy to target as long as you can call C, topologically at least.
I have done exactly the same thing for Desktop/Android apps using Frida (modified from https://github.com/google/ssl_logger). There are modules out there that dump SSLKEYLOG too (that can be used in Wireshark)
With IOS I’ve used the keylog strategy and it is very effective. IOS uses boringssl and the library calls a function to log the secret but this function never does anything normally. However, you can either trampoline this function to log the secret or modify the ssl context to add your own logger function. This is all public knowledge and you can find Frida scripts that will dump the TLS secrets.
I am not sure how much of this technique can be used elsewhere for legitimate purposes.
In this example, except for an administrator spying on other users on a shared machine, which is kind of already an admitted risk by users on a shared machine anyway.
> I am not sure how much of this technique can be used elsewhere for legitimate purposes
...as a Linux systems engineer, you are many times faced with debugging a black box problem wrapped in SSL on both ends which you need to peek into to understand what's going wrong; there is nothing suspect about this technique in this environment, it's what you're paid to do (solve problems). It's basically like having the ability to elevate your NIC port to promiscuous mode to debug an issue (tcpdump, e.g.) - it's a tool with no opinion, the human operating it is the one to be worried about.
It's useful to a security researcher or privacy advocate looking into what an application like zoom is actually sending around.
It may be also helpful when reverse engineering "proprietary" protocols, e.g. to create compatible clients.
It may be even easier to just "mitm" the traffic like this in applications you develop yourself to find out what going on deeply buried in some third party library. Easier than modifying the code or attaching a normal debugger.
Looking at the data our machines are sending over the network is perfectly legitimate activity. Companies should not be able to protect their software from us. We need to be able to see everything they are doing.
Well, they especially shouldn't be able to do that, but no, companies should not be able to hide anything at all. (If there's anything that shouldn't be public (eg security camera footage, billing records), the company as a whole shouldn't have access to it in the first place. Ideally them shouldn't be allowed to collect it at all, but there are obvious practical issues with applying that universally.)
Looks like nextgen ad blocking to me. If you can instrument TLS connections on the client, you can identify ad content and substitute blank video frames or just 404s.
Writing a toy ad blocker is actually on my todo list :)
There's just so many things you can so. The original goal of the post was to tamper with zoom's attention tracking for example (which was a field in one of their protobuf payloads).
Proxomitron had that capability years ago - MITM proxy to filter pages and block ads, among other things. I still use it, it's very useful and continues to run fine on the newest Windows.
An administrator spying on other users on a shared machine is not a legitimate purpose (though, yes, it is a fairly obvious risk which no one should be surprised by).
[ REDACTED ]
I had a nice little section on how to find the offsets here. When I first wrote it I was convinced that publishing two addresses couldn't possibly get me sued for reverse engineering. Some of the people who read the draft of this post changed my mind about it though, and it is 2020 after all so it is not a good time to be optimistic.
So, how would you find these offsets? Anyone know?
It's probably the most interesting part of the post.
There's a "hypothetical" paragraph afterwards, but if anyone wants to actually do this with Zoom and post the results, you'd probably earn lots of cred.
In particular, the exact arguments to the objdump command would help.