한 줄 요약: hackingtool은 여러 공개 보안 도구를 하나의 터미널 메뉴로 묶어 설치, 실행, 업데이트, 탐색을 돕는 Python 기반 카탈로그형 런처다.
실제 테스트는 반드시 명시적으로 허가된 실습 환경, 내부 자산, CTF 또는 감사 범위 안에서만 수행해야 한다.

그림: 저장소 images/A.png에서 수집한 메인 메뉴 실행 화면이다. 화면은 v1.1.0 표기를 포함한 레거시 스크린샷이지만, 프로젝트가 “카테고리 선택 → 도구 선택 → 액션 실행” 구조로 동작한다는 핵심 UI 흐름을 보여 준다.

Quick Links
| 구분 | 링크 | 비고 |
|---|---|---|
| Repository | Z4nzu/hackingtool | 공식 GitHub 저장소 |
| README | README.md | 프로젝트 소개, 카테고리, 설치법의 1차 문서 |
| Images / Demo assets | images/ | 저장소 내 스크린샷과 로고 자산 |
| Issues | Issues | 버그, 도구 요청, 사용자 피드백 |
| Pull Requests | Pull requests | 코드 변경 및 신규 도구 추가 흐름 |
| Installer | install.py, install.sh | 시스템 설치용 스크립트 |
| Docker | Dockerfile, docker-compose.yml | 컨테이너 실행 경로 |
| Wiki / Discussion | 별도 활성 문서 확인 불가 | Wiki URL은 저장소 루트로 리디렉션되며, Discussions 콘텐츠는 공개적으로 확인되지 않았다. |
| Paper | 없음 | README와 저장소 구조에서 논문 링크는 확인되지 않았다. |
Image & Asset Harvesting
| 파일 | 출처 | 이 문서 내 의미 |
|---|---|---|
figures/repo_main_menu_v1.png |
images/A.png |
터미널 기반 최상위 카테고리 메뉴 |
figures/repo_anonymous_category.png |
images/AA.png |
카테고리 내부 도구 목록 UI 예시 |
figures/repo_information_gathering_category.png |
images/AAA.png |
정보 수집 도구 목록과 설명 테이블 |
figures/repo_wireless_category.png |
images/AAAA.png |
무선 보안 도구 목록 예시. 고위험 기능은 허가된 랩에서만 다뤄야 한다. |
figures/repo_tool_action_menu.png |
images/AAAAA.png |
개별 도구의 Install / Run / Stop / Project Page / Back 액션 메뉴 |
figures/hackingtool_architecture.png |
분석 생성 | 소스 구조를 바탕으로 생성한 아키텍처 다이어그램. 저장소에는 별도 아키텍처 이미지가 없었다. |
figures/category_map.png |
분석 생성 | README의 카테고리별 도구 수를 시각화한 요약 그래픽 |
figures/tech_stack_snapshot.png |
분석 생성 | 기술 스택과 런타임 레이어 요약 |
figures/safe_setup_flow.png |
분석 생성 | 안전한 로컬 설치·탐색 흐름 요약 |
Key Features
1. 20개 상위 카테고리와 185개 이상 도구를 묶는 CLI 허브
README 기준으로 프로젝트는 Anonymously Hiding, Information Gathering, Web Attack, Forensics, Active Directory, Cloud Security, Mobile Security 등 20개 상위 카테고리를 제공한다.
v2.0.0 설명에서는 185개 이상 도구와 35개 신규 도구, Active Directory / Cloud Security / Mobile Security 신규 카테고리를 강조한다.
이 프로젝트의 핵심 가치는 개별 도구를 직접 기억하고 설치하는 대신, 카테고리형 메뉴에서 도구를 찾아 설치·실행·업데이트하도록 만든 데 있다.

그림: README의 “Tool Categories” 표를 기준으로 만든 카테고리 맵이다. Information Gathering, Other Tools, Web Attack, Phishing Attack, Wireless Attack 쪽에 많은 도구가 몰려 있어 정찰·웹·소셜 엔지니어링·무선 영역을 넓게 포괄한다.
2. 검색, 태그 필터, 추천 기반 탐색
v2.0.0 README는 /query 검색, t 태그 필터, r 추천 기능을 핵심 변경점으로 소개한다.
소스상 hackingtool.py는 전체 도구 컬렉션을 재귀적으로 수집하고, 제목·설명·태그 문자열을 기준으로 검색한다.
태그 필터는 osint, web, scanner, cloud, mobile, active-directory 같은 키워드 규칙을 통해 도구를 묶는다.
추천 기능은 “scan a network”, “find subdomains”, “pentest cloud”, “forensic analysis” 같은 작업 의도를 태그 목록으로 매핑해 관련 도구를 보여 주는 방식이다.
3. 카테고리별 도구 목록과 설명 테이블
각 카테고리 화면은 번호, 도구명, 설명을 표 형태로 보여 준다.
이는 단순한 실행기보다 “도구 카탈로그”에 가깝다.
사용자는 먼저 도구의 목적과 프로젝트 링크를 확인하고, 필요한 경우에만 설치 또는 실행 메뉴로 들어갈 수 있다.

그림: 저장소 images/AAA.png에서 수집한 Information Gathering 화면이다. Network Map, Dracnmap, Port scanning, Host to IP, ReconSpider 등 정찰 계열 도구가 하나의 표 안에 정리되어 있다. 이 화면은 프로젝트가 도구명뿐 아니라 간단한 설명까지 함께 제공한다는 점을 보여 준다.

그림: 저장소 images/AA.png에서 수집한 Anonymously Hiding Tools 화면이다. 카테고리 진입 후에는 다시 도구별 상세 액션 메뉴로 이동하는 구조다.
4. 개별 도구의 설치, 실행, 업데이트, 폴더 열기 액션
core.py의 HackingTool 클래스는 TITLE, DESCRIPTION, INSTALL_COMMANDS, RUN_COMMANDS, PROJECT_URL, SUPPORTED_OS, TAGS 같은 메타데이터를 중심으로 동작한다.
기본 액션은 Install, Run, Update, Open Folder이며, 프로젝트 URL이 있으면 브라우저로 열 수 있다.
설치 여부는 실행 바이너리가 PATH에 있는지 또는 git clone 대상 디렉터리가 존재하는지 확인하는 방식으로 판단한다.

그림: 저장소 images/AAAAA.png에서 수집한 개별 도구 액션 메뉴다. Anonymously Surf 도구를 예로 들어 Install, Run, Stop, Open Project Page, Back 액션이 표시된다. 현재 v2 계열 소스에서는 Install / Run / Update / Open Folder가 기본 액션으로 일반화되어 있다.
5. OS-aware 메뉴와 설치 상태 표시
README는 macOS에서 Linux 전용 도구를 숨기는 OS-aware 메뉴와 도구별 설치 상태 표시를 v2.0.0의 주요 개선점으로 적는다.
core.py의 컬렉션 클래스는 현재 OS와 각 도구의 SUPPORTED_OS를 비교해 활성 도구, 비호환 도구, 보관 처리된 도구를 분리한다.
이 방식은 사용자에게 “현재 환경에서 실행 가능한 도구만 우선 노출”하는 장점이 있다.
6. 보관 처리된 도구와 최신 도구의 공존
일부 레거시 도구는 ARCHIVED = True와 ARCHIVED_REASON으로 표시된다.
예를 들어 Web Attack 계열에는 Python 2 전용이거나 미관리 상태인 도구를 보관 메뉴로 밀어내는 로직이 있다.
반대로 Nuclei, ffuf, Katana, Gobuster, OWASP ZAP, mitmproxy, Trivy, Prowler, ScoutSuite, MobSF, Frida 등 비교적 현대적인 도구도 별도 클래스 형태로 추가되어 있다.
7. 고위험 기능을 포함한 넓은 범위의 보안 도구 카탈로그
카테고리에는 DDoS, RAT, Payload Creation, Phishing, Wireless Attack 같은 오용 가능성이 높은 영역도 포함된다.
분석 관점에서 이는 “보안 연구용 올인원 런처”라는 장점과 “조직 환경에서 그대로 배포하기에는 정책·권한·감사 통제가 부족하다”는 단점을 동시에 만든다.
실무 환경에서는 allowlist, 승인 워크플로, 감사 로그, 샌드박스, 네트워크 격리 정책을 별도로 붙이는 것이 필요하다.

그림: 저장소 images/AAAA.png에서 수집한 Wireless Attack Tools 화면이다. 이 계열의 도구는 주변 네트워크와 제3자 장비에 영향을 줄 수 있으므로 허가된 실험 장비와 차폐된 테스트 환경에서만 사용해야 한다.
8. 로컬 설치와 Docker 실행 경로 제공
README는 수동 설치, 원라이너 설치, Docker 빌드, Docker Compose 실행 방법을 함께 제공한다.
Dockerfile은 Kali rolling 이미지를 기반으로 git, python3-pip, python3-venv, curl, wget, php를 설치하고, requirements.txt를 먼저 복사해 pip 의존성을 설치한 뒤 전체 소스를 복사한다.
Compose 설정은 기본 서비스와 dev 프로파일을 구분하고, 런타임에 설치한 도구를 유지하기 위해 /root/.hackingtool 볼륨을 둔다.
Tech Stack

그림: 저장소의 README, requirements.txt, install.py, Dockerfile, docker-compose.yml, constants.py를 바탕으로 만든 기술 스택 스냅샷이다.
| 계층 | 구성 | 버전 / 조건 | 분석 메모 |
|---|---|---|---|
| Core language | Python | 3.10+ | v2.0.0에서 Python 2 코드를 제거하고 Python 3.10 이상을 요구한다. |
| CLI UI | Rich | rich>=13.0.0 |
표, 패널, 프롬프트, traceback 표시를 담당한다. |
| Shell scripts | Shell | install.sh, update.sh |
설치 및 업데이트 보조 스크립트. |
| Container | Docker / Docker Compose | Docker any | Kali rolling 기반 로컬 빌드. 외부 미검증 이미지를 당겨 쓰기보다 로컬 Dockerfile을 빌드하는 형태다. |
| Go toolchain | Go | 1.21+ | Nuclei, ffuf, amass, httpx, katana, dalfox, gobuster, subfinder 등 일부 도구 설치에 필요하다. |
| Ruby runtime | Ruby | any | haiti, evil-winrm 계열 도구에 필요하다. |
| Package managers | apt-get, pacman, dnf, zypper, apk, brew | OS별 | install.py와 os_detect.py가 패키지 매니저를 감지해 시스템 의존성을 설치한다. |
| User state | ~/.hackingtool |
config/log/tools dir | 사용자별 설정, 도구 설치 디렉터리, 로그 파일 경로가 분리되어 있다. |
| Language share | Python 95.3%, Shell 4.0%, Dockerfile 0.7% | GitHub language summary 기준 | 프로젝트 본체는 Python CLI이며, 설치·컨테이너 보조 파일이 주변을 이룬다. |
Architecture

그림: 저장소에는 별도 아키텍처 다이어그램이 없어서, hackingtool.py, core.py, `tools/.py,install.py,constants.py,config.py,os_detect.py`, Docker 관련 파일을 분석해 생성한 구조도다.*
핵심 구조
hackingtool.py는 엔트리포인트이자 메인 메뉴 라우터다.
Python 3.10 이상인지 먼저 검사하고, Rich 기반 배너와 2열 카테고리 메뉴를 출력한다.
사용자의 입력은 숫자 선택, /query 검색, t 태그 필터, r 추천, ? 도움말, q 종료로 분기된다.
core.py는 이 프로젝트의 실질적 프레임워크다. HackingTool은 단일 도구의 추상 모델이고, HackingToolsCollection은 카테고리 또는 중첩 컬렉션을 표현한다.
구별 클래스는 설치 명령, 실행 명령, 프로젝트 URL, OS 지원 여부, 추가 태그를 가진다.
컬렉션은 현재 OS와 보관 상태를 기준으로 표시 대상을 필터링한다.
tools/*.py는 도구 카탈로그 레이어다. active_directory.py, cloud_security.py, mobile_security.py, web_attack.py, forensics.py 등 각 파일은 하나의 보안 영역을 대표하며, 내부에 여러 HackingTool 하위 클래스를 둔다.
예를 들어 Cloud Security는 Prowler, ScoutSuite, Pacu, Trivy를, Active Directory는 BloodHound, NetExec, Impacket, Responder, Certipy, Kerbrute를 묶는다.
install.py와 install.sh는 시스템 설치 경로를 담당한다.
설치기는 root 권한 확인, OS 호환성 확인, 인터넷 연결 확인, 시스템 패키지 설치, 소스 복사 또는 clone, venv 생성, requirements.txt 설치, 런처 생성, 사용자 설정 디렉터리 생성을 순서대로 수행한다.
Docker 경로는 로컬 격리 실행을 위한 보조 루트다. Dockerfile은 Kali rolling을 기반으로 기본 의존성을 설치하고 hackingtool.py를 엔트리포인트로 둔다. Compose 파일은 기본 서비스와 개발용 source mount 프로파일을 분리한다.
작동 원리 요약
- 사용자가
hackingtool을 실행한다. hackingtool.py가 OS와 Python 버전을 확인하고 메인 메뉴를 렌더링한다.- 사용자가 카테고리, 검색, 태그, 추천 중 하나를 선택한다.
- 메뉴는
all_tools에 등록된HackingToolsCollection과HackingTool객체를 순회한다. - 개별 도구 선택 시
core.py의 공통 액션 메뉴가 표시된다. - Install / Run / Update 선택 시 각 도구 클래스에 저장된 명령이 로컬 shell에서 실행된다.
- 설치 상태는 바이너리 위치 또는 clone 디렉터리 유무로 표시된다.
설계상 장점
- 신규 도구 추가가 비교적 단순하다.
tools/*.py에 클래스 하나를 추가하고TITLE,DESCRIPTION,INSTALL_COMMANDS,RUN_COMMANDS,SUPPORTED_OS,PROJECT_URL을 채우면 된다. HackingTool과HackingToolsCollection이 분리되어 있어 도구 단위와 카테고리 단위 UI가 재사용된다.- OS 필터링, archived 도구, 설치 상태 표시, update 추론이 공통 프레임워크에 들어 있어 개별 도구 코드의 중복이 줄어든다.
- Docker와 수동 설치 경로가 함께 있어 사용자는 격리 실행 또는 시스템 설치 중 하나를 선택할 수 있다.
설계상 한계
- 도구 명령이 문자열 기반 shell 실행으로 이어지므로, 조직 환경에서는 실행 전 승인, allowlist, dry-run, 감사 로그가 필요하다.
- tool version pinning이 약하다. 여러 설치 명령이
@latest, 패키지 매니저 기본 버전, 최신 git clone에 의존하므로 재현 가능한 보안 평가에는 별도 lockfile이나 컨테이너 이미지 digest가 필요하다. - 일부 고위험 카테고리는 안전 통제 없이도 메뉴에 노출될 수 있다. 법적 승인, 대상 범위, 네트워크 격리, 로그 보존이 전제되어야 한다.
- README의 UI 스크린샷은 v1.1.0 화면이고 README 텍스트는 v2.0.0 기능을 설명하므로, 시각 자료와 최신 코드 UI 사이에 차이가 있을 수 있다.
Usage & Setup

그림: 공격 절차가 아니라 안전한 로컬 설치, 메뉴 탐색, 도움말 확인 흐름만 요약한 다이어그램이다.
권장 실행 환경
실제 운영망이 아닌 VM, Docker, CTF, 내부 승인 랩에서 실행하는 것이 안전하다.
특히 무선, 피싱, DDoS, RAT, payload 계열 카테고리는 제3자 시스템에 직접적인 피해나 법적 문제를 만들 수 있으므로 조직 보안 정책과 승인 범위를 먼저 확정해야 한다.
수동 설치
git clone https://github.com/Z4nzu/hackingtool.git
cd hackingtool
sudo python3 install.py
hackingtool
README에는 원라이너 설치도 제공되지만, 원격 스크립트를 root 권한으로 바로 실행하는 방식이므로 실무 환경에서는 먼저 스크립트를 검토한 뒤 수동 설치나 Docker를 쓰는 편이 낫다.
# README에 제시된 원라이너 형태. 실행 전 스크립트 검토 권장.
curl -sSL https://raw.githubusercontent.com/Z4nzu/hackingtool/master/install.sh | sudo bash
Docker 실행
# 이미지 빌드
docker build -t hackingtool .
# 직접 실행
docker run -it --rm hackingtool
# Compose 실행
docker compose up -d
docker exec -it hackingtool bash
# 종료
docker compose down
개발 모드에서는 소스 디렉터리를 컨테이너에 mount하는 dev 프로파일을 사용할 수 있다.
docker compose --profile dev up
docker exec -it hackingtool-dev bash
메뉴 조작 요약
/query 검색: 이름, 설명, 태그에서 도구 검색
t 태그 필터: osint, web, scanner, cloud, mobile 등
r 추천: 작업 의도에 맞는 도구 후보 표시
? 도움말
q 종료
97 현재 카테고리에서 설치되지 않은 도구 일괄 설치
99 이전 메뉴로 이동
공격·침투 절차는 이 요약에서 의도적으로 제외했다.
보고서의 목적은 저장소 구조와 기술적 설계를 이해하는 것이며, 실제 실행은 허가된 범위와 로컬 실습 환경에서만 다뤄야 한다.
Personal Insights
의료 AI 관점
의료 AI 환경에서는 모델 서버, PACS/RIS 연동, 병원 네트워크, 의료 IoT, 클라우드 저장소, API gateway 같은 자산의 보안 점검이 중요하다.
hackingtool은 다양한 공개 보안 도구를 빠르게 모아 보여 주는 “평가 도구 카탈로그”로는 유용하지만, 병원·의료 데이터 환경에 그대로 배포하기에는 부족하다.
PHI/PII가 오갈 수 있는 환경에서는 대상 범위 승인, 비식별 데이터 사용, 실행 명령 감사, 결과물 암호화, 접근 통제, change window 관리가 필요하다.
가장 현실적인 사용 방식은 의료 AI 시스템을 직접 공격하는 것이 아니라, 내부 보안팀이 승인한 랩 복제본에서 웹/API 스캐너, 컨테이너 취약점 점검, 클라우드 설정 점검, 로그 기반 포렌식 도구를 분리해 평가하는 것이다.
이때 hackingtool의 카탈로그 구조는 “어떤 보안 평가 도구가 어떤 목적에 쓰이는가”를 교육하는 데도 활용할 수 있다.
Bioinformatics 관점
바이오인포매틱스 파이프라인은 FastQC, BWA/Bowtie, STAR, Samtools, BLAST, GATK, Nextflow, Snakemake처럼 많은 외부 도구를 조합한다.
hackingtool의 구조는 보안 도구 대신 생명정보학 도구 카탈로그에도 적용할 수 있다.
즉, 도구별 TITLE, DESCRIPTION, INSTALL_COMMANDS, RUN_COMMANDS, TAGS, SUPPORTED_OS를 정의하고, 사용자가 “variant calling”, “RNA-seq QC”, “metagenomics classification” 같은 작업 의도로 도구를 추천받는 구조를 만들 수 있다.
다만 연구 재현성 측면에서는 @latest, 패키지 매니저 기본 버전, 임의 git clone은 위험하다.
Bioinformatics 용도로 확장한다면 conda environment lock, container digest, workflow version pinning, reference genome checksum, input/output provenance 기록이 필수다.
Autonomous Agent 개발 관점
이 저장소는 에이전트 개발 관점에서 흥미로운 “도구 메타데이터 레지스트리” 예시다.
각 도구는 이름, 설명, 설치 명령, 실행 명령, OS 조건, 태그를 명시하므로 agent action schema로 변환하기 쉽다.
예를 들어 에이전트가 “cloud posture check”라는 목표를 받으면 cloud 태그 도구를 후보로 찾고, 설치 여부와 OS 호환성을 확인한 뒤 dry-run 도움말만 실행하도록 설계할 수 있다.
그러나 현재 구조를 자율 에이전트에 그대로 연결하는 것은 위험하다.
shell 명령 실행은 고위험 capability이므로 명령 allowlist, parameter sanitizer, target scope verifier, human approval gate, dry-run mode, execution transcript logging, network egress policy, container sandbox가 필요하다.
특히 phishing, DDoS, RAT, payload 계열은 에이전트가 자동 선택하지 못하도록 policy layer에서 차단하거나 별도 승인을 요구해야 한다.
분석 근거와 제한
- 검토 대상: README, images 폴더,
hackingtool.py,core.py,tools/*.py,install.py,constants.py,config.py,os_detect.py,requirements.txt,Dockerfile,docker-compose.yml,.github템플릿 구조. - 저장소 내 별도 아키텍처 다이어그램은 확인되지 않아, 본 문서의 아키텍처 이미지는 소스 분석 기반으로 생성했다.
- 저장소 스크린샷은 README에 포함된 레거시 UI를 보여 주며, v2.0.0 Rich 기반 최신 UI와 일부 차이가 있을 수 있다.
- Wiki는 별도 문서가 아니라 저장소 루트로 리디렉션되었고, Discussions는 공개 콘텐츠를 확인할 수 없었다.
- 본 리포트는 프로젝트 구조와 방어적·교육적 활용 가능성을 분석한 문서이며, 무단 침해, 피싱, 서비스 방해, 악성 페이로드 생성 또는 제3자 시스템 대상 실행을 안내하지 않는다.
'AI 생성 글 정리 > tech_github' 카테고리의 다른 글
| ViMax — 아이디어·대본·소설을 멀티샷 영상으로 확장하는 Agentic Video Generation 프레임워크 (0) | 2026.05.21 |
|---|---|
| Scientific Agent Skills — AI 에이전트를 과학 연구 조수로 확장하는 138개 Agent Skill 라이브러리 (0) | 2026.05.21 |
| OpenHuman — 로컬 메모리와 데스크톱 UX를 결합한 개인 AI 슈퍼 인텔리전스 (0) | 2026.05.19 |
| TradingAgents — 실제 트레이딩 데스크를 모사한 멀티 에이전트 LLM 금융 분석 프레임워크 (0) | 2026.05.19 |
| Sniffnet — Rust 기반 크로스플랫폼 네트워크 트래픽 모니터 (0) | 2026.05.19 |