Even if yours isn't, why does it focus on an EOL Ubuntu version? Are we seriously saying that the gold standard of good development information for Darknet services is to install a 7 year old version of Ubuntu server? The APT repos for 18.04 are probably not even available nowadays!
I was hoping if someone could create a useful guide on how we can surf DN like what to find exactly what we want to and maybe know who's real and who's not, for me I'm trying to find someone who could provide database of audio call recordings direct from the Telecom service providers, and for others it can be other vendors etc.
Somethings never change over time, be it 7 years or 70 years.those commands still work on Debian 12 and even Ubuntu server 24.04.03 LTS. Ubuntu is based on debian. so all those commands and configurations are possible on Debian 12 nowadays. BTW, if somebody does not know about Debian based Linux distros or how to update package repositories on debian based distros, they should not be launching a darknet marketplace, I could easily modify that guide for Debian 12, but I am not gonna spoon-fed people, there are some principles that they should know themselves. if they don't know, they should not be running a DNM to begin with.
I wish I'd seen this earlier when it was posted. I love this idea! I strongly believe in the darknet, have a tech background myself and definitely plan to contribute, but I won't be in time for this competition (1 day remaining).
I'll certainly be reading all the guides and learning whatever I can.
I'll certainly be reading all the guides and learning whatever I can.
Here is my Submission:
submission title: A Simple Guide to Setting up and Optimizing an Onion Service.
link: /post/11669a34b89af2e825d5
submission title: A Simple Guide to Setting up and Optimizing an Onion Service.
link: /post/11669a34b89af2e825d5
I think I have added all the posts, but I will give another 24 hours for last minute posts as there have been multiple. 24 hours, that is all that is left.
I think in deciding a winner, I will share my opinion in who should win and let the community discuss with me on who should win. I would make poll but I do not want vote manipulation just for safety. This is the absolute final chance for submissions.
I think in deciding a winner, I will share my opinion in who should win and let the community discuss with me on who should win. I would make poll but I do not want vote manipulation just for safety. This is the absolute final chance for submissions.
Shit, I found out about this contest so late, and when I just tried to post it, I got a timeout and lost my first attempt. Anyway, here goes my submission for a small, yet I reckon that very helpful trick leveraging tor for data downloading:
----
Improving speed with parallel tor circuits
When you are trying to download files from .onion repositories using a single IP address, you risk encountering restrictions during the process. Some .onion sites may block excessive download attempts, while others enforce rate limits. For instance, if you automate downloads from a Tor-based repository, you might face captchas or temporary bans (think for example, info leaks from breaches announced by ransomware hacking groups). This can happen when multiple users share the same IP or when download requests appear unusually frequent. Building a download infrastructure with multiple IPs can be made super dirty cheap rotating / balancing Tor connections, with the main advantage of it being the big network of nodes,
All download traffic initiated during a Tor session will be routed through the same exit node and its associated IP address. To change this IP, you can restart Tor, send a NEWNYM signal, or, as in our case study, run multiple Tor instances simultaneously by assigning different ports to each. Here comes the trick: generating multiple SOCKS proxies ready for use, enabling faster downloads from .onion repositories.
Here comes the script, first the Windows version:
$baseSocksPort = 9150
$baseControlPort = 8118
# Create data directory if it doesn't exist
if (-not (Test-Path "data")) {
New-Item -ItemType Directory -Path "data" | Out-Null
}
# Loop from 0 to 10
for ($i = 0; $i -le 10; $i++) {
$j = $i + 1
$socksPort = $baseSocksPort + $i
$controlPort = $baseControlPort + $i
# Create instance-specific data directory
if (-not (Test-Path "data\tor$i")) {
Write-Host "Creating directory data\tor$i"
New-Item -ItemType Directory -Path "data\tor$i" | Out-Null
}
# Construct the Tor command
$torCommand = "tor --RunAsDaemon 1 --CookieAuthentication 0 --HashedControlPassword `"`" --ControlPort $controlPort --PidFile tor$i.pid --SocksPort $socksPort --DataDirectory data\tor$i"
Write-Host "Running: $torCommand"
# Run Tor as a background process
Start-Process -FilePath "tor" -ArgumentList "--RunAsDaemon 1 --CookieAuthentication 0 --HashedControlPassword `"`" --ControlPort $controlPort --PidFile tor$i.pid --SocksPort $socksPort --DataDirectory data\tor$i" -NoNewWindow
}
Now the Mac one (in MacOS, you will need first to install bash with brew):
#!/bin/bash
base_socks_port=9150
base_control_port=8118
# Create data directory if it doesn't exist
if [ ! -d "data" ]; then
mkdir "data"
fi
# Loop from 0 to 10
for i in {0..10}
do
j=$((i+1))
socks_port=$((base_socks_port+i))
control_port=$((base_control_port+i))
if [ ! -d "data/tor$i" ]; then
echo "Creating directory data/tor$i"
mkdir "data/tor$i"
fi
# Take into account that authentication for the control port is disabled. Must be used in secure and controlled environments
echo "Running: tor --RunAsDaemon 1 --CookieAuthentication 0 --HashedControlPassword \"\" --ControlPort $control_port --PidFile tor$i.pid --SocksPort $socks_port --DataDirectory data/tor$i"
tor --RunAsDaemon 1 --CookieAuthentication 0 --HashedControlPassword "" --ControlPort $control_port --PidFile tor$i.pid --SocksPort $socks_port --DataDirectory data/tor$i
done
These scripts assumes Tor is installed and in the system PATH. For Windows, Tor can be installed via the Tor Browser or a standalone package. For macOS, use Homebrew. For Linux, use the package manager (e.g., apt, yum). Running 11 Tor instances should not consume too many resources, but if your laptop is old-ish, monitor your CPU, and consider reducing the loop range if needed.
And it's as simple as that, now you can run in parallel things like this, in separate terminal tabs or within a multiple subshell console like tmux/screen:
curl --socks5-hostname localhost:9150 -L --retry 5 --retry-delay 5 -C - -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:102.0) Gecko/20100101 Firefox/102.0" -H "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" -H "Accept-Language: en-US,en;q=0.5" -O http://site.onion/part01.rar
curl --socks5-hostname localhost:9151 -L --retry 5 --retry-delay 5 -C - -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:102.0) Gecko/20100101 Firefox/102.0" -H "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" -H "Accept-Language: en-US,en;q=0.5" -O http://site.onion/part02.rar
.
.
.
and each connection will be routed through a different tor circuit. This can be of course used for web data scrapping, and avoid triggering WAF limits per IP ... just let your imagination run free.
----
Improving speed with parallel tor circuits
When you are trying to download files from .onion repositories using a single IP address, you risk encountering restrictions during the process. Some .onion sites may block excessive download attempts, while others enforce rate limits. For instance, if you automate downloads from a Tor-based repository, you might face captchas or temporary bans (think for example, info leaks from breaches announced by ransomware hacking groups). This can happen when multiple users share the same IP or when download requests appear unusually frequent. Building a download infrastructure with multiple IPs can be made super dirty cheap rotating / balancing Tor connections, with the main advantage of it being the big network of nodes,
All download traffic initiated during a Tor session will be routed through the same exit node and its associated IP address. To change this IP, you can restart Tor, send a NEWNYM signal, or, as in our case study, run multiple Tor instances simultaneously by assigning different ports to each. Here comes the trick: generating multiple SOCKS proxies ready for use, enabling faster downloads from .onion repositories.
Here comes the script, first the Windows version:
$baseSocksPort = 9150
$baseControlPort = 8118
# Create data directory if it doesn't exist
if (-not (Test-Path "data")) {
New-Item -ItemType Directory -Path "data" | Out-Null
}
# Loop from 0 to 10
for ($i = 0; $i -le 10; $i++) {
$j = $i + 1
$socksPort = $baseSocksPort + $i
$controlPort = $baseControlPort + $i
# Create instance-specific data directory
if (-not (Test-Path "data\tor$i")) {
Write-Host "Creating directory data\tor$i"
New-Item -ItemType Directory -Path "data\tor$i" | Out-Null
}
# Construct the Tor command
$torCommand = "tor --RunAsDaemon 1 --CookieAuthentication 0 --HashedControlPassword `"`" --ControlPort $controlPort --PidFile tor$i.pid --SocksPort $socksPort --DataDirectory data\tor$i"
Write-Host "Running: $torCommand"
# Run Tor as a background process
Start-Process -FilePath "tor" -ArgumentList "--RunAsDaemon 1 --CookieAuthentication 0 --HashedControlPassword `"`" --ControlPort $controlPort --PidFile tor$i.pid --SocksPort $socksPort --DataDirectory data\tor$i" -NoNewWindow
}
Now the Mac one (in MacOS, you will need first to install bash with brew):
#!/bin/bash
base_socks_port=9150
base_control_port=8118
# Create data directory if it doesn't exist
if [ ! -d "data" ]; then
mkdir "data"
fi
# Loop from 0 to 10
for i in {0..10}
do
j=$((i+1))
socks_port=$((base_socks_port+i))
control_port=$((base_control_port+i))
if [ ! -d "data/tor$i" ]; then
echo "Creating directory data/tor$i"
mkdir "data/tor$i"
fi
# Take into account that authentication for the control port is disabled. Must be used in secure and controlled environments
echo "Running: tor --RunAsDaemon 1 --CookieAuthentication 0 --HashedControlPassword \"\" --ControlPort $control_port --PidFile tor$i.pid --SocksPort $socks_port --DataDirectory data/tor$i"
tor --RunAsDaemon 1 --CookieAuthentication 0 --HashedControlPassword "" --ControlPort $control_port --PidFile tor$i.pid --SocksPort $socks_port --DataDirectory data/tor$i
done
These scripts assumes Tor is installed and in the system PATH. For Windows, Tor can be installed via the Tor Browser or a standalone package. For macOS, use Homebrew. For Linux, use the package manager (e.g., apt, yum). Running 11 Tor instances should not consume too many resources, but if your laptop is old-ish, monitor your CPU, and consider reducing the loop range if needed.
And it's as simple as that, now you can run in parallel things like this, in separate terminal tabs or within a multiple subshell console like tmux/screen:
curl --socks5-hostname localhost:9150 -L --retry 5 --retry-delay 5 -C - -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:102.0) Gecko/20100101 Firefox/102.0" -H "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" -H "Accept-Language: en-US,en;q=0.5" -O http://site.onion/part01.rar
curl --socks5-hostname localhost:9151 -L --retry 5 --retry-delay 5 -C - -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:102.0) Gecko/20100101 Firefox/102.0" -H "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" -H "Accept-Language: en-US,en;q=0.5" -O http://site.onion/part02.rar
.
.
.
and each connection will be routed through a different tor circuit. This can be of course used for web data scrapping, and avoid triggering WAF limits per IP ... just let your imagination run free.
Hi
Here’s my modest entry for the competition — I’m not pretending to reinvent the wheel, but this is what I actually put in place to keep a service usable under DDoS.
The guide was drafted with AI’s help — I’m wiped tonight, so I’ll give it a proper pass tomorrow to make sure everything’s solid.
It’s the first service I’ve deployed on the Tor network, so I’m open to any advice.
Architecture (real, not theoretical).
Core/Main (private): Tor v3 onion served by Nginx on 127.0.0.1:18082 (can run client-auth for trusted users).
Reverse layer (disposable): short-lived Tor v3 onions, each mapping 80 → 127.0.0.1:18080 (Nginx reverse → Core).
Rotator (public): Tor v3 onion with a tiny UI + API on 127.0.0.1:18081 that hands out one of the current reverse links.
Endpoint: /rotator/api/get returns {"onion":"<current_reverse>", "ts":<unix>}.
Director (daemon): connects to Tor ControlPort 127.0.0.1:9051, creates/removes ephemeral onions, keeps a pool.json of candidates and an available.json for quick reads, and prunes anything unhealthy.
Health & hygiene: quick HEAD check over Tor before suggesting a link; TTL ≈ 45 min per reverse onion; basic rate-limit + tiny cache on the Rotator; pool auto-replenished on failures or Tor restarts.
Why this helps (advantages in practice).
Blast-radius reduction: floods burn the disposable edge, not the Core. Killing a link is cheap; the Core stays stable.
Fast recovery: when a link degrades, the Rotator suggests a fresh one in seconds — no Core changes required.
Private backbone: the Core never needs to be public; you can enable v3 client-auth and keep trusted access smooth even during storms.
Simple ops: everything is local (Nginx + Tor); backups are just torrc + HS dirs + /opt/hydrahs/*.
Scales horizontally: increase pool_size to add more disposable fronts; thresholds keep noisy links out.
Behavior under pressure (what actually happens).
Rising errors/RPS on a reverse onion → Director marks it unhealthy → Rotator stops handing it out → Director spins a replacement → users hit “Get link” again and keep going.
Tor restarts → pool/state cleared → Director repopulates automatically.
Links
Rotator: http://opikety6nukdrqeoz6drgkpnwsgmpynojs6ksspv5iv2zqtaokmjljid.onion/
Reverse link: rotates (by design) — fetch from the Rotator above.
Concept in brief: a public Rotator issues short-lived Tor links to disposable relays that forward to a private Core. Under pressure, links are retired and replaced; the Core stays stable. Full details are on the reverse and in the forum topic (pending validation).
Here’s my modest entry for the competition — I’m not pretending to reinvent the wheel, but this is what I actually put in place to keep a service usable under DDoS.
The guide was drafted with AI’s help — I’m wiped tonight, so I’ll give it a proper pass tomorrow to make sure everything’s solid.
It’s the first service I’ve deployed on the Tor network, so I’m open to any advice.
Architecture (real, not theoretical).
Core/Main (private): Tor v3 onion served by Nginx on 127.0.0.1:18082 (can run client-auth for trusted users).
Reverse layer (disposable): short-lived Tor v3 onions, each mapping 80 → 127.0.0.1:18080 (Nginx reverse → Core).
Rotator (public): Tor v3 onion with a tiny UI + API on 127.0.0.1:18081 that hands out one of the current reverse links.
Endpoint: /rotator/api/get returns {"onion":"<current_reverse>", "ts":<unix>}.
Director (daemon): connects to Tor ControlPort 127.0.0.1:9051, creates/removes ephemeral onions, keeps a pool.json of candidates and an available.json for quick reads, and prunes anything unhealthy.
Health & hygiene: quick HEAD check over Tor before suggesting a link; TTL ≈ 45 min per reverse onion; basic rate-limit + tiny cache on the Rotator; pool auto-replenished on failures or Tor restarts.
Why this helps (advantages in practice).
Blast-radius reduction: floods burn the disposable edge, not the Core. Killing a link is cheap; the Core stays stable.
Fast recovery: when a link degrades, the Rotator suggests a fresh one in seconds — no Core changes required.
Private backbone: the Core never needs to be public; you can enable v3 client-auth and keep trusted access smooth even during storms.
Simple ops: everything is local (Nginx + Tor); backups are just torrc + HS dirs + /opt/hydrahs/*.
Scales horizontally: increase pool_size to add more disposable fronts; thresholds keep noisy links out.
Behavior under pressure (what actually happens).
Rising errors/RPS on a reverse onion → Director marks it unhealthy → Rotator stops handing it out → Director spins a replacement → users hit “Get link” again and keep going.
Tor restarts → pool/state cleared → Director repopulates automatically.
Links
Rotator: http://opikety6nukdrqeoz6drgkpnwsgmpynojs6ksspv5iv2zqtaokmjljid.onion/
Reverse link: rotates (by design) — fetch from the Rotator above.
Concept in brief: a public Rotator issues short-lived Tor links to disposable relays that forward to a private Core. Under pressure, links are retired and replaced; the Core stays stable. Full details are on the reverse and in the forum topic (pending validation).
Members-only continuation
This discussion contains more posts.
Create an account or sign in to continue reading the full conversation. 20 additional posts await inside.