NateLawson

10 ms·

1. 61.▲
   by NateLawson 11y ago

   Yes, self-checksumming becomes impossible [1]. If you are concerned about anyone reversing your code (Apple or otherwise), you must obfuscate it. Either you work at the ARM level or the bitcode level (watchOS for now), but the basic techniq
2. 62.▲
   by NateLawson 11y ago

   Yes, this is the real thing that should be debated -- where does the developer's responsibility end and the App Store's begin? If I created an app, both distributed internally (say, to my corporate users) and via the App Store, bu
3. 63.▲
   by NateLawson 11y ago

   There's no need to trust Apple with re-signing the binary, it just happens to be implemented that way. It throws away the reason for the original code signature, which was for the developer to securely say "I created this." Y
4. 64.▲
   by NateLawson 11y ago

   Close, but you're actually using inline asm in most cases. Then you're verifying the microarchitectural details of every CPU it executes on. (Intel's OpenSSL countermeasure to an RSA timing attack was dependent on CPUs not co
5. 65.▲
   by NateLawson 11y ago

   Apple already re-signs all apps sent through the App Store. That plus Fairplay encryption makes it unnecessarily difficult for end recipients to verify the chain of custody for the code. I don't quite get why Xcode couldn't genera
6. 66.▲
   by NateLawson 11y ago

   I agree most of his concerns are not very relevant. The legitimate concern I see is verifiability of code custody from the developer to the end user. However, Fairplay encryption of the exe means you have to dump the plaintext already in or
7. 67.▲
   by NateLawson 11y ago

   I disagree that LLVM bitcode makes reverse-engineering any easier on iOS. You can do everything in bitcode that you can do in native ARM code. The limitations are already there in terms of code signing, sandboxing, and page protection and b
8. 68.▲
   by NateLawson 11y ago

   There are already ObjC selector obfuscators that generate a random secret and hash all program values with that on each build. https://github.com/Polidea/ios-class-guard
9. 69.▲
   by NateLawson 11y ago

   Good question. Obfuscation is more common on Android (10% of apps) than iOS (1%), but it's also pretty interesting where it's used most. First, throw out Proguard on Android. That's not really obfuscation, it's an optimi
10. 70.▲
    by NateLawson 11y ago

    Correct, most malware infections of mobile devices are targeted attacks for espionage etc.
11. 71.▲
    by NateLawson 11y ago

    The carriers are already blocking messages that match this pattern. That's why you haven't seen widespread exploitation. https://twitter.com/jcase/status/628327791713517570 However, this only works in th
12. 72.▲
    by NateLawson 11y ago

    Hey, this is really neat. It reminds me of the lesswrong.com community, where the goal is to figure out ways of offsetting cognitive biases. One thing I've always wanted to see is a mandatory A/B test built into any new legislatio
13. 73.▲
    by NateLawson 11y ago

    Also a good idea. We're definitely focused on showing relationships both within and externally to each app.
14. 74.▲
    by NateLawson 11y ago

    Thanks, this is a good avenue to consider.
15. 75.▲
    by NateLawson 11y ago

    Yes, we are working on ways to provide predictive lead scoring to vendors, telling them which developers are most valuable and when. We have some promising results we'll be talking about more in the near future.
16. 76.▲
    by NateLawson 11y ago

    It's usually the latter, which is that 3rd-party code just gets pulled into what the developer is actually trying to protect. Nobody tries to hide all their dependencies, as far as I can tell. Occasionally, they're trying to hide
17. 77.▲
    by NateLawson 11y ago

    We've actually resisted going after malware because every binary analysis technology seems to be pulled into its orbit eventually. It's like the Black Hole of Reversing. :) What I do wonder is if there are more interesting questi
18. 78.▲
    by NateLawson 11y ago

    Interesting, thanks. We've discussed providing some kind of code quality score. Also, we can definitely do something interesting by comparing how other apps have performed that share code features with yours. The ideal would be a predi
19. 79.▲
    by NateLawson 11y ago

    We depend on a huge number of program features so CFG alone isn't enough to throw it off (data references, function layout, linker behavior, and much more are included in our matching). You're right that, at some point, you'v
20. 80.▲
    by NateLawson 11y ago

    It's really common in Android (10-20% of apps), but happens occasionally in iOS too. The most common Android obfuscator is Proguard, but we also see Codeguard and others. The most surprising thing we found is that many developers build
21. 81.▲
    by NateLawson 11y ago

    Thanks, high praise indeed. I am super curious too what anyone would want to know if you could see inside any apps in the app stores?
22. 82.▲
    by NateLawson 11y ago

    The chord graphs show the linkage relationships amongst all the native libraries in Android apps. Each library has an edge to the other libraries it depends on. To keep it clear, we don't show platform libraries that are too common, li
23. 83.▲
    by NateLawson 11y ago

    Yes, in two ways. First, it's often useful to target malware or other systems by the common packer code they use. This doesn't require deobfuscating anything. More interestingly, the matching algorithms we developed are by design
24. 84.▲
    by NateLawson 11y ago

    We're focused on applying our engine to solve problems in the app stores, so no plans to make it a standalone software product. Yes, we track JNI links from Java -> native. Yes, we do data flow analysis as well, but it's target
25. 85.▲
    by NateLawson 11y ago

    Yes, the 2nd one. We can tell people: * What components are in the app * Exactly which versions * How they're being used/integrated We give very specific instructions how to fix, telling devs exactly which files or components are
26. 86.▲
    by NateLawson 11y ago

    While that's a great joke, we actually have a unique way of minimizing false positives compared to the average static analysis tool. We apply code similarity techniques to reuse analysis across apps, so we don't naively treat a bi
27. 87.▲
    by NateLawson 11y ago

    I don't know how much you can talk about the tech, but I'm interested in how it fits with existing batteries & applications. Is it possibly an add-on to lead acid? A better jump starter? What about industrial like large motor
28. 88.▲
    by NateLawson 11y ago

    Hi, I'm happy to discuss how we're finding hidden flaws in millions of apps that even developers didn't know about. We've built a really cool binary code search engine that has indexed the structure and behavior of apps.
29. 89.▲
    by NateLawson 11y ago

    Hi, I'm the founder of SourceDNA. We've built an index of the code in iOS and Android apps to quickly answer questions like this about how they were built. TLDR; we created a tool that lets you just search for an app and see if it
30. 90.▲
    by NateLawson 11y ago

    I think they mean "only watch Illustrator" or "only Photoshop".