**وقتی سیستم خودت قربانی اول شد**

یه محقق امنیتی داشت یه بدافزار مشکوک رو آنالیز می‌کرد — مستقیم روی سیستم اصلیش. ده دقیقه نگذشته بود که فایل‌هاش رمزگذاری شده بود. باج‌افزار بود. اون فکر کرده بود فقط نگاه می‌کنه.

---

**ماشین مجازی یعنی یه سیستم داخل سیستم**

Virtual Machine یا VM یه محیط ایزوله‌ست — یعنی هر چیزی که اونجا اجرا بشه، از سیستم اصلیت جدا می‌مونه. بدافزار اجرا کنی، اسکن تهاجمی بزنی، سیستم کرش کنی — ماشین اصلیت دست نمی‌خوره. این ایزولاسیون دقیقاً همون چیزیه که اکثرا اول کار نادیده می‌گیرن.

---

**چرا Kali رو مستقیم نصب نکنیم؟**

می‌تونی. ولی اینجاست که اکثرا اشتباه می‌کنن. وقتی ابزارهایی مثل `nmap`، `metasploit` یا `burpsuite` رو روی سیستم اصلیت اجرا می‌کنی، هر خطا، هر تنظیم اشتباه، هر تست بد — مستقیم به محیط کاریت آسیب می‌زنه. VM بهت می‌ده که اشتباه کنی، یاد بگیری، و snapshot بگیری — یعنی هر وقت خراب کردی، برگردی به نقطه‌ی سالم.

---

**ست‌اپ استاندارد برای شروع**

دو تا ابزار رایگان که همه ازشون استفاده می‌کنن:
- **VirtualBox** — رایگان، کراس‌پلتفرم
- **VMware Workstation Player** — کمی سبک‌تر و پایدارتر

بعد از نصب، ایمیج رسمی Kali Linux رو از سایت kali.org بگیر — نسخه‌ی آماده برای VM دارن که نیازی به نصب نیست:

```
فرمت: .ova یا .vmdk
ورودی VirtualBox: File > Import Appliance
```

یه تنظیم مهم که نادیده گرفته می‌شه — **network adapter** رو بذار روی `Host-Only` یا `NAT`. نه `Bridged`. وقتی Bridged باشه، VM مستقیم به شبکه‌ی واقعیت وصله — یعنی اسکن‌هات از IP اصلیت می‌ره بیرون.

---

#محیط_هک

@codacker_ir

**هک یه ابزار نیست. یه طرز فکره.**

قبل از اولین حمله، مهاجم فقط نگاه می‌کنه


سال ۲۰۱۱، قبل از اینکه گروه Anonymous سرورهای HBGary Federal رو از پا دربیاره، هیچ اکسپلویتی اجرا نشد. هیچ پورتی اسکن نشد. اونا فقط نشستن و اطلاعات جمع کردن — ایمیل‌های عمومی، اسم کارمندا، سیستم CMS سایت. همین کافی بود که کل عملیات رو طراحی کنن.

---

Recon یعنی شناخت هدف قبل از هر اقدامی. دو نوع داره:
**Passive Recon** — هیچ ترافیکی به سمت هدف نمی‌ره. فقط از منابع عمومی اطلاعات جمع می‌کنی. موتور جستجو، LinkedIn، WHOIS، آرشیو وب. هدف هیچ‌وقت نمی‌فهمه کسی داره نگاهش می‌کنه.

**Active Recon** — مستقیم با سیستم هدف تعامل داری. پورت‌اسکن، DNS enumeration، fingerprinting. سریع‌تره، اما ردپا می‌ذاره.

---

اکثرا اینجا اشتباه می‌کنن: سریع می‌رن سراغ ابزار. Nmap رو باز می‌کنن و شروع می‌کنن به اسکن — در حالی که هنوز نمی‌دونن دارن چی رو اسکن می‌کنن. Recon پایه همیشه از Passive شروع می‌شه.

یه نقطه‌ی شروع ساده برای passive recon روی یه دامنه:

```
whois target.com
```
```
curl https://web.archive.org/web/*/target.com
```

این دو خط، بدون اینکه یه بسته‌ی واحد به سمت هدف بره، می‌تونن ساختار زیرساخت، تاریخچه‌ی سایت، و حتی ایمیل‌های ادمین رو بهت بدن.

---

هر هدفی یه سطح حمله داره. Recon یعنی پیدا کردن اون سطح — قبل از اینکه کسی بفهمه داری دنبالش می‌گردی.

#Recon

@codacker\_ir

**هک یه ابزار نیست. یه طرز فکره.**

یه ایمیل، یه هویت


سال ۲۰۱۳، قبل از اینکه Silk Road بسته بشه، FBI یه ایمیل پیدا کرد: rossulbricht@gmail.com. همین یه آدرس کافی بود تا هویت کامل بنیانگذار بزرگ‌ترین مارکت دارک‌وب رو بسازن — و بعدش دستگیرش کنن.

---

ایمیل یه نقطه‌ی شروعه، نه یه دیواره‌ی بسته.

اولین کاری که می‌کنی اینه که اون ایمیل رو توی **Have I Been Pwned** چک کنی. اگه توی یه دیتابیس لیک شده باشه، می‌فهمی این آدرس به کدوم سرویس‌ها وصل بوده — LinkedIn، Adobe، Dropbox. هر سرویس یه درِ جدیده.

---

بعدش نوبت **Google Dorking** می‌رسه — اینجاست که اکثرا اشتباه می‌کنن و فقط اسم رو سرچ می‌زنن.

درست اینه:

```
"rossulbricht@gmail.com" site:reddit.com
"rossulbricht@gmail.com" filetype:pdf
```

با این دستورا، هر جایی که اون ایمیل استفاده شده — فروم، داکیومنت، پروفایل — جلوی چشمته.

---

حالا اگه username از ایمیل استخراج کردی، ابزار **Sherlock** رو بنداز رو کار:

```
python3 sherlock.py rossulbricht
```

این ابزار بیشتر از ۳۰۰ پلتفرم رو یه‌جا چک می‌کنه. یه اسم کاربری، می‌تونه Twitter، GitHub، Telegram و Reddit یه نفر رو بهت بده — و از اون‌ها می‌رسی به عکس، لوکیشن، الگوی رفتاری.

---

یه ایمیل به تنهایی هیچه. ولی با روش درست، نقشه‌ی کامل یه آدم رو می‌کشه.
این OSINT نیست که بدونی چه ابزاری وجود داره — اینه که بدونی کجا شروع کنی و کجا دنبال کنی.

#OSINT

@codacker\_ir

**هک یه ابزار نیست. یه طرز فکره.**

گوشی هکر باید چی باشه؟


یه نفر توی فروم توضیح می‌داد که NetHunter رو روی گوشی Samsung Galaxy نصب کرده، ولی نیمی از toolها کار نمی‌کنن، kernel panic می‌گیره و USB OTG درست inject نمی‌کنه. مشکل از NetHunter نبود — مشکل از گوشی بود.

اینجاست که اکثرا اشتباه می‌کنن: فکر می‌کنن هر اندرویدی با یه custom ROM کافیه. واقعیت اینه که هک با گوشی قبل از هر چیز به یه چیز وابسته‌ست: **دسترسی به kernel**.

---

وقتی می‌گیم گوشی مناسب هک، یعنی گوشی‌ای که:
- bootloader قفل نداشته باشه یا راحت unlock بشه
- kernel سورس کدش عمومی باشه
- custom kernel بشه روش فلش کرد
- درایورهای USB و wireless chipset درست کار کنن

**Pixel** اینجا پادشاهه. گوگل سورس کرنل رو کامل منتشر می‌کنه، bootloader با یه دستور unlock می‌شه، و NetHunter رسماً روش ساپورت داره. Pixel 6 و 7 الان بهترین گزینه‌ان.

**OnePlus** (نسل‌های قدیمی‌تر — تا OnePlus 9) هم گزینه‌ی خوبیه. OxygenOS پایه‌ی AOSP داره، bootloader راحت باز می‌شه، و جامعه‌ی modding قوی داره. ولی از OnePlus 10 به بعد، با ادغام با OPPO، ماجرا کمی پیچیده‌تر شده.

**Xiaomi** با MIUI یه چالش جداگانه‌ست — bootloader unlock نیاز به تأیید حساب Mi داره و گاهی چند هفته طول می‌کشه. ولی وقتی unlock شد، گوشی‌هایی مثل Redmi Note series با LineageOS و NetHunter خوب کار می‌کنن.

---

برای چک کردن اینکه گوشیت NetHunter ساپورت می‌کنه یا نه:

```
https://nethunter.com/nethunter-devices.html
```

و برای اینکه ببینی bootloader گوشیت قابل unlock هست:

```bash
adb reboot bootloader
fastboot oem device-info
```

خروجی `Device unlocked: true` یعنی راهت بازه.

---

Samsung با Knox و Xiaomi با تأخیرهای unlock — برای شروع دردسرن. اگه جدی هستی، از Pixel شروع کن. اگه بودجه‌ات محدوده، OnePlus 7 یا 8 دست دومی پیدا کن.

#هک_با_گوشی

@codacker_ir

**هک یه ابزار نیست. یه طرز فکره.**

**گوشیت رو دست کم نگیر**

یه محقق امنیتی تو کنفرانس DEF CON یه بار نشون داد که تونسته یه تست نفوذ کامل رو فقط با یه اندروید روت‌شده انجام بده — بدون لپ‌تاپ، بدون Kali. اکثر کسایی که اون جلسه بودن باورشون نمی‌شد.

وقتی اندروید رو روت می‌کنی، دیگه فقط یه گوشی نیست — یه ترمینال لینوکسی داری توی جیبت. اینجاست که ابزارهای جدی وارد بازی می‌شن.

**Termux** اولین چیزیه که باید نصب کنی. یه محیط ترمینال کامله که بهت اجازه می‌ده پکیج‌های لینوکسی نصب کنی. با چند خط می‌تونی `nmap`، `hydra`، یا `sqlmap` رو مستقیم روی گوشی راه بندازی:

```
pkg install nmap
nmap -sV 192.168.1.1
```

**zANTI** و **cSploit** دو ابزار گرافیکی هستن که مخصوص اندروید روت طراحی شدن — اسکن شبکه، شناسایی دستگاه‌ها، حملات MITM. اینجاست که اکثرا اشتباه می‌کنن و فکر می‌کنن این ابزارها فقط تو لپ‌تاپ کار می‌کنن.

**NetHunter** از Offensive Security یه قدم جلوتره — یه کرنل اندروید اختصاصیه که ابزارهای Kali رو کامل روی گوشی می‌آره. با گوشی‌های خاصی مثل Nexus و OnePlus کار می‌کنه و حتی امکان تزریق بسته‌های وایرلس رو بهت می‌ده.

#هک_موبایل

@codacker\_ir

**هک یه ابزار نیست. یه طرز فکره.**

# ابزاری که فرودگاه‌ها ازش می‌ترسن

سال ۲۰۲۲، کانادا داشت جدی فکر می‌کرد Flipper Zero رو کلاً ممنوع کنه — چون ادعا می‌شد با این دستگاه می‌شه قفل ماشین‌ها رو زد و ماشین دزدید.

خب. حقیقتش چیه؟

---

Flipper Zero یه دستگاه کوچیکه — اندازه‌ی یه پاوربانک — که می‌تونه با طیف وسیعی از پروتکل‌های بی‌سیم ارتباط برقرار کنه. RFID، NFC، Infrared، Sub-GHz، Bluetooth، GPIO. یعنی هر چیزی که توی دنیای واقعی سیگنال بی‌سیم رد و بدل می‌کنه، Flipper می‌تونه باهاش حرف بزنه — گوش بده، ضبط کنه، دوباره پخش کنه.

---

اینجاست که اکثراً اشتباه می‌کنن: Flipper رو با «ابزار هک» اشتباه می‌گیرن، نه «ابزار تحقیق». مثلاً وقتی ریموت در پارکینگت رو جلوش می‌گیری، می‌تونه فرکانس رو ببینه — Sub-GHz حدود ۴۳۳ مگاهرتز. می‌تونه سیگنال رو ضبط کنه. ولی در مدرن پارکینگ؟ rolling code داره — یعنی هر بار کد عوض می‌شه. Flipper به‌تنهایی اونجا می‌مونه.

---

پس چرا همه ازش می‌ترسن؟ چون شفافه. یه چیزی که قبلاً فقط پنتسترهای حرفه‌ای با ابزارهای گرون‌قیمت انجام می‌دادن — مثل SDR و HackRF — حالا تو یه دستگاه ۱۶۹ دلاری با صفحه‌نمایش귀یمه و منوی ساده جمع شده. دیگه نمی‌شه گفت «این فقط کار متخصصاست». این یعنی آسیب‌پذیری‌هایی که سال‌ها زیر فرش بودن، حالا قابل نمایشن.

---

یه نمونه‌ی ساده: کارت‌های RFID 125kHz — همونایی که تو خیلی از ساختمون‌های اداری ایران هنوز هم ازشون استفاده می‌شه — هیچ رمزنگاری ندارن. Flipper می‌تونه اون کارت رو بخونه و کپیش کنه، توی چند ثانیه:

Read Card → EM4100 Protocol
ID: 0x4A2F91C3
Save → Clone to Writable Tag

این یه نمایش از یه آسیب‌پذیری واقعیه — نه سحر و جادو.

---

#FlipperZero

@codacker_ir

**هک یه ابزار نیست. یه طرز فکره

# وقتی یه آپستروف کل دیتابیس رو لو داد

سال ۲۰۰۸، هکری به اسم Alberto Gonzalez با تیمش بیش از ۱۳۰ میلیون شماره کارت اعتباری رو از شرکت Heartland Payment Systems دزدید. نقطه‌ی ورود؟ یه SQL Injection ساده روی یه فرم ورودی که کسی فکرش رو نمی‌کرد.

---

ماجرا اینجاست که SQL Injection یکی از قدیمی‌ترین آسیب‌پذیری‌هاست — ولی هنوز توی OWASP Top 10 جا داره. چرا؟ چون اکثر توسعه‌دهنده‌ها ورودی کاربر رو مستقیم می‌ریزن توی کوئری. وقتی یه فرم لاگین داری که این کوئری رو اجرا می‌کنه:

SELECT * FROM users WHERE username='$input' AND password='$pass'

کافیه تو فیلد username بنویسی:

' OR '1'='1' --

کوئری می‌شه:

SELECT * FROM users WHERE username='' OR '1'='1' --' AND password='...'

شرط همیشه true می‌شه. رمز عبور چک نمی‌شه. تو داخلی.

---

اینجاست که اکثرا فکر می‌کنن تموم شد — ولی تازه شروع شده. وقتی توسعه‌دهنده‌ها می‌فهمن چه خبره، شروع می‌کنن به فیلتر کردن. کلماتی مثل SELECT`، `UNION`، --` رو بلاک می‌کنن. اینجا bypass فیلترها مطرح می‌شه.

یه تکنیک رایج اینه که از comment های inline استفاده کنی تا کلمات کلیدی رو بشکنی:

UN/**/ION SEL/**/ECT null, username, password FROM users--

یا از تغییر case استفاده کنی چون بعضی فیلترها case-sensitive هستن:

uNiOn SeLeCt null, table_name FROM information_schema.tables--

یا اگه فیلتر فضای خالی رو می‌گیره، از %09 یا /**/ به عنوان جایگزین استفاده کنی.

---

نکته‌ای که خیلی‌ها نادیده می‌گیرن اینه: **SQL Injection فقط توی فرم‌ها نیست.** هدرهای HTTP، کوکی‌ها، پارامترهای URL — هر جایی که داده از کاربر گرفته می‌شه و وارد کوئری می‌شه، سطح حمله‌ته. ابزاری مثل sqlmap همین سطح‌ها رو به صورت خودکار اسکن می‌کنه — ولی قبل از اینکه به ابزار تکیه کنی، باید بدونی دستی چطور کار می‌کنه. ابزار بدون درک، فقط سروصداست.

#WebHacking

@codacker_ir

هک یک ابزار نیست ، یک طرز فکره

برای اولین بار تو کداکر: دنبال مدرس‌های حرفه‌ای هک و امنیت می‌گردیم
چندتا از دوره‌های کداکر درخواستشون اونقدر بالا رفته . می‌خوایم این دوره‌ها رو با بیشترین پروژه، بیشترین تمرین عملی و بالاترین کیفیت به بچه‌ها بدیم — و برای این کار به همکاری با مدرس‌هایی نیاز داریم که خودشون تو میدون بودن، نه فقط تو کتاب.
اگه تو حوزه‌ای از هک و امنیت (فرقی نمی‌کنه شبکه، وب، بگ‌بانتی، لینوکس، هر چی) تجربه واقعی داری و آماده‌ای تدریس کنی، به پشتیبانی پیام بده تا هماهنگی‌ها رو انجام بدیم.
@codacker_support

یه عدد. همین.


۲۰۱۹، یه محقق امنیتی داشت تو پنل کاربری یه فروشگاه آنلاین ایرانی گشت می‌زد. رفت روی صفحه‌ی سفارش‌هاش. URL این بود:

```
/orders/detail?id=1047
```

یه چیزی توی ذهنش کلیک کرد. عدد رو عوض کرد:

```
/orders/detail?id=1046
```

سفارش یه نفر دیگه. اسم، آدرس، شماره‌ی موبایل. کامل.

---

این IDOR هست — Insecure Direct Object Reference. یعنی سرور مستقیم به یه آبجکت ارجاع می‌ده (مثل ID سفارش)، بدون اینکه چک کنه این کاربر **اجازه** داره اون رو ببینه یا نه. احراز هویت هست، Authorization نیست — اینجاست که اکثرا اشتباه می‌کنن.

---

IDOR فقط توی URL نیست. توی body درخواست‌های POST هم پیدا می‌شه:

```json
{
"user_id": 5821,
"action": "get_profile"
}
```

عدد رو عوض کن. اگه سرور جواب داد — آسیب‌پذیری پیدا کردی.

---

این باگ به‌قدری ساده‌ست که خیلی‌ها جدی نمی‌گیرنش — ولی توی گزارش‌های HackerOne، سال‌هاست جزو پردرآمدترین باگ‌هاست. چرا؟ چون تاثیرش مستقیمه. داده‌ی واقعی، آدم‌های واقعی.

وقتی داری یه اپلیکیشن تست می‌کنی، با دو تا اکانت مختلف وارد شو. ID‌های اکانت اول رو با اکانت دوم تست کن. همین.

#IDOR

@codacker_ir

**هک یه ابزار نیست. یه طرز فکره.**

**وقتی Burp داری ولی ترافیک نمی‌بینی**

یه نفر تو یه باگ‌بانتی request می‌فرسته، Burp باز داره، ولی Proxy هیچی نمی‌گیره. نه رهگیری، نه لاگ — هیچی. یه ساعت وقت تلف می‌کنه، بعد می‌فهمه مشکل از همون اول بوده: Burp ست نشده بود. درست.

---

Burp Suite یه پروکسیه — یعنی باید بین مرورگر تو و سرور بشینه. برای این کار، دو طرف باید بدونن این واسطه وجود داره. طرف اول مرورگره، طرف دوم سیستم‌عامل — و هر دو باید تنظیم بشن.

**مرحله اول — Listener رو چک کن:**
بعد از باز کردن Burp، برو:

```
Proxy → Options → Proxy Listeners
```

باید یه listener روی `127.0.0.1:8080` فعال باشه. اگه نیست، `Add` بزن و خودت اضافه‌اش کن. این پورت، دروازه‌ی همه‌چیزه.

**مرحله دوم — مرورگر رو هدایت کن:**
مرورگرت باید بدونه ترافیک رو کجا بفرسته. تو Firefox برو:

```
Settings → Network Settings → Manual Proxy
HTTP Proxy: 127.0.0.1 | Port: 8080
```

گزینه‌ی «Use this proxy for HTTPS» رو هم فعال کن — وگرنه نصف ترافیک رو از دست می‌دی.

**مرحله سوم — CA Certificate، اینجاست که اکثرا اشتباه می‌کنن:**
برای سایت‌های HTTPS، Burp باید ترافیک رمزنگاری‌شده رو رمزگشایی کنه. این کار رو با یه گواهی self-signed انجام می‌ده. مرورگر بهش اعتماد نداره — مگه اینکه تو بهش بگی.

از همون مرورگر برو:
```
http://burpsuite
```
گواهی رو دانلود کن، بعد تو Firefox:
```
Settings → Privacy → View Certificates → Import
```
گواهی رو import کن و هر دو گزینه‌ی trust رو تیک بزن.

---

حالا برو یه سایت باز کن. اگه Burp تب `Intercept` توش داره قرمز می‌شه و درخواست‌ها می‌ان — ست شدی. اگه نه، اول چک کن `Intercept is on` فعاله.

این پایه‌ایه، درسته — ولی هر تستی که بعداً می‌کنی، از همین چند خط شروع می‌شه.

#BurpSuite

@codacker_ir

**هک یه ابزار نیست. یه طرز فکره.**

اولین برنامه‌ات رو اشتباه انتخاب کردی


یه نفر تو دیسکورد پرسید: «شش ماهه روی HackerOne کار می‌کنم، هنوز هیچی پیدا نکردم — مشکل از منه؟»

وقتی پرسیدم روی کدوم برنامه کار می‌کنه، گفت: Google.


اینجاست که اکثرا اشتباه می‌کنن — نه تو تکنیک، تو انتخاب.

برنامه‌های بزرگ مثل Google، Apple، Facebook رو هزار نفر قبل از تو زیر و رو کردن. Attack surface هنوز هست، ولی باگ‌های سطحی مدت‌هاست که رفتن. تازه‌کار اگه بره سراغ اینا، نه باگ پیدا می‌کنه، نه یاد می‌گیره — فقط خسته می‌شه.


پس چی انتخاب کن؟

دنبال برنامه‌هایی بگرد که **عمر کمتری دارن** — برنامه‌هایی که تازه به پلتفرم اضافه شدن. روی HackerOne فیلتر بزن روی «Launched» و تاریخ رو مرتب کن. برنامه‌های جوون، scope گسترده‌تری دارن و رقیب کمتری. یه برنامه‌ی SaaS کوچیک که سه ماه پیش لانچ شده، به مراتب بهتر از یه غول شش‌ساله‌ست.

یه فاکتور مهم دیگه: **response rate** برنامه رو چک کن. بعضی برنامه‌ها گزارش می‌گیرن، جواب نمی‌دن. قبل از شروع، تو Disclosure tab ببین تیم چقد فعاله.


یه روش ساده برای فیلتر کردن برنامه‌های مناسب روی HackerOne:

```
فیلترها:
- Bounties: Yes
- Managed: Yes (تیم تریاژ داره — جواب سریع‌تره)
- Age: کمتر از ۱ سال
- Scope: Web Application
```

بعد برو تو scope برنامه، ببین wildcard دارن یا نه — مثلاً `*.example.com` یعنی سطح حمله‌ی بزرگ‌تر و شانس بیشتر.


شروع درست، نصف راهه. اگه از همون اول برنامه‌ی اشتباه انتخاب کنی، نه باگ می‌بینی، نه انگیزه می‌مونه.

#BugBounty

@codacker_ir

**هک یه ابزار نیست. یه طرز فکره.**

**وقتی یه باگ‌بانتی‌هانتر ۴۷۳ ساب‌دامین پیدا کرد که تیم امنیتی ازشون خبر نداشت**

یه پنتستر رو تصور کن که روی یه شرکت بزرگ کار می‌کنه. اسکوپ رسمی: فقط `app.example.com`. اما اون قبل از هر چیز دیگه‌ای، subdomain enum می‌زنه — و پیداش می‌کنه: `staging-internal.example.com`، روی یه سرور قدیمی، بدون احراز هویت، با دیتابیس باز.

---

**ساب‌دامین چیه و چرا مهمه؟**

هر سازمان بزرگ ده‌ها یا صدها ساب‌دامین داره — بعضیاشون فراموش‌شده، بعضیاشون تست، بعضیاشون production بدون هیچ hardening‌ای. همین ساب‌دامین‌های فراموش‌شده معمولاً بهترین entry point هستن. وقتی روی `example.com` کار می‌کنی، فقط روی `www` وقت نذار.

---

**دو ابزار اصلی: Amass و Subfinder**

**Subfinder** سریعه، سبکه، و با passive sources مثل VirusTotal، Shodan، CertSpotter و چند ده منبع دیگه کار می‌کنه.
**Amass** سنگین‌تره، قابلیت active enumeration هم داره، و برای کارهای جدی‌تر مناسب‌تره.

اینجاست که اکثرا اشتباه می‌کنن — فقط یکی رو اجرا می‌کنن و فکر می‌کنن کارشون تمومه. ترکیب این دو، پوشش خیلی بهتری می‌ده.

---

**نصب و اجرا:**

```bash
# نصب Subfinder
go install -v github.com/projectdiscovery/subfinder/v2/cmd/subfinder@latest

# نصب Amass
go install -v github.com/owasp-amass/amass/v4/...@master

# اجرای ترکیبی و خروجی یکپارچه
subfinder -d example.com -o subfinder_out.txt
amass enum -passive -d example.com -o amass_out.txt

# ادغام و حذف تکراری‌ها
cat subfinder_out.txt amass_out.txt | sort -u > all_subs.txt
```

خروجی `all_subs.txt` رو مستقیم می‌تونی بدی به `httpx` تا ببینی کدوم‌ها live هستن — اینجاست که کار واقعی شروع می‌شه.

---

#Recon

@codacker_ir

**هک یه ابزار نیست. یه طرز فکره.**

🔐 وقتی پایتون مثل یه جاسوس مرورگرت رو تقلید می‌کنه

چرا بعضی اسکریپت‌ها بلاک می‌شن و بعضی نه؟ جواب تو HTTP Headers مخفیه.

---

وقتی با `requests.get()` یه سایت رو می‌زنی، سرور می‌فهمه که این یه اسکریپته نه یه انسان. چرا؟ چون User-Agent پیش‌فرض پایتون مثل این می‌مونه که با تابلو "من رباتم" وارد بشی. سرورهای هوشمند این درخواست‌ها رو فیلتر می‌کنن.

Header Spoofing یعنی درخواست HTTP خودت رو طوری بسازی که شبیه یه مرورگر واقعی به نظر برسه. این تکنیک هم تو Bug Bounty کاربرد داره، هم تو Web Scraping، هم وقتی می‌خوای WAF رو دور بزنی و ببینی پشتش چی هست.

نکته کلیدی اینه که فقط User-Agent کافی نیست. سرورهای پیشرفته‌تر Accept، Accept-Language و حتی ترتیب هدرها رو هم چک می‌کنن. یه درخواست واقعی Chrome ده‌ها هدر داره که همه باید منطقی باشن.

---

💻 مثال عملی:

```python
import requests

headers = {
'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36',
'Accept': 'text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8',
'Accept-Language': 'en-US,en;q=0.5',
'Connection': 'keep-alive',
}

response = requests.get('https://target.com', headers=headers)
print(response.status_code)
```

---

🔗 ابزار/منبع: httpbin.org/headers برای تست هدرهایی که می‌فرستی

#python #webscraping #bugbounty #headers #هک_اخلاقی

@codacker

―――――――――――――――――
🎓 مسترکلاس یادگیری هک از صفر تا حرفه‌ای
🔗 codacker.ir/product/hs-masterclass

سه چیزی که یه سیستم رو تسخیر می‌کنن — و اکثرا با هم اشتباه گرفته می‌شن


سال ۲۰۱۶، شبکه‌ی یه بیمارستان بزرگ در آمریکا قفل شد. نه توسط یه هکر با هودی، بلکه توسط سه لایه بدافزار که ماه‌ها پیش نصب شده بودن — و کسی نفهمیده بود.


**Trojan** اولین لایه‌ست. یه فایل به ظاهر سالم — PDF، نرم‌افزار، آپدیت جعلی — که وقتی اجرا می‌شه، در پشتی باز می‌کنه. کارش اینه که وارد بشه. نه بیشتر. Trojan به خودی خود مخرب نیست؛ حامله. payload اصلی رو با خودش می‌آره یا download می‌کنه. همون بیمارستان؟ یه فایل Excel با ماکرو آلوده، نقطه‌ی ورود بود.

**RAT** — یعنی Remote Access Trojan — لایه‌ی دومه. بعد از ورود، این بدافزار به مهاجم یه کنسول کامل می‌ده: صفحه رو می‌بینه، کیبورد رو ضبط می‌کنه، فایل‌ها رو جابجا می‌کنه، حتی دوربین رو روشن می‌کنه. ابزارهایی مثل `njRAT`، `DarkComet` یا `Quasar RAT` سال‌هاست استفاده می‌شن. ارتباط معمولاً روی پورت‌های غیرمعمول یا حتی از طریق DNS tunneling برقراره — که فایروال‌های ساده ازش رد می‌شن.

**Rootkit** لایه‌ی سومه و خطرناک‌ترینه. اینجاست که اکثرا اشتباه می‌کنن — فکر می‌کنن Rootkit یه بدافزار مجزاست. نه. Rootkit یه مکانیزمه؛ مخفی‌کاری در سطح kernel. وقتی Rootkit نصبه، حتی آنتی‌ویروس‌ها فرآیندهای مخرب رو نمی‌بینن. چون Rootkit به سیستم‌عامل دروغ می‌گه. `ls`، `ps`، `netstat` — همه دستکاری‌شده‌ن. تشخیصش نیاز به ابزارهایی مثل `chkrootkit` یا `rkhunter` داره، یا آنالیز حافظه با `Volatility`.

---

یه نمونه‌ی ساده از رفتار RAT در ترافیک شبکه:

```
C2 Server → Victim
GET /cmd?id=victim_001&cmd=screenshot HTTP/1.1
Host: totally-normal-domain.com
```

این HTTP request به نظر معمولیه. اما `cmd=screenshot` داره دستور می‌ده. اگه ترافیک رمزنگاری نشده باشه، یه IDS خوب این pattern رو می‌گیره.

---

قان

یه شب، ۱۴ تا تب مرورگر باز بود فقط برای پیدا کردن ساب‌دامین‌های یه هدف

‎subfinder‎ زدی، بعد ‎httpx‎، بعد باید خروجی رو دستی می‌ریختی تو ‎naabu‎، بعد نتیجه رو کپی می‌کردی تو یه فایل برای ‎nuclei.‎ هر بار همین مسیر، هر بار همین کپی-پیست‌ها. یه جایی وسط این چرخه از خودت می‌پرسی: چرا این کارو خود ابزارها برام نمی‌کنن؟

جواب اینه که قرار نیست بکنن. هر ابزار برای یه کار ساخته شده، نه برای گردش‌کار تو. اینجاست که اکثرا اشتباه می‌کنن — فکر می‌کنن باید صبر کنن یه ابزار همه‌کاره پیدا کنن، در حالی که راه‌حل یه اسکریپت ۳۰ خطیه که فقط مال خودشونه.

یه ‎CLI‎ شخصی یعنی تو منطق ریکان خودتو کد می‌کنی، نه اینکه دنبال فلگ درست تو داکیومنت ابزار بقیه بگردی:

#!/bin/bash
subfinder -d $1 -silent | httpx -silent | tee live.txt | naabu -silent -o ports.txt
nuclei -l live.txt -t cves/ -o result.txt

حالا کل زنجیره‌ای که قبلاً ۲۰ دقیقه دستی انجام می‌دادی، شده یه دستور: ./recon.sh target.com. این فقط سرعت نیست — کنترله. تو می‌دونی دقیقاً چی داره اجرا میشه، کجا باگ می‌خوره، کجا باید فیلتر اضافه کنی. ابزار آماده رو هر کسی داره، منطق شخصی رو فقط تو داری.

#‎Automation‎

@‎codacker_ir‎

هک یه ابزار نیست. یه طرز فکره.

یکسری مقاله جدید تو بازی هانت و هک و باگ بانتی دارم مینویسم مثل همین میزارم تو سایت

یه فایل ‎main.js‎ دو مگابایتی، و یه ‎API‎ ‎Key‎ که کسی حواسش نبوده

یه بار روی یه تارگت بزرگ، بعد از دو روز گشتن تو صفحات وب و هیچی پیدا نکردن، رفتم سراغ همون فایل‌های ‎js‎ که همه رد می‌شن ازشون چون «خب فقط کده دیگه». نیم ساعت بعد یه ‎endpoint‎ داخلی پیدا کردم که تو هیچ صفحه‌ای لینک نشده بود — /‎api/v2/internal/debug.‎ همون یکی کل مسیر گزارش رو باز کرد.

فایل‌های ‎JS‎ بعد از ‎build‎ و ‎minify‎ شدن، برای چشم آدم یه بلوک بی‌شکل کدن. ولی برای ابزاری مثل ‎LinkFinder‎ فقط یه رشته‌ست که باید توش الگو پیدا کرد — مسیرهایی که با /‎api‎ یا /‎v1‎ شروع می‌شن، دامنه‌های ساب‌دامین داخلی، توکن‌هایی که با الگوی ‎base64‎ یا ‎JWT‎ جفت و جور می‌شن.

کار رو این‌جوری شروع کن:

python3 linkfinder.py -i https://target.com/static/main.js -o cli

ولی خروجی خام کافی نیست. باید فیلترش کنی — چون ۹۰٪ چیزی که پیدا می‌کنه یا ‎CDN‎ عمومیه یا مسیر استاتیک بی‌ارزش. اونجاست که اکثرا اشتباه می‌کنن: همه‌ی ‎endpoint‎ها رو دستی چک می‌کنن بدون اولویت‌بندی. دنبال الگوهایی باش که کلمات ‎admin‎، ‎internal‎، ‎debug‎، ‎v2‎، ‎config‎ توشونه — این‌ها معمولا اون چیزیه که تیم ‎dev‎ فراموش کرده مخفی کنه.

برای ‎secret‎ها هم اگه دنبال دستیه بیشتری هستی، ‎trufflehog‎ یا ‎gitleaks‎ رو مستقیم رو همون فایل ‎js‎ اجرا کن، نه فقط رو ریپو گیت. خیلی وقتا کلید ‎API‎ مستقیم تو کد فرانت هاردکد شده، چون کسی فکر نکرده مرورگر هم یه محیط عمومیه.

#‎JSRecon‎

@‎codacker_ir‎

هک یه ابزار نیست. یه طرز فکره.

یه ‎commit‎ حذف شده، ولی کلید هنوز زنده‌ست

یه محقق بگ‌بانتی یه ریپوی عمومی رو پیدا کرد که ۲ سال پیش یه بار ‎AWS‎ ‎key‎ توش ‎commit‎ شده بود، بعد یه ‎commit‎ دیگه اومده و فایل رو پاک کرده. تیم امنیتی شرکت فکر می‌کرد چون فایل حذف شده، مشکل حل شده. ولی کلید تو ‎history‎ گیت هنوز بود، فعال بود، و همون باگ‌بانتی چند هزار دلار پاداش گرفت.

اینجاست که اکثرا اشتباه می‌کنن: فکر می‌کنن ‎git‎ ‎history‎ یعنی چیزی که الان می‌بینی. ولی هر ‎commit‎ قبلی هنوز تو .‎git‎ هست، حتی اگه از ‎HEAD‎ حذف شده باشه. برای همینه ابزارهایی مثل trufflehog و gitleaks کل تاریخچه‌ی ‎commit‎ها رو اسکن می‌کنن، نه فقط فایل‌های فعلی. یه دستور ساده:

trufflehog git https://github.com/target/repo --only-verified

فلگ --only-verified مهمه — یعنی فقط سکرت‌هایی که واقعاً تست شدن و فعالن رو نشون بده، نه هر رشته‌ای که شبیه ‎API‎ ‎key‎ به نظر میاد. با gitleaks هم می‌تونی همین کار رو با یه ‎config‎ سفارشی برای پترن‌های خاص شرکت انجام بدی:

gitleaks detect --source . --report-format json

نکته‌ی طلایی: فورک‌ها و ‎pull‎ ‎request‎های بسته‌شده هم ‎history‎ خودشون رو دارن. خیلی از تیم‌ها ریپوی اصلی رو تمیز نگه می‌دارن ولی یادشون میره یه ‎PR‎ قدیمی که هیچوقت ‎merge‎ نشده، هنوز یه ‎commit‎ با کلید واقعی توش داره.

#‎SecretScanning‎

@‎codacker_ir‎

هک یه ابزار نیست. یه طرز فکره.