Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/551 Thanks!
He has published articles
in several big German
magazines, computer
magazines, and he's an expert on packet
capture and analysis.
Yes, but we'll be talking today about
where the various issues that kind of
rissman sanitizing and anonymizing
packett captures and how
to deal with them.
So please help me welcome yes
to this talk on sanitizing.
Pacard captures fun and games until
someone uses IP Version six
or TCP Balcomb.
Thank you so welcome.
I didn't expect so many people in this
room because they have not news shows
coming up soon.
So if you're leaving in the
middle of the talk, I'm not
going to be disappointed.
So just go ahead.
Yeah, I'm jaspar.
If you want to follow my stuff
on Twitter, this is my
handle.
OK, let's talk is about
sanitizing ups.
So pick it captures.
I do a lot of work reading
packet capture. So you probably
heard of the tool called Wireshark.
I use it every day and
very often I have something that I want
to show other people. But there's
something in there that I can let them
know, like IP addresses and other
stuff that may be sensitive.
So I need to sanitize them,
remove all the critical information so
that nobody can see what
my IP addresses are, what my mic
addresses are, because from the megadoses
of you, which you probably know,
you can deduct the vendor
of the device quite a quite
often, not always, but in a lot of cases.
So it may be important
to do that before sharing stuff.
OK, so then first slide that I'm
going to show you is going to surprise
you because it has nothing to do with
because
once upon a time I did something
other than that.
I worked on computer games like this
one. I didn't write it, but I did the
German translation
and also that one.
It's like 20 years ago
I came to
remembering those times
when writing the talk, because back
then I had to do something that I hated
when sanitizing kept as well.
And that is using in Hex editor to
edit stuff because it's very complicated
to get things right back then,
in those times when Lucas Arts
and Westwood published those games,
we didn't get any source code
because you can imagine Lucas holds back
then was already very
well. They're not giving things to you
that way where they think you could do
something with it, like compile their
game again or something.
So they only get that got us the
binaries. So I had to pitch the German
translation into the English game.
Most of you know that most sentences
in German, if they are going to be nice,
are much longer than the English ones.
So we're sitting there in the room
translating the game and always thinking
like how damn how I'm going to translate
this. It needs to be
not longer than the English phrase
and still sound cool.
And that is a big problem.
So it cost a lot of nerve to
do that. And I can show you how that
looked like because I got the eye of
the beholder binary
here.
And you can see here there are all the
strings in there in the executable
and obfuscated, which was Krank.
In these times. It's quite, quite
surprising. Nobody uses plaintext
strings anymore. Right back
then there were. And so we were editing
in this all the time, translating
the game. And that is something that I
never want to do again.
But sometimes with pictures,
I had to do it again.
And this is what the talk is about, how
to get a solution to that kind
of problem these days.
Now, if you're doing computer game
translation, of course, you get the
resource files with all the translation
strings and them and everything.
So it's much easier. But back then, that
was really hard work.
So for those of
you who don't know what a picture
is, a picture is a packet capture,
meaning it's network effects
that have been captured using
a capture device.
It can be a PC or something special.
And it's a file format.
It's a binary lock.
And that is something quite
a number of people doesn't always
recognize or understand because a lot
of times we get questions about how to
read it with a text editor
doesn't really work.
You need to have something to read it.
And most people are for this kind
of thing, use Wireshark.
Peacoat is an old format.
It's used a lot still because
it's easy to write and easy to
read.
The much better one is pick up.
Gee, I don't know if you've heard about
it, but I can recommend it because
you can do much more things with it,
like putting comments into packets and
stuff like that.
But still, a lot of tools only can
do Peekapoo, so we have to
still work with it to be done right?
It's Wireshark right there.
Well done. Cap is the tool that writes
it. But Wireshark tells Dummkopf to write
the stuff and snort and
everything else.
So why sanitization?
Yeah, first of all, it's quite similar
for editing
packets to be able to replay them,
which is sometimes necessary to
mess with them and play them back to the
network and see how a device reacts to
it.
But it's a little bit different
because your focus is not on
changing the packets to test something,
but to remove sensitive details
like user credentials
or network topology.
You don't want somebody to know what the
IP addresses are in your network and what
the gateways are and what the addresses
are. Stuff like this device
and software version information.
Because as we all know, if you find
a banner from a device that tells you
this is Cisco router something, whatever,
everybody will, Google is there exploit
for this.
And if there's one, you try to attack
it. So it may be interesting to remove
those vulnerable protocols.
Of course, if you have telnet in your
network, I would consider that a
vulnerable protocol
and of course, payloads.
So if you have something that is
sensitive in itself and it's transported
over the network, maybe you want to
remove it because you don't
need it for the analysis or something
that you're doing later and then you can
strip it.
OK, very often people do something like
this, this is actually an screenshot that
I have taken from one of the Wireshark
Q&A sites.
People post these kinds of screenshots
of Wireshark and try to
remove the sensitive stuff by painting
over it.
Sometimes it's really funny because you
still have to decode down here and then
you can if you can read Hex, still
see everything.
So that's also the danger that you have
when doing something like this.
You may miss something that you need
to sanitize, but you didn't.
Well, see that this is also the same
information.
Most people never look at the hex
in Wireshark, so they don't realize that
everything that is in the Decode
area is also in the area.
And this one it isn't.
So that's OK.
And if I'm going to analyze something,
somebody shows me a screenshot like this
very often, my answer will be, first
of all, nice, but I
can't help you with it.
Get me a up if you can get
me the picture, because there's the IP
addresses that you don't want me to see
sanitized to replace them with something
else. OK, and this
is what we're going to talk about.
So there's two main
groups of people that want to send
it out, packet capture stats.
First of all, the network analysts and
a lot of them are, for example,
guys who work in the company.
I had one
occurrence where a firewall
administrator told his boss, OK,
this firewall company wants me to send
them captures from what our firewall
does so they can dybbuk why it's not
doing what it should do.
And the boss said, well, we can do that
because they're sensitive information
in this network and they're at
a kind of a deadlock like the
database.
The firewall vendor says, I
can help you without the pickups.
And the customer says, well, I can send
you the pickups.
So what do we do? Well, you could
sanitize them and remove everything that
you think is critical and then
hopefully not remove too
much, because if you remove too much, the
firewall window will say, well, with this
I can see what the problem is.
So you're always trying to find the right
balance between removing stuff
so that nobody sees your IP addresses
and whatever, but not so much
that it is unusable.
And sometimes I see people removing so
much stuff that it's basically unusable.
So you need to find the
right amount of sanitization.
As a network analyst, I often only need
packets up to the TCP layer because
if things go wrong in a network these
days, it's most of the time
related to how TCP works and
what it does. I can see timing
issues, retransmissions, packet
loss, whatever, and I don't need
the payload for it. So removing all
of this payload after the TGP had
a it's no big deal
because a lot of networks have
these obscure little boxes.
I don't know if you have seen any of
those.
There can be things like package papers,
firewalls, von accelerators,
all these magic boxes that
do funny things with GCP but don't
get them quite right all the time.
So in that case, you can lose everything
about TCP.
All the payloads doesn't care.
Don't matter.
So and sometimes you still
need stuff like Epicureans, so
DNS names and things like this,
or you URLs and then things get
complicated because then you're on top
of TCP, so you're in the
stuff that is transported over UDP
RTP and replacing
those can be a big nightmare.
And I will talk more about why it
can be a nightmare.
Security analyst or researcher, they
usually have other stuff they care about
because they don't care about Ethernet.
Our IP before TCP UDP
not that much at least.
I mean, if you see like an
ARP based attack.
Yeah, well, OK then Sanitas to make
addresses and you can still see the tech
going but from different Megadeath, it
doesn't matter
if you can also see here I intentionally
wrote IPV four because
nobody cares about IP for more anymore
because it's quite stable by now.
That doesn't really work for IPv6
because IPV six is still in a stage
where it does crazy things sometimes.
And it may be interesting to see attacks
that are based on IPV six like
extension header chains that you build.
I don't know how many of you are
using IPV six already.
Uh, quite a few.
OK, not that many say 10
percent, maybe there
are a lot of things
in life that is still problematic.
So sometimes you need to see those.
And of course, as malware analysts
or security analysts, you often need
stuff like the Epicureans.
You earles binary payloads so
you can just remove them.
So sometimes the.
Now, kind of sanitization that you do
is different if you're looking at it
from a network and as this point of view
or from a security researcher point
of view.
OK, the challenge, as I already said, is
don't remove too much to make it
unusable, unusable, but remove
as much as you need to not give away
anything that you want to keep her
secret.
So you need to find the right
amount of, well, replacement
or removal, whatever.
The second problem that we have is
if there's only one packet that you need
to change. That's quite simple.
You can still do it in the Hex editor if
you have to, because, yeah,
it's a lot of work, but it's just one
packet.
I put out a challenge like
half a year ago or a couple of months ago
at the Wireshark conference.
The packets were in the range
of, I don't know, a couple of million and
it was like a two gigabyte file
editing those because they were taking a
customer side. It was a real world
problem that I wanted to show as a as
an exercise.
So I had to sanitize
600000 or more packets.
And doing that was the Hex editor.
Well, I would be editing to the end
of my days, probably so trying
to replace everything that I needed.
So for that, you need something else you
can just do. It was an accident or
something that works well for just one
packet.
And I will show you a couple of editors
that you can use for one packet,
but not so much for any.
The protocol complexity is another
challenge.
Most of you have not yet
worked or played with AP physics that
much, but AP physics has a lot
of dependencies that can you really
make things very difficult.
I'm going to show you an example of how
difficult it can get.
And you maybe see, even
if you don't know much about IPV six,
that there are a lot of things that you
need to look at to be able to replace
stuff that it doesn't fall apart after
sanitization, basically.
You have protocol dependencies
again, IPV six or sometimes
AAFP and stuff like this depend on each
other. So if you replace something in
another protocol, you need to keep
that replacement consistent in
the next protocol.
Again, something I will show in
IPV six.
And then there's something that a German
university coined as a term I think
it's called defensive transformation.
Who's ever heard that defensive
transformation?
It basically means if you're looking at
a network package and you find some kind
of information that you don't know what
it is for, drop it
because you cannot keep it.
If you keep it, it may expose something
sensitive.
So defensive transformation means
when I look at the network packet,
I try to understand everything in the
packet and everything that I
don't understand.
I will not write into
the sanitized packet, so I will lose
information. But it's better to lose
information than to expose
stuff that you don't want to be exposed,
because very often in the end
you will find out, oh, I still expose the
IP address because it was still in the
Hexton or something like this.
So defensive transformation is a
principle that you should
well keep in place to
avoid mistakes exposing stuff.
Thank you.
OK, hexameters, I showed you that
already. So, I mean, replacing
packett content in the Hex editor is
well, it's quite a challenge
even if you are able to.
Well, I have Bill Murray here because
it's sort of like Groundhog's
Day task if you do that on a lot of
packets.
It looks like this you go on some
packets, like maybe
this one.
I use one or one editor
for this, so,
well, you can go in here and start
replacing stuff, but
you need to calculate IP addresses
into hex values all the time.
That doesn't make any kind of sense.
Not not for many IP addresses.
You can use search and replace, of
course, but very often you
will miss stuff.
And I want to show you something where
you can easily miss stuff.
And that is in, for example, the
GDP packet that I have here.
If you're replacing by
bytes, for example, in this set request.
You will see here IP addresses up here
they are 32 bit numbers,
but.
The IP address of the forward for here,
that is ASCII text, so
that is something completely different.
But it's the same IP address, but one is
32 bits, the other one is much longer.
Obviously, we can also
see that in the decode done
here, the IP addresses are somewhere in
here and down here you will
see the IP address
as text.
So you need to replace
text and 32 bit numbers and they
need to be the same IP address.
So you have to transform them all the
time. This is really no fun at all
because it will also change
the packet length.
If you do something like this and if you
change Peca length, something really
funny will happen.
And I can show you that because I already
did. You look at this trace there,
it looks fine. You have a son at the
beginning of Finback at the end.
No retransmissions, no packet loss, no
no warnings from Wireshark, nothing.
And I did a replacement
of the IP address in the forward form.
And now the trace looks like this.
You have a lot of red lines there
that really small. I will make them
bigger for you.
It tells me your previous segment not
captured an unknown segment, so
this is something where a network analyst
will get kind of
something is wrong here.
I have lost packets.
There's something missing here.
No, there isn't the only problem.
And you can see that up to this packet,
everything is fine.
The problem is that I replaced
the IP address in here, which was 192,
168, something longer than this,
actually seven characters longer
with something that's shorter.
And that means that every sequence number
in TCP following this packet will
be seven bytes too long.
So a wireshark will all be like a missing
seven byte here.
There are seven bytes missing.
There must be packet loss and it goes
through all the packets because every
sequence number after the packet that is
shorter or even longer
will be off by the same amount of points
that we replace. So you need to
then go into every packet and
adjust every sequence number, but
only after you did the replacement, not
before.
So you need to keep like a lookup data.
Like in which conversation did I
replace? In what sequence
number? How many bytes and how much do
I need to adjust this?
And you can do multiple replacements
in one conversation.
So they have multiple points of now
I need to at seven now I need to remove
14. No, I need to add twenty five
is really a nightmare.
So this is why TCP very often
can be hard to sanitize
correctly if you're going into
replacing stuff in the payload.
This only happens if you're in the TCP
payload. It doesn't happen if you change
anything. And that is if you had a.
All right, so this is how
you do the menu replacement,
there's also something in Wireshark that
I don't think many people have seen who
is used by a shark before
most of you. OK, good.
You can do this.
You can go into Wireshark.
And this one is, I hope, the correct
version, this
two point one. Well, it's quite new.
I use the legacy version.
Legacy means it's GTK based.
That's the old one.
And in here, you can go into edit
preferences.
And down here, there's a checkbox
for an able editor,
and with that, you can now
go to any picket.
And say I detected.
And now I can
go in here and for example.
Change.
Time to live and say, well, now it's 63.
OK, and instantly, of course,
the checksum is wrong
because I changed something right?
So if you're doing a replacement in a
packet, you always need
to fix the
checksum.
Really? Always.
Well, sometimes you have packets, whether
checksum is already bad in the original.
So what do we do to fix it in the fixed
version.
Mm. Hopefully not, because you
kind of remove the
symptom that the checksum was wrong from
the packet. So we need to keep it bad if
it was bad, but keep it correct
or recalculate it
if it was correct.
So something else that you need to keep
in mind, like, oh, what's the checksum,
OK. Well, replace it,
stuff like this. Well, this is something
you can do with Wireshark, but only in
the UK was not the new Kutty version.
OK, then the other thing we have
is why I edit, why edit
is a relatively new tool.
You can use it to as my desktop.
Oh, it can only work with pickup and
kepp father doesn't know pickup energy,
so I need to save this
as pick up first.
I should have kept an example
and pick and pick up for it, but I
didn't.
Test
scores justify conversion.
So, no, there it is,
and now you can go in here and say, well,
I want to.
Added the package, well, it's kind of
confusing because I think you need to
edit something here, but down here,
there's everything in that packet and
now you can say, well, I want to change
the host.
And want to write in here.
To picket for dot com, let's say,
I want to transit to.
Log dot com.
OK.
And the good thing about why I hate it
is it will automatically fix the checksum
so you don't have to worry about it.
You can also add stuff, remove stuff,
and you will run into the
same problem with the sequence number.
OK, so that is why our edit.
And again, if you do
the manual stuff, you
need to have Bill Murray on your side and
stay in the time loop because it will
take a lot of time to do this.
OK, if you do better editing, which means
you're looking at replacing stuff
in an automated way to a lot of packett
to many packets, and
there's a couple of things that you need
to keep in mind, like if
you replace an IP address with another IP
address, you need to keep replacing
the same original with the same
replacement.
You cannot just replace it with anything
you want. It needs to be consistent.
And there's a couple of problems with
that, because if you have a lot of IP
addresses, you need sort of a database
to store stuff or you do
a hash kind of thing so that you hash
the original and used the hash as an
output for the new IP address.
But very often that gives you funny IP
addresses so you can end up
with 127 zero zero
one as the replacement when the original
was 10 or something else, if you
like. Really, someone's someone sending
stuff from localhost?
I don't think so.
And then you look at the original.
Oh, no.
OK, so these are problems that you can
read into between the TCAP
rewrite our basically command
line tools that are used to prepare
packets for reinjection
into the network. So they're basically
designed to help you modify packets
for replay stuff.
So they're not sanitizing tools
by trade.
But you can use them, of course, also for
kind of sanitization.
Then this packet and these are the guys
with the defensive transformation,
then there's a new project
basically pack in as a
Linux tool that is using XML
files to do automatic conversions
on packets.
It's also quite nice because you can pipe
stuff from TGP directly into Pacard.
And on that we're right, never the
original to disk, but only
the senator stuff that is kind of
nice.
And you can define how strong
the replacement should be. If you want to
replace the Mac addresses, the IP
addresses and everything else,
let's pick up Flip, which from my
point of view is not such a good name
because I don't know if you know this
Lepic cap is the library that reads and
writes Bucephalus and these guys are
from China. They probably didn't realize
they wrote a paper on
it, anonymization and use that
kind of name.
So if you want to take a look at it,
they're basically use the Wireshark
sources to read and write packets
in an automated kind of way.
So they have a nice
project that hasn't
continued. And since 2012,
I think so.
Most Pécas sanitization
things that you can find on the network
are research papers.
And as soon as people have turned
in their research papers, the
development stops, of course.
So well, it's out there, it's open
source. Go and use it and modify it.
But it doesn't seem that many people
do OK.
And then there's the last one, which is
called Trece Ringler, and that is my
tool.
So I'm going to show it
to you.
It's in it's a bit different
because it doesn't run on Linux, except
you use one because it's written in
Delphi, which is.
Yeah, I know.
Not a great language.
Only Russians use it, I'm told.
So Ringler is for
automated replacement of stuff.
And I'm going to show you a little demo.
What you can do here is that
up here.
So you had a peek at file
or let's say.
It's just one and then you had a.
Randomization TASC.
And then you can tell it well, what do
you want replaced and
one of the most important ones is this
one telling it to remove everything
that you don't recognize.
So if that doesn't know how a protocol
works, please remove it completely
that way. Everything usually after TCP
will be dropped because
I cannot pass that many protocols yet
that are above UDP or TCP,
but I'm working on it.
So I'm not a research paper guy and I'm
continuing my work so it will improve.
Who can also tell it to truncate after a
certain layer or after a certain offset
or replace some strengthening here.
But the more important things usually are
replacing IP addresses so
it can be replaced by a list
telling it like, well, 192
168 start zero that want to replace
it by 10 or zero zero one.
And it will do that for every IP that it
finds, no matter where it is, if it's in
a packet or in IP packet or
in a payload, it doesn't matter.
It finds that it will replace it.
Or you can go in, say, well, replace
subnets, replace everything
that is in 192 168 zero
zero 24 by 10 zero
zero zero slash 24,
which is good because then all IP
addresses from the original net will
end up in a new net and not
in completely different networks, because
very often if you randomize stuff,
everything will end up in different crazy
networks. And you're like,
why are these two apiarists talking to
each other? They're like the ones in USA.
The other one is in Germany.
What are they doing with one hop between
them or something, so that doesn't make
any sense, it will do a lot of this also
automatically if you randomize IP
addresses, it will keep multicast
addresses, multicast, because that's
another problem.
If you have a multicast address and the
randomizing it, it could end
up like a Lubic address or other zero
address or a private address, which is
not the same anymore.
It's completely different than
other people.
I don't know if many have heard the term
that is the automatic private IP
addressing thingee.
If you do the ISP, but you don't get one
169 dot 254,
something everybody has seen.
And Kirsten, if you have
something like this in a trace, it's
quite interesting because that means the
IP didn't work. So for analysis, you
don't want to replace them.
And on the other hand, they're like
randomly generated anyway, so
they then don't post any kind of threat
if you expose them.
It doesn't make any sense to replace them
normally, but if you want to, you can
tell it to.
And then documentation, IP addresses are
a special IP address that is specifically
for documentation.
So replacing those doesn't make any sense
again.
Yeah, that's one for IP before too.
Not only IP six,
but few people know this.
OK, and then there's something here
that is called the private arrangement,
which means I told transferring that to
if you find an IP address
that is 192 something or
10 or something or 172 or
something, it's already private.
Please keep it private, because
I want to see in the end that it was
private and don't change it into a public
IP by mistake, because
then again, and I have something that
it wasn't before.
You can also go in and say, well.
Randomize it over the full address
range or do not randomize
it at all and keep all the private IP
addresses private because
it doesn't matter.
OK, similar things you can do for RPV six
for S&P, you can decide which
kind of Pécas you want to remove
if you choose to.
Then there's S&P six, and that
is quite interesting.
And I'm sure trace
why IPV six is such a big problem.
Fifteen. OK, this is the last time,
I think if you take a look at this
package, which is IPV six, so if you
haven't seen up to six before, I know you
do.
This packet is kind of problematic
because if you know a bit
about the destination
IP address here, f f zero
to
call on, call on one and so on,
it's a very special multicast address
that is created for research.
Kind of I want to know where my
neighbors, which used to be our
before our doesn't exist anymore.
And IPV six for those of you who don't
know.
So use ISP physics for this.
This IP address is based on
that IP address.
You can tell by looking at the last
couple of bytes here, you see they are
the same.
So this one and that one, if you replace
any of them, you need to keep the
two of them consistent.
But there are different classes, so that
is a problem.
OK, and the other thing, which is
even worse, and by
putting that fire in
here, every IPV six administrator will
tell you this, this IP
address was created from
the Mac address.
So look at the Macarius up there
and you will see it again that
this is 026 F5
somewhere up there on the
wall. You know, from there
at the destination, it's kind of
replaced here.
It's like this.
So you need to look at the IP address,
the multicast address and the Mac
address. And if you press any of them,
replace all of them.
So you need to change the Mac address,
then the IP address and the other IP
address. And that is something
that I can do.
But nobody else so far I've seen,
which is it was something where I thought
this is easy. And then it was a weekend
of coding.
So it took a lot more time than I
thought.
OK, and transmen can
even do work on crazy stuff
like this.
I don't know if you've ever seen a
package like this.
Yae is an ambulance
and is an IP UDP
GPU, which is a tunneling protocol
IP again TDP.
And if you want to sanitize this,
good luck because it's a lot of stuff.
But I can read all of them interest right
now and do the Senate version for you.
And it should work if it doesn't send me
an email, I fix it.
OK, so transferring that can be
downloaded and that's.
The last show before going
to questions if there are any.
It's downloadable here,
if you want to, I didn't open source
it yet, but I will.
I'm still looking at the licenses.
I'm getting crazy. I already asked you
about it, like how much money I'm going
to use while I'm going to use probably
GPL or something.
Then you can look at the trace as a
regular code also and.
Well, all of this already did.
Talking and
thanks and questions.
Right.
Anyone with questions?
There are four microphones in the room.
You can go to the microphones now,
if not, send me an email later that works
to Hartford or whatever.
Yeah, yeah.
There we go. Right here.
You talk about the problem
with HTP, analyzing HGP.
Could you get a little closer to the
microphone? Sure.
The problem with anonymizing HTP,
the IP wasn't there four
or five, six.
That's not something you can address with
Pegatron.
Not right now. No, I'm working on it.
I wrote a well, basically
what that does it it reads the
packet from Internet up to the highest
level. It can pass right
now that stop that TCP, but I'm
working on it hdb poza already
and then it replaces everything that
it finds and reconstructs the packets
from top to bottom.
So basically put it deposit, replace
everything, puts it back together.
That's the only way that you can do this.
And I've started working on the
deposit and try to get it done
for C.C.C., but I didn't
because I didn't have enough time.
It will be the next thing that I do and
then you can
do it.
Interesting.
It's a lot of work because there is
the reassembly coming into play.
Most of you know probably what this
viewer assembly means.
That means that you have to recombine all
the payloads first because an
Entity B request can spend
across multiple packets.
There are sometimes very long URLs that
go from one packet over four
or five more, and you need
to reconstruct it first
and then replace stuff.
And things can get longer or shorter,
they need to cut it into pieces again,
but they need to be the same size or they
should be.
So we need to remember where the cuts
were.
And what happens if you have packet loss
and something's missing in the middle and
then it's like, oh, there must be a
retransmissions somewhere, but where is
it? I have to look here, get
it here, put it in there, reconstruct
it, put it back there when they write the
file again. So I cannot even read
and write stuff sequentially.
I need to read it, try to
put it together and then remember where
everything was before I read it and write
it out like in the same order that I read
it. So that's why it's a nightmare
to work on TCBY stuff.
It's really not easy because otherwise I
would have done it already.
I'm working on this too for three years
now and I haven't got there yet, but I
will in some well, far
future maybe, but
I will do this for one Peckford stuff
already. So most HDB requests
are in a single packet unless they're
very long and that will be something that
I will do in the next couple of weeks,
probably.
Do we have any questions from the
Internet?
Yes, there was one question, do you
also anonymized domain
names right
now?
No, I don't.
But I'm really close to this because I
can already read DNS.
But DNS is another big problem.
I have one site on this.
If you're replacing Epicureans and
you have something like test package, dot
com, and you replace it with something
secret dot com, that means that you
replaced it with a secret com
with com and test with something.
And if you then have abcde, if
packaged food, you need to remember that
you replaced this with secret.
But this year and it's replaced with
something else. So again, you need to
remember part of the code and you need to
pull it apart, put it back together.
It takes a long time to get that right
and I haven't gotten there yet, but
it's one of the next things that I have
to do, because for the thing to work,
I need to be able to sanitize
the hostname in the request.
So that means first I need to be able to
sanitize Epicureans.
That is the first step that I have to do
and then I can do the rest.
So yeah, I will do that.
I'm not there yet.
Too much work in Dallas.
Thanks.
Thank you.
On the left side right here,
is there a command line interface?
Uh, not right now.
The problem with that is that
if you look at the replacement
parameters, interestingly, and you
see it's a big
dialog here
to add all these options
as a command line version would make
it very long or it needs some sort of a
perimeter file that you give
into the program.
I put a lot of code into the government
to be able to make
sure that the user doesn't do anything
crazy that will mess with my program.
And that's why I don't have a command
line version yet, because then I need to
sanitize the input first.
And that is a nightmare in its own, as
everybody knows. Right.
So sanitizing inputs are not
so much fun, even less fun than writing
a GUI, which is no fun at all.
OK, next question.
What's the Wireshark you usually try to
find a problem just just.
Whatever, not working or whatever
and worthwhile. Like, we did a lot of
work to actually
get it bulletproof, to
actually do the IP addressing and
whatever correctly dissect
it.
How often does that happen to you that
you actually.
Well.
May introduce new problems
into the countryside
and how easy or how hard
it is to actually detect detect
this.
OK, so if I get you right,
you mean when I read a pick up and write
again and do something wrong when writing
it, how often do I put problems
in there?
I mean, you actually trying to
troubleshoot something and you
try to sanitize the pick up and
then you send it to someone?
Mm hmm. And then he tried to analyze
it.
And then you find something that I
introduced by sanitizing it.
Exactly. OK, yes, that
is a problem.
And there's something that I live in
constant fear about, because if I
insert problems into a captcha far that
hasn't been there before, I may lose
reputation quite fast because basically
I'm more of a problem than helping you.
So I try to make sure that this doesn't
happen. And one of the first thing I
usually do is when I'm able to read and
write packet's files, I don't sanitize
them at all. I just read them,
deconstruct them and write them back
out again if that works.
And I figure if I get an identical copy,
I'm relatively sure that I'm
OK.
And then I need to do the replacement and
then there's a lot of checking if this is
correct, the good thing is I'm doing
it for over ten years now.
So I'm one of the most feared guys
when it comes to Wireshark, because I
very often am in contact with the
developers and giving them hell about how
wireshark this doesn't and doing things
wrong.
I can spot stuff going wrong by looking
at Pécas and the first thing I
always ask my service is why am I
wrong or am I wrong?
And very often it's 50 50.
I'm going to ask the Internet, is there
another question coming from the
Internet? No question from the Internet.
OK, then we have one right over
here. Thank you.
Yeah, it's been, I think,
the gates and since I looked at it.
But, uh, do you know about Argo's.
Yeah. And, um, run on
nimbies.
Not stuff.
I haven't really used it.
I have to admit. Um, the thing is
that
I was is I think I've
seen it to be Web based, uh,
from the front end kind of thing.
Um, I have to try to
take a look at it, but I haven't used it
yet.
OK, it's I think it's
mainly command line based, but it uses
a known capture format and
OK, does a lot of
analysis itself.
Hmm.
The problem with that would be if you can
you convert it to pick up.
Yes. OK, then it is OK.
Because what I don't like is somebody is
writing an arbitrary protocol and nobody
else can read and then you want to
give it away for somebody who only
can we pick up.
So if you can do that, well I have to
take a look at it.
I wanted to write a tool that is
fully under my control that I can tell to
do everything I like and
do not do stuff that I don't like.
So maybe I'm doing stuff that I already
can do.
I have to take a look at it, but thank
you.
OK, if there are no more questions.
Then, as you said, you can
email him.
But for now, please help me to
thank Jasper.
Thank you for the talk today.
Thank you.