HDTenEightyP/NetNews huggingface dataset:
Newsgroups: alt.hackers
From: flaps@dgp.toronto.edu (Alan J Rosenthal)
Subject: Re: Self Printing Program, revisited
Date: 4 Sep 92 12:33:28 GMT

{Note: When you get bored reading this article, skip to the end.}

positron@engin.umich.edu (Jonathan Scott Haas) writes:
>Awhile back, there was talk about how to write a program whose
>output would be the program itself. Here's my program, written
>in C, but I think perhaps it "cheats" a bit.
[reads its own source code from a file]

Well, is "cat" a self printing program because you can do
	cat /usr/src/bin/cat.c
?  "Cat" is not an extremely exciting or novel program.  Your program is less
exciting than cat.

Something similar but a little cooler is something in a microcomputer basic
environment which uses peeks to list whatever program is in memory, just like
the "list" command does, and thus lists itself.

However, none of these programs have the essential ingredient of a self-
printing program, which is that the program contains itself in a certain
sense.  In these programs, they have to go to some external area and look up
the source.  For example, in your program, if you compile it and then delete
the source it will stop functioning.  A proper self-printing program won't have
this failing.

Here's a program which prints itself, except that it's somewhat buggy and
sometimes dumps core instead.


#include <signal.h>

int main()
{
    kill(getpid(), SIGBUS);
}


--

Why don't we discuss cool variant problems?  Did anyone like my pair of
programs in different programming languages each of which output the other?
What are some other good variant problems?  Post or e-mail.
Newsgroups: alt.hackers
From: paulr@umbc4.umbc.edu (Paul Riddle)
Subject: Re: YAFP: TRS-80 Super Graphics
Organization: Univ. of MD, Baltimore County
Date: Sat, 29 Aug 1992 21:37:37 GMT

In article <YAMAUCHI.92Aug29141341@fox.ces.cwru.edu> yamauchi@ces.cwru.edu (Brian Yamauchi) writes:
>ObHack: Anyone else remember TRS-80 "Super Graphics"?
>
>The TRS-80 was capable of displaying character graphics (with
>butter-knife sharp resolution (128x72?) in two stunning colors (black
>and white) :-), but the catch was that it was impossible to actually
>enter graphics characters from the keyboard.  There were three
>conventional alternatives -- POKE bytes to screen memory (cumbersome),
>use CHR$ (slow), SET/RESET individual pixels (extremely slow).
>
>Softside magazine published a hack to get around this.  First, define
>an empty string such as:
>
>10 A$ = "     "

...

This reminds me of a similar hack on the Color Computer (Coco) that
people used to use to "hide" lines of BASIC code...  Not quite as
elegant, but the same idea.  What you would do is follow your line of
code with a comment, and then a number of X's equal to the length of
the line.  To illustrate:

10 PRINT "FOING BLASTERS":REM XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Then after that, you would go PEEKing through the area allocated to
your BASIC code (this value tended to change on the Coco, since you
could reserve low RAM for extra pages of hi-res graphics...  I think
the starting address was stored in low RAM somewhere) looking for the
sequence of X's.  Once you found them, you'd POKE the corresponding
locations with the value 8, which is an ASCII backspace.

Then when you listed your program, the line would flash for a brief
instant after which it would be backspaced over...  presto, "hidden"
lines of code.

I think a few software companies actually used this as a method of
copy-protection.

Aah, sweet memories of home-computer hacking.

Paul
-- 
If found, please return to:         |
Paul Riddle                         | paulr@umbc3.umbc.edu
UMBC, Academic Computing Services   |
Baltimore, MD 21228                 | (410) 455-3627
Newsgroups: alt.hackers
From: zowie@daedalus.stanford.edu (Craig "Powderkeg" DeForest)
Subject: Re: [Not-so-] Cheap modems from Prodigy
Organization: Stanford Center for Space Science and Astrophysics
Date: 27 Aug 92 02:32:44

Stephe Lewis Foskett <lancer@wpi.WPI.EDU> writes:
   Prodigy and a company called Tech Advantage are offering, for $39.95:
   * a 2400 bps internal modem
   * a month of PRODIGY (yay)
   * some modem software

   So what's so cool about this?  I don't know.  I don't know these people, I
   just wanted a cheap modem...

I don't know either.  

At least one company, Telemarket, is offering a 2400bps IBM compatible
internal modem for $25, complete with `some modem software'.  More than
half-a-dozen companies are selling internal 2400s and software for under $35.
Given the poor quality and admin-fascist nature of the PRODIGY (dis)service,
I wouldn't call a month of PRODIGY a (yay) item at _any_ price, even $4...
--
Craig DeForest:  zowie@banneker.stanford.edu  *or*  craig@reed.bitnet

"So, if you guys make a living looking at the SUN, why do you spend so much
        time at the SYNCHROTRON, working UNDERGROUND at NIGHT?"
From: gray@ml.csiro.au (Randall Gray)
Newsgroups: alt.hackers
Subject: Another first post (Does that sound wrong...?)
Date: 28 Aug 92 00:00:00 GMT

Obhack:  Wading through the keyboard driver of an old XT clone to find the
	interrupt which controlled the clock rate so that I could make
	minix run at the higher rate, dropping back to the "normal" speed
	when it had to use slow floppy disks.

Next on the list:
	Finding an easier way to post to alt.hackers!
Newsgroups: alt.hackers
From: flaps@dgp.toronto.edu (Alan J Rosenthal)
Subject: Re: Prime Number Generator
Date: 1 Sep 92 17:23:04 GMT

jim@rand.org (Jim Gillogly) writes:
>The whole idea beind RSA encryption is that large prime numbers are *easy* to
>prove prime,

Running a probabilistic algorithm does not yield a proof that they're prime.

(Or is there a non-probabilistic way?)
Newsgroups: alt.hackers,talk.bizarre
From: jon@zeus.med.utah.edu (Jonathan Byrd)
Subject: Re: Your very own Magic 8 Ball simulator
Organization: University of Utah
	<1992Sep3.014309.1325@terminator.cc.umich.edu> <3760@randvax.rand.org>
Date: 3 Sep 92 10:39:52

In article <3760@randvax.rand.org> jim@rand.org (Jim Gillogly) writes:

   #!/usr/bin/perl

   srand(time|$$);
   print
   (
	   "YES.",
	   "You may rely on it.",
	   "It is decidedly so.",
	   "Yes, definitely.",
	   "Without a doubt.",
	   "It is certain.",
	   "Most likely.",
	   "Outlook good.",
	   "Signs point to `yes.'",
	   "As I see it, yes.",
	   "Reply hazy, try again.",
	   "Concentrate and ask again.",
	   "Ask again later.",
	   "Better not tell you now.",
	   "Cannot predict now.",
	   "My sources say, `No.'",
	   "Very doubtful.",
	   "Don't count on it.",
	   "Outlook not so good.",
	   "My reply is: No."
   )[rand(20)] . "\n";

pah!  you're not done yet.  where the fuck is the part that parses the
input?

example:

if(x = strcmp(input_string, "Should I staple myself to the carpet and
beg mommy to vacuum-fuck me?") == 0) printf("Without a doubt.\n")

--
jonathan byrd
jon@apollo.med.utah.edu
Xref: sparky alt.hackers:1360 talk.bizarre:28749
From: jim@rand.org (Jim Gillogly)
Newsgroups: alt.hackers,talk.bizarre
Subject: Re: Your very own Magic 8 Ball simulator
Date: 3 Sep 92 17:43:38 GMT
Organization: Banzai Institute

In article <JON.92Sep3103952@zeus.med.utah.edu> jon@zeus.med.utah.edu (Jonathan Byrd) writes:
>pah!  you're not done yet.  where the fuck is the part that parses the
>input?

Nonsense -- all 8-ball implementations are well-known to be telepathic.
Concentrate harder!

ObHack: implementing a Tarot blackjack dealer in MUSH code... complete with
security and error-checking.

-- 
	Jim Gillogly
	jim@rand.org
Newsgroups: alt.hackers
From: root@whip.isca.uiowa.edu
Subject: Re: My First Post.
Date: Tue, 25 Aug 1992 21:10:08 GMT
Organization: ISCA

In article <BtJzvF.6Bx@mentor.cc.purdue.edu> devros@mentor.cc.purdue.edu (Devros) writes:
>On the local SUN net, format a disk to SunOS and fdmount it. Copy a shell
>to it and change permissions to setUID, setGID, and world executable. Put the
>disk in a computer with a disk editor that you can name the media type without
>a boot sector and find your UID on the disk, changing it to a root uid. Mount
>it back onto the SUN and execute. I haven't tried it, but theoretically you
>would get a setuid-root shell.

Only if it fdmount allows you to mount the disk with setuid priviledges.  I
very highly doubt this is the case...

Ob"Hack":  Accidentally creating a runaway process that forks itself to death,
           running as root, and with real time priority, on an HP 9000/710.  I
           was lucky they were created and died so fast the process table
           filled up and made the program abort so I didn't have to reboot the
           machine, but it sure locked it up solid for a few minutes!

PS - my first posting here....hope I'm doing this correctly :-)

--
/-----------------------------------------------------------------------------\
| Doug Siebert                             | "I don't have to take this abuse |
| Internet:  dsiebert@icaen.uiowa.edu      |  from you - I've got hundreds of |
| NeXTMail:  dsiebert@chop.isca.uiowa.edu  |  people waiting in line to abuse |
|     ICBM:  41d 39m 55s N, 91d 30m 43s W  |  me!"  Bill Murray, Ghostbusters |
\-----------------------------------------------------------------------------/
Hi, I'm a .signature worm.  I've already copied myself into your .signature.
Newsgroups: alt.hackers
From: peter@taronga.com (Peter da Silva)
Subject: Re: Prime Number Generator
Organization: Taronga Park BBS
Date: Mon, 31 Aug 1992 11:03:15 GMT

In article <grtyj5-@rpi.edu> cleggp@aix.rpi.edu (Paul Jason Clegg) writes:
>I'm interested in generating large prime numbers for use in some public key
>code encryption schemes, and I'm looking for the fastest way to generate all
>the primes from 2 up to as high as I can go on my 386/25 (Using BC++ 3.1, I
>figured this is somewhere in the what, 4 billion range?)

1. These are unlikely to be large enough.
2. Try the Seive of Eratosthenes. That's the greek dude you're thinking of.
   You only need to test the *primes* up to the square root of the number
   in question, and since you're generating all the primes you already
   *know* them all. Just use the standard seive up to 64K (no sweat) and
   use the primes in this array to test the rest of the number space.

   There is code for the seive all over the place, since Byte used it as a
   numerical benchmark for many years.

>But.  Does anyone know of even more efficient algorithm for determining the
>primeness of numbers?

See above.

>Has anyone ever come up with a O(n) algorithm for it?

If anyone does, there won't be any point in using primes for cryptosystems
any more.
-- 
                                                                `-_-'
                         Have you hugged your wolf today?        'U`

Peter da Silva, Taronga Park BBS, Houston, TX  +1 713 568 0480/1032
Newsgroups: alt.hackers
From: aaronb@suhana.analog.ingr.com (Aaron B.)
Subject: Hardware/Electronics hackers anybody?
Keywords: Hardware hackers
Reply-To: aaronb@suhana.analog.ingr.com
Organization: Home Office Enterprise
Date: Sat, 29 Aug 1992 23:22:50 GMT

Hi There:

First post:

Any room for hardware/electronics hackers in this newsgroup?
Let's hear it.  I have one myself but it's still not completed.

Aaron B.
aaronb@suhana.analog.ingr.com



Newsgroups: alt.hackers
From: bsy+@cs.cmu.edu (Bennet Yee)
Subject: Re: Prime Number Generator
Organization: Cranberry Melon, School of Cucumber Science
Date: Mon, 31 Aug 1992 19:02:59 GMT

In article <1992Aug31.160225.26724@gateway.novell.com> alex@otis (The Console DJ) writes:
>In article <grtyj5-@rpi.edu> cleggp@aix.rpi.edu (Paul Jason Clegg) writes:
>>I'm interested in generating large prime numbers for use in some public key
>>code encryption schemes, and I'm looking for the fastest way to generate all
>>the primes from 2 up to as high as I can go on my 386/25 (Using BC++ 3.1, I
>
>Someone correct me if I am wrong but the whole idea behind the encryption is
>the large prime numbers are difficult to  calulate??? Actually there should
>be no known algorithm (except brute force try every number thingy).

There are polynomial time algorithms for testing primality assuming
Generalized Reimann Hypothesis (GRH).  W/o assuming GRH, there are
probabilistic polynomial time algorithms (one-sided error, i.e., in R)
for testing primality.  It is easy to test the primality of numbers
that have hundreds or even thousands of decimal digits.  This, of
course, is feasible on 386's.

Note that the seive is exponential time, since you are creating a
table that is exponential in size on the _size_ of the number that you
want to test (size measured in number of bits required to represent
it).

*Factoring* is what's hard.  Or so number theorists believe.

These sort of questions are more appropriately posted to sci.crypt.

No ObHack.

-bsy


@article(MillerPrime,
	Key="Miller",
	Author="G. L. Miller",
	Title="Riemann's Hypothesis and a Test for Primality",
	Year=1976,
	Volume=13,
	Journal="Journal of Computing and Systems Science",
	Pages="300--317")

@article(SolovayStrassen,
	Key="Solovay and Strassen",
	Author="R. Solovay and V. Strassen",
	Title="A Fast {Monte-Carlo} Test for Primality",
	Month="March",
	Year=1977,
	Volume=6,
	Journal="SIAM Journal on Computing",
	Pages="84--85")

@article(RabinPrime,
	Key="Rabin",
	Author="Michael O. Rabin",
	Title="Probabilistic Algorithm for Testing Primality",
	Year=1980,
	Volume=12,
	Journal="Journal of Number Theory",
	Pages="128--138")
-- 
Bennet S. Yee		Phone: +1 412 268-7571		Email: bsy+@cs.cmu.edu
School of Computer Science, Carnegie Mellon, Pittsburgh, PA 15213-3890
From: row@bnr.co.uk (Reuben Wells)
Newsgroups: alt.hackers
Subject: Re: My First Post.
Date: 26 Aug 92 12:05:23 GMT
Reply-To: row@bnr.co.uk (Reuben Wells)
Organization: BNR Europe Limited, London Road, Harlow, Essex, GB

>Ob"Hack":  Accidentally creating a runaway process that forks itself to death,
>           running as root, and with real time priority, on an HP 9000/710.  I
>           was lucky they were created and died so fast the process table
>           filled up and made the program abort so I didn't have to reboot the
>           machine, but it sure locked it up solid for a few minutes!
>

Write a shell script called 'all' that does an rsh on every machine on the
network passing its parameters to the rsh command. Then after trying 
the really boring and naff stuff like 'all play sheep' try something like
'all all all' ...

I did not try this myself but had a friend that did on about 30 machines,
not only did he have to reboot *every* single machine once some of them
required several reboots ! It was quite amusing, he hadn't really thought
about what he was doing and didn't expect the network to stop, it was quite
pretty though looking at all the lights on the transceivers located around
the room :-) Its not surprising when you realise that it the machines were
trying to start around 27,000 processes between them !



Reuben O. Wells	- BNR Europe Ltd - (+44) 279 403704
Newsgroups: alt.hackers
From: imp@solbourne.com (Warner Losh)
Subject: Re: Self Printing Program, revisited
Organization: Solbourne, User Interface Group
Date: Fri, 4 Sep 1992 15:47:12 GMT

In article <1992Sep4.083327.15563@jarvis.csri.toronto.edu>
flaps@dgp.toronto.edu (Alan J Rosenthal) writes:
>Well, is "cat" a self printing program because you can do
>	cat /usr/src/bin/cat.c
>?  "Cat" is not an extremely exciting or novel program.  Your program is less
>exciting than cat.

I still like the solution for this in a scripting language under unix:

#!/bin/cat

It is almost cheating, but not quite.  It is certainly more novel than
the other solution just presented.

There is a shorter version if you do it completely in shell:
----------------------- cut here -------------------------------
----------------------- cut here -------------------------------

An empty shell script will produce no output and compare the same to
the original.

I'm sure that the shortest perl version of this program is even
shorter :-)

Warner
-- 
Warner Losh		imp@Solbourne.COM
I've almost finished my brute force solution to subtlety.
Newsgroups: alt.hackers
From: positron@engin.umich.edu (Jonathan Scott Haas)
Subject: Self Printing Program, revisited
Date: Thu, 03 Sep 92 23:54:41 EDT
Organization: University of Michigan Engineering, Ann Arbor

Awhile back, there was talk about how to write a program whose
output would be the program itself. Here's my program, written
in C, but I think perhaps it "cheats" a bit.

--clip here---------------------------------------------

/*
 * This is a program that should print itself. However, some
 * people might view its algorithm as cheating.
 *
 * Jonathan S. Haas, 3 Sep 92  11:49 pm
 *
 */

#include <stdio.h>

int main(void)
{
  char in[100];
  FILE *readme;

  readme=fopen(__FILE__,"r");
  while(!feof(readme)) {
    fgets(in,99,readme);
    printf("%s",in);
  }
  fclose(readme);
}


-- 
__/\__  Jonathan S. Haas         | Jake liked his women the way he liked
\    /  University of Michigan   | his kiwi fruit: sweet yet tart, firm-
/_  _\  positron@engin.umich.edu | fleshed yet yielding to the touch, and
  \/                             | covered with short brown fuzzy hair.
From: smb@ulysses.att.com (Steven Bellovin)
Newsgroups: alt.hackers
Subject: Re: Prime Number Generator
Date: 31 Aug 92 22:33:27 GMT

In article <1992Aug31.160225.26724@gateway.novell.com>, alex@otis (The Console 
DJ) writes:
> Someone correct me if I am wrong but the whole idea behind the encryption is
> the large prime numbers are difficult to  calulate??? Actually there should
> be no known algorithm (except brute force try every number thingy).

OK, you're wrong...  Generating large prime numbers is quite easy -- one
generates random odd numbers, does a few trial divisions, then applies
as many iterations as desired of probabilistic prime number generators.
The Sieve of Erastosthenes or exhaustive division trials would take far
too long for numbers of cryptographic interest, which are several hundred
bits long, at the very least.

The hard problems are things like factoring large numbers, or calculating
discrete logarithms in finite fields.  If you're interested in the subject,
read sci.crypt for a while.  Or read some books or papers on the subject.
The book I recommend is Davies and Prices's ``Security for Computer
Networks''.


		--Steve Bellovin
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: alt.hackers
Subject: Re: My First Post.
Date: 25 Aug 92 21:40:56 GMT
Organization: University of Helsinki

In article <BtJzvF.6Bx@mentor.cc.purdue.edu> devros@mentor.cc.purdue.edu (Devros) writes:
>Well, Here goes....

And on two /long/ lines..

>ObHack: On the local SUN net, format a disk to SunOS and fdmount it. 
>Copy a shell to it and change permissions to setUID, setGID, and world
>executable.  Put the disk in a computer with a disk editor that you can
>name the media type without a boot sector and find your UID on the disk,
>changing it to a root uid.  Mount it back onto the SUN and execute.  I
>haven't tried it, but theoretically you would get a setuid-root shell. 

"Theoretically" - if it indeed works, your sun setup isn't exactly
secure.  It's pretty easy to disallow suid programs, and I'd assume
fdmount does exactly that, leaving you as badly off as you were from the
beginning.  Now if you had made the disk by doing a "cat > /dev/fd0",
/that/ would be a hack (but it should still not work). 

Obhack: while debugging some weird VM bugs in the linux code, I used

	od -x /dev/kmem | less

to find the problem.  It worked too: it was a stray NULL pointer that
corrupted the page directory.  Who needs a kernel debugger anyway?

		Linus
Newsgroups: alt.hackers
Subject: Re: YAFP: TRS-80 Super Graphics
From: don@zl2tnm.gen.nz (Don Stokes)
Date: 30 Aug 92 05:24:50 GMT
Distribution: world
Organization: The Wolery

wiml@cs.washington.edu (William Lewis) writes:
> In article <YAMAUCHI.92Aug29141341@fox.ces.cwru.edu> yamauchi@ces.cwru.edu (Brian Yamauchi) writes:
> >Now, you can delete your VARPTR/POKE commands, and whenever you want
> >to display your alien invader, simply PRINT A$ at the appropriate
> >point in the screen.
> 
>  The same trick was the standard way to run assembly language
> programs on the ZX81/Timex-Sinclair 1000 (and others of their ilk).
> Youd first write a program like this:
> 
> 10 REM XXXXXXXXXXX....
> 20 FOR I=16514 TO 16823
> 30 INPUT A
> 40 POKE I,A
> 50 NEXT I

Both of these techniques are better desribed as "standard practice"... 

The TRS-80 graphics-as-strings was known as "string packing"; games like
Voyage of the Valkyrie used this extensively to keep the speed up. 

The ZX81 REM statement trick is actually documented in the manual that 
came with the machine, along with a couple of other schemes (using a string
to hold code, or fooling the system into thinking memory ended earlier than
it did).

ObHack: telephone management by modem -- I just type "ring joe" or whatever,
it dials the number, and if the line isn't busy it tells me when to pick up 
the phone....  (I also have it deliver messages by "voice", using an old 
Amiga 1000 as a (terrible) speech synthesiser... 8-)

--
Don Stokes, ZL2TNM (DS555)                        don@zl2tnm.gen.nz (home)
Network Manager, Computing Services Centre            don@vuw.ac.nz (work)
Victoria University of Wellington, New Zealand              +64-4-495-5052
From: jim@rand.org (Jim Gillogly)
Newsgroups: alt.hackers
Subject: Re: Prime Number Generator
Date: 31 Aug 92 17:55:59 GMT
Organization: Banzai Institute

In article <1992Aug31.160225.26724@gateway.novell.com> alex@otis (The Console DJ) writes:
>Someone correct me if I am wrong but the whole idea behind the encryption is
>the large prime numbers are difficult to  calulate??? Actually there should
>be no known algorithm (except brute force try every number thingy).

OK, I will.  The whole idea beind RSA encryption is that large prime numbers
are *easy* to prove prime, but large composite numbers (e.g. the product
of two large primes) are (so far as anybody knows) difficult to factor.

-- 
	Jim Gillogly
	jim@rand.org
Newsgroups: alt.hackers,alt.fan.dan-quayle
From: god@white-house.com (You know who)
Subject: An official message
Organization: heh
Date: Sun, 30 Aug 1992 19:28:36 GMT

finger quayle@ns1.cc.lehigh.edu
[ns1.cc.lehigh.edu]
----------------------------------------
         name: QUAYLE, TUCKER DANFORTH
        email: tdq2@Lehigh.EDU
         type: p-Undergrad
----------------------------------------
Newsgroups: alt.hackers,alt.folklore.computers