Failure to use shellphish-qemu-linux-x86_64 for a 32-bit ELF on a 64-bit host

[xjbian]

raise QEMUTracerError("the target didn't crash inside qemu or no corefile was created!" + 

archr.analyzers.qemu_tracer.QEMUTracerError: the target didn't crash inside qemu or no corefile was created!Make sure you launch it correctly! command: /tmp/archr_local_8suuaflh/shellphish_qemu/fire /tmp/archr_local_8suuaflh/shellphish_qemu/shellphish-qemu-linux-x86_64 -C /tmp/tracer_target_71_vz9cl -d nochain,exec,page,strace -D /tmp/tracer-e6sk_8x4.trace -E LD_BIND_NOW=1 -- ./rop

root@bxj-virtual-machine:/home/bxj/other/rex/tests# /tmp/archr_local_9k_8a488/shellphish_qemu/fire /tmp/archr_local_9k_8a488/shellphish_qemu/shellphish-qemu-linux-x86_64 -C /tmp/tracer_target_t_ue2dw1 -d nochain,exec,page,strace -D /tmp/tracer-ul43piva.trace -E LD_BIND_NOW=1 -- ./rop shellphish-qemu-linux-x86_64: ./rop: Invalid ELF image for this architecture

[rhelmot]

32-bit elf files need to be executed with shellphish-qemu-linux-i386. Did archr pick this qemu for you automatically? If so, this is an archr bug.

[xjbian]

It's automatic.I installed the rex on the vmware virtual machine,does this affect it?

[Kyle-Kyle]

Can you post how you invoke rex here? I think it may be because rex/archr does not automatically pick up the architecture correctly. @rhelmot actually, does archr have this capability?

[xjbian]

import rex import archr import os

from rex.vulnerability import Vulnerability

path = './rop' inp = b"A" * 200 with archr.targets.LocalTarget([path], target_os='') as target: crash = rex.Crash(target, inp) print(crash.crash_types) arsenal = crash.exploit() print(arsenal.dump())

[Kyle-Kyle]

OK. it seems like archr requires manually specifying the binary architecture currently. Can you try launching it with with archr.targets.LocalTarget([path], target_os='linux', target_arch='i386') as target: ?

[Kyle-Kyle]

I think we should add the automatic architecture selection feature to archr. I'll open an issue there.

[xjbian]

I try to set target_os='linux', target_arch='i386',but the following results are obtained: /usr/bin/python3 /home/bxj/other/rex/tests/test_rop.py Traceback (most recent call last): File "/home/bxj/other/rex/tests/test_rop.py", line 10, in crash = rex.Crash(target, inp) File "/home/bxj/other/rex/rex/crash.py", line 621, in init self._work() File "/home/bxj/other/rex/rex/crash.py", line 1004, in _work self.symbolic_trace() File "/home/bxj/other/rex/rex/crash.py", line 444, in symbolic_trace simgr.run() File "/usr/local/lib/python3.10/dist-packages/angr/sim_manager.py", line 298, in run self.step(stash=stash, kwargs) File "/usr/local/lib/python3.10/dist-packages/angr/misc/hookset.py", line 75, in call result = current_hook(self.func.self, args, kwargs) File "/usr/local/lib/python3.10/dist-packages/angr/exploration_techniques/tracer.py", line 321, in step return simgr.step(stash=stash, kwargs) File "/usr/local/lib/python3.10/dist-packages/angr/misc/hookset.py", line 80, in call return self.func(args, kwargs) File "/usr/local/lib/python3.10/dist-packages/angr/sim_manager.py", line 383, in step successors = self.step_state(state, successor_func=successor_func, *run_args) File "/usr/local/lib/python3.10/dist-packages/angr/misc/hookset.py", line 75, in call result = current_hook(self.func.self, args, **kwargs) File "/usr/local/lib/python3.10/dist-packages/angr/exploration_techniques/tracer.py", line 369, in step_state self._update_state_tracking(sat_succs[0]) File "/usr/local/lib/python3.10/dist-packages/angr/exploration_techniques/tracer.py", line 599, in _update_state_tracking raise TracerDesyncError("Oops! angr did not follow the trace", angr.exploration_techniques.tracer.TracerDesyncError: Oops! angr did not follow the trace

[xjbian]

I tried 64-bit ELF , it works fine.

[Kyle-Kyle]

That sounds like a bug. Can you post the binary so we can find the root cause?

[xjbian]

can you give me your email or wechat

[xjbian]

链接: https://pan.baidu.com/s/1Ftm6Pv5h_dEnLMTa_JBnIA 提取码: y5df 复制这段内容后打开百度网盘手机App，操作更方便哦 --来自百度网盘超级会员v1的分享

[Kyle-Kyle]

can you give me your email or wechat

My email is zengyhkylegmail.com

[Kyle-Kyle]

@rhelmot This is a statically compiled binary and the desync is caused by the diff between the number of environment variables. I don't think we can support this, right? Because the values of the env variables may cause desync later as well. But I wonder if there is a way to warn users about this instead of throwing out ambigous "desync" error

[xjbian]

Sorry, I was on vacation the other day.I don't quite understand that static compilation leads to differences in environment variables, which in turn causes desynchronization. Can you explain in detail, thanks.

[rhelmot]

Having a statically compiled binary doesn't lead to a difference in environment variables, but it makes it so that we cannot use SimProcedures to summarize the libc initialization functions which crawl the environment variables, so then if there is any difference in environment variables it will definitely be a problem for statically linked binaries.

You can fix this by using archr to generate your traces and your tracing states. It will make sure the environment is the same between the both of them.

[xjbian]

OK, I understand now, thanks