216 lines
11 KiB
Plaintext
216 lines
11 KiB
Plaintext
---[ Phrack Magazine Volume 8, Issue 52 January 26, 1998, article 01 of 20
|
|
|
|
|
|
-------------------------[ P H R A C K 5 2 I N D E X
|
|
|
|
|
|
--------[ Choose your own $PATH adventure
|
|
|
|
|
|
|
|
Whew. You would be quite surprised at the evil wheels I had to set in
|
|
motion in order to get this issue out. According to Newton, a Phrack Issue
|
|
remains at rest or continues to move in a straight line with a uniform
|
|
velocity if there is no unbalanced force acting on it. This issue was at rest.
|
|
Its velocity was constant. And there were few forces acting on it. Anyhow,
|
|
after many machinations it's here. Enjoy.
|
|
|
|
I have a gripe. Something upon which I'd like dwell for a spell. Let's
|
|
talk about coding aesthetic (from the C programming standpoint). Now, this is
|
|
not a harangue about effective coding or efficient coding, I'll save those for
|
|
some other time (perhaps for the time when I feel I can write effective and
|
|
efficient code proficiently enough to vituperate to those who do not). I
|
|
want to touch down on a few topics of visual appeal, which are overlooked so
|
|
often.
|
|
|
|
The five major areas I will cover are indentation, brace placement,
|
|
use of whitespace, commenting, as well as variable and function nomenclature.
|
|
I suppose I should also mention that coding style is a personal preference
|
|
type of thing. There are all kinds of schools of thought out there, and all
|
|
kinds of methodologies on how to write pretty code. In the grand scheme of
|
|
things, none are really any more correct than any others, except mine.
|
|
|
|
C is, for the most part, a format free programming language. Code can be
|
|
written with all manner of whitespace, tabs, and newlines. The compiler
|
|
certainly doesn't care. The machine doesn't care. This can be a double
|
|
edged sword. There is quite a bit of room for artistic interpretation. And
|
|
just like in real life, there is a lot of crappy art out there.
|
|
|
|
Indenting your code is a must. Please, do this. Indentation is here for
|
|
one simple reason: to clearly and unequivocally define blocks of control.
|
|
However, 8 space tabstops are overkill. Unless you are using a 2 point font on
|
|
a 13" screen, 4 spaces should easily define your control blocks. This allows
|
|
you to maintain clarity on an 80 column screen while nesting blocks of control
|
|
much deeper then you would with 8 space tab stops. 2 space tabstop advocates
|
|
should be shot. However, don't let typography take over your code (ala ink
|
|
obscuring the intent). If you have 7 million levels of indentation, perhaps
|
|
you should rethink your approach to tackling the problem...
|
|
|
|
Bracing has a simple solution. The most effective use of bracing is in
|
|
placing them on newlines so that they neatly enclose the area of control. This
|
|
is especially important with nested levels of control. I know this generates
|
|
empty lines. Oh well. They're free. Blocks of control become easily visible
|
|
and it is easy to isolate one from another. This goes for functions as well
|
|
as conditionals and loop structures. I know I go against K&R here. Oh well.
|
|
|
|
In the pursuit of clear, readable code, whitespace is your friend. Single
|
|
space all keywords and all variables and constants separated by commas. It's
|
|
a simple thing to do to drastically improve readability. When you have a
|
|
series of assignments, one after another, it's a nice touch to line them up on
|
|
the closest relative 4 space boundary. And please, no spaces between structure
|
|
pointer operators and structure contents.
|
|
|
|
Commenting is a delicate matter. Descriptive, concise, well written code
|
|
shouldn't really need commenting, or at least very much of it. But this isn't
|
|
a rant about descriptive, concise, well written code. If you feel the need
|
|
to comment your code, follow a few simple rules:
|
|
- Keep the comment block as small as possible.
|
|
- Don't tab out your comment frames to line up with each other. That's
|
|
just plain fucking annoying. If you're doing that, you have too many
|
|
comments anyway.
|
|
- Commenting datatype declarations rather then the functions that
|
|
manipulate them is usually more helpful.
|
|
- If you must comment, keep your style as consistent as possible. If the
|
|
commenting detracts from the readibilty of your code, you've just ponied
|
|
up any clarification you might have achieved with the commenting.
|
|
|
|
The major exception to these rules are file headers. The beginning of
|
|
source and header files should always have some descriptive information,
|
|
including: file name, author, purpose, modification dates, etc... These
|
|
comment blocks should always have a simple vertical line of unobtrusive
|
|
astricks, framed with the required forward slashes. People using C++ style
|
|
commenting in C programs should be drawn and quartered.
|
|
|
|
The other exception to this rule is when you are writing code specifically
|
|
for the benefit of others. If the code is intended to be a learning tool,
|
|
copious commenting is allowable.
|
|
|
|
Variable and function nomenclature should have connotation as to what their
|
|
purpose in life is. As short as possible while still preserving some sort of
|
|
identity. Descriptive names are wonderful, but don't go overboard. Generally,
|
|
a condensed one or two word descriptor (possiblely connected via an underscore)
|
|
will work fine. And please, no mixed case. The only time uppercase characters
|
|
should appear in C code are in symbolic constants and macros (and possibly
|
|
strings and comments).
|
|
|
|
|
|
This tirade is the result of my experiences in reading and writing C code.
|
|
In my travels as a stalwart mediocre programmer, I have progressed through many
|
|
levels of maturity in my programming style. Much of my old code exhibits many
|
|
of the very things eschewed as anathema in this jeremiad. Well, what can I
|
|
say? I believe that I have grown. I am at home with the me. This is me
|
|
breathing. (Tell me what movie that's from, and I will give you a Phrack
|
|
Donut.)
|
|
|
|
|
|
Enjoy the magazine. It is by and for the hacking community. Period.
|
|
|
|
|
|
-- Editor in Chief ----------------[ route
|
|
-- Director of Public Operations --[ dangergirl
|
|
-- Phrack World News --------------[ disorder
|
|
-- Werdsmith ----------------------[ loadammo
|
|
-------- Elite --------------------> asriel
|
|
-- Santa vs. Jesus ----------------[ ISS vs. SNI
|
|
-- Festively Plump ----------------[ Cartman
|
|
-- Extra Special Thanks -----------[ No one.
|
|
-- Official Phrack CD -------------[ FLA/Flavour of the Weak
|
|
-- Official Phrack Drink ----------[ `The C Kilborn` (2.9 parts ketel one,
|
|
-----------------------------------| .1 parts tonic)
|
|
-- Shout Outs and Thank Yous ------[ Lords of Acid, cantor, Yggdrasil,
|
|
-----------------------------------| snokerash, Voyager, TNO, Jeff Thompson,
|
|
-----------------------------------| angstrom, redragon, Rob Pike, halflife
|
|
-- B.A. Baracus Phrack Fracas -----[ loadammo vs. Death Veggie
|
|
-- Original flip.c author (props) -[ datagram
|
|
-- Gas Face Given (drops) ---------[ solo, klepto
|
|
|
|
Phrack Magazine V. 8, #52, January 26, 1998. ISSN 1068-1035
|
|
Contents Copyright (c) 1998 Phrack Magazine. All Rights Reserved. Nothing
|
|
may be reproduced in whole or in part without written permission from the
|
|
editor in chief. Phrack Magazine is made available quarterly to the public,
|
|
free of charge. Go nuts people.
|
|
|
|
|
|
Subscription requests, articles, comments, whatever should be directed to:
|
|
|
|
phrackedit@phrack.com
|
|
|
|
Submissions to the above email address may be encrypted with the following key:
|
|
|
|
-----BEGIN PGP PUBLIC KEY BLOCK-----
|
|
Version: 2.6.2
|
|
|
|
mQENAzMgU6YAAAEH/1/Kc1KrcUIyL5RBEVeD82JM9skWn60HBzy25FvR6QRYF8uW
|
|
ibPDuf3ecgGezQHM0/bDuQfxeOXDihqXQNZzXf02RuS/Au0yiILKqGGfqxxP88/O
|
|
vgEDrxu4vKpHBMYTE/Gh6u8QtcqfPYkrfFzJADzPEnPI7zw7ACAnXM5F+8+elt2j
|
|
0njg68iA8ms7W5f0AOcRXEXfCznxVTk470JAIsx76+2aPs9mpIFOB2f8u7xPKg+W
|
|
DDJ2wTS1vXzPsmsGJt1UypmitKBQYvJrrsLtTQ9FRavflvCpCWKiwCGIngIKt3yG
|
|
/v/uQb3qagZ3kiYr3nUJ+ULklSwej+lrReIdqYEABRG0GjxwaHJhY2tlZGl0QGlu
|
|
Zm9uZXh1cy5jb20+tA9QaHJhY2sgTWFnYXppbmU=
|
|
=1iyt
|
|
-----END PGP PUBLIC KEY BLOCK-----
|
|
|
|
As always, ENCRYPTED SUBSCRIPTION REQUESTS WILL BE IGNORED. Phrack goes out
|
|
plaintext. You certainly can subscribe in plaintext.
|
|
|
|
phrack:~# head -20 /usr/include/std-disclaimer.h
|
|
/*
|
|
* All information in Phrack Magazine is, to the best of the ability of the
|
|
* editors and contributors, truthful and accurate. When possible, all facts
|
|
* are checked, all code is compiled. However, we are not omniscient (hell,
|
|
* we don't even get paid). It is entirely possible something contained
|
|
* within this publication is incorrect in some way. If this is the case,
|
|
* please drop us some email so that we can correct it in a future issue.
|
|
*
|
|
*
|
|
* Also, keep in mind that Phrack Magazine accepts no responsibility for the
|
|
* entirely stupid (or illegal) things people may do with the information
|
|
* contained here-in. Phrack is a compendium of knowledge, wisdom, wit, and
|
|
* sass. We neither advocate, condone nor participate in any sort of illicit
|
|
* behavior. But we will sit back and watch.
|
|
*
|
|
*
|
|
* Lastly, it bears mentioning that the opinions that may be expressed in the
|
|
* article of Phrack Magazine are intellectual property of their authors.
|
|
* These opinions do not necessarily represent those of the Phrack Staff.
|
|
*/
|
|
|
|
-------------------------[ T A B L E O F C O N T E N T S
|
|
|
|
1 Introduction Phrack Staff 12K
|
|
2 Phrack Loopback Phrack Staff 60K
|
|
3 Line Noise various 79K
|
|
4 Phrack Prophile on o0 Phrack Staff 07K
|
|
5 Everything a hacker needs to know about getting busted Agent Steal 72K
|
|
6 Hardening the Linux Kernel daemon9 42K
|
|
7 The Linux pingd daemon9 17K
|
|
8 Steganography Thumbprinting anonymous 35K
|
|
9 On the Morality of Phreaking Phrack Staff 19K
|
|
10 A Quick NT Interrogation Probe twitch 18K
|
|
11 Subscriber Loop Carrier voyager 48K
|
|
12 Voice Response Systems voyager 18K
|
|
13 Pay Per View (you don't have to) cavalier 19K
|
|
14 The International Crime Syndicate Association D. Demming 20K
|
|
15 Digital Certificates Yggdrasil 14K
|
|
16 Piercing Firewalls bishnu 31K
|
|
17 Protected mode programming and O/S development mythrandir 76K
|
|
18 Weakening the Linux Kernel plaguez 27K
|
|
19 Phrack World News Disorder 64K
|
|
20 extract.c Phrack Staff 08K
|
|
|
|
687K
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
When Sen. Bob Kerrey (D-Neb.) was asked to define encryption, the results
|
|
were horrific. "Well, I mean, to answer your question, I mean, encryption is
|
|
-- the political equivalent of encryption is you ask me a question, I give you
|
|
an answer and you don't understand it," he managed. "I mean, I intentionally
|
|
garble the answer frequently. I intentionally garble the response so that you
|
|
can't understand what I'm saying. And that's -- you notice that I've got the
|
|
ability to do that."
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
----[ EOF
|