We don't have an ARM64 runner for creating release binaries since ~6 months.
Commenting this out until GitHub finally allows open source projects to use its own arm64 runners.
* Initial version of qemu-user tests
* Refactor testing files to reduce file duplication, introduce qemu-user-tests
* lint and edit github actions workflow file. Move old qemu-user tests to seperate directory
* Add iproute2 so ss command is available
* test ubuntu 24
* funkiness with current working directory...
* Further remote old test_qemu.sh and integrate into a Pytest fixture
* lint
* Disable ASLR, add test for aarch64 jumps
* Use Popen.kill() function to make sure it closes.
Co-authored-by: Disconnect3d <dominik.b.czarnota@gmail.com>
* qemu.kill() on the other fixture as well
* comment
* comment
* lint
* system test path stuff
* remove old try-catch block
* revert
* revert path change
* Use os._exit to pass return code, and move qemu-user tests above system tests because they run significantly faster
* lint
* Flush stdout before os._exit
* Comment out flaky check for the address of main in old qemu tests
* rename qemu-user to cross-arch
* rename qemu-user to cross-arch and hotfix to not run pytest when
cross-arch is used
* remove todo comment
* another comment
* Test pwndbg.gdblib.symbol.address is not None and revert setarch -R
* Revert os.exit change
* Revert os.exit change
* Revert os.exit change
* readd os.exit in new exit places
* lint
* rebase
* delete file introduced in rebase
* break up tests into 3 files to invoke separately. Update GitHub workflow, remove code duplication in existing test
* code coverage
* fix code coverage
* lint
* test difference between Ubuntu 22 and 24 in Kernel tests
* lint
---------
Co-authored-by: Disconnect3d <dominik.b.czarnota@gmail.com>
* Add gdb_version to mock gdblib
* Re-enable unit tests
* Only collect unit test coverage if --cov is passed
* Source venv before running tests in github action
* Add venv path PATH in to Dockerfile
* Only check for "/ls" in `which` test
* Move docs dependencies into pyproject, install with poetry in GH action
* Remove old sphinx files
* Remove custom theme dir
* Hide navigation and toc on the blog page
* Remove fetch-depth from docs GH workflow
* Source venv before running mkdocs build
* Remove caching from docs GH workflow
* Remove python version in docs GH workflow
- remove submodules from all files
- bump flake.lock
- add gdb-pt-dump as dependency
- fix building Dockerfile
- fix gdb-pt-dump was broken on portable packages
Until now we ran the lint job on CI on both Ubuntu 20.04 and Ubuntu 22.04. I am not sure why exactly we run it on both, but I think we can try running it only on Ubuntu 22.04 unless there are good reasons to keep both.
* Only run arch for testing
* Remove outdated arch repo
* Actually build the docker image
* Do not include site packages in sys.path
* Ignore `.relr.dyn` section; skip lines w/o spaces
Newer binaries can contain a `.relr.dyn` section to compress `R_X86_64_RELATIVE` relocation entries.
These binaries can be found for example on archlinux but also on Debian 12 for example.
`readelf` prints the content of the section similarly to this:
```
Relocation section '.relr.dyn' at offset 0x25220 contains 35 entries:
1198 offsets
00000000001ce8d0
00000000001ce8e0
```
Compared to `00000000001d2000 0000000000000025 R_X86_64_IRELATIVE 9f330` for
`.rela.plt`.
Pwndbg now chokes on the new format because it expects a space seperator where there is none.
It might be, that this is actually an upstream problem with binutils, because llvm-readelf prints this:
```
Relocation section '.relr.dyn' at offset 0x25220 contains 1198 entries:
Offset Info Type Symbol's Value Symbol's Name
00000000001ce8d0 0000000000000008 R_X86_64_RELATIVE
00000000001ce8e0 0000000000000008 R_X86_64_RELATIVE
```
Nevertheless, we aren't actually interested in `R_X86_64_RELATIVE` relocations so I guess it's fine to
just skip all lines that contain no spaces at all.
`.relr.dyn` can only containt `R_X86_64_RELATIVE` relocations as far as I understand
https://maskray.me/blog/2021-10-30-relative-relocations-and-relr
* Accept Full RELRO in test
Archlinux has libc and ld with Full RELRO.
We now just accept Partial and Full RELRO.
* Do not copy binaries from host to docker
The `Dockerfile` copies the whole pwndbg folder to the image.
If we have built binaries on the host before, these binaries will contain references to
the host system and *copied* to the image.
If we now run `context code` (inside docker) to have a look at the source code this will
fail, because we will try to refer to a path on the host system.
* Do not use loop index after loop
Do not use loop index after the loop. The tests assumed that the loop in line 186
would run at least once, thereby *resetting* `i` to zero. If we never enter the
loop, `i` will *continue* to have the value it had at the end of line 172.
This will cause the test to fail in mysterious ways because `i` is now not reset
to zero but still has the value `31` for example.
The solution is to never use `i` outside of a loop.
* Re-enable archlinux and temporarily disabled ones
* Fix coverage combine toml issue
This commit should fix this issue:
```
Run coverage combine
coverage combine
coverage xml
shell: /usr/bin/bash -e {0}
Can't read 'pyproject.toml' without TOML support. Install with [toml] extra
Error: Process completed with exit code 1.
```
* setup.sh: cleanup the --user flag since we use venv now
Cleans up the --user flag from setup.sh since it is unused after we changed setup.sh to install Python dependencies in a virtual environment
* Remove --user flag from CI workflows
* Fix codecov problem
We need to run the python `coverage` library to collect coverage.
However, gdb was failing to find it.
Recently, pwndbg moved to using venvs. When pwndbg is initialized
it setups the venv "manually", that is, no "source .venv/bin/activate"
is needed. When we run gdb tests, we pass the `gdbinit.py` of pwndbg as a
command to gdb to be executed like this:
`gdb --silent --nx --nh -ex 'py import coverage;coverage.process_startup()' --command PATH_TO_gdbinit.py`
The problem is that *order* matters. This means that *first* coverage
is imported (by `-ex py ...`) and only *then* the init script is executed.
When `coverage` is first imported, it's library search path only looks
in system libraries of python, and not the venv that gdbinit.py would load.
So we would try to import an old version of coverage and fail.
One solution would be to move around the commands, but this would be an
ugly hack IMHO. **Instead**, we should just tell gdb that this is an **init**
command that has to be executed before other commands.
Previously, the order did not matter. All of pwndbg's dependencies were
installed directly as system libraries to python. So the library search path
was the same before and after loading `gdbinit.py`.
---------
Co-authored-by: disconnect3d <dominik.b.czarnota@gmail.com>
Co-authored-by: intrigus <abc123zeus@live.de>
* Improve RISCV support
This is a resurrection of #829
Co-authored-by: Tobias Faller <faller@endiio.com>
* Silence bogus vermin warning
* Fix relative backwards jump calculations
The target address wouldn't be truncated to the pointer size.
* Add basic qemu-user test
* Run qemu-user tests in CI
* Make shfmt happy
* Fix pwntools < 4.11.0 support
* Support RISCV32 for pwntools < 4.11.0 as well
---------
Co-authored-by: Tobias Faller <faller@endiio.com>
* Specify dockerfile for ubuntu/debian
To add Dockerfile.arch later
* Support Arch Linux docker test
* Fix setup-dev supported distro
* Create set_zigpath function
* Download zig from upstream for archlinux
* Add hash as part of key for docker cache
as https://github.com/satackey/action-docker-layer-caching#inputs notes.
patryk4815
Xeonacid