Hey
j00n1x, how's it going? Look. I don't understand you at all. You're not
a white hat, since I've never seen you publish any papers, and you're
not a black or grey hat since I've never seen you hack, and I mean,
come on. That latest entry? What are you thinking? Do you think
software should be "alive"?! Why don't you publish papers academically
like the rest of the world and see if they would get through peer
review. I guess you're just chickenshit. Either that, or you're not
skilled enough to actually create the programs that you describe.
Besides, you don't even know that you can't have greater than 100%
probability. I've never even seen your code! Prove that you can code
that program that you described in the latest entry, write SKYNET! Come
on! Tell us, what
kind of hat do you wear? If you don't wear black, white, or grey, maybe
you wear one of those asian umbrella-gong hats?
My response: Thank you rational reader. I hope all goes well for you.
As for my skills, if I'm not skilled enough to create the programs then
fine, but if I am, does that imply that I should release something
harmful? What? Just to prove a point? As for academia, I'm not inclined
to believe that I need a degree in "reverse engineering" if such a
degree existed, and I certainly didn't create this site to be harassed
or to be judged. I knew that the probability
was wrong, I was wondering why nobody picked it up. I guess if they
can't even do stack overflows properly they're not really going to care
about probability.
And I don't fucking wear hats.
Some reader, I think they called themselves "(o.O)" something or
rather, (I
have no idea why you'd have a nickname as a horizontal emoticon, it's
much more fashionable to have letters and numbers), wrote in:
Hi
j00n1x, I love your work. The idea of automatic exploitation of format
strings is not new, it seems to be a rehash of something,
kinda like everything else you've done here, and you know, I think if
something can be automated and exploited, I think, you know, it could
probably be used to fix it on the fly.
My response: Thank you concerned white hat, even if it's not a new
idea, who are you anyway? Some guy with a Phd? I know. You're that
person -- you wrote in to some mailing list a decade ago to suggest
using C++
strings didn't you, and you pointed out all the advantages and nobody
listened? Thank you for belittling my work. Have you considered working
in a psychiatry ward? Perhaps you belong there. I hear the food tastes
pretty good. Thanks for your comments.
Shellcode Generator v2 - Comes with a handy hexdump utility (which is
more useful for shellcodes than the hexdump on unix) and the shellcode
provided allows you to alter the command being executed without having
to change the opcodes to match the length. Exits cleanly if program
couldn't be executed. e.g. "/bin/sh" can now be "/bin/zsh" without
having to change code. NB: leave the \xff character after the string,
as the shellcode uses the \xff character to determine the string's
length. shellcode2.tgz
Smashing 101 Perfect - A bit more complex than mini to understand, but
no longer uses NOPs, i.e. hits perfectly at the beginning of the
shellcode. You *must* take into account the exact buffer's size
including padding in this version for it to work. i.e. from an offset
relative to the %ebp. e.g. LEA 0xfffff000(%ebp), %eax .. the
"0xfffff000" value will be different depending on compiler and code,
and is the buffer's size in negative 2's complement notation. It
doesn't use HOMERUN and hits only the saved ebp and eip, exactly.
(There is no value that is used in smash.c that is 'not exact' --
compared to mini, where the buffer's size doesn't have to be exact). smashing101-perfect.tgz
2003 / 12 (December)
Smashing 101 mini - Perhaps the shortest method for exploiting local
stack buffer overflows? smashing101-mini.tgz
Propolice test - A small program which shows the true behaviour of
propolice's "guard" variable. It shows that it is only initialised at
program load and does not change value thereafter. The value it chooses
seems to be random. propolice-test.c
2003 / 09 (September)
SMS - Short Message System - A package which allows connections to port
8000 via telnet, etc to leave messages on a computer. This is based off
example-tcp-server.c sms-small.tgz
Auditing 101 - This package will calculate the probability of a
vulnerability in any given C source code by using the number of
'dangerous' code lines (i.e. functions or syntax which are prone to
error) with relative weights against the total size of the code. If
only Theo used this for openssh... (it found openssh to be more
dangerous than lsh and found the use of gets() in
openbsd-compat/bsd-cray.c which was fixed in 3.7). "One can hope!" . By
using this program, you can quantitively determine two different
packages to see which one is more secure, and/or coded better. When the
probabilty is 1.0 or greater, you should definitely watch out against
using that particular package! You can re-adjust the weights and the
table to easily add more keywords.
p.s. for those who don't know -- gets() is a vulnerable C library
function which still remains in the standard C libraries today!
Updated packages available -- easier install script! audit-101.tgz
Linked List example - Singly linked lists, Doubly linked lists, Doubly
linked rings, (Doubly) linked semi-rings. Examples and details on
performance provided. You should be able to recreate any of these
structures within 30 minutes -- that is when you know you've become
fluent with them. (The gurus can churn these out within 5 minutes.) You
should know the structure of the loops for traversing and appending off
by heart. Insertion, deletion is not provided and is an exercise for
the reader to figure out. In the real world, insertion and deletion is
rarely memorised and is also 'figured out' on the spot (i.e. they
aren't hard to figure out, but it's a pain to remember them). Note: If
you're happy with using STL in C++ or Java's containers or various
other higher level language support for such structures then that's
fine -- I'm not forcing you to learn this. When you've become fluent
with this, create a parser that breaks the input into words (i.e.
whitespace/tabs/newlines delimited) and store each word into a node. linkedlist.tgz
Static Library example - How to make a static library (libmoo.a) and
what the differences are between a static library and a group of object
(.o) files (i.e. proving virtually no difference). Note: A dynamic
library ends with .so and is equivalent to .dll files in windows. A
static library .a file is equivalent to .lib files in windows. And of
course, .o files are equivalent to .obj files. So aside from naming and
internal structure differences, they are similar in architecture and
design. static-libs.tgz
LD_PRELOAD example - Overrides a function with the use of LD_PRELOAD.
Can only work with dynamic executables. Not exactly the latest
technique in code insertion, but should be noted for it's usefulness,
especially in debugging broken applications. Note: in this example, it
shows how to override a function but not how to execute the original
overriden function. To do that, you need to use dlopen() to open libc
and dlsym() to get the function pointer to the overridden function. preload.tgz
Chroot Shell v2 - Provides a chrooted shell. Now also sets HOME and
DISPLAY environment variables so that it's friendly for applications. chroot-shell2.tgz
Chroot Shell - Provides a chrooted shell for accounts on Linux systems.
Makes sure enough files from /bin, /etc and /lib are copied so that
near full-funtionality is retained. Only public files (those files that
can be seen by the account) are copied. Because the files are copied
with the account's permissions, no suid programs will retain their
'root' ownership, hence making that account secure against local root
exploits
(although any remote or kernel exploit will still root the box!) Have
fun!
An example login:
Login: user Password:
Last login: <date> from <host> uid: 500 gid: 500 euid: 0 egid: 500 after chroot, using: uid: 500 gid: 500
bash$ pwd / bash$ ls bin etc lib bash$
Just like a real shell, except, it's missing half the other 'normal'
directories. You can add more files by altering chroot-prepare to copy
more directories, and it will not affect the security at all. However,
you can never run X because X (and similar) programs need suid root.
Sniffer v4 - The ultimate packet sniffer. Now a fully fledged program
that decodes ICMP and TCP headers and can easily be modified to support
more protocols. Any further work on this and it'll be a re-write of
TCPDUMP! source
Sniffer v3 - Packet sniffing example. Can now decode ethernet frames
and also dumps outgoing packets! source
Sniffer v2 - Packet sniffing example. Uses PF_PACKET/SOCK_DGRAM for IP
layer sniffing, and is capable of binding to a device and setting it to
promiscuous mode. source
Format strings 101 - Introduction to format strings. An example of
overwriting memory at any location with any value using a format
string. Does not detail how to exploit format strings yet. format-string-101.tgz
--
Summary about the cryptography section below:
Assumes a RSA or DH/DSA
keypair has been exchanged with the other party. Also assumes that the
other party knows the passsword for the password based symmetric
algorithm. Assumes both were done under a 'secured channel' (i.e.
possibly face to face).
Initial:
#1 Data -> compress -> encrypt with password
based symmetric algorithm -> encrypt with XOR-otp -- generates 2
files: keyfile and output.
Securing:
Generate 2 base text files:
#2 Keyfile -> RSA or DH/DSA -> secured keyfile
-> steganography + base text file #1 -> secured keyfile-stego[1].
#3 OTP Output -> mmencode -> steganography +
base text file #2 -> otp-output-stego [2]
#4 Base text file #1 -> RSA or DH/DSA ->
secured base text file #1 [3]
#5 Base text file #2 -> RSA or DH/DSA ->
secured base text file #2 [4]
Send to other party:
Send secured keyfile-stego [1] via any insecure
channel
Send otp-output-stego[2] via any insecure channel
Send secured base text files [3] & [4] via a
secured channel (i.e. same channel used for RSA or DH/DSA
authentication). You can send it in an insecure channel but it will
alert the attacker since it will use typical RSA or DH/DSA headers.
The idea is to build on top of existing security methods (i.e. pgp uses
symmetric with asymmetric crypto but no steganography or one-time pad),
although doing so will increase the cost of delivery. It will however
improve stealth as steganography prevents the naked eye from
determining the data, and the OTP will thoroughly thrash any attempts
at deciphering header information from the earlier symmetric algorithm
applied to the data (i.e. step #1). Remember, in some countries, they
can force you to give up your "keys" if they _know_ that you have
encrypted data. The idea in this case, is to hide the data in such a
way that it cannot be proven without a doubt.
Notice that in any typical crypto scenario, ultimately, something needs
to be sent to the other party fairly securely. If it's PGP, it's the
pgp fingerprint (sure you can broadcast the fingerprint publicly like
the public key, but that's not the point of the fingerprint! The
fingerprint is meant to be read *back* to the owner of the key!) If
it's symmetric key algorithm, it's the password. If this has told you
anything, it shows that whilst cryptography is useful for information
hiding, it cannot match face-to-face or similarly secured channels. And
that is the problem that eavesdroppers have had in the past, and will
have, in the future.
--
Linear text steganography - Inserts a file into a text document (a base
text file). It is a linear insertion so that it can be 'brute
forced' quite easily. Also if the source code was available, linear
insertion can be cracked easily. One could use a random insertion
method with key as seed, and then the
attacker needs: 1) source and, 2) key or 3) base text file to break the
stego (either one of #2 or #3 is sufficient). Because steganography is
a weak defense, the best method would be to encrypt using a one-time
pad and then use steganography.
This would severely limit the ability of any eavesdropper and allow
refutability. steganography.tgz
XOR One-time pad encryption - (nearly) unbreakable as long as you keep
the
keyfile and the original file secret. Unfortunately keyfile must be as
large as the original file. Also both parties need the keyfile. Because
a one-time pad encryption is not a password based symmetric key
encryption, it is still vulnerable as there is no 'secret' that is
offline (i.e. inside someone's head). Similarly, it doesn't fall under
the category of "symmetric key" encryption for that reason. xor-otp.tgz
2003 / 07 (July)
Serial Number v2 - An example serial number generator in C++.
Useful for developers as well as security enthusiasts. Has some notes
on the security model being used. serial.tgz
Serial Number - An example serial number generator in C++.
Useful for developers as well as security enthusiasts. (Sorry in GZIP
format, since yahoo doesn't like .cpp filename extensions.) source-gzip
Overflow detection - Uses mmap() and mprotect() to create a boundary
page after the buffer to detect overflows. source
Socket - Packet sniffing example. Uses AF_INET/SOCK_RAW and
PF_PACKET/SOCK_DGRAM for IP layer sniffing. source
Brute - A brute forcing skeleton package. brute.tgz
AI - AI/brute's result which generated code that hacked the evaluation
function! Unbelievable! This source is demonstrating why it worked... source
Socket - Raw socket example. Spoofs any type of the packets described
below (TCP SYN, UDP, ICMP echo reply) with checksum implemented. source
Socket - Raw socket example. Spoofs an ICMP "echo reply" packet (i.e.
not like smurf) source
Socket - Raw socket example. Spoofs a TCP SYN packet source
Socket - Raw socket example. Spoofs an UDP packet - Updated. source
Kernel module (2.4.xx) - Overrides any function inside the kernel by
overwriting the function's instruction (opcodes) with a JMP. module-skel.c
Smashing the Stack 106 - 1 byte zero termination overflows aka "off by
one". smashing106.tgz
Assembly code obfuscator - inserts "useless" JMPs and PUSH opcodes so
that it scrambles simple disassemblers (like gdb) from decoding the
binary properly. obfuscator.tgz
Shellcode Generator - Converts assembly to shellcode -- Supplied with
Aleph1's shellcode (45 bytes) and comments and my shortest shellcode
(33 bytes originally but now 32 bytes) with comments. UPDATED: Now
contains buffer & alor's 23
byte shellcode and a modified buffer & alor (26 bytes) which is
guaranteed to
work without changing method of injection. UPDATE: Now contains a bind
shell code and generator scans for \0, \r, \n to warn you. shellcode.tgz
Smashing the Stack 105 - Dealing
with randomised canary values. No known method is available to break
the protection directly, and stack buffer overflow exploits are reduced
to a mathematical game of chance. This may (or may not) represent
"StackGuard" and "ProPolice". smashing105.tgz
Smashing the Stack 104 - Breaking
through compiler add-on security that use 'canary' values. This may (or
may not) represent "StackGuard" and "ProPolice". smashing104.tgz
A cute 16 line x86 assembly graphics flasher here.
Weird stuff here.
An ad pic from ediets... shame if you
pronounce their company name too fast it sounds ... well.. you know.
Isn't the e- prefix worn out by now?
A screenshot of my 3D graphics engine
rendering
a torus (donut shape). Another screenshot, this
time of an unidentified flying ellipsoid object.
Copywrong 2003 by draichess
This page best viewed in Mozilla,
since it can stop those annoying
pop-up ads. Sorry f0lkz, I can't afford a domain to host some
tutorials.
