HackingTool — 보안 연구·펜테스트 도구를 한 CLI에서 묶는 오픈소스 오케스트레이터

HackingTool은 개별 보안 도구를 직접 구현하기보다, 여러 오픈소스 보안 도구의 설치·실행·업데이트·프로젝트 페이지 접근을 터미널 메뉴로 묶는 Python 기반 CLI 래퍼입니다. 저장소의 README는 v2.0.0 기준 Python 3.10+, 20개 카테고리, 185개 이상의 도구, 19개 태그 필터, 검색·추천·일괄 설치·Docker 실행을 핵심 변화로 제시합니다.

분석 기준: 2026-04-26에 GitHub 저장소의 README, 코드 구조, 이미지 자산, Issues/PR 표면,
hackingtool.py, core.py, config.py, constants.py,
os_detect.py, Dockerfile, docker-compose.yml,
주요 tools/*.py 모듈을 확인했습니다.
별도 Wiki는 저장소 루트로 리다이렉트되었고, GitHub 내 별도 Discussion 탭은노출되지 않았습니다.

안전 범위: 이 문서는 프로젝트 구조와 방어적·승인된 보안 테스트 관점의 분석입니다.
제3자 시스템, 운영 환경, 무단 네트워크에 대한 실행 절차는 다루지 않습니다.

 

Quick Links

항목	링크	비고
Repository / README	https://github.com/Z4nzu/hackingtool	공식 GitHub 저장소
README 원문	https://github.com/Z4nzu/hackingtool/blob/master/README.md	v2.0.0 기능·설치·카테고리 요약
이미지 자산	https://github.com/Z4nzu/hackingtool/tree/master/images	저장소 내 PNG UI 스크린샷 및 SVG 로고
Auto-generated docs	https://www.mintlify.com/Z4nzu/hackingtool/reference/tool-list	Mintlify 자동 생성 문서. README보다 오래된 100+ tools / 17 categories 기준으로 보여 최신성과 차이가 있습니다.
Issues	https://github.com/Z4nzu/hackingtool/issues	Tool Request와 버그/기능 요청이 주류
Pull Requests	https://github.com/Z4nzu/hackingtool/pulls	문서·기능 개선 PR 흐름 확인 가능
Demo	https://github.com/Z4nzu/hackingtool/tree/master/images	별도 데모 영상 링크는 확인되지 않았고, 저장소의 UI 스크린샷이 데모 역할을 합니다.
Paper	없음	논문 링크는 저장소/README에서 확인되지 않았습니다.

Key Features

1. 20개 카테고리 중심의 터미널 메뉴

프로젝트의 1차 사용 경험은 hackingtool.py가 렌더링하는 터미널 메뉴입니다. 최신 코드에서는 Rich 기반 패널과 표를 사용하고, README는 20개 카테고리와 185개 이상의 도구를 강조합니다. 저장소의 PNG 스크린샷은 구 버전 배너(v1.1.0)를 포함하지만, 카테고리 기반 UX를 설명하는 대표 자산으로 유효합니다.

캡션: 저장소 images/A.png에서 수집한 메인 메뉴 예시입니다. Anonymously Hiding, Information Gathering, Wireless Attack, Web Attack, Forensics, Payload Creation 등 주요 보안 도구 카테고리를 한 화면에서 선택하는 구조를 보여줍니다.

2. 카테고리별 도구 목록과 설명 테이블

각 카테고리는 HackingToolsCollection으로 표현되며, 내부에는 개별 HackingTool 인스턴스가 들어갑니다. 사용자는 카테고리를 선택한 뒤 도구명, 설명, 설치 상태를 보고 세부 작업 메뉴로 진입합니다. 예를 들어 Information Gathering 카테고리에는 Nmap, Dracnmap, port scanning, Host to IP, RED HAWK, ReconSpider, SecretFinder 등 정찰·OSINT 계열 도구가 묶여 있습니다.

 

캡션: 저장소 images/AAA.png에서 수집한 정보수집 도구 목록입니다. 네트워크 발견, 웹/도메인 정보수집, OSINT, 노출 정보 탐색 계열 도구가 하나의 표로 정리됩니다.

Wireless Attack 카테고리도 같은 패턴을 사용합니다. 다만 무선 공격·피싱·DDoS·RAT·Post Exploitation·Payload Creation 등 고위험 카테고리가 포함되므로, 교육용 격리 랩과 승인된 범위가 필수입니다.

 

캡션: 저장소 images/AAAA.png에서 수집한 무선 보안 도구 목록입니다. 무선 랩 환경에서만 검토해야 하는 도구들이 카테고리 메뉴로 노출되는 모습을 보여줍니다.

3. 개별 도구 단위의 Install / Run / Update / Open Folder 작업

core.py의 HackingTool 기본 클래스는 INSTALL_COMMANDS, RUN_COMMANDS, PROJECT_URL, SUPPORTED_OS, TAGS 같은 메타데이터를 기반으로 도구별 작업 메뉴를 구성합니다. 기본 액션은 설치, 실행, 업데이트, 설치 폴더 열기이며, 프로젝트 URL이 있으면 브라우저에서 upstream 저장소를 여는 옵션도 제공합니다.

 

캡션: 저장소 images/AAAAA.png에서 수집한 개별 도구 액션 메뉴입니다. 특정 도구를 선택하면 설치, 실행, 프로젝트 페이지 열기, 상위 메뉴 복귀 같은 작업이 제공됩니다.

4. 검색, 태그 필터, 자연어형 추천

README의 Quick Commands는 /query, t, r, ?, q, 97, 99를 핵심 조작으로 제시합니다. 코드상 search_tools()는 도구명·설명·태그에서 문자열을 검색하고, _get_all_tags()는 도구명과 설명을 정규식 규칙으로 분석해 osint, scanner, web, cloud, mobile, active-directory, credentials 같은 태그 인덱스를 구성합니다. _RECOMMENDATIONS는 “scan a network”, “pentest web application”, “pentest cloud”, “forensic analysis” 같은 작업 의도를 태그 묶음으로 매핑합니다.

5. 설치 상태 표시와 일괄 설치

core.py의 is_installed 속성은 실행 명령의 첫 바이너리가 PATH에 있는지, 또는 git clone 대상 디렉터리가 존재하는지 확인합니다. 카테고리 목록에서는 설치된 도구와 미설치 도구를 상태 기호로 표시하고, 카테고리 내 미설치 도구가 있으면 97번으로 일괄 설치를 시도할 수 있습니다. 이 기능은 랩 환경 구성 자동화에는 편리하지만, 운영 장비에서 무분별하게 실행하면 의존성 충돌·권한 문제·예상치 못한 외부 코드 설치를 초래할 수 있습니다.

6. OS-aware 메뉴와 환경 감지

os_detect.py는 Linux/macOS/Windows, 배포판 ID, 패키지 매니저, WSL 여부, 아키텍처, root 여부를 자동 감지합니다. HackingToolsCollection._active_tools()는 현재 OS와 도구의 SUPPORTED_OS를 비교해 호환되지 않는 도구를 숨깁니다. macOS는 부분 지원으로 간주되며, Windows는 네이티브 실행보다 WSL2 또는 Linux 계열 환경이 안내됩니다.

7. 외부 도구 설치·업데이트를 위한 얇은 래퍼 구조

HackingTool의 핵심은 자체 취약점 스캐너가 아니라 “도구 카탈로그 + 실행 래퍼”입니다. tools/*.py 파일들은 개별 도구마다 upstream 저장소, 설치 명령, 실행 명령, 지원 OS를 선언합니다. 업데이트는 git pull, pip install --upgrade, go install, gem update 같은 설치 방식별 휴리스틱으로 처리됩니다. 이 구조는 확장성이 좋지만, 명령이 대부분 raw shell 문자열이므로 프로덕션급 안전성을 확보하려면 명령 검증, 버전 pinning, allowlist, 서명 검증, 감사 로그가 필요합니다.

8. Docker 및 Compose 기반 실행 경로

Dockerfile은 kalilinux/kali-rolling:latest를 기반으로 Git, Python, pip, curl, wget, PHP 등을 설치한 뒤 python3 /root/hackingtool/hackingtool.py를 ENTRYPOINT로 실행합니다. docker-compose.yml은 기본 컨테이너와 dev profile을 제공하고, /root/.hackingtool를 볼륨으로 유지해 런타임에 설치한 도구 데이터를 컨테이너 재시작 후에도 보존하도록 구성합니다.

9. 기여 워크플로

README는 새 도구 제안을 [Tool Request] ToolName — Category 형식의 Issue로 올리고, PR은 tools/*.py에 클래스, TITLE, DESCRIPTION, 설치·실행 명령, 지원 OS, 테스트 여부를 포함하도록 요구합니다. 즉, 프로젝트 확장은 “새 도구 메타데이터를 카테고리 모듈에 추가하는 방식”에 가깝습니다.

수집 이미지 매핑

저장소 원본	저장 경로	설명
images/A.png	figures/main_menu_v1.png	메인 메뉴 및 카테고리 선택 화면
images/AA.png	figures/category_anonymously_hiding.png	Anonymously Hiding 카테고리 목록
images/AAA.png	figures/category_information_gathering.png	Information Gathering 카테고리 목록
images/AAAA.png	figures/category_wireless_attack.png	Wireless Attack 카테고리 목록
images/AAAAA.png	figures/tool_action_menu_anonsurf.png	개별 도구 액션 메뉴
분석 기반 생성	figures/architecture.png	코드 구조를 바탕으로 재구성한 아키텍처 다이어그램

Tech Stack

영역	기술 / 버전	분석 메모
Core language	Python 3.10+	README와 hackingtool.py, install.py에서 Python 3.10 이상을 요구합니다.
Terminal UI	Rich >=13.0.0	requirements.txt의 유일한 런타임 Python 패키지입니다. 패널, 테이블, 프롬프트, 테마를 담당합니다.
Shell automation	Bash	install.sh, update.sh가 전역 설치, venv 구성, 업데이트를 담당합니다.
Container	Docker, Docker Compose	Kali rolling 기반 이미지와 persistent volume을 제공합니다.
Base image	kalilinux/kali-rolling:latest	보안 도구 의존성 확보에 유리하지만, reproducibility 측면에서는 digest pinning이 없습니다.
External language runtimes	Go 1.21+, Ruby, Java, PHP	여러 외부 도구가 Go/Ruby/Java/PHP 런타임 또는 패키지 매니저를 요구합니다.
Supported OS	Linux 중심, macOS 부분 지원	Kali/Parrot/Ubuntu 계열이 자연스러운 대상입니다. 일부 무선·네트워크 도구는 Linux 전용입니다.
Package managers	apt-get, pacman, dnf, zypper, apk, brew, pkg	os_detect.py가 패키지 매니저를 탐지하고 필요한 core package 목록을 매핑합니다.
Repository language mix	Python 중심, Shell, Dockerfile	GitHub 언어 통계 기준 Python 비중이 압도적이며, Shell/Dockerfile은 설치·컨테이너 계층입니다.
License	MIT	저장소 루트에 MIT 라이선스가 있습니다. 단, 포함/설치되는 외부 도구의 라이선스는 별도 확인이 필요합니다.

Architecture

캡션: 저장소 README와 주요 소스 파일을 바탕으로 작성한 분석용 아키텍처 다이어그램입니다. HackingTool은 hackingtool.py의 메뉴 진입점, core.py의 공통 도구/컬렉션 추상화, `tools/.py의 카테고리별 래퍼,~/.hackingtool/tools`의 외부 도구 설치 위치로 구성되는 오케스트레이션 레이어입니다.*

핵심 흐름

1. 사용자가 터미널에서 hackingtool을 실행합니다.
2. hackingtool.py가 Python 버전을 검사하고, Rich UI로 헤더·카테고리 메뉴·검색/태그/추천 인터페이스를 렌더링합니다.
3. tool_definitions와 all_tools가 20개 카테고리 객체를 로드합니다.
4. 각 카테고리는 HackingToolsCollection이며, 각 도구는 HackingTool입니다.
5. 개별 도구는 INSTALL_COMMANDS, RUN_COMMANDS, PROJECT_URL, SUPPORTED_OS, REQUIRES_* 메타데이터를 갖습니다.
6. 설치·실행·업데이트는 대부분 외부 저장소 clone, package manager, pip/go/gem 설치, 또는 바이너리 실행으로 위임됩니다.
7. config.py, constants.py, os_detect.py가 사용자 경로, 버전, 설치 위치, OS/패키지 매니저 정보를 보조합니다.
8. Docker 경로에서는 Kali 기반 컨테이너 안에서 동일한 Python CLI를 ENTRYPOINT로 실행합니다.

설계상 강점

• 도구 추가가 비교적 단순합니다. 새 class를 tools/*.py에 넣고 카테고리의 TOOLS 리스트에 추가하면 됩니다.
• CLI 메뉴, 설치 상태, 업데이트 흐름이 공통 base class에 묶여 있어 도구별 중복 코드가 줄어듭니다.
• OS 호환성 메타데이터와 현재 OS 감지를 통해 macOS/WSL/Linux 차이를 어느 정도 반영합니다.
• Docker 실행 경로가 있어 호스트 환경을 직접 오염시키지 않는 랩 구성이 가능합니다.

설계상 한계와 리스크

• 외부 도구 설치 명령이 raw shell 문자열이며, 버전 pinning이 부족합니다. 동일한 명령이 시간이 지나며 다른 결과를 낼 수 있습니다.
• 일부 설치 경로는 root 권한 또는 전역 경로(/usr/share/hackingtool, /usr/bin/hackingtool)를 사용합니다.
• 도구 카탈로그에 피싱, DDoS, RAT, payload, post-exploitation 범주가 포함되어 있어 권한·목적·대상 검증이 없는 자동화와 결합하면 위험합니다.
• 설치 상태 확인은 PATH와 clone 디렉터리 존재 여부 중심의 휴리스틱입니다. 실제 버전·무결성·정상 작동 여부를 보장하지 않습니다.
• SBOM, signature verification, dependency lockfile, audit log, policy gate, dry-run 모드가 기본 제공되지 않습니다.

Usage & Setup

운영 장비가 아니라 격리된 VM, Docker, 또는 승인된 보안 테스트 랩에서만 검토하는 것이 적절합니다. 특히 원격 스크립트를 sudo로 파이프 실행하는 방식은 편리하지만, 실행 전 install.sh 내용을 직접 검토하는 절차가 필요합니다.

One-liner 설치

curl -sSL https://raw.githubusercontent.com/Z4nzu/hackingtool/master/install.sh | sudo bash
hackingtool

수동 설치

git clone https://github.com/Z4nzu/hackingtool.git
cd hackingtool
sudo python3 install.py
hackingtool

Docker 실행

# Build
docker build -t hackingtool .

# Direct run
docker run -it --rm hackingtool

# Compose run
docker compose up -d
docker exec -it hackingtool bash

# Dev mode with live source mount
docker compose --profile dev up
docker exec -it hackingtool-dev bash

# Stop
docker compose down
docker compose down -v

실행 후 메뉴 흐름

• 메인 메뉴: 카테고리 선택, /query 검색, t 태그 필터, r 추천, ? 도움말, q 종료.
• 카테고리 메뉴: 도구 선택, 97 카테고리 내 미설치 도구 일괄 설치, 99 뒤로가기.
• 도구 메뉴: Install, Run, Update, Open Folder, Open Project Page.

캡션: 저장소 images/AA.png에서 수집한 카테고리 화면입니다. 선택한 카테고리 내 도구 목록을 표로 보여주고, 사용자는 도구 번호를 입력해 세부 액션 메뉴로 이동합니다.

Personal Insights

의료 AI 관점

의료 AI 시스템은 모델 자체보다 배포 환경, 데이터 파이프라인, API, 인증, 로그, 네트워크 경계에서 보안 문제가 자주 발생합니다. HackingTool은 의료 AI 전용 도구는 아니지만, “여러 검증 도구를 카탈로그화하고 랩에서 실행하는 CLI 오케스트레이터”라는 패턴은 병원 내부 AI 서비스, FHIR API, DICOM/PACS 네트워크, 모델 서빙 엔드포인트의 보안 점검 워크벤치로 재해석할 수 있습니다.

다만 그대로 의료 환경에 투입하기에는 위험합니다. 환자정보와 임상 데이터가 포함된 환경에서는 무작위 도구 설치, raw shell command, 외부 저장소 clone, root 권한 실행, 버전 미고정이 모두 큰 리스크입니다. 의료 AI 검증용으로 변형하려면 피싱·DDoS·RAT·payload 계열은 제거하고, 승인된 스캐너·SBOM 생성기·secret scanner·컨테이너 취약점 스캐너·TLS 검사·API schema 검사처럼 방어적 도구만 allowlist로 제한해야 합니다. 또한 모든 실행은 synthetic data, isolated network, immutable logs, human approval, scope manifest를 전제로 해야 합니다.

Bioinformatics 관점

Bioinformatics 파이프라인은 Nextflow, Snakemake, CWL, Docker/Singularity, Conda, 대규모 공개 reference dataset, 클라우드 스토리지, HPC scheduler를 함께 사용하기 때문에 공급망과 재현성이 핵심입니다. HackingTool의 메타데이터 기반 도구 등록 방식은 보안 도구뿐 아니라 “파이프라인 검증 도구 registry”로 응용할 여지가 있습니다. 예를 들어 container image scanning, dependency scanning, secret scanning, data access policy check, S3/GCS bucket misconfiguration check, workflow provenance check를 하나의 CLI에 묶는 방식입니다.

하지만 bioinformatics에서는 go install @latest, unpinned apt/pip 설치, root install이 재현성 문제를 만듭니다. 연구·임상 유전체 분석 환경에서는 lockfile, container digest, SBOM, signed artifacts, exact version metadata, dataset access audit가 필요합니다. HackingTool식 wrapper 구조를 쓰더라도 각 도구는 명확한 version, checksum, license, citation, allowed input/output boundary를 가져야 합니다.

Autonomous Agent 개발 관점

HackingTool은 agent tool registry로 확장하기 쉬운 구조를 갖고 있습니다. 각 도구가 title, description, tags, install/run commands, supported OS를 갖기 때문에 LLM agent가 “작업 의도 → 태그 → 후보 도구 → 실행 전 승인” 흐름을 설계하기 쉽습니다. 특히 _RECOMMENDATIONS처럼 자연어 목표를 태그로 매핑하는 구조는 agent planner의 초기 형태로 볼 수 있습니다.

그러나 현재 구조를 agent에게 직접 연결하는 것은 안전하지 않습니다. raw shell command와 고위험 카테고리가 존재하고, 실행 전 대상 scope 검증·권한 검증·dry-run·policy gate·rate limit·audit trail이 없습니다. Autonomous security agent로 발전시키려면 다음이 필요합니다.

• 도구별 risk level, allowed target type, required authorization artifact, expected side effects를 명시하는 schema.
• 명령 실행 전 dry-run과 human-in-the-loop 승인.
• 대상 범위 manifest와 네트워크 egress allowlist.
• 실행 결과와 원본 명령을 분리 저장하는 tamper-evident audit log.
• offensive capability를 포함한 도구는 기본 비활성화하고, 교육용 sandbox에서만 활성화.
• “설치 가능한 도구”와 “실행 가능한 작업”을 분리해 agent가 임의로 외부 코드를 설치하지 못하게 하는 정책.

결론

HackingTool은 단일 보안 도구라기보다, 다수의 외부 보안 도구를 메뉴·검색·태그·추천·설치 상태·업데이트 흐름으로 묶는 CLI 카탈로그입니다. 교육용 랩이나 승인된 내부 보안 점검 환경에서는 빠른 탐색성과 도구 큐레이션 측면에서 유용합니다. 반면 의료 AI, bioinformatics, autonomous agent처럼 높은 신뢰성과 감사 가능성이 필요한 영역에 적용하려면 allowlist, version pinning, sandbox, audit logging, 정책 기반 실행 제어가 선행되어야 합니다.