diff options
author | dusoleil <howcansocksbereal@gmail.com> | 2023-03-13 09:18:41 -0400 |
---|---|---|
committer | dusoleil <howcansocksbereal@gmail.com> | 2023-03-13 18:28:47 -0400 |
commit | 0b7f6eba62c93c53c0adc9eda6c8fffb507b8fdd (patch) | |
tree | 90283244b3f435c773722c062f836b1caaa0fc56 /hooks | |
parent | 4b9c5eb4b98a2898b746bfcee8febb02580d7b43 (diff) | |
download | sploit-0b7f6eba62c93c53c0adc9eda6c8fffb507b8fdd.tar.gz sploit-0b7f6eba62c93c53c0adc9eda6c8fffb507b8fdd.zip |
arch: refactor byte/int conversions
The built in int's to_bytes and from_bytes functions have some weird
behavior with the signed parameter. Rather than expecting the user to
properly give btoi/itob the right signed value to pass through to
to_bytes/from_btyes, it makes more sense to just always convert an
unsigned number. Using the new int conversions, this can always be
unambiguous with respect to the width of the int.
There may also be situations where a user would like to truncate/sign
extend an int to a certain length other than the configured architecture
wordsize or convert to a different endianness. These are now
parameterized. There is no need to parameterize the width for btoi
because you will now always get an unsigned int back (and because of
python, the width is ambiguous). The user can convert it to whatever
width/sign they want after the fact with the new int conversion methods.
This also means that payload's int() does not need to take a signed
argument either. Whatever sign of int you give it, when it calls itob,
it will get the correct bytearray at the width of the configured
architecture's wordsize.
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
Reviewed-by: Malfurious <m@lfurio.us>
Diffstat (limited to 'hooks')
0 files changed, 0 insertions, 0 deletions