Full Disclosure Mailing List Shutting Down

Posted on

Sadly, the last post on Full Disclosure mailing list was by John Cartwright stating that he is suspending the list indefinitely. He lists his reasons below:


When Len and I created the Full-Disclosure list way back in July 2002,
we knew that we’d have our fair share of legal troubles along the way.
We were right. To date we’ve had all sorts of requests to delete
things, requests not to delete things, and a variety of legal threats
both valid or otherwise. However, I always assumed that the turning
point would be a sweeping request for large-scale deletion of
information that some vendor or other had taken exception to.

I never imagined that request might come from a researcher within the
‘community’ itself (and I use that word loosely in modern times). But
today, having spent a fair amount of time dealing with complaints from
a particular individual (who shall remain nameless) I realised that
I’m done. The list has had its fair share of trolling, flooding,
furry porn, fake exploits and DoS attacks over the years, but none of
those things really affected the integrity of the list itself.
However, taking a virtual hatchet to the list archives on the whim of
an individual just doesn’t feel right. That ‘one of our own’ would
undermine the efforts of the last 12 years is really the straw that
broke the camel’s back.

I’m not willing to fight this fight any longer. It’s getting harder
to operate an open forum in today’s legal climate, let alone a
security-related one. There is no honour amongst hackers any more.
There is no real community. There is precious little skill. The
entire security game is becoming more and more regulated. This is all
a sign of things to come, and a reflection on the sad state of an
industry that should never have become an industry.

I’m suspending service indefinitely. Thanks for playing.

– John


Lets hope this is just a haox, or maybe the list comes back in another shape or form.

Easy String Encryption With Bouncy Castle and Jasypt

Posted on

At times you want a an easy and straightforward way to encrypt strings without the hassle of undocumented cryptographic libraries *cough* bouncy castle *cough*. This is where Jasypt comes in. It is a powerful encryption library that makes cryptography fun and easy! What makes Jasypt nice is that it can perform simple encryption using passwords very quickly. That is quickly in terms of development time.

Below is a simple example of using Jasypt to encrypt a string using BouncyCastle as the provider.

PooledPBEStringEncryptor encryptor = new PooledPBEStringEncryptor();
encryptor.setSaltGenerator(new RandomSaltGenerator());
String crypted = encryptor.encrypt("Hello World!");
String plain = encryptor.decrypt(crypted);

The above code should work, but you will need to download Jasypt and BouncyCastle libraries and set them on your classpath.

The Legion of the Bouncy Castle – Listing Public Key Certifications

Posted on Updated on

Instead of calling this post Part 6, I’ve decided to just give them nice and descriptive names from now on.

When managing your PGP Keys you often need to know who you trust and who you do not trust. All we need is the public key file (ASCII armored or binary). I have nested the operation in 3 different methods, mainly done for readability.

public void listPublicKeyCertifications() {
	String keysDir = System.getProperty("user.dir")+File.separator+"src/george/crypto/pgp/keys";
	File publicKeyFile = new File(keysDir+File.separator+"MrBilly.asc");
	try {
		System.out.println("The public key was certified by: ");	
		List<String> keyIds = listCertifications(publicKeyFile);
		for (String keyId : keyIds) {
	catch(Exception ex) {

public static final List<String> listCertifications(File publicKeyFile) throws IOException {
	FileInputStream keyInputStream = new FileInputStream(publicKeyFile);
	List<String> keyIds = getCertifications(keyInputStream);
	return keyIds;

private static final List<String> getCertifications(InputStream input) throws IOException
	List<String> keyIds = new ArrayList<String>();
	PGPPublicKeyRing pgpPubRing = new PGPPublicKeyRing(PGPUtil.getDecoderStream(input), new JcaKeyFingerprintCalculator());
	PGPPublicKey pubKey = pgpPubRing.getPublicKey();
	Iterator<PGPSignature> sigIter = pubKey.getSignatures();
	while(sigIter.hasNext()) {
		PGPSignature pgpSig =;
		long keyId = pgpSig.getKeyID();
	return keyIds;

Read the rest of this entry »

PGP Cryptography With The Legion of the Bouncy Castle – Part 5

Posted on

We’re back! Back to PGP Cryptography tutorials!! Because when I want to learn something new I learn faster by writing a tutorial about it, sharing code and receiving feedback.

So in Part 4 I apologized that I did not have a lot of time and just showed how to integrate Bouncy Castle with Android by using SpongyCastle. Now I will go through how to generate and verify detached signatures. This has become important since Part 2 did teach how to sign and verify files, but the signature was embedded inside the file. Though this works, it did not work when trying to verify the file using a regular program like GPG / Kleopatra. Also not all PGP clients support ZLIB compression which could break compatibility. So I decided that the need to generate detached signatures was important.

Continuing with the previous examples we have the PGPTools file which I wrote to make cryptography easier with BC (Full source can be found here). Generating a detached signature file needs the following:

  • The file you want to sign
  • The name of signature file that will be generated
  • The PGP Key ring that contains your secret and public keys

Another interesting thing to know to go by is the naming convention of these files. Most programs look for it and makes it easier for the user to utilize and for programs to find. Supposed there is a file called “TheFile.txt”, below is how the signature file would be named:

  • ASCII Armored Signature: TheFile.txt.asc
  • Binary Signature: TheFile.txt.sig

This is not mandatory, but a nice convention to follow.

Read the rest of this entry »

Alpha Networks Inc. Want to Backdoor Your Router

Posted on Updated on

In recent news posted on the Dev ttyS0 blog that a spin-off company of D-Link called Alpha Networks Inc. has embedded a backdoor to various D-Link and Planex firmware.

The blog post titled “Reverse-Engineering a D-Link Backdoor” really does a great job showing the step-by-step process the author took find the back door. There are nice visual diagrams and code fragments too.

In a nut shell, the genius programmers at Alpha Networks Inc. wrote some programs or services that needed to change the routers settings remotely. Knowing that the HTTP server on the device could do this, they thought to re-use its functionality. Yeah, 1 step forward, but it needs a password to log in so they though to add a routine to by-pass the authentication check based on a static user-agent, 2 steps backwards or rather 100 steps backwards into a pit of stupidity.

It’s bad enough they got one or more programmers who thought of doing this, it is even worse when you see what the user-agent string is; here have a look:


Now for the grand moment of where genius meets idiot, spell that backwards!


Yeah, Thanks “Joel” and I bet 04882 must be your employee ID code or something else that might be personally or professionally related to you. Thanks for backdooring D-Link firmware. This was already found by Russian hackers in 2010, so who know how long this might have been exploited for.

*** Update ***
Posted buffer overflow exploit proof of concept code on check it out here

WhatsApp ? WhatsCryptography? WhatsEncryption? Answer is: I don’t know

Posted on

And it happens again to WhatsApp, being further embarrassed by researchers showing that they do not know how to implement encryption correctly. Recently Help-Net Security published an article about a Dutch Computer Science and Mathematics student (Thijs Alkemade) at Utrecht University has discovered how WhatsApp encrypts and authenticats its messages.

we know that not only does WhatsApp use the same (RC4) encryption key for the messages in both directions, but also the same HMAC key to authenticate messages.

The main problem being:

“But a MAC by itself is not enough to detect all forms of tampering: an attacker could drop specific messages, swap them or even transmit them back to the sender,”

But also points out that there is a simple solution which is using TLS. So in conclusion

  • All WhatsApp users are still not safe
  • Your messages can be sniffed out
  • Your message can be decrypted
  • Your only protection is to stop using WhatsApp
  • Wait for WhatsApp to learn how Encryption works so they can implement it correctly

I’ll end this post with a quote from Thijs Alkemade:

“solution that has been reviewed, updated and fixed for more than 15 years, like TLS.”