nsploit/sploit/rev, branch master Process interaction tool for software exploitation Rename sploit package to nsploit 2025-01-05T04:54:51+00:00 Malfurious m@lfurio.us 2025-01-03T00:17:34+00:00 0f00627964a4b2e515108401fa2cfe94600ad648 Rename all affected files, references to file paths, and module imports within the code. Since this line of development represents a fork from the original sploit, a name change is seen as necessary to distinguish the projects, as well as allow them to be installed side by side. What does the "n" mean? Great question! You can think of it as meaning "new sploit" if you want, though that's not quite intended. The name is simply distinct and easy to pronounce. I had originally settled on "msploit" (something along the lines of "Malf's sploit"), but this name is too close to "metasploit" for me - and N is right next to it on the keyboard. Signed-off-by: Malfurious <m@lfurio.us> 
Rename all affected files, references to file paths, and module imports
within the code.  Since this line of development represents a fork from
the original sploit, a name change is seen as necessary to distinguish
the projects, as well as allow them to be installed side by side.

What does the "n" mean?  Great question!  You can think of it as meaning
"new sploit" if you want, though that's not quite intended.  The name is
simply distinct and easy to pronounce.  I had originally settled on
"msploit" (something along the lines of "Malf's sploit"), but this name
is too close to "metasploit" for me - and N is right next to it on the
keyboard.

Signed-off-by: Malfurious <m@lfurio.us>
Update ROP gadget types to extend IndexEntry 2025-01-01T12:08:49+00:00 Malfurious m@lfurio.us 2024-02-01T09:45:26+00:00 f6941e9a9cd75be539714d361a6f4ceb88450515 This leverages some code reuse and helps these types play nicely with the new Symtbl updates. Signed-off-by: Malfurious <m@lfurio.us> 
This leverages some code reuse and helps these types play nicely with
the new Symtbl updates.

Signed-off-by: Malfurious <m@lfurio.us>
log: Move to sploit.util package 2024-01-13T22:22:12+00:00 Malfurious m@lfurio.us 2024-01-12T21:26:03+00:00 074a15310b8bbeeeeb00bf5ab5877c12f1ca1861 Signed-off-by: Malfurious <m@lfurio.us> 
Signed-off-by: Malfurious <m@lfurio.us>
util: Promote from module to package 2024-01-13T22:22:12+00:00 Malfurious m@lfurio.us 2024-01-12T19:28:26+00:00 ead4ec1340555569e00919891383e05dca839b01 We would like to move additional modules under the namespace of "util" to clean up the top-level "sploit" package. To start, the functions from the previous util module are moved. Given the package is named "util" the module is renamed to "cmd" to somewhat match the theme of the contained functions. Per the previous commits, these functions are now exposed via the util package as well. Signed-off-by: Malfurious <m@lfurio.us> 
We would like to move additional modules under the namespace of "util"
to clean up the top-level "sploit" package.  To start, the functions
from the previous util module are moved.  Given the package is named
"util" the module is renamed to "cmd" to somewhat match the theme of the
contained functions.

Per the previous commits, these functions are now exposed via the util
package as well.

Signed-off-by: Malfurious <m@lfurio.us>
rev: Expose modules' contents through package 2024-01-13T22:22:12+00:00 Malfurious m@lfurio.us 2024-01-12T11:34:38+00:00 0e028487596091afb3ea1035f7f78ef7661c9c6e This is the start of an overarching change meant to simplify sploit library imports. In general, all packages (directories) are intended to export all the classes, methods, and variables of their contained modules. This way users need only import the package, which leads to less verbose import statements (and usually fewer import statements). We would still like to gate objects behind their respective packages, rather than providing the whole world with `from sploit import *` so that users can still have some amount of control over what is brought into their global namespace. Beware: For code internal to sploit, full module imports should probably continue to be used. Otherwise, there is a possibility for circular imports if two modules from two packages cross import. Signed-off-by: Malfurious <m@lfurio.us> 
This is the start of an overarching change meant to simplify sploit
library imports.  In general, all packages (directories) are intended to
export all the classes, methods, and variables of their contained
modules.  This way users need only import the package, which leads to
less verbose import statements (and usually fewer import statements).

We would still like to gate objects behind their respective packages,
rather than providing the whole world with `from sploit import *` so
that users can still have some amount of control over what is brought
into their global namespace.

Beware: For code internal to sploit, full module imports should probably
continue to be used.  Otherwise, there is a possibility for circular
imports if two modules from two packages cross import.

Signed-off-by: Malfurious <m@lfurio.us>
r2: Don't return duplicate gadgets in gadget search 2023-03-24T07:50:55+00:00 dusoleil howcansocksbereal@gmail.com 2023-03-23T08:07:28+00:00 61971e65dd280c84e4c4e06e86f0c4ba1aed03aa Signed-off-by: dusoleil <howcansocksbereal@gmail.com> Reviewed-by: Malfurious <m@lfurio.us> 
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
Reviewed-by: Malfurious <m@lfurio.us>
r2: Get all relocs that have a name 2023-03-23T12:19:34+00:00 dusoleil howcansocksbereal@gmail.com 2023-03-23T12:19:34+00:00 e313b0eb10278ddc3cfdb42baa100fa8f60aba61 Originally I was deciding whether to get a reloc based on the type. I'm not sure what SET_64 vs ADD_64 means, but the SET* types seemed to be the only symbols we care about. After running into a binary where a SET* symbol didn't have a name (and crashed sploit), I have decided to filter on that instead. Signed-off-by: dusoleil <howcansocksbereal@gmail.com> 
Originally I was deciding whether to get a reloc based on the type.  I'm
not sure what SET_64 vs ADD_64 means, but the SET* types seemed to be
the only symbols we care about.  After running into a binary where a
SET* symbol didn't have a name (and crashed sploit), I have decided to
filter on that instead.

Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
rev: Use json output for get_bin_info() 2023-03-23T07:45:20+00:00 dusoleil howcansocksbereal@gmail.com 2023-03-23T07:45:20+00:00 f388499a625af89e56669a8c76c65da21a7c1b1a Grabbing the json and returning that dict directly avoids all of the processing we were doing before. I also added in a small, temporary band-aid for PE files until we add actual support for them. The 'relro' key doesn't exist on PE files, so just default it to '' in ELF. Signed-off-by: dusoleil <howcansocksbereal@gmail.com> 
Grabbing the json and returning that dict directly avoids all of the
processing we were doing before.  I also added in a small, temporary
band-aid for PE files until we add actual support for them.  The 'relro'
key doesn't exist on PE files, so just default it to '' in ELF.

Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
r2: Rewrite get_elf_symbols() 2023-03-23T07:23:18+00:00 dusoleil howcansocksbereal@gmail.com 2023-03-23T07:23:18+00:00 382737c817a172a03b054bcc447437019eabcfb3 This addresses a couple issues with get_elf_symbols(). First of all, we can greatly simplify our processing of the r2 output by getting back json instead of trying to do string processing on their pretty-printed tables. This resolves a number of issues we were running into and also makes the code way more maintainable. Second, we have reevaluated what we actually want to get out of r2. We now grab section offsets, all FUNC, OBJ, and NOTYPE symbols, and all strings. The strings and section offsets no longer try to escape special characters and sometimes aren't accessible through normal object attributes, but now that we have dictionary subscripting, this isn't an issue. Lastly, a few subsets of the symbols are separated into their own tables and added to the main table as subtables. Sections are located at sym.sect and offset at 0. Imported symbols are located at sym.imp and are offset at sect['.plt']. Relocations are located at sym.rel and are offset at sect['.got']. Strings are located at sym.str and are offset at sect['.rodata']. Signed-off-by: dusoleil <howcansocksbereal@gmail.com> 
This addresses a couple issues with get_elf_symbols().

First of all, we can greatly simplify our processing of the r2 output by
getting back json instead of trying to do string processing on their
pretty-printed tables.  This resolves a number of issues we were running
into and also makes the code way more maintainable.

Second, we have reevaluated what we actually want to get out of r2.  We
now grab section offsets, all FUNC, OBJ, and NOTYPE symbols, and all
strings.  The strings and section offsets no longer try to escape
special characters and sometimes aren't accessible through normal object
attributes, but now that we have dictionary subscripting, this isn't an
issue.

Lastly, a few subsets of the symbols are separated into their own tables
and added to the main table as subtables.  Sections are located at
sym.sect and offset at 0.  Imported symbols are located at sym.imp and are
offset at sect['.plt'].  Relocations are located at sym.rel and are offset at
sect['.got'].  Strings are located at sym.str and are offset at
sect['.rodata'].

Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
r2: limit gadget search to exec privilege sections 2023-03-19T13:26:08+00:00 dusoleil howcansocksbereal@gmail.com 2023-03-19T13:26:08+00:00 e4793b798fe84c856c76817814b3867d3ce7b85e Signed-off-by: dusoleil <howcansocksbereal@gmail.com> 
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>