7 ms·

Calling attention to this: disassembly is a thing. It is entirely possible to reconstruct a program's design and logic from the disassembled code. This is what

by pnathan 13y ago

Calling attention to this: disassembly is a thing. It is entirely possible to reconstruct a program's design and logic from the disassembled code. This is what software crackers and antivirus writers do on a regular basis. For an enlightening write-up, see the Symantec paper(s) on Stuxnet.

ars_technician 13y ago
Right, but it's harder to detect subtle manipulation. It only takes a one bit error to reduce the key space by half.
- tptacek 13y ago
  It is hard to detect subtle manipulation period. But assembly language is an extremely concrete representation of a program; it is not an especially great way to write underhanded code. It's possible to write obfuscated assembly, of course, but it sticks out as obfuscated. To further get your head around the lack of cover compiled code would give a backdoor, it's worth knowing that Hopper will give you serviceable C-ish code from x86_64 for... let me check here... fifty nine bucks. (It's possible that my only message with that last graf is "Hopper is great").
  - pg_is_a_butt 13y ago
    assembly language is not an extremely concrete representation of a program if the hardware is engineered with backdoors which is exactly what this article suggests is happening. if some specific set of registers is set a certain way followed by a very specific series of commands, there is no practical way to prove that the hardware is doing what it should.
    - tptacek 13y ago
      You are talking about a wildly different threat model than this little section of the thread is talking about. Meanwhile: if you can't trust the hardware, you can't trust C code either.
  - ars_technician 13y ago
    How easy is to detect off-by-one errors looking at assembly?
forgottenpaswrd 13y ago
"This is what software crackers and antivirus writers do on a regular basis. For an enlightening write-up, see the Symantec paper(s) on Stuxnet." Well, not really. I was both software cracker and virus writer myself(just for fun, we never distributed our virus or our cracks, keygens and stuff outside). I was part of a larger group doing it. I had contacts with people that became famous for breaking several important protections, specially for games. You have no idea how big software is. A million lines of code is impossible to read by any human being in his entire life. Yes, there are automatic tools and great disassemblers like IDA pro, but even if you were to see the entire source code, it is very easy to hide some flaw into the code. If you add undocumented hardware into the equation, then it is very hard to disassemble without significant resources. This hardware took dozens of millions of dollars to develop, hundreds of very smart people to design, with all the documentation. It will take at least an order of magnitude more to decode not having that info.
- tptacek 13y ago
  I don't know when you were a virus writer (the heyday of the virus writers I knew was the mid-1990s, and the virus writers I was aware of post-2000 had more knowledge of WinAPI than of x86), but: the state of the art for disassembly and reverse engineering has progressed dramatically in the past 10 years. In particular, reverse engineering is no longer the specialty of virus authors the way it used to be; a totally mainstream application of reverse engineering, practiced by most major security companies, is reverse engineering patches to find the underlying security flaws they fix so they can be weaponized. It is easy to hide flaws in any code. Assembly doesn't make it much easier.
  - dr_doom 13y ago
    Can you expand on or point to a write up on reverse engineering patches? Do you mean that reversers' try to locate the, say, buffer overflow that was fixed and try to find another way to exploit it? Why would major companies want to do this?
    - tptacek 13y ago

by pnathan 13y ago

ars_technician 13y ago

Right, but it's harder to detect subtle manipulation. It only takes a one bit error to reduce the key space by half.

tptacek 13y ago
It is hard to detect subtle manipulation period. But assembly language is an extremely concrete representation of a program; it is not an especially great way to write underhanded code. It's possible to write obfuscated assembly, of course, but it sticks out as obfuscated. To further get your head around the lack of cover compiled code would give a backdoor, it's worth knowing that Hopper will give you serviceable C-ish code from x86_64 for... let me check here... fifty nine bucks. (It's possible that my only message with that last graf is "Hopper is great").
- pg_is_a_butt 13y ago
  assembly language is not an extremely concrete representation of a program if the hardware is engineered with backdoors which is exactly what this article suggests is happening. if some specific set of registers is set a certain way followed by a very specific series of commands, there is no practical way to prove that the hardware is doing what it should.
  - tptacek 13y ago
    You are talking about a wildly different threat model than this little section of the thread is talking about. Meanwhile: if you can't trust the hardware, you can't trust C code either.
- ars_technician 13y ago
  How easy is to detect off-by-one errors looking at assembly?

forgottenpaswrd 13y ago

"This is what software crackers and antivirus writers do on a regular basis. For an enlightening write-up, see the Symantec paper(s) on Stuxnet." Well, not really. I was both software cracker and virus writer myself(just for fun, we never distributed our virus or our cracks, keygens and stuff outside). I was part of a larger group doing it. I had contacts with people that became famous for breaking several important protections, specially for games. You have no idea how big software is. A million lines of code is impossible to read by any human being in his entire life. Yes, there are automatic tools and great disassemblers like IDA pro, but even if you were to see the entire source code, it is very easy to hide some flaw into the code. If you add undocumented hardware into the equation, then it is very hard to disassemble without significant resources. This hardware took dozens of millions of dollars to develop, hundreds of very smart people to design, with all the documentation. It will take at least an order of magnitude more to decode not having that info.

tptacek 13y ago
I don't know when you were a virus writer (the heyday of the virus writers I knew was the mid-1990s, and the virus writers I was aware of post-2000 had more knowledge of WinAPI than of x86), but: the state of the art for disassembly and reverse engineering has progressed dramatically in the past 10 years. In particular, reverse engineering is no longer the specialty of virus authors the way it used to be; a totally mainstream application of reverse engineering, practiced by most major security companies, is reverse engineering patches to find the underlying security flaws they fix so they can be weaponized. It is easy to hide flaws in any code. Assembly doesn't make it much easier.
- dr_doom 13y ago
  Can you expand on or point to a write up on reverse engineering patches? Do you mean that reversers' try to locate the, say, buffer overflow that was fixed and try to find another way to exploit it? Why would major companies want to do this?
  - tptacek 13y ago