I would probably be breaking protocol for writing this way and I ask that the admins and users of the platform turn a blind eye to the unstructured tutorial ( not actually one, this is actually a story ) they are about to read.
As most of you realized that I had halted the tutorial of the reverse tcp program and the ransomware series ( Null Byte ).
With the ransomware series, I noticed that users were equipping programs with the very tutorial codes that I was posting and I kind of felt bad and guilty because in as much as I placed a disclaimer and note to detach myself from any federal prosecution, I knew there will always be the other guy on the other side of the world who would turn a blind eye and use the knowledge for malicious profit. This isn’t any theoretical garbage I came up with because I actually witnessed upcoming tutorial codes and ideas ( which I might have given out to enthusiasts ) being equipped with unix programs for malicious profit. I believe that if you are capable of violating and committing crime then you should be skilled enough to write your own programs. I know someone will probably say that without the work and time of others, we wouldn’t probably be where we are now in this technological world and that it stands out, everything we have is as a result of others. I in fact believe and agree with you on that idea but not when it comes to a self replicating program that can mimic Mirai and also cause mass destruction. I have therefore stopped the tutorials for the ransomware which I know isn’t going to cause a slow down in any computer crime because the world is growing faster and faster each day and that more sophisticated creations are been brought into reality. The bottom line is my codes won’t be the cause of another world outage.
With the reverse tcp: 
oh boy, hmm I had already written the program in advance and structured it into a framework where I implemented a lot of features like the remote importing, downloading, gaining root with escalation attacks, webcam, screenshot, spying, credentials stealing, etc. I therefore wanted to take users through the development process which was the idea behind the series. 
In the quest to make it fully supported across most linux distributions, I had to port it to various distributions to account for the different system designs and here the unfortunate happened : I messed up 
I unfortunately wiped the last virtual machine ( having the latest development of the program ) which was something I often did to save space ( limited hardware here please ) and to give way for the installation of other distributions. This brought me back to square -1 ( if it exists ) and honestly having your 6-8 months leisure project being thrown away like that is quite frustrating. Enough of the talking.
Users have been requesting the continuation of the series which I don’t even know how to continue since the project isn’t standalone anymore but now a framework. I was hoping someone today or anytime reading can take up the series which is the reason for the post. I’m giving out the last backed up file so that an interested party can take it up and help the community. I might help ( not guaranteed, life is getting busy ) once in a while.
I will only demonstrate some need to know general information about the project just to get interested parties started. Forgive me if I use images again and not commenting in my source code. Please read to the end for your benefit
ZeroSpy: https://github.com/sergeantexploiter/zero
Starting the Shell ( Attacker )
Hitting python zero.py in the directory starts the program.
NOTE: There was a scary banner before the prompt which I removed to save space for typing ( Was introduced in the destroyed VM version ). Hitting help prints the help screen. The script first checks for runnables. These are custom alias files that get loaded when the framework starts, maybe like start mutiple listeners on different ports instead typing them manually. Runnable files use same command codes just like the way you would type them in the terminal. The folder for runnables is located in the configurations folder. An example of a runnable is start_services which just starts multiple listeners. Runnables use a hash tag for comments.
Feel free to ticker with the commands, the one I’m demonstrating is the start_server command which accepts two parameters: the host and port ( as you already know ). Use localhost instead if you want to enter empty double/single strings for the host. It just helps the program display better.
We can accept multiple clients on one listener without disrupting the other connections on the same listening port
Connecting to the Shell ( Client/Victim )
The client script uses the connect.py file. The syntax is: python connect.py <host> <port>. The client uses an auto-connect function which reconnects should the connection fail.
Back to the Shell ( Attacker )
When a client is connected, we get something like this on our terminal.
This does not drop us directly into the shell but instead pushes it into the background in order to allow us continue what we’re doing without interruption ( Defaults idea ).
We can however list all connections with sessions
We can interact with the connected shell with the interact command followed by the session id.
When connected to a client, there are a whole new set of commands available ( which was where the development was taking place until dooms day without backup ).
The development commands were host-scanner ( needed threads ), check_vm ( needed more cross platform results ), webcam_list webcam_snap ( destroyed in VM wipeout ), retrieve-directory ( embedded in script but not shown screen - clones the given directory - made some progress but also wiped in VM destruction ), screenshot ( needed more libraries for older and bare distributions like lubuntu ). Encryption command ( restructured to use an inbuilt secure key for first data communication with attacker, DH-key exchange and AES-SHA256 for data transmission - wiped out ).
One would notice the shell ( session ) signature information after executing the sysinfo command.
The signature was first calculated and stored with all the hashing algorithms before the script was deployed. I don’t know if I implemented the checking feature at the attacker in the old version but the whole idea was to check the shell signature before accepting the connection. This was to help defend against tampering should the script be discovered, the script uses its own source code as its signature. The connection is supposed to drop if the signature doesn’t match. The feature can however be defeated if encryption for data transmission is not secure ( user can first get the signature and then send the same signature with a tampered script )
The client/victim script also has a self destruct feature ( sh() in script - commented out ) that was executed upon connecting for the first time. The feature used shred and should it not exist used an inbuilt shredding function ( which needs reviews as I believe is not secure ).
One more implemented but lost feature was the scalability. I had a seperate program that allowed the attacker to choose his own modules and compile them into the client script without having to use the entire client script. The client in turn after a successful connect, sent all available commands to the attacker
I know, call me lazy but after a client is disconnected, it fails to be removed at the attacker’s side even after a successful message printed. This can be fixed by removing the id from the connection array and session array variables in the zero.py.
CONCLUSION
I’ll be lurking around for some few nanoseconds before I disappear. Should anyone need clarifications or question, I’ll be willing to help.
I’m posting the files because others might need it and probably because I personally saw potential in the script. If I cannot continue doesn’t mean that someone else can’t sacrifice two nights to get my idea and continue from where I stopped. I see potential in this community. I’ve a pot belly now so I’m kinda lazy now adays. Until we meet again.
Sergeant