5 ms·

You can check it yourself with reverse engineering tools, e.g. on Android you could look at the APK with jadx and see the decompiled Signal implantation, and ho

by jimllo 3y ago

You can check it yourself with reverse engineering tools, e.g. on Android you could look at the APK with jadx and see the decompiled Signal implantation, and how it compares to the open source Java library from Signal that it is derived from.

NoImmatureAdHom 3y ago
Would it be unfair of me to rephrase as, "It is possible to do this ridiculous, difficult thing that doesn't even always work in order to get some insight into a situation which would be trivial if the source were available with reproducible builds"?
- TillE 3y ago
  Reverse engineering is not onerously difficult if you have the right tools, some experience, and a decent grasp of assembly language. It's only really annoying if you can't use a debugger.
  - georgeplusplus 3y ago
    Any good resources you recommend for a noob to the art who doesn't know assembly? I've reverse engineered file types. But not actual code.
    - ldarby 3y ago
      You just need to understand assembly. Maybe there are books that can help, I'm not aware of any, but to get started I'd recommend taking a binary of any open source software (preferably a non-optimised build, or just your own hello world with some loops etc), run it in a debugger, and step through each assembly instruction at a time and figure out what it's doing, with the corresponding source code. Eventually you may be able to do this without needing the source code, which is the goal. I think this is about the same effort as learning a new language (spoken, not programming), i.e. it'll take months of being immersed in it to get good at it. On the other hand, maybe your binary can be decompiled to source code (e.g. CFR can decompile java classes, I've used that a bit but haven't checked if that's useful for Android apps).
      - ldarby 3y ago
        (3 days later, responding to myself). Maybe this was bad advice, this approach is like trying to learn a spoken language by listening to a recording and looking up each word at a time. Probably it'd be better to get a deep understanding of how CPUs work in general, I can recommend the book Computer Organization and Design by Hennessy and Patterson for this. I agree with the other commenter that 15 years is more realistic so maybe just start by getting a 4 year degree in CompSci (and that book will probably be required reading).
  - bombolo 3y ago
    And don't forget to know everything about cryptography and security to actually spot the issues! All in all with 15yrs of training you can start the task :D
- throwaway290 3y ago
  Security auditing an app by source is not automatically easier than security auditing an app from its actual runtime behavior. Source can be a 1mloc tangled mess or have some vulnerable dependency deep in your dependency tree causing app to behave insecurely which could be quickly detected by monitoring how the app behaves in use, network packets sent, memory etc. How else do you think many 0days to closed products were found? What you say can be true if source is readable and well written and you have somehow a guarantee that source is not modified before publishing the app. Or if you just are inexperienced with auditing the app other than reading the code (I know I am).
  - NoImmatureAdHom 3y ago
    This is really helpful for understanding, thank you. Perhaps the question is improved by incorporating the intent of the maintainers. An example: If we're interested in whether WhatsApp's developers have implemented the Signal protocol in good faith, because we suspect they have not (we suspect they've put in backdoors at the behest of bad governments), then having the source available (and reproducible builds to use) allows us to check that more easily than analysis on the binary's behavior. This is because the primary way the duplicitous maintainers would do this is in their own source. It's possible (and for three letter agencies probably common and desirable) to deliberately introduce bugs in dependencies that provide the desired behavior in some end product, but it probably shouldn't be our base case. Our base case should be: you swear your code implements the Signal protocol without backdoors...ok, great, you show us the code.
- nisegami 3y ago
  >if the source were available with reproducible builds Does Signal itself even have reproducible builds?
  - cuu508 3y ago
    Looks like it https://github.com/signalapp/Signal-Android/blob/main/reproducible-builds/README.md https://github.com/signalapp/Signal-Android/blob/main/reprod...
  - xorcist 3y ago
    It does, but you're not really allowed to use it at scale. Open whisper systems has repeatedly threatened to play cat and mouse games with any third party distribution based on reproducible builds and lock them out. They are fully entitled to do that of course, as it is their system. But that makes it far less useful for hobbyists.

by jimllo 3y ago

NoImmatureAdHom 3y ago

Would it be unfair of me to rephrase as, "It is possible to do this ridiculous, difficult thing that doesn't even always work in order to get some insight into a situation which would be trivial if the source were available with reproducible builds"?

TillE 3y ago
Reverse engineering is not onerously difficult if you have the right tools, some experience, and a decent grasp of assembly language. It's only really annoying if you can't use a debugger.
- georgeplusplus 3y ago
  Any good resources you recommend for a noob to the art who doesn't know assembly? I've reverse engineered file types. But not actual code.
  - ldarby 3y ago
    You just need to understand assembly. Maybe there are books that can help, I'm not aware of any, but to get started I'd recommend taking a binary of any open source software (preferably a non-optimised build, or just your own hello world with some loops etc), run it in a debugger, and step through each assembly instruction at a time and figure out what it's doing, with the corresponding source code. Eventually you may be able to do this without needing the source code, which is the goal. I think this is about the same effort as learning a new language (spoken, not programming), i.e. it'll take months of being immersed in it to get good at it. On the other hand, maybe your binary can be decompiled to source code (e.g. CFR can decompile java classes, I've used that a bit but haven't checked if that's useful for Android apps).
    - ldarby 3y ago
      (3 days later, responding to myself). Maybe this was bad advice, this approach is like trying to learn a spoken language by listening to a recording and looking up each word at a time. Probably it'd be better to get a deep understanding of how CPUs work in general, I can recommend the book Computer Organization and Design by Hennessy and Patterson for this. I agree with the other commenter that 15 years is more realistic so maybe just start by getting a 4 year degree in CompSci (and that book will probably be required reading).
- bombolo 3y ago
  And don't forget to know everything about cryptography and security to actually spot the issues! All in all with 15yrs of training you can start the task :D
throwaway290 3y ago
Security auditing an app by source is not automatically easier than security auditing an app from its actual runtime behavior. Source can be a 1mloc tangled mess or have some vulnerable dependency deep in your dependency tree causing app to behave insecurely which could be quickly detected by monitoring how the app behaves in use, network packets sent, memory etc. How else do you think many 0days to closed products were found? What you say can be true if source is readable and well written and you have somehow a guarantee that source is not modified before publishing the app. Or if you just are inexperienced with auditing the app other than reading the code (I know I am).
- NoImmatureAdHom 3y ago
  This is really helpful for understanding, thank you. Perhaps the question is improved by incorporating the intent of the maintainers. An example: If we're interested in whether WhatsApp's developers have implemented the Signal protocol in good faith, because we suspect they have not (we suspect they've put in backdoors at the behest of bad governments), then having the source available (and reproducible builds to use) allows us to check that more easily than analysis on the binary's behavior. This is because the primary way the duplicitous maintainers would do this is in their own source. It's possible (and for three letter agencies probably common and desirable) to deliberately introduce bugs in dependencies that provide the desired behavior in some end product, but it probably shouldn't be our base case. Our base case should be: you swear your code implements the Signal protocol without backdoors...ok, great, you show us the code.
nisegami 3y ago
>if the source were available with reproducible builds Does Signal itself even have reproducible builds?
- cuu508 3y ago
  Looks like it https://github.com/signalapp/Signal-Android/blob/main/reproducible-builds/README.md https://github.com/signalapp/Signal-Android/blob/main/reprod...
- xorcist 3y ago
  It does, but you're not really allowed to use it at scale. Open whisper systems has repeatedly threatened to play cat and mouse games with any third party distribution based on reproducible builds and lock them out. They are fully entitled to do that of course, as it is their system. But that makes it far less useful for hobbyists.