registers command fails on remote qemu-system-i386 target

[Noxwizard]

• Did you use the latest version of GEF from dev branch?
• Is your bug specific to GEF (not GDB)? - Try to reproduce it running gdb -nx
• Did you read the documentation first?
• Did you check issues (including the closed ones) - and the PR?
  • Similar to [ppc64] Command 'registers' failed to execute properly, reason: max() arg is an empty sequence #812

Step 1: Describe your environment

• Operating System / Distribution: Ubuntu 20.04.3, 5.4.0-100-generic
• Architecture: x64
• GEF version (including the Python library version) run version in GEF.

GEF: rev:2b7f31515a3638718b133e0d3b096aedeef5518c (Git - clean)
SHA256(/home/noxwizard/gef/gef.py): 767fcae12cac4cc6dbd3a0b2f51ad6b66f40ed72be199f256ed6c85aed44a70f
GDB: 9.2
GDB-Python: 3.8

Step 2: Describe your problem

Steps to reproduce

1. Download "small.ffs" image from here: https://wiki.qemu.org/Testing/System_Images
2. Extract .ffs image file
3. Run in QEMU: qemu-system-i386 small.ffs -gdb tcp::1234
4. Launch gdb
5. Attach to exposed gdb stub: gef-remote localhost:1234
6. Issue step-instruction command

Minimalist test case

See instructions to reproduce

Observed Results

• gdb connects, but GEF is unable to read the registers with error: [!] Command 'registers' failed to execute properly, reason: max() arg is an empty sequence

gef➤  gef-remote localhost:1234
warning: No executable has been specified and target does not support
determining executable automatically.  Try using the "file" command.
0x90216c0f in ?? ()
[+] Connected to 'localhost:1234'
[+] Remote information loaded to temporary path '/tmp/gef/1'
[!] Command 'gef-remote' failed to execute properly, reason: Not a valid ELF file (magic)
gef➤  si
0x90216c12 in ?? ()

[ Legend: Modified register | Code | Heap | Stack | String ]
───────────────────────────────────────────────────────────────── registers ────
[!] Command 'registers' failed to execute properly, reason: max() arg is an empty sequence
───────────────────────────────────────────────────────────────────── stack ────
0x00000090275a64│+0x0000: 0x0000000000f9ef  →  0x0000000000f9ef
0x00000090275a64│+0x0000: 0x0000000000f9ef  →  0x0000000000f9ef
0x00000090275a64│+0x0000: 0x0000000000f9ef  →  0x0000000000f9ef
0x00000090275a64│+0x0000: 0x0000000000f9ef  →  0x0000000000f9ef
0x00000090275a64│+0x0000: 0x0000000000f9ef  →  0x0000000000f9ef
0x00000090275a64│+0x0000: 0x0000000000f9ef  →  0x0000000000f9ef
0x00000090275a64│+0x0000: 0x0000000000f9ef  →  0x0000000000f9ef
0x00000090275a64│+0x0000: 0x0000000000f9ef  →  0x0000000000f9ef
───────────────────────────────────────────────────────────── code:generic: ────
   0x90216c0d                  push   ebx
   0x90216c0e                  popf   
   0x90216c0f                  movzx  edx, dl
 → 0x90216c12                  shl    edx, 0x8
   0x90216c15                  movzx  eax, cl
   0x90216c18                  or     edx, eax
   0x90216c1a                  mov    eax, edx
   0x90216c1c                  pop    ebx
   0x90216c1d                  pop    esi
─────────────────────────────────────────────────────────────────── threads ────
[#0] Id 1, stopped 0x90216c12 in ?? (), reason: SINGLE STEP
───────────────────────────────────────────────────────────────────── trace ────
[#0] 0x90216c12 → shl edx, 0x8
[#1] 0x90216c6d → mov edx, eax
[#2] 0x90137768 → add esp, 0xfffffffc
[#3] 0x9020c7a7 → lea esp, [ebp-0x18]
[#4] 0x90193596 → add esp, 0x20
[#5] 0x9020a63c → add esp, 0x10
[#6] 0x90192ed0 → jmp 0x90192f0f
[#7] 0x90193060 → add esp, 0x10
[#8] 0x9020a0c4 → lea esp, [ebp-0x18]
[#9] 0x90193596 → add esp, 0x20
────────────────────────────────────────────────────────────────────────────────
gef➤  

Expected results

• Registers are shown like normal

Traces

N/A

Let me know if you need any other information.

[hugsy]

Thanks for reporting the issue, we'll check it out.

[hugsy]

I could reproduce your issue, but it's not a bug, simply a misconfiguration:
GEF normally determines the architecture to use either by inspecting the ELF provided, or when specifically told to use a specific one. Since qemu-system-i386 -s gdb stub doesn't provide any ELF to run, GDB doesn't send the event to let GEF determine the architecture, resulting in GEF running in the default (basic) architecture. It indicates the failure in the warning messages:

[+] Remote information loaded to temporary path '/tmp/gef/1'
[!] Command 'gef-remote' failed to execute properly, reason: Not a valid ELF file (magic)

So to solve your problem, you can simply force the architecture using reset_architecture (in this case, X86):

gef➤  pi reset_architecture("X86")                                                                       
gef➤  gef-remote localhost 1234    

And that works just fine:

[hugsy]

Also works fine for ppc64 (cc @aik)

[Noxwizard]

That does indeed fix it. Thanks!

[aik]

@hugsy pi reset_architecture("ppc64") does work but gdb also allows passing a file which in my case is file ~/pbuild/kernel-llvm/vmlinux and gdb takes arch from there.