Difference between revisions of "Summerschool Aachen 2004/Project Days"

From C4 Wiki
Jump to: navigation, search
(DeNtiSt)
Line 43: Line 43:
 
== DeNtiSt ==
 
== DeNtiSt ==
  
Lutz and I are working on a DNS tunnel (hence that stupid name, you know about drilling and stuff ;-). We spent most of our time so far working out the basics of the DNS protocol and think we have now actually come up with a way of achieving what we want, simply using the encoded domain names to push data and using RDATA TXT fields for retrieval. We first thought about using CNAME chaining, but are not really sure whether this would work out, since the specs are a little unclear about it. Besides, RDATA TXT offers a lot more space to put stuff into.
+
We are working on a DNS tunnel (hence that stupid name, you know about drilling and stuff ;-). We want to keep it simple, so this will be just a way to create one point-to-point connection to get data across the network. At a later time this might be usable to implement some other protocol on top of that.
 +
 
 +
We spent most of our time so far working out the basics of the DNS protocol and think we have now actually come up with a way of achieving what we want, simply using the encoded domain names to push data and using RDATA TXT fields for retrieval. We first thought about using CNAME chains, but are not really sure whether this would work, since the specs are a little unclear about it. Besides, RDATA TXT offers a lot more space to put stuff into.
  
 
An interesting point about it will be to poll data from our "fake" nameserver, we will probably have to play with the correct TTL and use some sort of sequence numbers to avoid caching problems.
 
An interesting point about it will be to poll data from our "fake" nameserver, we will probably have to play with the correct TTL and use some sort of sequence numbers to avoid caching problems.
  
 
Our first milestone was to actually come up with a basic idea of how to implement this, which we just achieved. By
 
Our first milestone was to actually come up with a basic idea of how to implement this, which we just achieved. By
this time tomorrow, we should have basic implementations of the server aswell as the client, so we have some spare time to actually get it working and enhance with features that come to our minds.
+
this time tomorrow, we should have basic implementations of the server as well as the client, so we have some spare time to actually get it working and enhance with features that come to our minds.
  
 
-- [[Ernest Hammerschmidt]] and [[Lutz Böhne]]
 
-- [[Ernest Hammerschmidt]] and [[Lutz Böhne]]

Revision as of 14:10, 30 September 2004

As you all should know, on Friday, Octobre 1st, we have a Project Day. Everybody should work all day on a project that he can choose (more or less) freely.

Please make sure to inform us about your project and your goal until Wednesday, Septembre 29th!

Feel free to ask us for help if you lack of ideas.

--Cklein 23:24, 23 Sep 2004 (CEST)


Marp

Me and Mario planned to try and finish a (non-working) perl module he made a while ago which allows you to forge arp packets. (this module is called Marp).

-- Ilja van Sprundel

Shotgun

I am planning on continue developping the generic automatic feature extraction tool for fingerprinting protocols. I have already some code from the network Recon Lab, but I still need to code a classification engine, and solidify the code so that it is useable by others.

-- George

arpangel

I will write a program that looks for ARP replies on a network and compares the data with a local database. In case of a mismatch, it will send out a packet with the correct info.

This is meant to defend against ARP spoofing where an attacker periodically sends out unsolicited ARP replies to poison the cache of other machines. The aim is to update the cache of victim machines as quickly as possible, so that the forged information will be kept in the cache as shortly as possible.

The other aim of the project is for me to play with libnet and libpcap.

-- Alexander Becher

DeNtiSt

We are working on a DNS tunnel (hence that stupid name, you know about drilling and stuff ;-). We want to keep it simple, so this will be just a way to create one point-to-point connection to get data across the network. At a later time this might be usable to implement some other protocol on top of that.

We spent most of our time so far working out the basics of the DNS protocol and think we have now actually come up with a way of achieving what we want, simply using the encoded domain names to push data and using RDATA TXT fields for retrieval. We first thought about using CNAME chains, but are not really sure whether this would work, since the specs are a little unclear about it. Besides, RDATA TXT offers a lot more space to put stuff into.

An interesting point about it will be to poll data from our "fake" nameserver, we will probably have to play with the correct TTL and use some sort of sequence numbers to avoid caching problems.

Our first milestone was to actually come up with a basic idea of how to implement this, which we just achieved. By this time tomorrow, we should have basic implementations of the server as well as the client, so we have some spare time to actually get it working and enhance with features that come to our minds.

-- Ernest Hammerschmidt and Lutz Böhne