This article was requested on how to set up hidden services that would protect the operator. Like most things, there is an easy way and a difficult way when it comes to hidden services. If you do things the easy way, you could compromise the location of your host. Good OpSec, best practices, and an understanding of how the Tor network works will pay off dividends for privacy when running hidden services.
*Disclaimer: This information is presented for educational purposes and I am not responsible for your actions. What YOU do with this information is YOUR responsibility.*
Hidden Service Risks
Please pause here and go read the following article. The aforementioned article covers what is a hidden service and even how to set one up. In this article, I want to highlight how to set one up with privacy and security in mind for our service. For this article, I will use an nginx service but I will cover some points on email and ssh services as well. There are a lot of considerations when setting up a service and many will involve you to understand the compromises for each. I hope this information can help you and your users stay safe and private.
The first major consideration is where will we host this service, this is a critical misstep for many as they will host them in a KYC service tied directly to them, or they could use many offshore hosting options that do not require KYC. This is a personal choice and you should make the best decision for what you plan to do. This is very important based on where you reside as in some nations you may have to deal with nation-state if your service is counter to their narratives. I would advise you to tread carefully on which option you take as it may eventually put the noose around your neck. If you decide to go KYC less hosting which I recommend you will pay a premium, you can find these by doing some searches on DuckDuckGo. I will cover some of this in the next sections on connecting to these services while protecting yourself.
The second major consideration is how much you understand about how services such as web, mail, and others. If you are inexperienced I would highly recommend you spend some time setting up some tests and run them locally so that you can gain familiarity as this could also be very costly in the future. Improper configurations lead to blackmail, exploitation, and in some cases theauthorities knocking on your door. While you may not plan to run anything that is considered illegal it is still best practice to operate as though you are. Operating in this way will give you a much-needed perspective about the risks of using anonymity networks. By using services improperly we could leak our actual IP address to a would-be attacker, this could be used against us and we should refrain from allowing this attack to surface.
A third major consideration, maintaining the service. Oftentimes onions come and go, this could be part of your operation security model but it does make it harder for your users to know the current valid onion address. This consideration is important as many copycats could be nation-states and other bad actors to de-anonymize your would-be users. It can be a very dangerous world if you do not plan. There are plenty of other vectors here but this could compromise you as well and your interactions.
A fourth major consideration, I would advise you to spend some time learning about proper PGP usage as you should use this for official communications regarding your service. You should refrain from using Clearnet publications for your service, post on dread, in your XMMP groups, and allow others to do word of mouth advertisement on the internet. Using Reddit, Twitter, and other public services could compromise your operational security if you truly wish to remain private. VPN’s are also your enemy when operating a hidden service, they only shield your requests from your Internet Service Provider(ISP), but the operators of the VPN’s do have logs and in a lot of cases will provide them to law enforcement.
There are also several other smaller considerations and I will do my best to cover them in this write-up and others for you, this information will never replace your research and testing. There is a lot of value that is gained from experimenting and testing on your own. Never test in your production environment, that is a risk not worth taking.
Obtaining Device(s)
Your Internet Service Provider(ISP) and mobile internet providers are constantly building profile data about you. This is why it is important to obtain devices and use them correctly. Understanding that this information can prove you are the user connecting to a location or was activating via phone and or 2FA authentication setup on a device, even on Android this can be tracked, it is imperative you follow best practices to avoid this information ever being able to tie you to any of the devices. This process can be very tedious but it is extremely important to take the measures seriously to prevent any issues. I can not stress this enough, you can be your own worst enemy if you do not do this properly.
In the current environment it is perfectly acceptable to go out in public fully covered up and wearing a mask, in fact it is even encouraged. In doing so there are a number of benefits when obtaining a device, first and foremost pay in cash. DO NOT PAY WITH A CARD FOR YOUR PHONE OR DEVICE YOU PLAN TO USE FOR A HIDDEN SERVICE YOU WISH TO REMAIN HIDDEN. If you do pay with a card, you are essentially failing at basic operational security to setup and thus any and all measures you take after this will be on a broken foundation to which you have started. The fortress will have a weakness you introduced, do not end up like Ross. He improperly used cryptography, had bad opsec, and was quite arrogant to law enforcement. This will end badly for you if you behave in this way.
When paying in cash, obtain the cash from an ATM from a different area and not for the specific amount. It can often be better to slowly accumulate over a couple of days and weeks to get the desired amount in your normal routine pattern. Do not obtain cash at the location you plan to purchase a device at, also note I would recommend to not wear clothing you have worn into this location you wish to buy from before, wear a hat and obfuscate all that you can. Many companies do keep security recordings for months and many are using machine learning, facial recognition, and other behavioral monitoring software to sell the data to third parties. This could be leveraged against you if you were to be able to be identified for purchasing device(s) and they were implicated for any illicit actions. Once you have obtained the devices, I would encourage you to never connect them to your home network or any network with your primary devices ever. Metadata collection and correlation is a real threat to your operational security in this way.
Also note that if you purchased a phone, possibly to use with Signal or other applications never have it on and near your primary phone. This metadata collection can be a problem in the future if your device is ever identified. This metadata collection has even impacted the CIA, FBI, and counter terrorism measures in foreign countries. It is better to be safe than it is to be sorry. There are no “do-overs” when it comes to the preparation phase for such operations. You should also be prepared to destroy devices after this point if anything is compromised. There is a cost to operational security, it is not free, freedom is also not free. I would highly recommend using Tails as your operating system for your device, I would also encourage you to keep a USB drive with some files you may need such as future ssh key, pgp keys, tox information, xmpp details, and make sure it is encrypted. NOTE: BIOMETRICS ARE A HUGE RISK TO YOU, DO NOT USE THEM FOR SECURING YOUR DEVICES.
I would highly suggest a Yubikey as one method to secure a phone or device you may be using for this operation. It is not required, but definitely make sure you keep up with your USB drives that contain Tails, and the drive that contains your data. DO NOT KEEP THEM ON SAME DEVICE UNLESS YOU ARE CONFIDENT IN YOUR DISPOSAL STRATEGY.
Services
As mentioned in the earlier section, some hosting providers will operate without knowing who you are. There are many “offshore” or “bullet-proof” hosting services. Each has its pros and cons, please do your research on them. I would also recommend that you understand in doing a proper truly “hidden service” youshould use Tails to connect to it via a live image and not with your daily driver machine. Tails is a live operating system that boots from USB and by using this without persistence you will prevent logging of your activities to your device. I would recommend using Tails, routing all your research traffic over Tor, and if possible not using your home network to connect to the internet for this research to prevent logging. When possible, do not use your ISP for anything related to your hidden service if you wish to truly remain private.
Once you have identified a service you will use that will probably accept bitcoin or monero to provide you a host without knowing any customer data on you, it is now time to use these coins properly. For Bitcoin, you should use Samourai and whirlpool some sats using best practices to prevent any issues. I would advise you to obtain the sats without KYC if possible through several methods, this is to protect you in case you make a mistake along the way. Cryptography can save you or hang you, do not forget that. Monero is fairly straightforward in its use to remain private, do not run torrenting software, or anything identifiable when sending a transaction to the services. Again, for obtaining do your best to not use KYC services to further remain anonymous. Any other options that a provider may have, please do your research and understand the attack surfaces associated with each before purchasing.
We also will need an email address for this. Protonmail is great and so is Tutanota. Tutanota is a little more accessible because it does not require any other authorization methods like existing email or a phone number as Protonmail does. Many email providers are now requiring the use of a multiple authorization model for setting up an account, this is a direct result of spammers and abusers. This is a very important consideration and we should refrain from using our phone even the burner phone. Limit your attack surfaces and information disclosures. This is for your safety.
We will now need to set up our device to connect to the provider, again you should use a dedicated device that is running Tails via live USB. As previously mentioned you could easily at this time use cash while being completely anonymous in public thanks to the Covid-19 outbreak, use this to your advantage to obtain a burner phone, a disposable laptop, and refrain from connecting any of your services connected to you with these devices. I would also advise you to not be on the same networks as these devices with your other devices. Traffic logging by ISP’s even when not your own can be very telling of your behavior. It is also very important to note that having your burner phone while next to your other phone’s can and will lead to identification via metadata, avoid this at all costs. When using a burner phone keep it off when not needed and battery out of it.
Once we have setup our device and got our coins ready for purchase, and our email, we now need to connect to the service from not at home. Covid has currently thrown a wrench into some easier to hide in public methods. However, understanding the physical security operations of an offsite location could allow us to perform the purchase from the provider in safety, as we can still use their wifi with our device. I would encourage you to learn about the location of cameras and how much foot traffic of your possible destination to use. If you are in a city you may be able to connect to a number of free wifi networks or you could even leverage WPA-PSK breaking to use private networks of your choice, that is up to you. Once you have decided on what you will purchase I would suggest not to get the panel options, but only the shell. I will discuss why in the next section.
Set Up Your Hosting Account
Providers often give you a choice for a CPanel or shell, refrain from using the panels. Often time’s a provider may include tracking techniques as they custom roll them for their platform. While it may seem unlike it can and does happen, authorities are aware of this too. You need to take actions to prevent this and while it may make your setup more involved it will save you from getting de-anonymized by the provider. Providers will also cooperate with law enforcement and are not going to compromise their operation for you, they are a business. In this environment, it is better to be very paranoid as anything can be used against you.
As we now have selected our service, purchased, and now received our login credentials via our secure email. We will now need to understand that if we directly connect to the shell from a location there will be not only a key exchange but an IP to IP direct route connection. If you read the article, I told you to pause to read, then you can reference it to setup torsocks proxy and route your ssh connection over the tor network to make the initial shell connection. This will prevent an identifying connection if followed properly. Once you are shelled in you can use that article’s reference to set up a v2 hidden service for ssh. You can still use v2 and v3 together by definitions in the /etc/tor/torrc configuration as mentioned in the article. This is important as you can limit access further on the v2 shell by use of the stealth argument.
This connection method will allow us to use ssh over tor, if properly configured you will not leak any information, and will provide you a pretty good layer of privacy while you working on the newly obtained host. Refrain from ever connecting to the IP address again, now we should rely on going over the hidden service. You should lock down your ssh service based on your needs. In the next section, I will cover mapping hidden services to Unix sockets versus the use of localhost which can disclose IP information. We will now not connect to this machine again until we are ready to set up and deploy. DO NOT USE YOUR JUST OBTAINED VPS FOR TESTING.
Setting Up a Test Environment
At this point, we now need to setup a local test environment on a spare machine on our network, not accessible to the outside world. We will also not put this machine accessible on the public internet. I would encourage you to obtain a device via Craigslist or something so that it may not be traced back to you via a purchase, or obtain from the aforementioned cash method thanks to Covid. You could also use a Raspberry Pi or any number of devices that you could obtain without ordering on the internet. Your goal here is to prevent a trail. Once you install a Linux/Unix based operating system we can begin some testing and hardening. I will provide a future deep dive into hardening Linux/Unix systems, it could be a book and several books have been written on the topic. Each step you take in better understanding your setup, including even running a similar operating system and version of that of your VPS you ordered will greatly increase your security understanding and operation hazard limiting. In other words, the more time you spend on testing and securing, the better off you will be in the long term.
You can choose to use a virtual machine for your test and development environment, however, keep in mind that you will want to limit all work to that device and drive. This is important as you should not leave a trace that could be linked to you for safety reasons. This can be very tedious but in order to stay safe you will have to make some sacrifices of time and convenience as you have already to even get to this point. Install the operating system of your choice based on the operating system that will be on your VPS that you ordered. You will want to update the operating system before proceeding to setting up webserver or any other actions. Many operating system vendors address security in linux/unix environments much faster than in non nix environments. Maintaining your service will be just as important as creating it.
In a standard webserver, forum, or application server setup you would normally just map to the localhost(127.0.0.1) address and there would be no issues as per typical in most deployments. However, in a hidden service that we wish to keep private we must take a few steps to keep from such information being disclosed. Often overlooked are error messages and paths, these default to disclose version numbers and the IP address of the host they are running on. This could end very badly for an operator if this were to be leveraged against them, such as the case with Empire. Blackmail and extortion happen daily in some circles of hidden service operators. Often times law enforcement look to leverage bad operators that may have ties to other operators that they are after. To avoid this we need to take a few steps on our service(s) to do what we can to prevent them from unwanted information disclosure.
In order to keep this more digestible I will spare you the concept of Unix and Unix like operating systems to which everything is a file and to be treated as such. This includes communication protocols to drivers. This is a standard found in POSIX operating systems. Unix sockets are important as they are used by the operating system in exchange of IP addresses when dealing with communication channels. This provides us a way to configure the hidden service as well as the running service to prevent information disclosure if the service supports unix sockets. Let’s first take a look at nginx, there are plenty of other web servers, just make sure they support unix sockets. You will need a webserver to host a forum, market, or any browser related service.
We need to first install a web server on a machine on our network to walk through this configuration. I am assuming you are familiar enough with your operating system in order to use the package manager or to install from source, here are a few examples to do the installation of nginx and tor:
For Debian based Linux:
- sudo apt get install nginx tor -y
- sudo yum install nginx tor -y
FreeBSD/OpenBSD with ports system:
- sudo pkg install nginx tor -y
If you wish to use another webserver, please do some research prior to use with unix socket. You will need to confirm this. Once the web server is installed there are a couple of assumptions that are made, one it will automatically start with a baseline set with a test page at the IP address and port that it resides on as long as there is no firewall rules blocking the inbound traffic to the host.
Let’s start the web server with the following command:
Systemd hosts:
- sudo systemctl start nginx.service
These commands assume you are running a systemd based operating system if you are not, simply revert to using:
- /etc/init.d/$service $action
Replace $service with the service name such as http, httpd, or nginx. Replace $action with the action like start, stop, restart. Once the service is running to which we can confirm this with the following command(replace $service with http or nginx):
- ps -ef | grep -i $service
You can also test this by simply opening a web browser and using the following URL:
Change IP address to the IP of the host to which you have setup the web server on. You will be greeted by a welcome page.
Now that we can see the webserver is working, we should spend a little time locking down the host, going to cover that in the next section. For now, if you wish to test a few pages you can easily do this in the following directory:
- /usr/share/nginx/html
Let’s get tor daemon up and running so we can begin our configurations of our hidden service. We have already installed the daemon, but let’s get the hidden service configuration ready so we can start it up shortly. You will need to edit the following file:
- /etc/tor/torrc
In this file you will need to uncomment out four lines:
- RunAsDaemon 1
- DataDirectory
- HiddenServiceDir /var/lib/tor/hidden_service/
- HiddenServicePort 80 127.0.0.1:80
On the last line we uncommented, we will change it to the following for use with nginx over a unix socket:
- HiddenServicePort 80 unix:/var/run/nginx.sock
Once this is done, save your changes. Let’s move on to getting nginx configured and starting this hidden service over a unix socket.
Configurations
We have an operating system installed, a webserver, but we are not done in the locking it down for the hidden service. We need to map nginx to a unix socket, configure our inbound ports, and limit the amount of information our server may disclose upon error messages. Here is an example of an nginx.conf that is setup for a hidden service with some common security measures enabled:
Currently we have some options to prevent someone presenting our content on another site with the additon of:
- add_header X-Frame-Options “SAMEORIGIN”;
A line to attempt to reduce possible cross-site scripting:
- add_header X-XSS-Protection”1; mode=block”;
And some limiting of buffer sizes, for obvious reasons for various overflow attacks:
- client_body_buffer_size 1k;
- client_header_buffer_size 1k;
- client_max_body_size 1k;
- large_client_header_buffers 2 1k;
We also want to uncomment the following line which will appear in your configuration:
- server_tokens off;
Disabling server_tokens will prevent display of revealing information about our service, this is important for the operation and security of the service.
Please make the above changes in your /etc/nginx/nginx.conf file using your editor and be sure to save them.
These measure can be combined with numerous other best practices with nginx in order to reduce attack vectors on your service. There is so much more to be added with securing nginx, just do your own research and do some thorough testing. We will now need to modify the nginx port and it’s listening information. To do this edit the following file:
- /etc/nginx/sites-available/default
You will want to comment the following two lines and add a listen line like the following:
By enabling the listen to unix:/var/run/nginx.sock we are now telling nginx to listen to the unix socket that we will bind to that location. We now need to make another change to nginx as a service, to do this open edit the following file:
- /lib/systemd/system/nginx.service
In the [Service] block please add the following line:
- PrivateNetwork=yes
Once you have done this you will now need to restart the nginx service, after we restart this time we will need to change the steps we normally take to restart and I will cover that shortly. If you are running a non systemd environment please check the init scripts and restart services. To restart this time run the following commands:
- sudo systemctl daemon-reload
- sudo systemctl restart nginx
- sudo sytemctl status nginx
Now let’s get tor daemon started, to do this we need to run the following command:
- sudo systemctl start tor
You can check the status by running the following command:
- sudo systemctl status tor
Once you see a message about tor starting completely we will need to run the following command to get our onion url:
- sudo cat /var/lib/tor/hidden_service/hostname
Copy this to your clipboard, and open the Tor browser and verify you are able to resolve the onion url.
Lastly, we need to make a change to our nginx service and to do this we will need to edit the following file:
- /etc/nginx/sites-available/default
Look for the server_name line, remove the _ and replace it with your onion url. Once you have done this, it will be time to restart nginx. This time and any time in the future we will need to run three commands in order to restart nginx. This will also apply to any other service you may bind to a unix socket. The three commands to run are as follows:
- sudo systemctl stop nginx
- sudo rm /var/run/nginx.sock
- sudo systemctl start nginx
And now check again over using the Tor browser. Congratulations you now have a hidden service bound to a unix socket and not leaking most information. There are still plenty more things to go over, but for now you have a great starting point. I encourage to to do some exploring and testing on your own for your needs. Firewalls, SELinux permissions, and various other vectors still are left to be locked down. You will need to spend significant time to do this the correct way.
Testing, Service Building, Security…
As we now can use the Unix sockets for a particular service we may need for our hidden service, we can explore adding the other required services you may need to be set up this way. As we are doing this in our test environment, we should be working on automating this process to limit our time being logged into the VPS and service in the future. Remember, we can not login from home, that is a huge risk that we should not take. Consider your availability and timing for various tasks associated with the service. I will cover some of these pieces.
We are now using sockets for the services, with a hardened operating system, and solid operational security we are ready for the development and implementation of our service. Do not use GitHub, Gitlab, or any hosted code repository for your project. This will end badly for you and again is just another vector that could be used to de-anonymize you and the service. While these services provide convenience they are at the compromise of potential attack surface if any information is ever found about the repository. It is best to keep your code on a USB drive and encrypted with PGP, make sure to use a separate key for your code to keep a separation of keys for email and code.
There are lots of automation and tooling that exists in a nonoperational security-focused environment, and while they are amazing, they are attack vectors for you or your users. It is important to understand the service you wish to deploy and what is required. An important consideration is what language(s) you will use and the reliance on JavaScript. Note the majority of users of Tor are using the browser for privacy reasons and will often have javascript disabled. You may want to use PHP or rely on HTML when possible to prevent privacy issues. There is no silver bullet for secure implementations and you should take this time now that you have a development environment set up to mimic the VPS host(s) you will use to test.
Once you have constructed what your service will be, automate all processes with shell scripts. The more automation around your deployment, setup, maintenance, and backup will save you on the time needed at locations you will be logging in from. Use the development environment to your advantage and make sure that every time you will perform any tasks for the service that you understand them and have tested them thoroughly. It is also important to make sure that your development environment can be disposed of if needed. Do not disclose to others about your work in this environment or that you are working on such a service. This is more often than not, just one of many ways that operators end up in blackmail situations.
As we begin to flesh out the development environment, we will also need to do stringent security auditing. While developing the service, be sure to research every version of the software you will employ to provide the service. This includes the following(examples, your list may vary):
- Operating System
- Database
- Webserver
- Plugins
- Application Server
- Programming Language
- Tor Daemon
You will need to pay close attention to this information and confirm when security vulnerabilities are found for them. You should also be sure to check this during the development as well by checking CVE’s. This process should be done on all applications or services you write, whether a hidden service or not. In the case of a hidden service you will want to stay on top of this as adversaries will definitely be testing. Operational security of the service is just as important as your own. A leak is a leak, and you do not want to have that broadcasted all over the internet publicly.
Production Readiness Check
Now we have successfully gotten a host, done some setup for our development, and we have done our development and testing. We are ready to begin the movement to our VPS, you should understand each and every facet of this process before jumping to deploying our project to our server. Let’s revisit a couple of important items to check off prior to pushing out our new service.
- Secure device(s) obtained through untraceable method.
- VPS host(s) obtained without KYC and without traceable purchase trail.
- SSH running on the VPS host over the tor network properly.
- SSH on our device(s) running over torsocks properly.
- Tails and familiarity with using it.
- Code and configurations to setup our service(s).
- Security hardening steps we plan to implement on the VPS.
- Script(s) to automate our processes of installation, hardening, and deployment.
- Secure location that is not at our home network.
- None of our normal devices on the same network or near us at the time.
Once you are ready to deploy it will be all on you, once it is out there and in use, everything that you did to properly protect the service can and will be tested by adversaries. I would strongly encourage you to avoid only using one location to access the service when you need to maintain it or handle communications for any feedback. Also, do not under any circumstances access your service from your home with your other devices. While the tor network does a great job at handling anonymity, your other devices are not necessarily as secure as the one we used to set up our service. By not using your home network to access the service in any way prevents a traceable route to your ISP in case of attacks on the tor network relays.
Operation security will be continuously tested going forward. There will be some increases in your stress amongst other things if your service takes off. Market operators often deal with a large number of threats and continuous security testing by outsiders, public disclosures of their failures by researchers, and the constant fear of law enforcement. A journalist in regions with oppressive regimes are always constantly under pressure due to one slip could cause them to be placed in internment camps, prison, or executed. There are extreme risks for operators and users alike. You must take your operational security of yourself and your users very seriously.
Communication Guidelines
Now that you have gotten to the point that you are ready to deploy your service, another consideration is how you will get the word out to the world. This will have to be a personal choice and only you can decide on that. I am going to provide a few guidelines on some social media platforms on Clearnet and tor networks so that you can make the choice that works for you. Do understand that you will need to have a PGP key set up so that your communications can be signed by your key to prevent copycats and scammers. This step is very critical for your success and peace of mind for your users.
Reddit for some reason has become a hotbed for some hidden service operators to post and advertise there, I would suggest against this as Reddit does cooperate with law enforcement. Use Dread instead of Reddit and allow your users to advertise for you by providing a good service or information. Your safety and the safety of the hidden service are your priority. Any risks you take could compromise you and the service. Do not risk it. Avoid any ties to your claiming of the service when you want it to remain hidden, you can sink your battleship here.
Twitter is also used by some and I again recommend against it, Twitter in many cases prevents you from using it with any regularity without your account being associated with a phone number. While we do have a burner phone, associating it with that burner phone would likely be used against you and it would create a direct link to your tweets to the device. Twitter archives all deleted tweets and will gladly provide them upon request, again another consideration when going live with the service. Facebook, Instagram, and Snapchat are all also tied to phone numbers. The same issues Twitter faces are applied here. It is best to limit communications about the service to anyone you come in daily contact with as well. Remember, the more people who know it is you the more that can report you or could become liabilities in the future.
Again, this exercise is to demonstrate the threat modeling that you should consider when you want to run a truly hidden service. You should also consider these angles when considering the risks that others take to share information or to rebel against oppression. You should revisit your threat modeling and review your attack vectors weekly when working in such conditions, take appropriate actions to resolve any issues. Not only is it a good idea to understand your attack vectors, but you should also spend time considering what actions you will take when an issue occurs. Always have a well thought out plan that you can execute. Make sure you plan around multiple scenarios around a failure. Better safe than busted.
Closing
Hidden Services are a necessity in the modern world. They can provide groups with the power to facilitate trade, information exchange, and collaboration in a variety of ways. They can also be very easily targeted as they gain popularity and the operators are inexperienced with handling the hazards of operation. Commonly it is believed that secure communication and processes are all that is needed. There is a lot of precautions you need to take to do this correctly, if you take what I have shared and other information on each process you can do this safely and securely.
There are other threat models to consider in your day to day interactions and within your communication guidelines. If you are operating a simple blog as a resident of a nation that does not oppress its civilians then you do not understand the need for this type of information. If you choose to operate the same blog that may criticize your leaders in a nation in which can and does oppress its people, your operational hazards will differ greatly. What your needs are may differ from others, however, we all should strive for good privacy and anonymity when possible.
I have already been requested to do a write up on scaling hidden services, and I will get to that soon enough. Stay safe in your journeys and good luck!
This article was written on a raspberry pi 3, not the best idea but it was done as it was the only device I had at the time that I could write this on my primary machine due to logic board being replaced. This took days longer than expected. I hope that you found the information useful and if you would like more on a specific topic covered feel free to reach out to me on the following platforms:
Signal:(867–675–1041),
Tox: D7D264EA7541C4324625A8360267C3C54F9C1AF564D4266FE45F2BCB68924E21CB2A75746D51
