is the version of capstone that we have in Kali not new enough for sickle?

After checking you are correct, the version currently installed in Kali will work perfectly. I made a couple changes, and verified sickle worked properly on a fresh Kali 2017.3 install.

Pushed some changes to the sickle. Thank you for your time.

To help speed up the process of evaluating the tool, please make sure to include the following information (the more information you include, the more beneficial it will for us):

• [Name] - The name of the tool
• [Version] - What version of the tool should be added?
  --- If it uses source control (such as git), please make sure there is a release to match (e.g. git tag)
• [Homepage] - Where can the tool be found online? Where to go to get more information?
• [Download] - Where to go to get the tool?
• [Author] - Who made the tool?
• [Licence] - How is the software distributed? What conditions does it come with?
• [Description] - What is the tool about? What does it do?
• [Dependencies] - What is needed for the tool to work?
• [Similar tools] - What other tools are out there?
• [How to install] - How do you compile it?
• [How to use] - What are some basic commands/functions to demonstrate it?

Absolutely, if there’s any other information that would help let me know. Below is the
requested info:

-[Name] - Sickle

-[Version] - 1.4

-[Homepage] - https://github.com/wetw0rk/Sickle

-[Download] - https://github.com/wetw0rk/Sickle.git

-[Author] - Milton Valencia (wetw0rk)

-[License] - MIT License

-[Description] - Sickle is a shellcode development tool created to speed up the various steps
needed to create functioning shellcode. Sickle aids the developer in:
identification of bad characters, formatting in multiple languages (python,
perl, powershell, etc), executing shellcode in both Linux and Windows environments,
comparing reversed shellcode to original, and disassemble shellcode into various
architectures (ARM-THUMB, x86-32, x86-64, etc).

-[Dependencies] - capstone (If used within Kali the existing version of capstone works out of the
box. Otherwise it’s recommended to install via pip3 pip3 install capstone)

-[Similar tools] - msfvenom, ndisasm, shellnoob

-[How to install] - git clone https://github.com/wetw0rk/Sickle.git
cd Sickle/ && chmod +x sickle.py && cp sickle.py /usr/bin/sickle
echo “Sickle installed!”

-[How to use] - Identification of instructions what result bad characters:
sickle -r shellcode -f python -v jumpcode -b "\x00" -c
Running shellcode (Sickle detects if Windows or Linux):
sickle -r shellcode -rs
Comparing shellcode:
sickle -r <my reverse shell> -e <original reverse shell>
Disassembly of shellcode (x86-64):
sickle -r reverse-shell -d -a x86 -m 64
Asciinema example:
https://asciinema.org/a/7vvVRjZGbY7OlqMsh6dBi7FDU

I also went ahead and added screenshots.

I went ahead and added a git tag as well: https://github.com/wetw0rk/Sickle/releases/tag/v1.4

thanks

@g0tmi1k I recently released v1.5 the git tag is here:

https://github.com/wetw0rk/Sickle/releases/tag/v1.5

The only notable change is the compare function.

Thanks

Whenever a new change is made do we need to release a new tag?

Not for every change necessarily, but if you consider a new change worth a new release, then you should.

It depends on your idea of versioning.

If it's a bug change, you could do v1.5.1, if it's enough to be considered a new release, you could do v1.6. If it's massive changes, then possibly 2.0.

Alright sweet in that case I went ahead and added a new release tag https://github.com/wetw0rk/Sickle/releases/tag/v1.6

Syntax, Running Shellcode in 64bit, and Comparing shellcode has changed. Running shellcode in 64bit is more reliable thanks to contributor luoyeah, and comparing shellcode has dramatically changed since 1.5 (ASM and Opcodes vs just opcodes). Examples below:

Identification of instructions what result bad characters:
sickle -r shellcode -f python -v jumpcode -b "\x00" -c
Running shellcode (Sickle detects if Windows or Linux):
sickle -r shellcode -rs
Comparing shellcode:
sickle -r <my reverse shell> -e <original reverse shell>
Disassembly of shellcode (x86-64):
sickle -r reverse-shell -a x86_64 -d
Asciinema example:
https://asciinema.org/a/7vvVRjZGbY7OlqMsh6dBi7FDU

v2 release ◝(⁰▿⁰)◜

https://github.com/wetw0rk/Sickle.git

@kali-team, please could this be packaged up.
@author, If you want to help the packaging process, you can check the documentation here ~ https://www.kali.org/docs/development/public-packaging

Recently pushed v2.0.2 below is usage with the new module layout:

-[Name] - Sickle

-[Version] - 2.0.2

-[Homepage] - https://github.com/wetw0rk/Sickle

-[Download] - https://github.com/wetw0rk/Sickle.git

-[Author] - Milton Valencia (wetw0rk)

-[License] - MIT License

-[Description] - Sickle is a payload development tool originally created to aid in crafting shellcode, however it can be used in crafting payloads for other exploit types as well (non-binary). Although the current modules are mostly aimed towards assembly this tool is not limited to shellcode.

-[Dependencies] - capstone

-[Similar tools] - msfvenom, ndisasm, shellnoob

-[How to install] - git clone https://github.com/wetw0rk/Sickle.git && cd Sickle/ && python3 setup.py install

-[How to use] -

Help:
sickle -h
List Modules:
sickle -l
Diff module:
sickle -i -m diff # help (applys to all modules)
sickle -r <bin1> -m diff BINFILE=<bin2> MODE=hexdump
sickle -r <bin1> -m diff BINFILE=<bin2> MODE=byte
sickle -r <bin1> -m diff BINFILE=<bin2> MODE=asm
sickle -r <bin1> -m diff BINFILE=<bin2> MODE=raw
Format module (default module):
sickle -i # list formats
sickle -r <bin> -f <format>

Drafted package is available: https://gitlab.com/Arszilla/sickle

I have uploaded the tool. I had to rename it (sickle-tool) because the name sickle is already used by another Debian package.