zax failure on "zola" binary
The third zax failure I've been asked to submit; this time on the pre-built "zola" binary.
Package link: https://github.com/getzola/zola/releases
Best, -Stefan
Activity
Interestingly, i can zipr zola, but not zafl it. It fails with a STARS assertion in the zax step.
@clc, Care to take a look?
Binary is too big to attach, but is on helix64 in ~jdh8d/tmp/zola.exe
Note: It takes a long time to get to the zax failure due to IRDB read/write operations. We should consider converting zax to a thanos plugin (@an7s ).
@jdh8d Updating my work environment to examine this, I found a local edit that I need to stash or undo, from early August:
helix64$ git diff fix_calls.cpp diff --git a/irdb-libs/ir_builders/fix_calls.cpp b/irdb-libs/ir_builders/fix_cal index f5d508f..e0314a6 100644 --- a/irdb-libs/ir_builders/fix_calls.cpp +++ b/irdb-libs/ir_builders/fix_calls.cpp @@ -252,7 +252,7 @@ class FixCalls_t : public TransformStep_t // calls to not the entry of a function likely result // from ida/rida mis-identification of functions. no need to fix them. -#if 0 +#if 1 assert(cfg->getEntry()); /* if the call instruction isn't to a function entry pRemember anything about this? I assume I should just go back to commenting this section out again by making the #if 1 back into #if 0.
@jdh8d So,
./clean-all.shfollowed by./build-all.sh --debugdoes not give me everything I need for gdb, because libstars.so still has no debugging symbols. Do we have a standard procedure for this kind of debugging build effort?That's some crazy code in zola.exe. Now I need to figure out how to fix it.
Problem: Tracking the value of the stack pointer. There is a function with the following behavior:
- Does not alter RAX.
- Manipulates RSP in a loop but then restores it.
- Each call to this function puts a (different) large value in RAX.
- Right after each call comes "sub rsp,rax" which allocates a chunk of space.
Simple example of a call to this function:
bce8 20d560 0 bcea ffffffff bce8 push rbp(push rbp) bcea 20d561 0 bcec ffffffff bce8 mov rbp, rsp(mov r bp, rsp) bcec 20d564 0 bcee ffffffff bce8 push r15(push r15) bcee 20d566 0 bcf0 ffffffff bce8 push r14(push r14) bcf0 20d568 0 bcf2 ffffffff bce8 push r13(push r13) bcf2 20d56a 0 bcf4 ffffffff bce8 push r12(push r12) bcf4 20d56c 0 bcf6 ffffffff bce8 push rbx(push rbx) bcf6 20d56d 0 bcf8 ffffffff bce8 and rsp, 0xfffffff fffffff80(and rsp, 0xffffffffffffff80) bcf8 20d571 0 bcfa ffffffff bce8 mov eax, 0x1780(mo v eax, 0x1780) bcfa 20d576 0 bcfc 45080c bce8 call 0xbc77c0(call 0xbc77c0) bcfc 20d57b 0 bcfe ffffffff bce8 sub rsp, rax(sub rsp, rax)So, with
add rsp,raxinside the function right before the return, thesub rsp,raxinstruction will undo it, but first the location of the stored return address will be changed. Looking at the function in question:45080a bc77ba 0 45080c ffffffff NoFunc nop word [rax + rax](nop word [rax + rax]) 45080c bc77c0 0 45080e ffffffff NoFunc mov r11, rax(mov r11, rax) 45080e bc77c3 0 450810 ffffffff NoFunc cmp r11, 0x1000(cmp r11, 0x1000) 450810 bc77ca 0 450812 45081c NoFunc jbe 0xbc77e8(jbe 0xbc77e8) 450812 bc77cc 0 450814 ffffffff NoFunc sub rsp, 0x1000(sub rsp, 0x1000) 450814 bc77d3 0 450816 ffffffff NoFunc test qword [rsp + 8], rsp(test qword [rsp + 8], rsp) 450816 bc77d8 0 450818 ffffffff NoFunc sub r11, 0x1000(sub r11, 0x1000) 450818 bc77df 0 45081a ffffffff NoFunc cmp r11, 0x1000(cmp r11, 0x1000) 45081a bc77e6 0 45081c 450812 NoFunc ja 0xbc77cc(ja 0xbc77cc) 45081c bc77e8 0 45081e ffffffff NoFunc sub rsp, r11(sub rsp, r11) 45081e bc77eb 0 450820 ffffffff NoFunc test qword [rsp + 8], rsp(test qword [rsp + 8], rsp) 450820 bc77f0 0 450822 ffffffff NoFunc add rsp, rax(add rsp, rax) 450822 bc77f3 0 ffffffff ffffffff NoFunc ret (ret )Given an input value of 0x1780, we have this operation:
- Copy 0x1780 into R11, leave RAX alone.
- R11 is not <= 0x1000, so fall through the "jbe" statement.
- Subtract 0x1000 from RSP, allocating space (?).
- Subtract 0x1000 from R11, leaving 0x0780.
- R11 is now less than 0x1000, so fall through the "ja" statement.
- Subtract R11 from RSP, meaning subtract 0x0780, so RSP is now 0x1780 less than it was on entry.
- Add RAX (still has 0x1780) to RSP, so adjustments to RSP are undone.
- Return.
Therefore, in this example, the return goes to the instruction after the call, which subtracts 0x1780 from RSP, right? That allocates a big chunk of space, but STARS cannot easily analyze how much (0x1780) although I could add a simple analysis to determine if RAX was unchanged by the weird callee. That analysis is already performed later (i.e. we have a phase-ordering issue here).
Also, it appears that the two "test" opcodes in the weird callee are irrelevant, as the flags get reset by an add or sub opcode before the next conditional branch. Bizarre.
Investigation led to numerous corner cases in stack pointer analysis. That will need to continue in the future.
Meanwhile, the committed fixes keep STARS from crashing, but I see a zipr crash when I do the following in peasoup_umbrella:
$PSZ ./zola.exe ./zola.mg -c rida -c dump_map -c move_globals
helix64$ tail zipr.log Creating call sites in LSDA for 370cbc:pop rbx Creating call sites in LSDA for 33bb2a:mov rdi, rsp zipr.exe: zipr/src/ehwrite.cpp:854: bool zipr::EhWriter::ElfEhWriter_t<ptrsize>::FDErepresentation_t::LSDArepresentation_t::canExtend(IRDB_SDK::Instruction_t*) const [with int ptrsize = 8]: Assertion `(tt_encoding&0xf)==0x3 || (tt_encoding)==0xff || ((tt_encoding&0xf)==0x0 && ptrsize==4) || (tt_encoding&0xf)==0xb' failed. /localtmp/clc5q/GitProjects/peasoup_umbrella/irdb-libs/plugins_install/zipr.sh: line 7: 13280 Aborted (core dumped) LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$ZIPR_INSTALL/lib $ZIPR_INSTALL/bin/zipr.exe --variant $cloneid --zipr:objcopy $PS_OBJCOPY $other_opts #ATTRIBUTE start_time=2019-12-10T14:59:17-0500 #ATTRIBUTE end_time=2019-12-10T15:25:03-0500 #ATTRIBUTE step_name=zipr #ATTRIBUTE step_number=5 #ATTRIBUTE step_command=/localtmp/clc5q/GitProjects/peasoup_umbrella/irdb-libs/plugins_install/zipr.sh 160 #ATTRIBUTE step_exitcode=134Is this a known zipr problem already being worked on?
