search command will crash qemu process

[bb33bb]

search command will crash qemu process

[disconnect3d]

Any stack trace? Any minimal PoC? :(
Any chance u can debug it and see what's the cause?

[bb33bb]

Any stack trace? Any minimal PoC? :( Any chance u can debug it and see what's the cause?

I am going to make a detail readme.md and see you later.
I dont konw why , and i tried to debug qemu.
any how ,wait me a little time and i will try my best.
Because search command is really so important for me.
Is there any possible to make it multithread search ?

[bb33bb]

Here is the video
https://github.com/pwndbg/pwndbg/assets/5463104/3d1ec5df-a3fd-4906-9f12-3b3f727519eb

[bb33bb]

the full detail is :
01-start qemu

#!/bin/bash
qemu-system-aarch64
-M virt
-cpu cortex-a57
-nographic --no-reboot -monitor /dev/null
-smp 4
-m 4G
-kernel Image
-drive file=./rootfs.img,format=raw,if=none,id=hd0
-device virtio-blk-device,drive=hd0
-netdev user,id=net0,hostfwd=tcp::10021-:22 -device virtio-net-device,netdev=net0
-device virtio-gpu-pci
-append "root=/dev/vda rw console=ttyAMA0 nokaslr"
-fsdev local,id=fsdev0,path=.,security_model=none
-device virtio-9p-device,id=fs0,fsdev=fsdev0,mount_tag=hostshare
-pidfile vm.pid
-gdb tcp::1234
2>&1 | tee vm.log

02-start gdb
gdb-multiarch
-ex "target remote localhost:1234"
-ex "set auto-load safe-path /"

03-search
pwndbg> search 0x0000000011223355
Searching for value: '0x0000000011223355'
Ignoring packet error, continuing...
pwndbg> quit

04-quit

[bb33bb]

i have to say that when searching , we have to wait for a long time ,and i tried to attach qemu, finally i droped it .
Because i think i am not so skiled to handle this.
is there any possible to make it a little more args ? Because this will really cost a long time.
For example, CE allow us search data by align memory with 0x10 or 0x8

[bata24]

This is completely speculation, so please forgive me if I'm wrong.

I know a problem with searching the entire memory with qemu-system.
I think there are cases where the area reserved for hardware crashes just by touching it. For example, an area for UART.
I encountered this phenomenon while analyzing HITCON CTF 2018 super_hexagon (This challenge is non-linux).

[bb33bb]

this is the crash situation
I guess it touched some area that not readable.

[bb33bb]

another thing i wanna to add is , configure like this:

echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope

then debugger can see alot memory

[disconnect3d]

I haven’t yet dived into the issue but I want to put a note here that we offload searching to GDB which may or may not be optimal. I am going to see if this can be optimized at GDB side of things (although if so, it will take a bit time for them to pull it and release it).

…

On Tue, 21 Nov 2023 at 05:01, boy1337 ***@***.***> wrote: another thing i wanna to add is , configure like this: echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope then debugger can see alot memory — Reply to this email directly, view it on GitHub <#1931 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACMLWCTUADBL7NA6O52Z6J3YFQRQTAVCNFSM6AAAAAA67EPZZCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMRQGIYDCOBSGM> . You are receiving this because you commented.Message ID: ***@***.***>

[bb33bb]

I haven’t yet dived into the issue but I want to put a note here that we offload searching to GDB which may or may not be optimal. I am going to see if this can be optimized at GDB side of things (although if so, it will take a bit time for them to pull it and release it).

really thanks for your work!!

[bb33bb]

昨天尝试，问题依旧存在

[bata24]

I discovered an area that may be one of the causes.
The guest crashes when accessing the GIC (General Interrupt Controller) area.
These areas exist on ARM and ARM64, but not on x86 or x64.

gef> monitor info mtree -f 
FlatView #0
 AS "memory", root: system
 AS "cpu-memory-0", root: system
 AS "cpu-memory-1", root: system
 Root memory region: system
  0000000000000000-0000000003ffffff (prio 0, romd): virt.flash0
  0000000004000000-0000000007ffffff (prio 0, romd): virt.flash1
  0000000008000000-0000000008000fff (prio 0, i/o): gic_dist     <--- here
  0000000008010000-0000000008011fff (prio 0, i/o): gic_cpu      <--- here
  0000000008020000-0000000008020fff (prio 0, i/o): gicv2m
  0000000009000000-0000000009000fff (prio 0, i/o): pl011
  0000000009010000-0000000009010fff (prio 0, i/o): pl031
...
gef> 

gef> p2v 0x8000000
Phys: 0x8000000 -> Virt: 0xf0800000
Total 1 results are found

gef> x/16xg 0xf0800000
0xf0800000:     Remote connection closed
gef> 

However, there are cases where it does not crash even when accessed.

• ARM / ARM64 built with buildroot did not crash.
• debian of ARM / ARM64 crashed.

I don't know the cause of this.

[disconnect3d]

@bata24 Thanks for more info!

But what exactly do u debug that causes this? I guess this may differ based on the target?

E.g. remote gdbserver vs QEMU user vs QEMU kernel vs real device debug bridge?

[bata24]

Suppose the GIC area is the cause.

We need to consider GIC when debugging kernels and bear metal firmware. In other words, qemu-system, OpenOCD, KGDB stub, VMware stub, etc. are at least targets to be considered. Conversely, I don't think qemu-user and gdbserver are target.

By the way, the area where GIC exists seems to be different for each environment, so it seems to be represented by a device tree.

Therefore, to identify the GIC area (for the purpose of avoiding access to this area), it is limited when we can read the information of device tree from the GDB side. The case of qemu-system can be identified with the monitor info command, but in other cases it does not know if it can be identified.

[bb33bb]

I discovered an area that may be one of the causes. The guest crashes when accessing the GIC (General Interrupt Controller) area. These areas exist on ARM and ARM64, but not on x86 or x64.

gef> monitor info mtree -f 
FlatView #0
 AS "memory", root: system
 AS "cpu-memory-0", root: system
 AS "cpu-memory-1", root: system
 Root memory region: system
  0000000000000000-0000000003ffffff (prio 0, romd): virt.flash0
  0000000004000000-0000000007ffffff (prio 0, romd): virt.flash1
  0000000008000000-0000000008000fff (prio 0, i/o): gic_dist     <--- here
  0000000008010000-0000000008011fff (prio 0, i/o): gic_cpu      <--- here
  0000000008020000-0000000008020fff (prio 0, i/o): gicv2m
  0000000009000000-0000000009000fff (prio 0, i/o): pl011
  0000000009010000-0000000009010fff (prio 0, i/o): pl031
...
gef> 

gef> p2v 0x8000000
Phys: 0x8000000 -> Virt: 0xf0800000
Total 1 results are found

gef> x/16xg 0xf0800000
0xf0800000:     Remote connection closed
gef> 

However, there are cases where it does not crash even when accessed.

• ARM / ARM64 built with buildroot did not crash.
• debian of ARM / ARM64 crashed.

I don't know the cause of this.

amazing that u can test the root cause!!
another amazing is using gef to find pwndbg root cause.