🔍 Advanced Nmap Service Scanner – Bash Script

This blog post introduces a powerful Bash script designed to automate and streamline network service scanning using Nmap. The script uses service-specific plugins, checks only open ports, logs results with timestamps, and outputs color-coded terminal feedback.

📂 View it on GitHub: github.com/ElusiveHacker/Tanker

🚀 Features

✅ Scans only open ports for efficiency
📜 Uses Nmap plugins/scripts tailored to each service
🎨 Color-coded terminal output:
- 🟡 Yellow for open ports
- 🔵 Blue for closed/filtered ports
📅 Start and end time displayed and logged
🕒 Total scan duration shown in the report
🗂️ Full report saved in scan_report.txt

⚙️ Requirements

A Linux/Unix system with bash installed
Nmap installed and in your $PATH

📦 Services Scanned

The script includes a pre-configured list of commonly scanned services:

Service	Port	Protocol	Nmap Script(s)
telnet	23	TCP	telnet-ntlm-info
ssh	22	TCP	ssh2-enum-algos
msrpc	135	TCP	msrpc-enum
nbstat	137	TCP	nbstat
ldap	389	TCP	ldap-rootdse
http	80	TCP	http-headers
smtp	25	TCP	smtp-open-relay, smtp-strangeport
wsman	5985	TCP	http-headers

🛠️ How to Use

1️⃣ Give execute permission and run the script:

chmod +x nmap_service_scanner.sh
./nmap_service_scanner.sh

2️⃣ When prompted, enter a valid IP or CIDR:

Enter an IP address or CIDR range: 192.168.1.0/24

📄 Output & Report

🖥️ Terminal output is color-coded for quick review
📝 All detailed results (including plugin output) are saved to scan_report.txt
⏱️ Includes:
- Start time
- End time
- Total duration in seconds

📌 Notes

➡️ UDP scans are slower and depend on the defined services. You can extend or modify the service list directly inside the script.

🧑‍💻 About

This tool was developed to simplify focused Nmap scanning for sysadmins, security testers, and red teams. Feel free to fork, improve, or suggest enhancements!

🔗 GitHub Repository: github.com/ElusiveHacker/Tanker

📜 License

This project is licensed under the MIT License.

03/05/2021

Solidity Smart Contract Upgradeability

Introduction

This article is going to focus on Smart Contract upgradability, why this important and how can we achieve it. When dealing with Smart Contracts we need to be able to upgrade our system code. This is because if security critical bugs appear , we should be able to remediate the bugs. We would also want to enhance the code and add more features. Smart Contract upgradability is not as simple as upgrading a normal software due to the blockchain immutability.

As already mentioned by design, smart contracts are immutable. On the other hand, software quality heavily depends on the ability to upgrade and patch source code in order to produce iterative releases. Even though blockchain based software profits significantly from the technology’s immutability, still a certain degree of mutability is needed for bug fixing and potential product improvements.

Preparing for Upgrades

In order to properly do the upgrade we should be focusing in the following aspects of the project:

Have money management strategies in place
Create a pause functionality
Have paths to upgrades

Switching addresses
Switching Oracles
Proxy contracts

The mentioned functionality is mandatory in order to properly maintain and do risk management on your system. The money management strategy has to do with were and how we hold the funds and the system data. The switch address is related to the proxy contract and the rest have to do with the flow paths we designed to upgrade the smart contracts [1].

Proxy Contract

The basic idea is using a proxy for upgrades. The first contract is a simple wrapper or "proxy" which users interact with directly and is in charge of forwarding transactions to and from the second contract, which contains the logic. The key concept to understand is that the logic contract can be replaced while the proxy, or the access point is never changed. Both contracts are still immutable in the sense that their code cannot be changed, but the logic contract can simply be swapped by another contract. The wrapper can thus point to a different logic implementation and in doing so, the software is "upgraded"

Note: This abstract proxy contract provides a fallback function that delegates all calls to another contract using the EVM instruction delegatecall. We refer to the second contract as the implementation behind the proxy, and it has to be specified by overriding the virtual _implementation function. Additionally, delegation to the implementation can be triggered manually through the _fallback function, or to a different contract through the _delegate function.

The most immediate problem that proxies need to solve is how the proxy exposes the entire interface of the logic contract without requiring a one to one mapping of the entire logic contract’s interface. That would be difficult to maintain, prone to errors, and would make the interface itself not upgradeable. Hence, a dynamic forwarding mechanism is required [1].

Proxy Setup

Below we can see that the contract proxy has one to one relationship with all the logic contract proxy. An this is important in order to understand that this setup kind of breaks the immutability of the blockchain.