When we moved to argparse command parsing we introduced `gdb_sloppy_parse` which wasn't perfect: e.g. for `gdb.parse_and_eval("__libc_start_main")` would return a `gdb.Value()` whose `.type.name` was `long long`.
As a result when code that used `gdb_sloppy_parse` then casted the result to `int(gdb_value)` it crashed because for some reason GDB errored.
This commit fixes the issues related to it by adding `AddressExpr` and `HexOrAddressExpr` functions.
It also adds tests for some of the windbg compatibility commands and fixes some nifty details here and there.
Those lines are redundant in our case: pwndbg is not imported or launched directly.
Also, the coding lines were relevant in Py2 but are not really needed in Py3.
Those regs does not seem to work on i386: I can't do `i r dil` in i386 but I can do so in amd64 binaries.
Via https://www.tortall.net/projects/yasm/manual/html/arch-x86-registers.html :
```
The 64-bit x86 register set consists of 16 general purpose registers, only 8 of which are available in 16-bit and 32-bit mode. The core eight 16-bit registers are AX, BX, CX, DX, SI, DI, BP, and SP. The least significant 8 bits of the first four of these registers are accessible via the AL, BL, CL, and DL in all execution modes. In 64-bit mode, the least significant 8 bits of the other four of these registers are also accessible; these are named SIL, DIL, SPL, and BPL. The most significant 8 bits of the first four 16-bit registers are also available, although there are some restrictions on when they can be used in 64-bit mode; these are named AH, BH, CH, and DH.
```
and the table present there, it seems SIL, DIL, SPL and BPL are only available in 64-bit mode.
The typeinfo module used a static global tempdir location of /tmp/pwndbg
that an attacker may control and prepare symlinks of the predictable
files that are then written to.
Package glibc-debuginfo, which is a requirement,
requires repo-debug to be enabled, which is not enabled
by default.
This commit enables this repo when installing if it is
not already enabled.
TL;DR: With .splitlines() we splitted over universal splitlines which did not correspond to GDB's target code line splitting...
As a result we got `context code` to produce bogus out of sync lines that didn't correspond to GDB's `line` command.
See also https://docs.python.org/3/library/stdtypes.html#str.splitlines
Addresses #957 by enclosing anonymous map names printed by vmmap in square brackets.
Search still works & xinfo plays nice, but please let me know if you find anything this breaks.
Revert the change from 3e4ad60 and make the `pwndbg.proc.get_file` to strip the "target:" prefix instead of the `pwndbg.proc.exe`.
This way, we will prevent bugs when pwndbg code would use `pwndbg.proc.exe` on remote targets but not pass the returned path to `pwndbg.proc.get_file` to get the real remote file and instead use the local one (if it exists in the same path).
Additionally, we assert the `path` passed to `pwndbg.proc.get_file` so we prevent incorrect use of the function when an absolute path or not a remote path is passed to it.
Before this commit the `pwndbg.proc.exe` could return a "target:" prefix when `pwndbg.proc.exe` was executed on remote targets. This could be seen by:
1. Executing gdbserver in one terminal: gdbserver 127.0.0.1:1234 `which ps`
2. Executing `gdb -ex 'target remote :1234'` in another terminal and then invoking `pi pwndbg.proc.exe`.
This resulted in `checksec` (and some other) commands crashes which were using the `pwndbg.file.get_fille` functionality as it downloaded the remote file by using the `gdb.execute("remote get %s %s")` command passing it a path prefixed with `"target:"` which this GDB command does not support.
The `pwndbg.memoize.reset_on_new_base_address` decorator is super problematic: its start event was called before `pwndbg.arch.update` event because the pwndbg/memoize.py file is executed faster than the pwndbg/arch.py file. This happens even if we import pwndbg/arch.py as first import because it imports regs.py and events.py and those import memoize.py and so on.
TL;DR: The decorator was quite redundant and made too many calls in the end which caused some problems when executing:
1. In one console: qemu-x86_64 -g 1234 `which ps`
2. In another, attaching to this via `gdb` -> `target remote :1234`
Tobias Faller