disassembly failures for libc.so

[m4b]

Can't seem to get through disassembly of libc.so without a panic of unimplemented, here is a sample:

DEBUG:panopticon_amd64::disassembler: 'Mnemonic { area: Bound { start: 1336920, end: 1336924 }, opcode: "movdqu", operands: [Variable { name: "MMX7", subscript: None, offset: 0, size: 64 }, Variable { name: "XMM0", subscript: None, offset: 0, size: 128 }], instructions: [], format_string: [Variable { has_sign: false }, Literal(','), Literal(' '), Variable { has_sign: false }] }' with 4 bytes
DEBUG:panopticon_amd64::architecture:     res: Ok(Match { tokens: [197, 254, 127, 7], mnemonics: [Mnemonic { area: Bound { start: 1336920, end: 1336924 }, opcode: "movdqu", operands: [Variable { name: "MMX7", subscript: None, offset: 0, size: 64 }, Variable { name: "XMM0", subscript: None, offset: 0, size: 128 }], instructions: [], format_string: [Variable { has_sign: false }, Literal(','), Literal(' '), Variable { has_sign: false }] }], jumps: [(1336920, Constant { value: 1336924, size: 64 }, True)], configuration: Long })
DEBUG:panopticon_core::function: 146658: movdqu ([197, 254, 127, 7])
DEBUG:panopticon_core::function: jump to Constant { value: 1336924, size: 64 }
DEBUG:panopticon_amd64::architecture: disass @ 0x1465e6: [98, 241, 254, 72, 111, 6, 98, 241, 254, 72, 111, 76, 22, 255, 98]
thread '<unnamed>' panicked at 'not yet implemented', /home/m4b/git/panopticon/amd64/src/disassembler.rs:2465
note: Run with `RUST_BACKTRACE=1` for a backtrace.
INFO:panop: disassembly thread finished

here's another with backtrace:

DEBUG:panopticon_amd64::architecture: disass @ 0x146b47: [196, 226, 121, 120, 192, 98, 242, 253, 72, 89, 192, 72, 131, 250, 64]
DEBUG:panopticon_amd64::disassembler: call pbroadcastb with [Variable { name: "YMM0", subscript: None, offset: 0, size: 256 }, Variable { name: "YMM8", subscript: None, offset: 0, size: 256 }]
DEBUG:panopticon_amd64::disassembler: 'Mnemonic { area: Bound { start: 1338183, end: 1338188 }, opcode: "pbroadcastb", operands: [Variable { name: "YMM0", subscript: None, offset: 0, size: 256 }, Variable { name: "YMM8", subscript: None, offset: 0, size: 256 }], instructions: [], format_string: [Variable { has_sign: false }, Literal(','), Literal(' '), Variable { has_sign: false }] }' with 5 bytes
DEBUG:panopticon_amd64::architecture:     res: Ok(Match { tokens: [196, 226, 121, 120, 192], mnemonics: [Mnemonic { area: Bound { start: 1338183, end: 1338188 }, opcode: "pbroadcastb", operands: [Variable { name: "YMM0", subscript: None, offset: 0, size: 256 }, Variable { name: "YMM8", subscript: None, offset: 0, size: 256 }], instructions: [], format_string: [Variable { has_sign: false }, Literal(','), Literal(' '), Variable { has_sign: false }] }], jumps: [(1338183, Constant { value: 1338188, size: 64 }, True)], configuration: Long })
DEBUG:panopticon_core::function: 146b47: pbroadcastb ([196, 226, 121, 120, 192])
DEBUG:panopticon_core::function: jump to Constant { value: 1338188, size: 64 }
DEBUG:panopticon_amd64::architecture: disass @ 0x146b4c: [98, 242, 253, 72, 89, 192, 72, 131, 250, 64, 15, 130, 209, 0, 0]
thread '<unnamed>' panicked at 'not yet implemented', /home/m4b/git/panopticon/amd64/src/disassembler.rs:2465
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
             at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::_print
             at /checkout/src/libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at /checkout/src/libstd/sys_common/backtrace.rs:60
             at /checkout/src/libstd/panicking.rs:355
   3: std::panicking::default_hook
             at /checkout/src/libstd/panicking.rs:371
   4: std::panicking::rust_panic_with_hook
             at /checkout/src/libstd/panicking.rs:549
   5: std::panicking::begin_panic
             at /checkout/src/libstd/panicking.rs:511
   6: panopticon_amd64::disassembler::read
             at /home/m4b/git/panopticon/amd64/src/disassembler.rs:2465
   7: <panopticon_amd64::architecture::Amd64 as panopticon_core::disassembler::Architecture>::decode
             at /home/m4b/git/panopticon/amd64/src/architecture.rs:72
   8: panopticon_core::function::Function::disassemble
             at /home/m4b/git/panopticon/core/src/function.rs:405
   9: panopticon_analysis::pipeline::pipeline::{{closure}}::{{closure}}
             at /home/m4b/git/panopticon/analysis/src/pipeline.rs:69
  10: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &'a mut F>::call_once
             at /checkout/src/libcore/ops/function.rs:191
  11: <core::option::Option<T>>::map
             at /checkout/src/libcore/option.rs:398
  12: <core::iter::Map<I, F> as core::iter::iterator::Iterator>::next
             at /checkout/src/libcore/iter/mod.rs:1069
  13: <alloc::vec::Vec<T>>::extend_desugared
             at /checkout/src/liballoc/vec.rs:1899
  14: <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T, I>>::spec_extend
             at /checkout/src/liballoc/vec.rs:1796
  15: <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T, I>>::from_iter
             at /checkout/src/liballoc/vec.rs:1791
  16: <alloc::vec::Vec<T> as core::iter::traits::FromIterator<T>>::from_iter
             at /checkout/src/liballoc/vec.rs:1692
  17: core::iter::iterator::Iterator::collect
             at /checkout/src/libcore/iter/iterator.rs:1256
  18: panopticon_analysis::pipeline::pipeline::{{closure}}
             at /home/m4b/git/panopticon/analysis/src/pipeline.rs:64
INFO:panop: disassembly thread finished

[m4b]

This is caused by Evex prefixes.

Short term: #310 will return an error instead of panicking, so disassembly can continue.

Long term: someone needs to implement the evex instructions

[flanfly]

3 byte EVEX prefixes are supported now. Can we close this?

[m4b]

Hmm, I'm getting an iob:

INFO:panopticon_analysis::pipeline: targets - (3)
INFO:panopticon_analysis::pipeline: Finished analysis: 2880 failures 5
thread 'main' panicked at 'index out of bounds: the len is 0 but the index is 0', /checkout/src/liballoc/vec.rs:1555:10
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
             at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::_print
             at /checkout/src/libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at /checkout/src/libstd/sys_common/backtrace.rs:60
             at /checkout/src/libstd/panicking.rs:380
   3: std::panicking::default_hook
             at /checkout/src/libstd/panicking.rs:396
   4: std::panicking::rust_panic_with_hook
             at /checkout/src/libstd/panicking.rs:611
   5: std::panicking::begin_panic_new
             at /checkout/src/libstd/panicking.rs:553
   6: std::panicking::begin_panic_fmt
             at /checkout/src/libstd/panicking.rs:521
   7: rust_begin_unwind
             at /checkout/src/libstd/panicking.rs:497
   8: core::panicking::panic_fmt
             at /checkout/src/libcore/panicking.rs:92
   9: core::panicking::panic_bounds_check
             at /checkout/src/libcore/panicking.rs:68
  10: panop::run
  11: panop::main
  12: __rust_maybe_catch_panic
             at /checkout/src/libpanic_unwind/lib.rs:98
  13: std::rt::lang_start
             at /checkout/src/libstd/panicking.rs:458
             at /checkout/src/libstd/panic.rs:361
             at /checkout/src/libstd/rt.rs:59
  14: __libc_start_main
  15: _start
Command exited with non-zero status 101
149.61user 1.29system 0:44.63elapsed 338%CPU (0avgtext+0avgdata 2279720maxresident)k
11104inputs+0outputs (35major+565269minor)pagefaults 0swaps

[m4b]

durrrr nevermind i dunno wth happened, false alarm, carry on!

[m4b]

actually it looks like some calls got broken on latest master:

RUST_BACKTRACE=1 RUST_LOG=panop=info cargo run --release -- /usr/lib/libc.so.6 -f printf

[m4b]

This is strange, why would there be a difference?

   51551: (call 0x48dc0)
          call ?, 0x48dc0:64
...
   5185d: (call 0x0)
          call ?, 0xff110:1

[flanfly]

Dunno, but the 2nd is definitely wrong, it calls to a one bit constant.

[m4b]

Objdump (note the addr32 on the callq):

   51551:       e8 6a 78 ff ff          callq  48dc0 <_IO_vfprintf>
   51556:       48 8b 4c 24 18          mov    0x18(%rsp),%rcx
   5155b:       64 48 33 0c 25 28 00    xor    %fs:0x28,%rcx
   51562:       00 00 
   51564:       75 08                   jne    5156e <_IO_printf+0xbe>
   51566:       48 81 c4 d8 00 00 00    add    $0xd8,%rsp
   5156d:       c3                      retq   
   5156e:       67 e8 9c db 0a 00       addr32 callq ff110 <__stack_chk_fail>
   51574:       66 2e 0f 1f 84 00 00    nopw   %cs:0x0(%rax,%rax,1)
   5157b:       00 00 00 
   5157e:       66 90                   xchg   %ax,%ax

il:

   51551: call 48dc0 <vfprintf>
   51556: mov rcx, qword ptr [rsp+0x18]
   5155b: xor rcx, qword ptr fs:[0x28]
   51564: jne 5156e
   51566: add rsp, d8
   5156d: ret 
   5156e: call 0
   51574: nop word ptr cs:[rax+rax*1]
   5157e: xchg ax, ax

[flanfly]

Ok, Panopticon doesn't handle the address size override prefix. That seems to be the problem.

[flanfly]

@m4b try this: https://github.com/flanfly/panopticon/tree/addr-sz-override

[m4b]

Yup this seems resolved, great work!!!