hpr-knowledge-base/hpr_transcripts/hpr0917.txt

Episode: 917
Title: HPR0917: Uber Leet Hacker Force Radio 6
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr0917/hpr0917.mp3
Transcribed: 2025-10-08 04:55:07

---

I'll take you back to one of the things that I've been thinking about and what I've been thinking about and what I've been thinking about and what I've been thinking about and what I've been thinking about and what I've been thinking about and what I've been thinking about and what I've been thinking about and what I've been thinking about and what I've been thinking about and what I've been thinking about and what I've been thinking about and what I've been thinking about and what I've been thinking about and what I've been thinking about and what I've been thinking about and what I've been thinking about and what I've been thinking about and what I've been thinking about and what I've been thinking about and what I've been thinking about and what I've been thinking about and what I've been thinking about and what I've been thinking about and what I've been thinking about and what I've been thinking about and what I've been thinking about and what I've been thinking about and what I've been thinking about and what I've been thinking about and what I've
been thinking about and what I've been thinking about and what I've been thinking about and what I've been thinking about
I'll tell you this, I'll tell you this, I'll tell you this, I'll tell you this, I'll tell you this, I'll tell you this, I'll tell you this, I'll tell you this, I'll tell you this, I'll tell you this, I'll tell you this, I'll tell you this, I'll tell you this, I'll tell you this, I'll tell you this, I'll tell you this, I'll tell you this, I'll tell you this, I'll tell you this, I'll tell you this, I'll tell you this, I'll tell you this, I'll tell you this, I'll tell you this, I'll tell you this, I'll tell you this, I'll tell you this, I'll tell you this, I'll tell you this, I'll tell you this, I'll tell you this, I'll tell you this, I'll tell you this, I'll tell you this, I'll tell you this, I'll tell you this, I'll tell you this, I
'll tell you this, I'll tell you this, I'll tell you this, I'll tell you this
now and the last episode. One thing that has happened is I wrote this encryption
framework called Conquer, which I'm going to release now. That's what the
set says about releasing Conquer to the public. So it's going to be a short one,
and it's going to be all about Conquer. Well Conquer is it's it's
question of Lee useful is what it is. No I kid, I think it's I think it's
fairly useful. It's it allows you to encrypt parts of the configuration file.
Or any file for that matter, but I had configuration files in mind. The seldom
case where you need to store a password in a configuration file is rare as this
may be, but sometimes necessary where you have to store a password in a
configuration file. You need to start encrypted is what you need to do. It can't
be plain texting a configuration file. If you wrote your configuration file
under a user named Carl and someone gained Carl permissions, they would be
able to read your password. The password doesn't need to be in the scope of
Carl. Password doesn't need to be here at all. It needs to be taken out of the
out of the situation. It needs to be taken out of the configuration file. This is
what Conquer does. Now how this works is well let me explain how it came about.
That will probably explain how it works. I am a while ago. I wrote this this
web-based work queue management software for this particular client. On the web
server, the backend, which I wrote and see, just because I'm comfortable with
see than any other language, and web apps need to be secure as fuck. In my
opinion, the attack service, the attack market, which perhaps is a more accurate
term, the attack service is the size of a cloud nowadays because it is a cloud.
And cloud-based things, cloud-based programs, web apps, and other things that are in
the cloud need to be secure and writing something and see is the only way for me to make
something secure. Let me move my phone. That's GSM noise and I can't find my phone. So sorry
about the GSM noise.
So yeah, I could have written in PHP or Perl or something like that, but I feel I don't
know well enough to write something secure. That's not saying that these languages are
insecure. Just for me, personally, writing and see is much more comfortable. So it's
a see back. And in one advantage of this is you can do funny things with outfiles. You
can do funny things with binaries as your backend is a binary. And that's what conquer does.
Funny things. Now, when you run a program, kind of going back to Carl, when you run a
program, the program that you run the binary that you run is usually, in most cases, usually
owned by root. All the files in a slash user slash local slash bin are all owned by root.
They match any binary that you run nowadays is owned by root. If it's installed into
whatever host you're running, there are exceptions to this, but this is my little OpenVSD
box here. I'm willing to bet every program that I run when it's not custom software before
I have the install framework in that software is is owned by root. And so it's conquer
leverages that root ownership to secure passwords. It does this by marking the executable execute
only that is able to read the configuration file. Now, if you run into a problem, and you
run into a particular trap that decides to dump core all over the place, and your executable
is execute only the kernel won't dump core. And if it's execute only, you can't read the
binary. And that's where the key is stored. That's where the decryption key is stored for the
configuration file. It's stored in one place in the binary with root ownership, as opposed
to having passwords here and there owned by carl. And so I don't think any usefulness
is taken away in this concept at all. And a bit of security is gained from it. And that's
what that's what conquer is. So let me explain in a little bit more detail how this works.
Conquer is two parts. It's a library called libconquer and a program called Conquer crypt. Now, when
you write your application, when you link your application against libconquer and you run it,
the application searches for a private key in itself. And if it doesn't find it, it generates one.
And spits out a copy of itself in a specified location under specified ownership with execute
only permissions. The idea behind this is if you make sudo make install during the sudo make
install part as root, the decryption key and the encryption key, the private and the public key
in this case are the encryption keys and the encryption key, the encryption key. Those keys,
the private key is established under the scope of root and put the binary with that key.
The only place for that binary is under a location that's owned by root. And so that key
doesn't really go anywhere. That key never sees the light of day. That key never sees the light
of user carl or anything like this. So when you run your program or your application, when you're
when you're building it in that sudo make make install, the checks to see it first figures out
its binary, the location of its binary. If you have a proc file system, this is rather simple.
If you don't have a proc file system, it's a little bit convoluted. But it eventually figures out
its binary. It checks all the symbols in the binary. They're loaded location and compares that
against its own symbols for good measure. And if it looks reasonable, this is the same binary
that's running. It generates an RSA key pair. The private component is stored in a symbol.
And then that is outputted by the program. So when you run this program, what is outputted,
which is an replica of what you ran before, just with the key and it under the correct ownership
and execute permissions, when you run this program, it acts like normal. And LibConquer provides a
mechanism for reading configuration files that may partially or wholly be encrypted that look
just like LibC. So you can read, you can seek, you can end a file, a file just as you would in
normal file. And there's the encrypted part of it is completely transparent to you.
And so tacking this onto your existing application that uses a password in a configuration file,
hopefully will be fairly trivial. And that's the idea. Now CompCript, the component of it,
the other component of it, the other half of Conquer. What CompCript does is it encrypts an input
file as specified and outputs, encrypts it and outputs it to an output file. If you don't
specify an input file, an output file is used as standard and standard out. But the one thing you do
have to specify is a public key. Now if it can't find this public key in the working directory,
it searches the database of public keys, which is in bar slash DB slash CompCript.
By default, you can change this, of course, if you want to. And encrypt your
input with that key. Now the output is fairly readable. It looks like any encrypted message
that you would see from pretty good privacy or a new privacy guard, where you have that sort of
begin block and block. And the base 64 message in between that is printable and can be included in.
You know, just your path, your mail sort of encoding format. I forget what it's called. I know
it's called PEM, but I forget what PEM stands for, but the transport protocol used by a,
it'd be specified dash dash armor. In a new privacy guard, that's what the output looks like. So
it can be dealt with fairly easy easily and you just put that new configuration file and that's it.
So that's that's conquer for you. Hopefully you'll find this useful. The only public
really available, the only public implementation of it right now is the latest version of yes,
please, which you can find in the in the in the show notes. You can also find a link to download
conquer in the show notes as well. I'm not going to don't think I'm going to maintain
you really hacker for a website mainly because the space given to me kindly given to me mind you.
I'm not complaining. I'm glad that someone gave me space, but FTPing stuff into the space is
not a good place for a hacker show to be online. So yeah, I'm not going to, I'm not going to update
the website. You'll you can find the links to the latest version of yes, please, which
which implement conquer and latest version of conquer in the show notes. Thank you for listening,
everyone. Thanks a lot for listening and hopefully a new episode will be coming out. I have a lot
of a lot of dead code is what I have a lot of programs that never really went anywhere and so
so there's code to be had. There's code to be talked about. There's code to be worked on perhaps
which is what Uberly hacker for us radio is about. Take care everyone. Bye bye and happy hacking.
You have been listening to Hacker Public Radio or Hacker Public Radio does our. We are a
community podcast network that releases shows every weekday Monday through Friday. Today's show,
like all our shows, was contributed by a HBR listener like yourself. If you ever consider recording
a podcast, then visit our website to find out how easy it really is. Hacker Public Radio was founded
by the digital dot pound and the economical and computer cloud. HBR is funded by the binary
revolution at binref.com. All binref projects are crowd-sponsored by linear pages. From shared
hosting to custom private clouds, go to lunar pages.com for all your hosting needs. Unless otherwise
stasis, today's show is released under a creative commons, attribution, share a line, read