This post can be treated as a continuation of previously published article of “Deanonymization made simple”. As mentioned, more than five hundred of publicly gathered hidden services were misconfigured to disclose /server-status page. I’ve analyzed all of them, and the results looked quite interesting to me to publish those.

I would like to thank my friends @josephfcox and @flexlibris for providing me with invites to Riseup and making this article possible.

cbcf9dde327c475d99627c87f58cab7ac6689164bf2fe7734c10c78005ed118e == sha256(“[10.08.2015] I’ve discovered that about 2% of the known darkweb is controlled by one organization.”)

We all know how frustrating account theft could be. Just imagine - you read the news about yesterday’s successful attack on some service with full database dump published on Pastebin, and you suddenly notice that your e-mail is listed there too… What if the news are one week/month/year old, and you didn’t change your password since registration?

Always wanted to have my own version of Privnote to be sure of how the data is handled on the server… Finally, here it is.

Description:

• connection is secured by HTTPS
• note is encrypted on the client side with Triplesec (Salsa20 + AES + Twofish) with randomly generated key - the server doesn’t know what’s inside
• due to heavy crypto, it will take >$100k to break a single note
• upon successful submission, a URL type of {token}#{key} is generated
• direct access of the generated URL will show the decrypted note (using the {key})
• for security purposes, you may want to send the link without the key, so the receiver will have to enter the key manually to decrypt your message
• there is only one shot - once the URL is accessed, the note is permanently deleted from the server. Additionally, notes auto-expire in 72 hours after creation.

Hope you’ll find it useful.

My recent Keybase overview gave me an impulse to read more about KDFs, their implementations and modern applications, which I’m going to present in the following post.

KDF is a Key Derivation Function. As follows from the definition, such function is used to derive one or more keys from some secret value - source of initial keying material. Derived keys can then be used in different ways, such as to encrypt other important data, to built a MAC, or even as-is. One example of using KDF is to generate a session key during TLS handshake.

It’s been quite a while I analyzed malware last time, so I decided to refresh my knowledge and write a short post on common x86 malware anti-debugging techniques. Techniques here do not include obfuscation like false branches, spaghetti code etc., and present an extract of popular ways to kick debugger’s ass. Please note: this is not a complete set of techniques and rather “shortcuts” than a guide. If you’d like to read more in details, I’ve provided links to some great antidbg materials in the end of the post. Feel free to contact me to complete the list with undescribed technique and/or correct already described ones!

Disclaimer: all vulnerabilities described here were reported to developers and published with their consent

“Get a public key, safely, starting just with someone’s social media username(s).” - this is what you likely to see if you visit the main page of an ambitious project named Keybase. A great idea to (finally) bring public-key cryptography en masse and make its use easy and fun. The project is in fact a public key directory wrapped by well-worked model of social networking and tightly bound to those networks itself.