| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Some code previously assumed a Symtbl's base value to always be zero.
This was often the case, however the assumption would break (for example)
when attempting to rebase() a mapped Symtbl.
As of the previous patch enabling freer modification of base, the
potentiality of these bugs will be higher.
Signed-off-by: Malfurious <m@lfurio.us>
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
Lift restriction (name mangling) to Payload helper functions, as their
use will be useful in Payload subclasses.
Signed-off-by: Malfurious <m@lfurio.us>
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
This is just a slight code reduction, but will make any future code
simpler as well. Explicit comparision to None is more correct as well;
centralizing this for reuse better justifies the wordier if statement.
Signed-off-by: Malfurious <m@lfurio.us>
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
Given the current design of Symtbl, creating subclasses of it gets more
tedious the further one goes down a potential class hierarchy. As I am
planning to introduce new features in the future that explicitly extend
Payload, make this change now to minimize the impact.
Additionally, switching Payload's relationship with Symtbl from "is-a"
to "has-a" makes it more consistent with rev.ELF, the other major user
of Symtbl. (And in both cases, the member is named 'sym')
Signed-off-by: Malfurious <m@lfurio.us>
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
Often times, users of the Payload module wish to push a list of integers
to a payload buffer. Currently, the best (and intended) way to do this
is to make several calls to .int(). However, as part of the ROP effort,
I am planning to add function 'gadget(addr, *params)' to the Payload
class. Per the design of this function, calling it with an expanded
list of values would be equivalent to passing each to .int()
individually. In order to discourage the use of .gadget(), as a
shortcut to a series of .int()s, .int(), and most other insertion
functions, now accept arbitrarily many value arguments.
Functions that support additional options (such as .int()'s 'signed'
parameter) will apply such options to all values. If a symbol name is
defined, it will reference the beginning of the block of values.
Keep in mind, this will also allow inserting zero values. For example,
obj.bin(sym='end') will tag the end of the payload without extending its
content. This use-case is not intended to be particularly useful, but
exists as a consequence of the change.
Payload.rep() and the pad functions are not affected by this commit, as
I don't think changing their semantics in this way makes sense.
Signed-off-by: Malfurious <m@lfurio.us>
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
The design/implementation of class Payload is updated for better
compatibility with Symtbl, and to address some usability issues that
have come up so far:
No more automatically fixed-up stack alignment by default: In fact,
alignment as a concept is fully removed from the tool, in preparation
for another upcoming ROP-centric addon to Payload. Therefore, insertion
of return addresses (via .ret()) are now equivalent to any other integer
value.
No instance size value: Each call to .pad() uses an independent size
passed as a parameter, but functions in the same manor as before.
Padding can also now be inserted at the beginning of the payload:
.pad_front() prepends the necessary amount of data, and updates the
tracked offsets of values that were already inserted to the payload.
Payload now directly extends Symtbl: Instead of possessing a Symtbl
member, payload objects can directly be treated as symbol tables for
things like mounting them as subtables, or mapping them to access
absolute addresses.
New call syntax to access binary data: As a shorthand, users may now
use the call syntax to get the bytes string built by the tool. If an
argument is passed, it is another byte string containing illegal bytes
that we check the built payload for. Unfortunately, the __str__ magic
func doesn't like returning bytes string; plus, that overload is already
in use for formatting the symbol table content (worth not hiding).
New semantic insertion functions: .bin(), .str() [C-style strings],
.int(), .ret(), and more. Some of these functions are direct synonyms,
however their use can provide more clarity in Sploit scripts.
Smarter default element symbol names: Instead of just using '_' as a
placeholder if no symbol name is ever given, we now uniquely name each
inserted element according to the API function that was used, then slap
on an incrementing number. An explicit name still bypasses this scheme.
Insertion functions can now be chained together: Functions previously
returned the offset/address of the inserted value. However, this
feature was seldom used, and there is now the possibility of
.pad_front() invalidating previously-returned offsets. Instead,
functional-style chaining is enabled to reduce boilerplate, and help
with quick oneliners.
Signed-off-by: Malfurious <m@lfurio.us>
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
class Payload is a tool for constructing stack-smash payloads and ROP
chains. Its design is intended to abstract away some of the more
tedious details of crafting a payload.
Payload utilizes mem.Symtbl internally to optionally manage a collection
of named offsets into its own buffer (these are usually in reference to
entities appended to the payload via its main API). Alternatively, the
API calls to append any entity will return the address of that entity as
well.
Returned (and looked-up) addresses are relative to the beginning of the
payload by default. However, when the payload is constructed with a
known base address value, these become absolute. This is useful for
reusing addresses later in the payload body.
class Placeholder is designed to be functionally compatible with
bytearrays and bytestrings. When constructed, they take the value of
'zero', according to the current arch config. This facility enables
some API's to detect whether a dummy value was passed as a required
argument when said argument _may_ be unnecessary in niche situations.
Signed-off-by: Malfurious <m@lfurio.us>
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
