TUCoPS :: Networks :: nimbus.txt

Hacking The Nimbus Network

Unauthorised Access UK  0636-708063  10pm-7am  12oo/24oo

Hackers Cove  8:30pm-7am  +44 (0)204 792642

--------------------------------------------------------------------------------
  Research Machines Nimbus hacking, by The Green Rhino
--------------------------------------------------------------------------------

Please upload to other boards, but keep this header intact.
Any corrections will be welcomed.


--------------------------------------------------------------------------------
As everybody probably already knows, Research Machines sell, what they claim
 to be a computer, as the Nimbus.  They charge double the price anybody else 
charges so that they can then give schools their traditional discount.  Looking 
back through some PCW issues, I found a review that suggested that Nimbuses
 (Nimbi? Nimbus with a long 'u' ?), with MS-NET were the best computers that a
 school could buy.  They were supposed to be faster, and more powerful, because
 of the 80186 processor, and the network was found to be the most reliable and
 fastest.  They may have been better than any others at the time, but their
 performance still leaves a lot to be desired.

Anyway, enough prattle, now what about hacking the network?  The simplest, and
 quickest way to get at the root directory is of course to get at the
 fileserver, terminate the server program, and then you're in.  Just type the 
user password file, and then CTRL-ALT-DEL to restart the server.

As far as I know, there are two releases of the network software, and their
 file structures are organised slightly differently.  I'll start with release
 1.  The logon screen is a light blue colour.  This is limited to about 64
 offers.  An offer is a resource e.g. a printer, a floppy drive, or a fixed
 disk.  An offer can be defined at the file server either at boot-up, or while
 the network is running.  The syntax is:
SHARE <resource name>=<path name> (password) (/[rwcd])
The resource name is an arbitrary name for the offer, up to (I think) 8 
characters long.  The path name is something like: "C:\FOO.BAR", or "PRN:". 
 There can be one or more switches, which begin with a '/' , after the password
.  They are (R)ead access, (W)rite access, (C)hange access, (D)elete.  They
 are independent of each other, but must occur in that order. 

If no access is given to a resource then anything connected to the resource 
can not do anything, apart from select, and deselect it.  For example, if the
 resource without access is a drive, you can change to that drive, and even
 change directory, but you can't do a directory of the files on the disk. 
 Usually read and write access is given to most resources, with important
 offers being given only read access.  For example, in the standard setup,
 normal users are given only read access to drive P, which is public, and
 read/write/change access to drive N.  By the way, if you are given read and 
write but not change, you just can't delete any file, although you can save
 files.  Also, you would normally be given only write access to a printer!

The resource name in Release 1 is usually the user name, for example two
 common resource shares might be:
SHARE user1=C:\user1 pw1 /rwc
SHARE public=C:\public pw2 /rwc

So far, I haven't mentioned the password field, or how users are allocated
 to resources etc.  The password field is just an optional, up to 8 character
 field that means that people with a little utility called USE, can't just get
 in. (But more of that later).  The resources are totally separate from the
 users, and are held in a file called OFFERS, which, in Release1, is held on 
the root directory of the server boot-up floppy.

The users information, passwords, access etc., are held in a file called USERS.
NET somewhere on the Winchester.  This is generated from USERS.TXT, which
 contains in ASCII format the passwords, and access.  USERS.TXT is not 
essential, and it is redundant in Release 2.  USERS.NET is not TYPEable, but 
if you try doing an ASCII dump, ignoring control characters (DEBUG.COM is good 
for this), you'll see somewhere a list of user names and passwords.  This file 
also contains details of which resources are allocated to users.  It will
 contain the resource names and passwords (if any).  Another way to get the
 resource names and passwords is to watch the server's screen when it boots
 up!  If you can't understand what is happening with USERS.NET, and your 
system has MAIL installed, try typing the file USERS in \MAIL.  
This contains the mail passwords which are by default the login ones.

Using the user information is easy -- just type in the user name and password
 at the login screen.  A user to watch out for is NETMGR.  He has access to
 the whole hard disk -- if you succeed in cracking this user,
 try drives K,L,M and N.  The default password is SECRET, and it is sometimes
 not changed.  But doing it this way is a bit elementary, and you can get
 caught all too easily if someone types 'STATUS' on the file server, as the
 user name, and machine number will be displayed on the screen.

If you manage to obtain the resource names and passwords, what use are they?
  Somewhere on the network you will find a little utility called USE.EXE.  It
 may be on the public drive, or the server boot-up floppy.  The files NET.EXE,
 NET.HLP, and USE.HLP, and SETNAME.COM may be of use as well.  Anyway, the
 syntax is:
To connect: USE <device name> \\netname\resourcename (password)
To disconnect: USE <device name> /d
Alternatively, REUSE.EXE will do just as well.  Its syntax is:
REUSE <device name> \\netname\resourcename (password)

What do they do?  USE (dis)connects you to a resource.  REUSE connects you 
to a different resource.  The fields for these commands are the same as for
 the SHARE command, apart from the netname command.  Try typing 'SET' when
 you're logged on.  Somewhere there may be a line saying 'SERVER=', and then 
the net name.  If not, it will usually be SERVER, or SERVER1.

This is a rather sketchy report, since I don't have time to explain 
everything, but another idea is to monitor the data sent across the network 
directly, using sub-Bios calls.  You can use BBC BASIC, or RM BASIC with the 
Sub_Bios extension package to make them.  For details of the calls, have a 
look in the Advanced Reference Manual.
If you do manage to get USE working, then first type 'SETNAME .'. That is: 
setname <dot>.  This means that nobody will notice that you are using the root
 directory resource.

Release 2 is slightly different.  This has a dark blue screen, and the 
standard system message after booting up is: 'Welcome to The Standard Network 
release 2', or something of the sort.  There is also a space at the bottom
 where the network manager can place messages.  In release 2, all the
 interesting files are kept in \network, and \mgr of the hard disk.  The
 files in \mgr are automatically copied over to \network on boot-up, and so 
the \network files are the ones in operation, the \mgr files are the ones 
that will be used next boot-up.  Make any modifications to files in the \mgr
 directory, so that the changes won't immediately be noticed.  An interesting
 file to change is SYSMESS.TXT.  There are other executable files in the \MGR
 directory, the most notable of which is NETMAN.  Just be careful using it.
  The best thing is to copy all the files in \MGR over to your ram drive, run
 NETMAN in the ramdrive, and then copy NETGO.BAT, and USERS.NET back to \MGR
.  You get sharing violation errors if more than one person tries to run 
netman directly, so check first.  If you add a line at the beginning of the
 file NETGO.BAT saying NETST, and create a batch file which copies USERS.NET 
over to the public drive under an innocuous name, then you will be able to 
find out anybody's password at any time.

Whatever you do DON'T delete important files, or somebody else's work. 
 It's just hooliganism and is absolutely pointless, like the viruses that are
 going round.  Anybody who knows enough and wants to can easily stop them --
 it's only innocent users who don't know what's going on who get caught. 
 What might be an idea is a little suggestion in SYSMESS.TXT that the
 security is improved.
--------------------------------------------------------------------------------

TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH