3 ms·

> You run their software in binary form, having no idea what it does. You have no way to verify whether what they say is true. Sorry, but it's a bit tiring see

by lgeek 13y ago

> You run their software in binary form, having no idea what it does. You have no way to verify whether what they say is true. Sorry, but it's a bit tiring seeing this blanket statement. You can absolutely verify what closed source software does. starting from low tech approaches: * dissasembly, decompilation and debugging. This is standard old-school reverse engineering. Native code / bytecode is source code, it's just not optimised to be read by humans. :) * monitoring systemcalls - on Unixes you have strace and other similar tools which allow you to monitor all the systemcalls of an application. This should show all interactions with local and remote data. * dynamic binary analysis - tools like DynamoRIO and Pin run native code in a system similar to a JIT engine. You can transparently add code which will report what the application does. * data tracing - using dynamic analysis or managed languages. Data can be tagged based on source (e.g. treating input from files as sensitive) as it is being processed by an application. When that data is pushed outside the application using systemcalls, you can determine where it was coming from, even if it's encrypted or obfuscated. There is a project which implements this on Android (and the results are quite scary): http://appanalysis.org/ http://appanalysis.org/

astrodust 13y ago
That's a valid point, but there's a difference between what software does, which you're recommending you divine based on historical activity, and what it can do, which remains unknown. Even disassembling provides only a limited view into the code itself. If this method worked every time, we wouldn't have viruses. There are ways of concealing the true functionality of a piece of code to make disassembly and interpretation extremely difficult. Granted this is true with pure source code as well, but usually subversive code is much more obvious. This is not always the case, though.
- lgeek 13y ago
  You're right about this. Dynamic analysis instance is only useful if the application goes on to the relevant execution path, and static analysis is made quite difficult by dynamic generation and a few other tricks. However, if hidden behaviour (e.g. backdoors) is a concern, you can implement fine grained access control based on historical activity. Anyway, my point is that for almost every problem in this area there's a solution. But I think the main issue is that there isn't more pro/consumer software for this kind of auditing / sandboxing. I guess that has to do both with user education (no interest) and industry being afraid of transparency.
  - javajosh 13y ago
    Actually, the only interesting behaviors all involve phoning home at some point. That's where a product like Little Snitch comes in handy - whatever it is (including OS updates), you can see what is accessing the outside world. It turns out this is actually pretty good way to detect bad stuff.
  - astrodust 13y ago
    Access control is going to be pretty hard to implement for something like EFI firmware, CPU microcode, or other forms of embedded software. As much as people whinge about sandboxing, I think it's a great idea and hope there's more of it. Apple's model for OS X where certain kinds of apps come with certain limitations, but there is a switch for people to opt out of those restrictions, is a great compromise. Safe for users with limited technical ability and wide open for those that need it.

by lgeek 13y ago

astrodust 13y ago

That's a valid point, but there's a difference between what software does, which you're recommending you divine based on historical activity, and what it can do, which remains unknown. Even disassembling provides only a limited view into the code itself. If this method worked every time, we wouldn't have viruses. There are ways of concealing the true functionality of a piece of code to make disassembly and interpretation extremely difficult. Granted this is true with pure source code as well, but usually subversive code is much more obvious. This is not always the case, though.

lgeek 13y ago
You're right about this. Dynamic analysis instance is only useful if the application goes on to the relevant execution path, and static analysis is made quite difficult by dynamic generation and a few other tricks. However, if hidden behaviour (e.g. backdoors) is a concern, you can implement fine grained access control based on historical activity. Anyway, my point is that for almost every problem in this area there's a solution. But I think the main issue is that there isn't more pro/consumer software for this kind of auditing / sandboxing. I guess that has to do both with user education (no interest) and industry being afraid of transparency.
- javajosh 13y ago
  Actually, the only interesting behaviors all involve phoning home at some point. That's where a product like Little Snitch comes in handy - whatever it is (including OS updates), you can see what is accessing the outside world. It turns out this is actually pretty good way to detect bad stuff.
- astrodust 13y ago
  Access control is going to be pretty hard to implement for something like EFI firmware, CPU microcode, or other forms of embedded software. As much as people whinge about sandboxing, I think it's a great idea and hope there's more of it. Apple's model for OS X where certain kinds of apps come with certain limitations, but there is a switch for people to opt out of those restrictions, is a great compromise. Safe for users with limited technical ability and wide open for those that need it.