
<div className="article-lead">

In a fast-moving tech industry, the **IT project manager** role is still misunderstood. Plenty of companies, from startups to huge enterprises, lean on a broken idea: either the PM must be a **hardcore programmer**, or the PM is basically a **senior admin** whose job is to **relay** client email to engineering and paste replies back. Neither version is fair, and neither is what strong delivery needs.

</div>

<Notice type="info">

**In one sentence:** Your worth as a PM is **not** “lines of code written,” and **not** “how fast you forwarded a chat.” The real job is to be a **bridge** between **business problems** and **how the team actually ships**.

</Notice>

So let’s be clear: that’s **strategic work**, not courier work. The sections below unpack the usual myths, what the “forwarder” trap looks like, and how to shift toward real integration.

## The myth of the coding project manager

One myth refuses to die: *you can’t lead a software project if you don’t code.* That mixes up **leading delivery** with **writing the implementation**.

A solid IT PM is strong at **process**, **integration**, and **communication**, not at memorizing every layer of the stack. A simple rule works well: **know your limits**, say what you don’t know out loud, and **pull in** engineers who *do* know.

Your day job is to **orchestrate**: link objectives to solutions, ask the uncomfortable questions early, and turn dense technical language into something **clients can act on**. You’re meant to be the **thinking** part of the operation, not the fastest typist in the thread.

## The “message forwarder” syndrome (and why it happens)

A lot of projects feel chaotic, and PMs feel stuck, when the organization **never really invested** in project discipline. When maturity is low, leadership quietly shrinks the PM role into a **human router**.

<Notice type="warning">

**The toxic loop:** maybe you’ve seen this pattern:

1. The client sends a **vague** email about a new feature.
2. The PM **copy-pastes** it into a ticket and sends it to dev as-is.
3. Developers push back because the ask **doesn’t make sense** as written.
4. The PM **copy-pastes** the technical pushback and forwards it straight back to the client.

</Notice>

In that loop, the PM often has **no real room** to analyze the request, weigh risk, or make a call. They end up feeling like a **walking inbox**, and everyone else feels it too.

## Why that pass-through style wrecks projects

**Engineering burns out.** Devs get squeezed because nobody is shielding them from **half-baked** demands. Reverse-engineering the client’s **business logic** from a forwarded paragraph shouldn’t fall only on the people writing code.

**Problems show up late.** Without someone thinking strategically, “risks” live in a spreadsheet until they become **real blockers** in the middle of the sprint.

**Respect drops on both sides.** Engineering starts treating the PM as **admin overhead**, and the client sees a **slow messenger** instead of someone who can frame options and trade-offs.

## The shift: become a strategic integrator

A strong PM doesn’t **blindly forward** the client’s latest ping. They **intercept** it.

You sit with the **core business need** first. You talk with a **tech lead** or senior engineer: *Can we build this? Do we have capacity this sprint? What breaks if we say yes?* Only after that do you step back to the client and the team with a **clear plan**, not a ping-pong chain of raw frustration.

**Translation** beats **forwarding**. **Alignment** beats **noise**.

<Notice type="tip">

**Takeaways you can actually use**

- You’re aiming to be a **strategic integrator**, not a **message forwarder**. If your company only lets you **ticket and relay**, that’s worth naming out loud, and pushing back on where you need **authority to clarify** work before it hits the team.

- **Not knowing how to code is fine.** Your leverage is getting the right experts in one conversation and steering everyone toward **one business goal**.

- Breaking the forwarder habit takes **courage**: you take on more **ownership** for how work is framed. It’s uncomfortable at first, but it’s also how PMs stop being treated as **paperwork** and start being treated as **partners**.

</Notice>

> **Something to ask yourself honestly:** Are you **leading** your team, or mostly **moving other people’s emails** between inboxes?


You don’t need to be a hardcore coder to lead software work, and you shouldn’t be a human router either. What IT PMs are actually for, and how to escape the forwarder trap.

The Reality of IT Project Management: Stop Being a Glorified Message Forwarder


In cybersecurity, quickly finding and reasoning over **Common Vulnerabilities and Exposures (CVE)** still matters. This project is a **hybrid vulnerability search and analysis pipeline**: it bridges **keyword search** and **semantic retrieval** (Sentence-BERT + FAISS), then layers a **locally hosted DeepSeek-class LLM** for structured technical analysis, plus **NVD** enrichment and a **validation / self-refinement** loop when model output is thin or malformed.

It is meant for **research**, **labs**, and **threat-intelligence-style workflows**, not as a turnkey production appliance without your own review, caching, and governance.

## Acknowledgements

Thank you to the engineers whose feedback and ideas shaped this architecture:

- [Rifqi HZ](https://www.linkedin.com/in/rifqihz/)
- [Riyan Firmansyah](https://www.linkedin.com/in/riyanfirmansyah/)
- [Harry Adinanta](https://www.linkedin.com/in/harryadinanta/)
- [Arif D](https://www.linkedin.com/in/arifd/)

## Architecture and flow

The diagram shows how records move from **CVE JSON** through **hybrid search**, **NVD enrichment**, and **LLM analysis**.

![Architecture: CVE JSON, hybrid search, NVD API, DeepSeek analysis, output](/images/post/hybrid-cve-search-architecture.png)
*End-to-end flow from ingestion to structured analysis.*

## Output screenshot

Below is a **representative** terminal or log capture after a run (layout depends on your shell and logging).

![Example pipeline output: DeepSeek analysis and structured sections](/images/post/hybrid-cve-search-output.png)
*Illustrative run: search hits, NVD context, and formatted LLM output.*

## Technology stack

- **Python 3**: orchestration and tooling.
- **Sentence-BERT** (`sentence-transformers`): dense embeddings (e.g. `all-MiniLM-L6-v2`).
- **FAISS**: fast similarity search over normalized vectors (`IndexFlatIP` in the reference script).
- **DeepSeek R1 / Qwen family (example: 32B-class)**: served **locally** behind an HTTP API compatible with chat-completions style calls.
- **aiohttp** and **requests**: async batching to NVD and synchronous LLM calls, depending on the code path.
- **JSON** and **regex**: structuring data, stripping model “thinking” blocks, and validating section headers in LLM replies.

## Core workflow

**1. CVE JSON ingestion:** load vulnerability records from `cve_data.json`. Each entry should include at least an `id` and an `output` field (description text used for search).

**2. Embedding generation and indexing:** encode every `output` with Sentence-BERT, L2-normalize embeddings, and add them to a FAISS index (saved as `cve_index.faiss` in the sample).

**3. Hybrid search engine**

- **Keyword first:** scan descriptions for query terms, score with embedding cosine similarity when keywords hit.
- **Semantic fallback:** if keyword results are weak, query FAISS with the query embedding.
- **Dynamic thresholding:** `adjust_threshold(query)` tweaks similarity cutoffs from query length (short vs long queries).

**4. DeepSeek LLM analysis:** after retrieval, build a **structured prompt** (CVE id, advisory text, sections for type, severity, exploitability, components, mitigation). POST to your local model endpoint.

**5. Autonomous self-refinement:** if the reply fails validation (missing sections, too short), generate **feedback**, append **previous response**, and **re-prompt**, up to a small retry budget (e.g. three attempts).

**6. Data enrichment and logging:** fetch live metadata from the **NVD JSON API** (CVSS where available, references, timestamps). Print or log consolidated results.

<Notice type="tip">

Replace `BASE_URL`, `MODEL_NAME`, and file paths with **your** server layout. Never commit API keys or internal hostnames you cannot share.

</Notice>

## Current development status

**Shipped in the reference prototype**

- Hybrid search (keyword path + FAISS fallback).
- FAISS build, search, and index save/load pattern.
- Local LLM HTTP integration.
- NVD fetch and parse helpers (CVSS v4 / v3.1 / v2 fields as available).
- Response validation and refinement loop scaffolding.

**Still pending**

- Hardened **deployment** docs (Docker Compose, GPU notes, health checks).
- Formal **retrieval evaluation** (precision/recall or nDCG on a labeled query set).
- **Web UI** or dashboard instead of CLI-only.
- **Caching** (embeddings, NVD responses, LLM outputs) for high-volume use.
- Richer logging around each refinement attempt.

## Important deployment notes

- **Infrastructure:** you need the DeepSeek (or compatible) model **running and reachable** at the configured base URL; match tokenizer and context limits to your hardware.
- **Validation:** current checks are mostly **regex / structure**. Stronger pipelines might add scoring, judge models, or human review for high-risk outputs.
- **Performance:** without caching, repeated queries and large prompts can be slow or expensive, so plan batch sizes and concurrency limits.
- **NVD:** follow [NVD API terms](https://nvd.nist.gov/developers/terms-of-use) and rate limits; add backoff on errors.

<Notice type="warning">

Use this tooling only where you are **authorized** to query vulnerability data and run analysis. Combining CVE text with LLM output does not replace policy, legal review, or patch management.

</Notice>

## Conclusion

The pipeline demonstrates how **vector search** and **LLM reasoning** can be chained for CVE-centric workflows: find candidates, enrich from NVD, then produce consistent write-ups, while iterating when the model drifts.

<Notice type="info">

**To run it yourself:** start your local inference server, place a valid `cve_data.json` next to the script, install `sentence-transformers`, `faiss-cpu` (or `faiss-gpu`), `aiohttp`, and `requests`, then review the appendix code paths (especially async NVD batching and refinement) before trusting output in production.

</Notice>

## Appendix A: Example `cve_data.json`

```json
[
    {
        "id": "CVE-2025-21697",
        "output": "The Linux kernel is vulnerable due to improper handling of job pointers. Specifically, after a job completes, the job pointer must be explicitly set to NULL to prevent warnings and potential crashes when unloading the driver. This vulnerability can lead to unintended behavior or memory corruption. The issue arises in the kernel's handling of job management, where a stale pointer may cause dereferencing of invalid memory. This issue affects kernel versions prior to the fix in the latest release, which addresses the pointer management. System administrators are advised to update their kernels to the latest stable version to mitigate potential risks of exploitation."
    },
    {
        "id": "CVE-2025-0652",
        "output": "A critical vulnerability exists in GitLab EE/CE versions 16.9 before 17.7.7, 17.8 before 17.8.5, and 17.9 before 17.9.2. Unauthorized users can exploit this vulnerability to gain access to confidential information. The issue arises due to improper access controls that fail to sufficiently restrict certain sensitive data, allowing unauthorized users to view or manipulate it. This can result in data leakage or unauthorized access to sensitive project information. GitLab has released fixes for affected versions, and users are strongly recommended to upgrade to the latest patched versions to prevent exploitation of this vulnerability."
    }
]
```

## Appendix B: Reference source (Python)

Below is the **research / prototype** script as used in development. Thread `cve_info` consistently through `build_prompt` in refinement paths, tighten SSL usage for NVD calls in production, and add tests before relying on it for anything critical.

```python
import json
import aiohttp
from aiohttp import ClientSession, TCPConnector
import asyncio
import requests
import logging
import numpy as np
from sentence_transformers import SentenceTransformer
import faiss
import re

# logging.basicConfig(level=logging.INFO, format="%(asctime)s - %(levelname)s - %(message)s")

def load_cve_data(file_path):
    try:
        with open(file_path, 'r') as f:
            return json.load(f)
    except FileNotFoundError:
        logging.error(f"File {file_path} not found!")
        return []
    except json.JSONDecodeError:
        logging.error(f"File {file_path} is not a valid JSON!")
        return []

class CVEModel:
    def __init__(self, model_name='all-MiniLM-L6-v2'):
        self.model = SentenceTransformer(model_name)

    def encode_texts(self, texts):
        embeddings = self.model.encode(texts)
        return embeddings / np.linalg.norm(embeddings, axis=1, keepdims=True)

class FaissIndex:
    def __init__(self, embeddings):
        self.d = embeddings.shape[1]
        self.index = faiss.IndexFlatIP(self.d)
        self.index.add(embeddings)

    def search(self, query_embedding, k=1):
        distances, indices = self.index.search(query_embedding, k)
        return distances, indices

    def save(self, filename):
        faiss.write_index(self.index, filename)

def adjust_threshold(query):
    words = query.split()
    filtered_words = [word for word in words if len(word) > 3]
    num_words = len(filtered_words)

    if num_words > 2:
        return 0.5
    elif num_words < 2:
        return 0.1
    elif num_words == 2:
        return 0.3
    return 0.7

class CVESearch:
    def __init__(self, data, model, faiss_index):
        self.data = data
        self.model = model
        self.faiss_index = faiss_index

    def search_by_keywords(self, query, threshold=0.7):
        query_lower = query.lower()
        matching_entries = []

        for entry in self.data:
            matching_words = [word for word in query_lower.split() if word in entry['output'].lower()]
            if matching_words:
                output_embedding = self.model.encode_texts([entry['output']])
                query_embedding = self.model.encode_texts([query])

                similarity = np.dot(query_embedding, output_embedding.T)[0][0]
                if similarity >= threshold:
                    matching_entries.append({
                        'ID': entry['id'],
                        'Distance': similarity,
                        'Output': entry['output']
                    })
        return matching_entries

    def search_query(self, query, k=1, threshold=0.7):
        threshold = adjust_threshold(query)
        keyword_results = self.search_by_keywords(query, threshold)
        if keyword_results:
            return keyword_results

        query_embedding = self.model.encode_texts([query])
        distances, indices = self.faiss_index.search(query_embedding, k)

        results = []
        for i in range(len(indices[0])):
            idx = indices[0][i]
            if distances[0][i] >= threshold:
                result = {
                    'ID': self.data[idx]['id'],
                    'Distance': distances[0][i],
                    'Output': self.data[idx]['output']
                }
                results.append(result)

        return results

BASE_URL = "{{URL}}"
MODEL_NAME = "{{DeepSeekModel}}"
HEADERS = {"Content-Type": "application/json"}

def chat_with_model(prompt):
    payload = {
        "model": MODEL_NAME,
        "messages": [{"role": "user", "content": prompt}],
        "max_tokens": 5000
    }
    response = requests.post(f"{BASE_URL}/chat/completions", json=payload, headers=HEADERS)
    if response.status_code == 200:
        return response.json()
    else:
        return {"error": f"Request failed with status code {response.status_code}"}

data = load_cve_data("cve_data.json")
cve_model = CVEModel()
output_texts = [entry['output'] for entry in data]
output_embeddings = cve_model.encode_texts(output_texts)
faiss_index = FaissIndex(output_embeddings)
faiss_index.save("cve_index.faiss")

cve_search = CVESearch(data, cve_model, faiss_index)

query = "server-side request forgery"
results = cve_search.search_query(query, k=5, threshold=0.5)

def clean_deepseek_response(response):
    return re.sub(r"<redacted_thinking>.*?</redacted_thinking>", "", response, flags=re.DOTALL).strip()

async def fetch_cve_data(session, url):
    connector = TCPConnector(ssl=False)
    async with ClientSession(connector=connector) as session:
        async with session.get(url) as response:
            if response.status == 200:
                return await response.json()
            logging.error(f"Failed to fetch data from {url}")
            return None

def parse_cve_data(response):
    cve_item = response.get("vulnerabilities", [])[0].get("cve", {})
    return {
        "id": cve_item.get("id", "N/A"),
        "published": cve_item.get("published", "N/A"),
        "last_modified": cve_item.get("lastModified", "N/A"),
        "description": next((d.get("value") for d in cve_item.get("descriptions", []) if d.get("lang") == "en"), "No description available"),
        "cvss_v40": next((m.get("cvssData", {}).get("baseScore") for m in cve_item.get("metrics", {}).get("cvssMetricV40", [])), "N/A"),
        "cvss_v31": next((m.get("cvssData", {}).get("baseScore") for m in cve_item.get("metrics", {}).get("cvssMetricV31", [])), "N/A"),
        "cvss_v2": next((m.get("cvssData", {}).get("baseScore") for m in cve_item.get("metrics", {}).get("cvssMetricV2", [])), "N/A"),
        "references": [ref.get("url") for ref in cve_item.get("references", [])]
    }

def build_prompt(advisories, cve_info, refinement_feedback=None, previous_response=None):
    base = f"""
You are a cybersecurity expert. Analyze the following vulnerability advisories and provide structured responses.
Ensure your response is detailed, well-structured, and follows the format below.

### CVE ID:
{cve_info['id']}

### Vulnerability Type:
### Vulnerability Description:
### Severity Level:
### Affected Versions:
### Exploitability:
### Affected Components:
### Mitigation or Workaround:

**Advisories:** {advisories}
"""
    if previous_response:
        base += f"\n\n### Previous Response:\n{previous_response}\n"
    if refinement_feedback:
        base += f"\n\n### Refinement Instructions:\n{refinement_feedback}\n"
    return base

def validate_response(response):
    required_sections = ["Vulnerability Type", "Vulnerability Description", "Severity Level", "Exploitability"]
    for section in required_sections:
        if f"### {section}:" not in response:
            return False
    return True

def is_significant_change(old_response, new_response, threshold=0.1):
    old_len, new_len = len(old_response), len(new_response)
    if old_len == 0:
        return True
    return abs(new_len - old_len) / old_len > threshold

def refine_deepseek_response(original_prompt, deepseek_response):
    issues = []
    if "Vulnerability Type:" not in deepseek_response:
        issues.append("Missing 'Vulnerability Type'.")
    if "Vulnerability Description:" not in deepseek_response or len(deepseek_response.split("Vulnerability Description:")[1].strip()) < 50:
        issues.append("Description too short.")

    if issues:
        feedback = "Improve based on: " + ", ".join(issues)
        return build_prompt(original_prompt, None, refinement_feedback=feedback, previous_response=deepseek_response), True
    return deepseek_response, False

async def process_advisories_in_batches(results, batch_size=2):
    async with aiohttp.ClientSession() as session:
        for i in range(0, len(results), batch_size):
            batch = results[i:i + batch_size]
            advisories = "\n\n".join([f"ID: {res['ID']}\nOutput: {res['Output']}" for res in batch])
            tasks = [fetch_cve_data(session, f"https://services.nvd.nist.gov/rest/json/cves/2.0?cveId={res['ID']}") for res in batch]
            responses = await asyncio.gather(*tasks)

            for response, res in zip(responses, batch):
                if response:
                    cve_info = parse_cve_data(response)
                    prompt = build_prompt(advisories, cve_info)
                    retries = 3
                    previous_response = ""

                    while retries > 0:
                        analysis_result = chat_with_model(prompt)
                        if "choices" in analysis_result:
                            raw_message = analysis_result['choices'][0]['message']['content']
                            cleaned_message = clean_deepseek_response(raw_message)

                            if validate_response(cleaned_message):
                                if retries < 3 and not is_significant_change(previous_response, cleaned_message):
                                    break
                                print("\nDeepSeek Analysis Result:\n", cleaned_message)
                                break

                            previous_response = cleaned_message
                            prompt, needs_refinement = refine_deepseek_response(prompt, cleaned_message)
                            if not needs_refinement:
                                break
                        retries -= 1

if results:
    asyncio.run(process_advisories_in_batches(results, batch_size=2))
```

The refinement helper passes `None` as `cve_info` in one branch. **Fix that** by keeping a real `cve_info` dict when rebuilding prompts so `cve_info['id']` never crashes. The async `fetch_cve_data` helper is also a sketch: prefer a single `ClientSession`, TLS verification aligned with your policy, and structured error handling for production.


Keyword + FAISS semantic search over CVE text, NVD enrichment, and structured DeepSeek analysis, with validation loops. Full architecture, stack, workflow, and source appendices.

Hybrid CVE Search & DeepSeek Analysis: A Semantic Security Pipeline


The ESP32 is an inexpensive microcontroller with on-board Wi‑Fi and Bluetooth. This project uses **promiscuous mode** so the radio can pass raw 802.11 frames to your code, extracts **source MAC addresses**, and calls a small HTTP API to show **vendor names** (OUI lookup). That is useful for labs, inventory, and learning how Wi‑Fi looks on the air.

**What this article covers:** enabling promiscuous RX on ESP32, deduplicating MACs, batching API calls, and staying on the right side of ethics and law.

## The idea in plain language

Normally a Wi‑Fi interface drops frames that are not addressed to it. Promiscuous mode turns that filter off (within chip limits) so a callback receives more of what is in the air. From each buffer you can read bytes that correspond to MAC addresses, build a unique list, and only then query an online database that maps the first bytes of a MAC (OUI) to a manufacturer.

The firmware alternates between “listen for a while” and “pause, resolve vendors, print, clear, repeat” so Serial stays readable and you do not hammer the API.

## What you get at the end

- **Layer 2 visibility** without joining a network as the main goal (you still use STA mode here because the sketch uses the internet for lookups).
- **Stable MAC list** using hash sets so each address is processed once per cycle.
- **Vendor labels** from a JSON API (`maclookup.app` in the example).
- **Predictable timing**: sniff window → pause → lookups → resume.

## What you need

- An ESP32 dev board.
- Arduino IDE with the ESP32 core installed.
- Libraries: built-in `WiFi`, `HTTPClient`, `esp_wifi`; add **ArduinoJson** from the Library Manager.

## How the sketch is organized

1. Connect in `WIFI_STA` and wait for an IP (needed for HTTP in this design).
2. Call `esp_wifi_set_promiscuous(true)` and register `esp_wifi_set_promiscuous_rx_cb`.
3. In the callback, parse the buffer, format a MAC string, insert into a set if new, print a short line on Serial.
4. When a timer fires, turn promiscuous mode off, iterate MACs, `GET` the API, parse JSON, collect matches.
5. Print a summary, clear the sniff set, restart the timer, enable promiscuous mode again.

<Notice type="tip">

802.11 frame layouts differ by type; the sample uses a fixed byte offset to keep the example short. Treat it as a learning aid: validate offsets with real captures if you depend on them.

</Notice>

## Firmware (Arduino sketch)

Set your Wi‑Fi credentials before uploading.

```cpp
#include <Arduino.h>
#include <WiFi.h>
#include <HTTPClient.h>
#include <ArduinoJson.h>
#include <unordered_set>
#include <vector>
#include <string>
#include <esp_wifi.h>

const char* ssid = "YOUR_SSID";
const char* password = "YOUR_PASSWORD";
const char* macLookupURL = "https://api.maclookup.app/v2/macs/";

struct MacEntry {
    std::string mac;
    std::string data;
};

std::unordered_set<std::string> sniffedMacs;
std::unordered_set<std::string> lookedUpMacs;
std::vector<MacEntry> foundMacs;

unsigned long sniffingStartTime;
const unsigned long sniffingDuration = 60000;

std::string lookupMac(const std::string& mac) {
    HTTPClient http;
    http.begin(String(macLookupURL) + mac.c_str());
    int code = http.GET();
    if (code > 0) {
        String response = http.getString();
        http.end();
        return std::string(response.c_str());
    }
    http.end();
    return "";
}

void packetSniffer(void* buf, wifi_promiscuous_pkt_type_t type) {
    wifi_promiscuous_pkt_t* pkt = (wifi_promiscuous_pkt_t*)buf;
    uint8_t* macAddr = pkt->payload + 10;
    char macStr[18];
    snprintf(macStr, sizeof(macStr), "%02X:%02X:%02X:%02X:%02X:%02X",
             macAddr[0], macAddr[1], macAddr[2], macAddr[3], macAddr[4], macAddr[5]);
    std::string macAddress(macStr);
    if (sniffedMacs.find(macAddress) == sniffedMacs.end()) {
        sniffedMacs.insert(macAddress);
        Serial.printf("Intercepted MAC: %s\n", macAddress.c_str());
    }
}

void setup() {
    Serial.begin(115200);
    delay(1000);
    WiFi.begin(ssid, password);
    Serial.printf("\nConnecting to Wi-Fi: %s\n", ssid);
    while (WiFi.status() != WL_CONNECTED) {
        delay(1000);
        Serial.print(".");
    }
    Serial.println("\nWi-Fi connected.");
    WiFi.mode(WIFI_STA);
    esp_wifi_set_promiscuous(true);
    esp_wifi_set_promiscuous_rx_cb(&packetSniffer);
    sniffingStartTime = millis();
    Serial.println("Sniffing started...");
}

void loop() {
    if (millis() - sniffingStartTime >= sniffingDuration) {
        esp_wifi_set_promiscuous(false);
        Serial.println("\nSniffing window closed. API lookups...");

        for (const auto& mac : sniffedMacs) {
            if (lookedUpMacs.find(mac) == lookedUpMacs.end()) {
                Serial.printf("Querying OUI for: %s\n", mac.c_str());
                std::string response = lookupMac(mac);
                if (!response.empty()) {
                    StaticJsonDocument<512> doc;
                    DeserializationError err = deserializeJson(doc, response);
                    if (!err && doc["found"].as<bool>()) {
                        foundMacs.push_back({mac, response});
                        Serial.println("Vendor resolved.");
                    }
                }
                lookedUpMacs.insert(mac);
            }
        }

        Serial.println("\nResolved MAC inventory:");
        for (const auto& entry : foundMacs) {
            Serial.printf("MAC: %s | Data: %s\n", entry.mac.c_str(), entry.data.c_str());
        }

        sniffedMacs.clear();
        sniffingStartTime = millis();
        Serial.println("\nRestarting promiscuous mode...");
        esp_wifi_set_promiscuous(true);
    }
}
```

## What it looks like on Serial

Below is example output; your MACs and JSON payloads will differ.

![Serial Monitor showing sniffing, lookups, and resolved lines](/images/post/esp32-wifi-sniffer-serial-output.png)

*Typical flow: connect → intercept MACs → query phase → printed inventory.*

<Notice type="warning">

Use this only for **education**, **your own network**, **home labs**, or **authorized** security work. Capturing or analyzing radio traffic without permission can be illegal. Do not deploy in offices, schools, or public spaces unless you have clear written authorization and follow local law.

</Notice>

## Next steps

If you outgrow the fixed offset, pair this with proper frame parsing or PCAP-style logging. You can also cache OUIs locally to reduce API use. Whatever you build, keep purpose and permission explicit. That is what makes the project genuinely useful instead of risky.


Turn an ESP32 into a Layer‑2 Wi‑Fi sniffer: capture MACs in promiscuous mode, dedupe with a hash set, then resolve vendors via a MAC/OUI API (ethics included).

ESP32 Wi‑Fi Packet Sniffer: Promiscuous Mode & Automated OUI Lookup


Apple’s **App-Site Association (AASA)** is the small JSON contract behind **Universal Links**: it tells iOS which HTTPS URLs on your domain may open your app instead of the browser. This article walks through what the file is, where it must live, why **HTTPS** matters, and how to think about it in a security review, without treating a normal public file like a vulnerability by default.

Official overview from Apple: [Universal Links](https://developer.apple.com/library/archive/documentation/General/Conceptual/AppSearch/UniversalLinks.html).

## Quick takeaways

- AASA links your **domain** to an **iOS app** so standard `https://` links can deep-link into the app when appropriate.
- It must be served from a **fixed, documented URL** over **valid HTTPS** (no sloppy redirects).
- The file is **public configuration**, not a CVE, but it can still help testers **map routes** and **identifiers** during assessments.

## What is AASA?

**App-Site Association** is how iOS decides whether a normal web URL should **hand off to your app** or stay in Safari (or the user’s default browser). Custom schemes like `myapp://` are different: Universal Links use ordinary **https://** URLs, which feels seamless for users and keeps one URL for web and app.

When someone taps a link, the system checks whether your domain is associated with an installed app. If the association matches, the app opens; otherwise the link behaves like a regular web URL.

## Where the file lives

The filename is exactly **`apple-app-site-association`** (no `.json` suffix). iOS will fetch it from **one** of:

1. **Domain root:** `https://<your-domain>/apple-app-site-association`
2. **Recommended:** `https://<your-domain>/.well-known/apple-app-site-association`

### Minimal JSON shape

Replace `TEAMID` and `bundle.identifier` with your Apple **Team ID** and app **bundle ID**.

```json
{
  "applinks": {
    "apps": [],
    "details": [
      {
        "appID": "TEAMID.bundle.identifier",
        "paths": ["/products/*", "/help/faq"]
      }
    ]
  }
}
```

## Why HTTPS is non‑negotiable

iOS downloads this file to **verify** the app–domain relationship. That only works if the download is trustworthy.

- **Integrity:** TLS reduces the chance of tampering in transit (for example, on untrusted networks).
- **Policy:** If the file is not available over **valid HTTPS**, verification fails and **Universal Links will not behave** as you expect.

Use a proper certificate, a stable URL, and avoid redirect chains that break Apple’s fetch.

## AASA is not `robots.txt`

People sometimes call AASA “Apple’s robots.txt.” The jobs are different:

- **`robots.txt`** speaks mainly to **search crawlers** (indexing hints), in **plain text**, and is broadly informational.
- **AASA** is for **iOS**, uses **JSON**, and participates in **verified** app–site association over HTTPS.

Both can mention URL paths, but the **audience and mechanics** are not the same. Do not copy one mental model onto the other.

<Notice type="info">

**Security angle:** AASA is **meant to be fetched** by Apple’s ecosystem. It is not, by itself, a “vulnerability” in iOS. In a pentest it can still support **information gathering**: `paths` may reveal routing you care about, and you may see **Team ID** and **bundle ID** as context, not magic exploits.

</Notice>

Real problems usually come from **misconfiguration**: mapping sensitive routes, or surprising behavior in the app. Keep entries aligned with **routes you intentionally support** and document what should open in-app versus the browser.

## Closing

Ship Universal Links with the file under **`.well-known`**, **clean HTTPS**, and tests on real devices. Treat AASA as **public routing metadata**: fine for defenders and testers to read; the fix for risk is good product and config hygiene, not hiding the file.

If you run both an app and a site, maintaining an explicit list of which URLs may open the app pays off every time you change navigation or authentication.


How Apple’s AASA file powers Universal Links: where to host the JSON, why HTTPS is non‑negotiable, and how to read it from a security angle, without the myths.

Mastering Apple's App-Site Association (AASA) for Universal Links


If you run a vulnerability scan (**Nessus**, **OpenVAS**, **Qualys**, or similar) against an Ubuntu server, you may see **“SSH Weak Message Authentication Code (MAC) algorithms.”** SSH is still the right tool for remote administration, but default **sshd** configs often keep **legacy algorithms** enabled for **backward compatibility**, which scanners and compliance frameworks (PCI-DSS, HIPAA, CIS benchmarks) increasingly reject.

This guide explains **what MACs do** in SSH, **why weak MACs matter**, and how to **harden** your Ubuntu **sshd** with a **safe, reversible** procedure: backup, edit, **validate syntax**, restart, verify.

<Notice type="warning">

Always keep a **working root session** or **out-of-band console** (cloud provider serial console, IPMI, etc.) before changing SSH config. A **syntax error** in `sshd_config` can **lock you out** if you restart without testing.

</Notice>

## What SSH MAC algorithms do

An SSH session uses several cryptographic layers. Alongside **key exchange (KEX)** and **ciphers** (confidentiality), **Message Authentication Codes (MACs)** provide **integrity and authenticity** for each packet: they act like a **cryptographic checksum** so that tampering or corruption in transit is detectable, which matters against **man-in-the-middle** and noisy networks.

**Ciphers** protect secrecy; **MACs** help ensure the **data you receive is exactly what the peer sent** (within the threat model of the algorithm).

## Why scanners flag “weak” MACs

Older MACs such as **`hmac-md5`**, **`hmac-sha1`**, and truncated **96-bit** variants are **deprecated** for good reasons: attack research and compute power have **reduced trust** in legacy hash-based MACs for long-term use. Leaving them enabled advertises that the server will **negotiate down** to weaker options; many compliance baselines require **SHA-2–based MACs** such as **`hmac-sha2-256`** and **`hmac-sha2-512`**.

Hardening **MACs** is one piece of a broader **SSH crypto policy** (you may also tune **ciphers** and **KEX** in separate directives; that is out of scope for this short note).

## Step-by-step: enforce strong MACs on Ubuntu

### 1. Back up the configuration

```bash
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
```

Keep the backup until you **confirm** new connections work after the change.

### 2. Edit `sshd_config`

```bash
sudo nano /etc/ssh/sshd_config
```

Use `vim` or another editor if you prefer.

### 3. Set a strict `MACs` line

Find an existing **`MACs`** line or add one at the **end** of the file:

```text
MACs hmac-sha2-512,hmac-sha2-256
```

This list **only** allows SHA-2 MACs (order may matter for negotiation, and both are widely supported by modern clients).

In nano: **Ctrl+O** to save, **Enter**, **Ctrl+X** to exit.

### 4. Validate syntax (mandatory)

```bash
sudo sshd -t
```

**No output** usually means **syntax is valid**. If you see an error, **fix the file** before restarting.

### 5. Apply the change

```bash
sudo systemctl restart ssh
```

On many Ubuntu systems the service is **`ssh`** (or **`sshd`** depending on version). Restarting **typically does not drop your current session**, but **new** sessions must use the updated settings. **Keep this window open** until you test a **second** connection.

### 6. Verify from a client

On a **modern** machine, list MACs your **client** supports (OpenSSH):

```bash
ssh -Q mac
```

To see what the **server advertises** on port 22, you can use **nmap** (install if needed):

```bash
nmap -p 22 --script ssh2-enum-algos YOUR_SERVER_IP
```

Inspect the **`mac_algorithms`** section: you should see **only** the SHA-2 MACs you configured (plus any client/server overlap rules your versions expose).

<Notice type="tip">

Test a **second SSH login** from another terminal **before** closing your original session. If the client is too old and lacks SHA-2 MACs, **upgrade the client** or temporarily add a compatible MAC **only** after risk assessment. Do not re-enable weak MACs without a documented exception.

</Notice>

## Ongoing hygiene

Cryptographic guidance **changes**. Revisit **sshd** settings when you **upgrade OpenSSH**, **change compliance scope**, or after **major** distribution upgrades. **Automated scanning** plus **configuration management** (Ansible, cloud-init, etc.) helps keep drift low.

## Closing

Restricting SSH to **strong MAC algorithms** reduces **negotiation risk** and aligns hosts with **modern baselines**, without changing how you use SSH day to day, as long as you **validate config**, **keep a safety path**, and **verify** clients can still connect.


What SSH Message Authentication Codes do, why scanners flag weak MACs, and how to restrict sshd to SHA-2 on Ubuntu: backup, validate, restart, verify.

SSH MAC Hardening on Ubuntu: Drop Weak Algorithms Without Breaking Access


**Serialization** packs structured data into a string you can store or send. **Deserialization** unpacks that string back into values (and sometimes **objects**) in memory. When **`unserialize()`** in PHP runs on **attacker-controlled** data, the runtime may rebuild **classes** and run **magic methods**; combined with dangerous patterns like **`eval()`**, that path can lead to **PHP object injection** and **remote code execution (RCE)**.

This article explains the mechanics in order: format, how a web **search** parameter can expose the bug, how **objects** escalate impact, and **mitigations** that actually work in production.

**You will learn:** how to read PHP serialized strings, how to recognize blind deserialization in HTTP parameters, what **POI** requires, and how to break the attack class with **JSON**, **signing**, and **safe unserialize options**.

<Notice type="warning">

For **education and authorized security testing only**. Do not target systems without **explicit permission**.

</Notice>

## Concepts: serialization and the trust boundary

Think of serialization like **flat-pack furniture**: you disassemble a structure so it fits in one box for transport. Deserialization is **reassembly** at the destination.

For developers, that “box” is convenient: one database column can hold a whole array or object graph instead of many relational fields. The **security problem** is trust: if the box is opened with **`unserialize()`** and the bytes came from a **user** (query string, cookie, file upload, API body), you are asking the runtime to rebuild **whatever object graph they encoded**, including gadget classes that execute code when constructed or destroyed.

That blind trust is **insecure deserialization**. OWASP classifies it as a major category because one weak entry point can compromise the host.

## PHP serialization format (mechanics)

PHP’s `serialize()` output is deterministic text, not opaque binary. Learn to read a few patterns and debugging gets easier.

### Example: arrays, strings, integers

```php
<?php
$array   = array("Cyber", "Punk");
$string  = "Cyber Punk";
$integer = 12345;

echo 'Result data array: '. serialize($array) . PHP_EOL;
echo 'Result data string: '. serialize($string) . PHP_EOL;
echo 'Result data integer: '. serialize($integer) . PHP_EOL;
?>
```

Typical output:

```text
Result data array: a:2:{i:0;s:5:"Cyber";i:1;s:4:"Punk";}
Result data string: s:10:"Cyber Punk";
Result data integer: i:12345;
```

**How to read it**

- **`a:2:{...}`**: array with **2** elements. `i:0;` is integer key `0`. `s:5:"Cyber"` is a **string** of length **5**. Keys and values alternate inside the braces.
- **`s:10:"Cyber Punk";`**: a string of length **10** (spaces count).
- **`i:12345;`**: integer literal.

### Reversing with `unserialize()`

```php
<?php
$array   = 'a:2:{i:0;s:5:"Cyber";i:1;s:4:"Punk";}';
$string  = 's:10:"Cyber Punk";';
$integer = 'i:12345;';

echo 'Result data array: '; print_r(unserialize($array)); echo PHP_EOL;
echo 'Result data string: '; print_r(unserialize($string)); echo PHP_EOL;
echo 'Result data integer: '; print_r(unserialize($integer)); echo PHP_EOL;
?>
```

You get native PHP values back (arrays, scalars) **until** the payload starts with **`O:`**, which means an **object** is being instantiated.

## Lab walkthrough: a search form

The screenshots below use a small **search** interface to show how parameters change when you move from plain text to serialized data.

![Demo web UI for search and deserialization testing](/images/post/php-deserialization-demo-ui.png)
*Lab layout: a search field where the backend may call `unserialize()` on the input.*

### Plain string input

A normal query such as `Cyber Punk` travels as a familiar query string:

```text
?search=Cyber+Punk
```

No serialization, just URL-encoded text.

![Search with a plain string (no serialization)](/images/post/php-search-plain-string.png)
*Baseline: string-only search parameter.*

### Serialized array input

If the application **unserializes** the `search` value, you can submit a **serialized array**, for example:

```text
a:2:{i:0;s:5:"Cyber";i:1;s:4:"Punk";}
```

In the browser that becomes **percent-encoded** in the URL (long `search=...` value). After deserialization, the page may **print the array**, which is strong evidence that **user input reaches `unserialize()`** without a safe alternative.

![Search using a serialized PHP array in the parameter](/images/post/php-search-serialized-array.png)
*Array payload: serialized structure reflected after deserialization.*

If you see output resembling:

```text
Array ( [0] => Cyber [1] => Punk )
```

…you have confirmed the **deserialization entry point** for deeper testing (still only on systems you are allowed to test).

## From arrays to objects: PHP object injection (POI)

Arrays and strings are bad enough for logic bugs, but **objects** are worse: PHP may invoke **magic methods** during unserialization and teardown.

**Two ingredients for a classic chain**

1. A **class** in the application (or autoloaded) whose magic methods do something dangerous, or call **`eval()`** on properties.
2. **`unserialize()` applied to data the attacker controls** (directly or indirectly).

### Magic methods that often appear in write-ups

- **`__wakeup()`**: runs after the object is reconstructed from a serialized blob; often used to “repair” state (and sometimes abused).
- **`__destruct()`**: runs when the object is destroyed at the end of a request; historically abused in chains.

**Why `eval()` is catastrophic here**

If **`eval()`** runs on a property an attacker sets in the serialized object, they supply **PHP source**, not just data. That is a straight line to executing arbitrary code **as the PHP process**, often paired with **`system()`**, **`exec()`**, or other wrappers depending on what you place inside the evaluated string.

### Vulnerable pattern (illustrative only)

```php
<?php
class PHPObjectUser {
    public $username;
    public $password;

    function __wakeup() {
        if (isset($this->username)) {
            $str = $this->username;
            echo $str . '  ';
        }
        if (isset($this->password)) {
            eval($this->password);
            echo '  ';
        }
    }
}

if (isset($_GET['search'])) {
    $req = $_GET['search'];
    $var1 = unserialize($req);
    echo '<br><br>';
    print_r($var1);
} else {
    echo "";
}
?>
```

The critical line is **`unserialize($req)`** on **GET input**. In production code, never do this on untrusted bytes.

### Example object payload (lab)

To trigger **`__wakeup()`** with a malicious `password` string processed by **`eval()`**, an attacker might send a serialized `PHPObjectUser` like:

```text
O:13:"PHPObjectUser":2:{s:8:"username";s:13:"administrator";s:8:"password";s:13:"system('ls');";}
```

**Structure in plain terms**

- **`O:13:"PHPObjectUser"`**: object whose class name length is 13.
- **`2`**: two properties.
- **`username`** / **`password`** property names and string values follow the usual `s:N:"..."` rules.
- The **`password`** value is chosen so that **`eval()`** executes a **PHP expression** that calls the OS (here, listing files; **lab only**).

![Search with a serialized object payload (illustrative RCE chain)](/images/post/php-search-serialized-object-payload.png)
*Object injection: long encoded `search` parameter and visible effects in the lab UI.*

**What typically happens in such a broken lab**

1. The browser sends the encoded payload in **`search`**.
2. **`__wakeup()`** runs as soon as the object is materialized.
3. The server may echo **`administrator`** (username branch).
4. **`eval()`** runs the attacker-controlled PHP (e.g. **`system('ls')`**), so **command output** may appear (directory listing such as `index.php`).
5. **`print_r`** may still dump the object graph afterward, which is useful for debugging and terrifying in production.

<Notice type="info">

Treat **`eval()`** as banned in security-sensitive code paths. Prefer **safe APIs**, **subprocess** controls, and **never** evaluate strings derived from HTTP input.

</Notice>

## Mitigation strategies (practical order)

**1. Do not `unserialize()` untrusted data**  
This is the golden rule. If the bytes can be edited by a client, assume they are hostile. Use a format that cannot instantiate arbitrary PHP classes from the wire.

**2. Prefer JSON for structured data**  
Use **`json_encode()` / `json_decode()`** for request bodies and cookies when you only need arrays and scalars. JSON does not deserialize into attacker-chosen PHP classes, so typical **object gadget** chains do not apply the same way.

**3. If you must ship serialized blobs, sign them**  
Compute an **HMAC** (or similar) over the exact string using a **server-only secret**. Before calling **`unserialize()`**, verify the MAC. Any tamper breaks the signature and you can reject the input without parsing.

**4. Restrict what `unserialize()` may instantiate**  
On modern PHP, pass options such as **`['allowed_classes' => false]`** when objects are not required, or whitelist a small set of class names. Combine with **type checks** after decoding.

**5. Defense in depth**  
Least privilege for the PHP worker, hardened images, logging, and avoiding dangerous helpers (`eval`, dynamic `include` of user paths) anywhere near request handling.

## Closing

**Insecure deserialization** stays relevant because serialization feels convenient and old tutorials **`unserialize()`** cookies and parameters. Modern designs treat **JSON**, **protobuf**, or **signed tokens** as the default, and treat **`unserialize()`** on external input as a **last resort**, which is usually a mistake.

If you maintain legacy PHP, audit every **`unserialize()`**, **`phar`** wrappers, and **session** handlers that touch serialized data. Fixing trust boundaries here pays off more than chasing symptoms downstream.


Serialization vs deserialization, PHP format line-by-line, a search-form lab with screenshots, object injection to RCE, and mitigations: JSON, HMAC, and allowed_classes.

Showing posts fromworkstation

SSH MAC Hardening on Ubuntu: Drop Weak Algorithms Without Breaking Access

The Reality of IT Project Management: Stop Being a Glorified Message Forwarder