fix(packing): dd() raises TypeError on a bytearray destination - #2772

dd() lists bytearray among its supported destination types, and has an explicit isinstance(dst, ..., bytearray) branch for it, but every bytearray destination raises TypeError on 4.15.0.

>>> from pwn import *
>>> dd(bytearray(b'Hello!'), b'?', skip=5)
Traceback (most recent call last):
  ...
    dst[skip : skip + len(src)] = list(map(p8, bytearray(src)))
    ~~~^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: 'bytes' object cannot be interpreted as an integer

The cause is the shared list/bytearray branch at

The fix assigns the byte string src directly when the destination is a bytearray. Every src branch above the destination dispatch, at packing.py:1039-1089, has already reduced src to a byte string, so the slice assignment is always valid, and this makes a bytearray destination agree with the bytes and str destinations, which already copy src verbatim. dd(bytearray(b'Hello!'), b'?', skip=5) now returns bytearray(b'Hello?') and updates the caller's buffer in place, which is what the "If dst is a mutable type it will be updated" contract in the docstring promises.

Testing

The new doctest in the dd() docstring covers both the returned value and the in-place update. Run the way CI runs it, on the touched module only:

$ PWNLIB_NOTERM=1 python -bb -m sphinx -b doctest docs/source docs/build/doctest docs/source/util/packing.rst
71 tests in 1 items.
71 passed and 0 failed.
Test passed.

Reverting only the one-line code change and keeping the new doctest gives 69 passed and 2 failed, with TypeError: 'bytes' object cannot be interpreted as an integer on dd(buf, b'?', skip = 5) and bytearray(b'Hello!') instead of bytearray(b'Hello?') on the follow-up check, so the doctest is a real regression test rather than a restatement of the new behaviour.

flake8 . --count --select=E9,F63,F7,E71 --show-source --statistics --exclude=android-?dk reports 0, and pylint --exit-zero --errors-only pwnlib/util/packing.py -f parseable produces output identical to stable at 7e5e79d, so the PyLint job sees no new errors. Ran on macOS 15 with Python 3.11.9 and Sphinx 8.2.3.

Target Branch

This targets stable because the crash is present in the released 4.15.0 and in beta and dev as well, which the PR template maps to a stable bug fix.