5 ms·

Hi, I’m the author of this post. Feel free to ask questions, if any.

75dvtwin 8y ago
if you could briefly outline the space/position of this framework, relative to others (eg https://github.com/cea-sec/miasm https://github.com/cea-sec/miasm ). Would very much appreciate. Also, besides security aspect (eg intrusion/virus detection), I was looking at these frameworks as a 'higher-level than assembler, and less hardware architecture dependent than LLVM IR) -- is there an angle where reverse engineering tools, have a separate live an better-than-assembler toolchain for low level programming?
- Icyphox 8y ago
  For starters, the purpose of this post was never to build an entire framework, like the one you’ve linked, but rather a small set of scripts to try and understand what disassemblers do under the hood. These scripts can also be tossed into some kind of automation pipeline of sorts, something like a CI/CD perhaps. There's a lot you can (potentially) do. And your second question, I'm not sure I understand what you're attempting to convey.
matmann2001 8y ago
Hey. In your C code, you write to memory beyond what you malloc'd. You malloc'd 9 bytes for 'pw', but later do "pw[9] = '\0'", which accesses the 10th byte, which doesn't belong to you.
- w0mbat 8y ago
  Yes, that jumped off the page at me too, and distracted me from the rest of the article.
  - matmann2001 8y ago
    Especially given the topic, I kept jumping around to see if it was intentional. Like maybe they would use these RE tools to exploit it.
- blattimwind 8y ago
  malloc allocates aligned memory [1], so technically it's correct that he writes past the allocated memory, but technically it's also impossible for that write to fail or for that write to overwrite something else. [1] bonus point: for what kind of alignment? (The minimum is quite well specified, for C standards)
  - spieglt 8y ago
    https://www.gnu.org/software/libc/manual/html_node/Aligned-Memory-Blocks.html https://www.gnu.org/software/libc/manual/html_node/Aligned-M... "The address of a block returned by malloc or realloc in GNU systems is always a multiple of eight (or sixteen on 64-bit systems)." I was about to say, "what if they're on a 32-bit system and so were only allocated one 8-byte block?" but then realized that since they'd requested 9 bytes, they'd be given two 8-byte blocks, or one 16-byte block on a 64-bit system. Is that right?
    - spieglt 8y ago
      Well, I guess alignment doesn't say anything about how large of a block is allocated.... And this is the clearest source I can find, which says 32 bytes. https://prog21.dadgum.com/179.html https://prog21.dadgum.com/179.html
      - blattimwind 8y ago
        > Well, I guess alignment doesn't say anything about how large of a block is allocated It tells you where something can't be, and because virtual memory is allocated in whole pages the "padding" so to speak will always be accessible. There's also the obvious truism that if you can access something in a cache line, all addresses in the cache line are safe to access. (Vectorized algorithms frequently implicitly rely on this for short reads, IOW there is no way reading a 128 or 256 bit vector can fault if just reading the first lane would not fault).
        saagarjha 8y ago
        > Vectorized algorithms frequently implicitly rely on this for short reads This is extremely processor-dependent and you should not be writing C if you’re relying on this.
- Icyphox 8y ago
  Ah my bad. I’ll make sure to fix it. Sorry about that.

if you could briefly outline the space/position of this framework, relative to others (eg https://github.com/cea-sec/miasm https://github.com/cea-sec/miasm ). Would very much appreciate. Also, besides security aspect (eg intrusion/virus detection), I was looking at these frameworks as a 'higher-level than assembler, and less hardware architecture dependent than LLVM IR) -- is there an angle where reverse engineering tools, have a separate live an better-than-assembler toolchain for low level programming?

Icyphox 8y ago
For starters, the purpose of this post was never to build an entire framework, like the one you’ve linked, but rather a small set of scripts to try and understand what disassemblers do under the hood. These scripts can also be tossed into some kind of automation pipeline of sorts, something like a CI/CD perhaps. There's a lot you can (potentially) do. And your second question, I'm not sure I understand what you're attempting to convey.

matmann2001 8y ago

Hey. In your C code, you write to memory beyond what you malloc'd. You malloc'd 9 bytes for 'pw', but later do "pw[9] = '\0'", which accesses the 10th byte, which doesn't belong to you.

w0mbat 8y ago
Yes, that jumped off the page at me too, and distracted me from the rest of the article.
- matmann2001 8y ago
  Especially given the topic, I kept jumping around to see if it was intentional. Like maybe they would use these RE tools to exploit it.
blattimwind 8y ago
malloc allocates aligned memory [1], so technically it's correct that he writes past the allocated memory, but technically it's also impossible for that write to fail or for that write to overwrite something else. [1] bonus point: for what kind of alignment? (The minimum is quite well specified, for C standards)
- spieglt 8y ago
  https://www.gnu.org/software/libc/manual/html_node/Aligned-Memory-Blocks.html https://www.gnu.org/software/libc/manual/html_node/Aligned-M... "The address of a block returned by malloc or realloc in GNU systems is always a multiple of eight (or sixteen on 64-bit systems)." I was about to say, "what if they're on a 32-bit system and so were only allocated one 8-byte block?" but then realized that since they'd requested 9 bytes, they'd be given two 8-byte blocks, or one 16-byte block on a 64-bit system. Is that right?
  - spieglt 8y ago
    Well, I guess alignment doesn't say anything about how large of a block is allocated.... And this is the clearest source I can find, which says 32 bytes. https://prog21.dadgum.com/179.html https://prog21.dadgum.com/179.html
    - blattimwind 8y ago
      > Well, I guess alignment doesn't say anything about how large of a block is allocated It tells you where something can't be, and because virtual memory is allocated in whole pages the "padding" so to speak will always be accessible. There's also the obvious truism that if you can access something in a cache line, all addresses in the cache line are safe to access. (Vectorized algorithms frequently implicitly rely on this for short reads, IOW there is no way reading a 128 or 256 bit vector can fault if just reading the first lane would not fault).
      - saagarjha 8y ago
        > Vectorized algorithms frequently implicitly rely on this for short reads This is extremely processor-dependent and you should not be writing C if you’re relying on this.
Icyphox 8y ago
Ah my bad. I’ll make sure to fix it. Sorry about that.