46 ms·

Where in the world did you get one byte per second?? Perhaps give it a try yourself?

by wglb 8y ago

lisper 8y ago
I pulled it out of my hat. What do you think is a realistic rate for reverse-engineering machine code?
- pvg 8y ago
  A lot more seems to be pulled out of a hat here, though. At how many bytes per second do you read and interpret regular high-level source code? How do we know there isn't a secret backdoor in the Linux kernel and all of its drivers? 1.6 GB is the total image size - it's not all code, let alone OS or security-critical code. It's not all reversed from scratch every time a new update appears. It's not like the people looking at it are also staring at reams of ARM assembly. Etc, etc.
  - lisper 8y ago
    > At how many bytes per second do you read and interpret regular high-level source code? I don't know, but it's not hard to put an upper bound on it. A VT-100 screen worth of code is at most 2000 characters. If it takes me one minute to grok the code on a screen that's (again, at most) 33 characters per second. Even if we take this upper bound as the rate at which one can process object code (which, again, seems wildly optimistic to me) that's still several work-years to go through the iOS image. > How do we know there isn't a secret backdoor in the Linux kernel and all of its drivers? We don't. I don't claim that Linux is better. Go back and look at the context of my original comment. It applies to both iOS and Android. Tptacek's response veered the discussion onto iOS. The problem is not that Apple or Google is evil or incompetent. They may be, but that's not the point. The problem is that these systems are too complicated, and the rewards for breaking them are too high. A back door in to iOS or Android could literally allow someone to rule the world (the President of the United States has been reported to use an unsecured phone). That is not a situation about which it is wise to be complacent. > 1.6 GB is the total image size - it's not all code, let alone OS or security-critical code. That is certainly true. But a back door can hide just about anywhere, so you have to look at all of it. > It's not like the people looking at it are also staring at reams of ARM assembly. Etc, etc. Yes, I know that. That's not really the point. Even if it were feasible to thoroughly audit the object code (I don't believe it is, but I'll concede it for the sake of argument) this effort is not a coordinated white-hat endeavor. Many of the reverse-engineers are black hats, or state actors not necessarily sympathetic to the needs of U.S. consumers. Even if they do find an issue it is not a slam-dunk that they will responsibly disclose it rather than attempt to exploit it for monetary or political profit.
    - tptacek 8y ago
      You write this as if you hadn't kicked this weird subthread off with the argument that iOS was problematic because nobody can audit it. "No one outside Apple can audit their products". That is simultaneously false and inconsistent with the comment you just wrote.
      - lisper 8y ago
        "No one outside Apple can audit their products" is obviously an overstatement. Obviously people can take Apple's products and test them, subject them to fuzzing and reverse-engineering. But no one outside of Apple has access to their design documents and source code, and that limits the extent and effectiveness of those efforts. I probably should have hedged with, "No one outside of Apple can FULLY audit their products" or something like that. Also, the focus on iOS is a distraction. Apple makes their own silicon. Vulnerabilities are probably more likely to be hiding there than in the software. Modern silicon is very hard to reverse-engineer.
        tptacek 8y ago
        None of your arguments in this thread cohere. You wonder upthread why I'm not volunteering more of my own perspective on this. It's because I don't want to arm you with more weird tangents to pursue. Let's try to break this down: 1. We're talking about SS7 security. 2. Whether or not SS7 is secure, if your phone is compromised and hostile, it's game-over. So it's hard to see how this debate is even relevant. 3. You introduced the argument that Apple and Google phones were untrustworthy because nobody outside Apple (or Google) can audit them. You now say that's an overstatement. 4. When informed that there's in fact a whole cottage industry of people outside Apple who do audit iOS from binaries --- effectively enough, I'll add now, that they routinely find vulnerabilities that Apple missed despite Apple's privileged access to "design documents and source code" --- you express incredulity. 5. You denominate your incredulity in a "bytes per second" rate of reverse engineering based on compiled image sizes. 6. Later, you derive a rate from the number of characters you can fit on a VT100 screen. 7. You later clarify: we have to audit everything, you see: not just the kernel and privileged services but also every pixel in the Apple logo that appears when you boot the phone, and, of course, the security of the weather app. 8. Now we can't trust silicon either. Vulnerabilities are (???) more likely to be hiding there than in software. This is a kaleidoscope of weird, wrong arguments about security, and, once again, has nothing to do with the thread. If you simultaneously believe all these things, it still doesn't make sense to try to protect phone calls by securing the SS7 network. What I think you should do is take a simple binary from your desktop OS, download a copy of radare, learn how to use it, and blow your own mind about how even the free, open source reversing tooling works. I'm not being snarky. I think you'll be surprised by how this stuff works.
- wglb 8y ago
  So might I gently suggest that you ask someone who has deep experience, well beyond his hat, with actual reversing? Such as 'tptacek, 'cperciva, 'yan, many others here.
  - lisper 8y ago
    I would be happy to get a real data point, but it won't affect my argument unless my estimate is off by orders of magnitude. I don't need an accurate estimate for my argument to hold, just an upper bound that is in the ballpark.
    - tptacek 8y ago
      You're not even counting the right thing. How many orders of magnitude off you are isn't even the most important problem with your analysis.
      - lisper 8y ago
        This comment is a moving target. You edited it between when I received a copy via HN Replies and when I came here to respond. At the moment it reads, in its entirety: > You're not even counting the right thing. How many orders of magnitude off you are isn't even the most important problem with your analysis. It's more than a little disingenuous of you to say that without saying what the most important problem is. How exactly did you expect me to respond to this?
        tptacek 8y ago
        The previous sentence, which I edited out because I didn't like it, and it didn't make an argument I hadn't already made, was "this is like asking how many bushels it would take to reach orbit". I edit comments to refine language but never to change their meaning. No, I don't agree that I'm being disingenuous.

Where in the world did you get one byte per second?? Perhaps give it a try yourself?

by wglb 8y ago

Where in the world did you get one byte per second?? Perhaps give it a try yourself?

lisper 8y ago

I pulled it out of my hat. What do you think is a realistic rate for reverse-engineering machine code?

pvg 8y ago
A lot more seems to be pulled out of a hat here, though. At how many bytes per second do you read and interpret regular high-level source code? How do we know there isn't a secret backdoor in the Linux kernel and all of its drivers? 1.6 GB is the total image size - it's not all code, let alone OS or security-critical code. It's not all reversed from scratch every time a new update appears. It's not like the people looking at it are also staring at reams of ARM assembly. Etc, etc.
- lisper 8y ago
  > At how many bytes per second do you read and interpret regular high-level source code? I don't know, but it's not hard to put an upper bound on it. A VT-100 screen worth of code is at most 2000 characters. If it takes me one minute to grok the code on a screen that's (again, at most) 33 characters per second. Even if we take this upper bound as the rate at which one can process object code (which, again, seems wildly optimistic to me) that's still several work-years to go through the iOS image. > How do we know there isn't a secret backdoor in the Linux kernel and all of its drivers? We don't. I don't claim that Linux is better. Go back and look at the context of my original comment. It applies to both iOS and Android. Tptacek's response veered the discussion onto iOS. The problem is not that Apple or Google is evil or incompetent. They may be, but that's not the point. The problem is that these systems are too complicated, and the rewards for breaking them are too high. A back door in to iOS or Android could literally allow someone to rule the world (the President of the United States has been reported to use an unsecured phone). That is not a situation about which it is wise to be complacent. > 1.6 GB is the total image size - it's not all code, let alone OS or security-critical code. That is certainly true. But a back door can hide just about anywhere, so you have to look at all of it. > It's not like the people looking at it are also staring at reams of ARM assembly. Etc, etc. Yes, I know that. That's not really the point. Even if it were feasible to thoroughly audit the object code (I don't believe it is, but I'll concede it for the sake of argument) this effort is not a coordinated white-hat endeavor. Many of the reverse-engineers are black hats, or state actors not necessarily sympathetic to the needs of U.S. consumers. Even if they do find an issue it is not a slam-dunk that they will responsibly disclose it rather than attempt to exploit it for monetary or political profit.
  - tptacek 8y ago
    You write this as if you hadn't kicked this weird subthread off with the argument that iOS was problematic because nobody can audit it. "No one outside Apple can audit their products". That is simultaneously false and inconsistent with the comment you just wrote.
    - lisper 8y ago
      "No one outside Apple can audit their products" is obviously an overstatement. Obviously people can take Apple's products and test them, subject them to fuzzing and reverse-engineering. But no one outside of Apple has access to their design documents and source code, and that limits the extent and effectiveness of those efforts. I probably should have hedged with, "No one outside of Apple can FULLY audit their products" or something like that. Also, the focus on iOS is a distraction. Apple makes their own silicon. Vulnerabilities are probably more likely to be hiding there than in the software. Modern silicon is very hard to reverse-engineer.
      - tptacek 8y ago
        None of your arguments in this thread cohere. You wonder upthread why I'm not volunteering more of my own perspective on this. It's because I don't want to arm you with more weird tangents to pursue. Let's try to break this down: 1. We're talking about SS7 security. 2. Whether or not SS7 is secure, if your phone is compromised and hostile, it's game-over. So it's hard to see how this debate is even relevant. 3. You introduced the argument that Apple and Google phones were untrustworthy because nobody outside Apple (or Google) can audit them. You now say that's an overstatement. 4. When informed that there's in fact a whole cottage industry of people outside Apple who do audit iOS from binaries --- effectively enough, I'll add now, that they routinely find vulnerabilities that Apple missed despite Apple's privileged access to "design documents and source code" --- you express incredulity. 5. You denominate your incredulity in a "bytes per second" rate of reverse engineering based on compiled image sizes. 6. Later, you derive a rate from the number of characters you can fit on a VT100 screen. 7. You later clarify: we have to audit everything, you see: not just the kernel and privileged services but also every pixel in the Apple logo that appears when you boot the phone, and, of course, the security of the weather app. 8. Now we can't trust silicon either. Vulnerabilities are (???) more likely to be hiding there than in software. This is a kaleidoscope of weird, wrong arguments about security, and, once again, has nothing to do with the thread. If you simultaneously believe all these things, it still doesn't make sense to try to protect phone calls by securing the SS7 network. What I think you should do is take a simple binary from your desktop OS, download a copy of radare, learn how to use it, and blow your own mind about how even the free, open source reversing tooling works. I'm not being snarky. I think you'll be surprised by how this stuff works.
wglb 8y ago
So might I gently suggest that you ask someone who has deep experience, well beyond his hat, with actual reversing? Such as 'tptacek, 'cperciva, 'yan, many others here.
- lisper 8y ago
  I would be happy to get a real data point, but it won't affect my argument unless my estimate is off by orders of magnitude. I don't need an accurate estimate for my argument to hold, just an upper bound that is in the ballpark.
  - tptacek 8y ago
    You're not even counting the right thing. How many orders of magnitude off you are isn't even the most important problem with your analysis.
    - lisper 8y ago
      This comment is a moving target. You edited it between when I received a copy via HN Replies and when I came here to respond. At the moment it reads, in its entirety: > You're not even counting the right thing. How many orders of magnitude off you are isn't even the most important problem with your analysis. It's more than a little disingenuous of you to say that without saying what the most important problem is. How exactly did you expect me to respond to this?
      - tptacek 8y ago
        The previous sentence, which I edited out because I didn't like it, and it didn't make an argument I hadn't already made, was "this is like asking how many bushels it would take to reach orbit". I edit comments to refine language but never to change their meaning. No, I don't agree that I'm being disingenuous.