Conference hydra::amiga_v1

    I was wondering this myself.  On my C64 (yes, I admit to owning
    a C64) this was easy.  Memory was broken up into chunks that you
    could use, and since you had 'control' you didn't have to worry
    about pesky things :^) like 'safe memory allocation'.  Just POKE 
    where you felt was safe.
    
    It sounds like you want to share a piece of memory between 
    several independently running applications.  In C, I would say to 
    malloc a buffer, and 'send' the starting address of the buffer to 
    the other application, who in turn would know what to do with it.
    
    In AmigaBASIC perhaps you could DIM an array, get the address
    (is that possible in A-BASIC?) and send that using whatever mechanism
    is at your disposal for inter-process communication.
    
    If AmigaBASIC gets it's memory off of your local stack space (like C), 
    this would only work as long as the allocator doesn't go away.
    Once it does, that memory becomes fair game for anyone else who might
    need it.
    
    Perhaps the Amiga has a small chunk of memory tucked away somewhere
    to use as you see fit.  Kind of like the C64's cassette buffer :^).
    I have my doubts though.  Of course, you could opt to create a small
    RAM: file to keep the info you need.  The new process could read
    it, and clean it up once finished.
    
    ~Steve - I'm just mumbling, and probably making no sense at all

    Thanks Steve - creating a small RAM: device is quite a good
    idea...although I'm not sure How secure I could make this...I can
    POKE a value into a memory adress and once the code is compiled
    into an object it's a little more difficult for a would-be hacker to locate
    the right address and extract the information from it during the
    running of the applications. a RAM: device is a little easier to
    get at...
    
    The Friend that I am writing this stuff for wants to place restrictions
    on certain files (READ/WRITE/PRINT/DELETE) - kind of like a Privilege
    mask. I dont think a RAM: device would be secure enough for his
    needs. 

    There MUST be a way - this was a piece of cake with my old system-80
    because the documentation clearly stated which areas of memory were
    used for what...the standard Amiga documentation does not have this
    info...
    
    Cheers & thanks for the alternative
    
    
    Phil
    

    Hmmm,
    if You need a 'safe' POKE, You have to allocate the memory.
    Perhaps the system routine 'AllocAbs()' will help.
    Don't know the exact syntax, but I'll figure it out if You want.
    
    But don't ask me, how to call this routine from BASIC (I don't know).
    
    Gerald

    What are you trying to do?  If you are trying to build in a password
    protection scheme, perhaps you should consider using a password file
    which has the password encoded in it.  That works better in a
    multitasking environment than trying to find a fixed chunk of memory 
    you can use.  Most of the memory on the Amiga is dyinamically allocated
    and deallocated.  Even if you do find a static chunk, you won't be able
    to guarantee that it will remain available across versions of the op
    sys.  
    
    I know you can make a file practiacally invisible (it can be done by 
    accident, I think it can also be done on purpose - I'm not an Ami 
    expert yet).  That should keep casual attackers from getting your
    passwords.  Then if you use a reasonable encoding scheme (like the 
    double key method (trap door?) that VMS uses it can be very hard to
    find out what passwords are being used (particularly if you don't
    publish the encoding scheme).
    
    Have fun.
    
    Yours
    Erg

    Tell me more about this "Double Key" encoding please...
    
    What I have at present:
    
    1. The disk auto boots and loads to WB
    2. User selects icon to start application.
    3. Security screen appears and asks for username and Password. 
    4. if after three attempts the user has not entered a correct
       username and password the application writes the illegal
       username and password used to a journal file and then trashes
       the Security file so it cannot be read. To recreate the security
       file, one must access another utility from the WB. To access
       this utility, one must have the product registration number
       (supplied with disk) and the password selected by the person
       who initially boots up the disk.   
     5. If a correct username/password is entered the application makes
        note of a privilege mask associated with said username. 1=READ
        2=READ/WRITE,3=READ/WRITE/PRINT and 4=READ/WRITE/PRINT/DELETE.
        it is this priviliege "mask" that must be poked into a memory
        location. Each module that is loaded, checks this memory address
        and takes steps to ensure that only those with the right privilege
        may perform certain actions from within the application.
         
     At present the USER file is stored in plain binary mode...it would
     be nice to make this a little more secure for him...      
    
     Any help appreciated...
    
     Cheers
    

    RE .5:
    
    I have a few comments about your intended strategy.
    
>   1. The disk auto boots and loads to WB
    
    If the user can ^D out of the boot sequence, they can also circumvent
    your authentication mechanism.  If they CAN'T, then you could do
    authentication prior to starting the workbench.
    
>   2. User selects icon to start application.
    
    OK.  Alternately, a LOGIN program could be provided that renders the
    application usable (via volatile storage).
    
>   3. Security screen appears and asks for username and Password.
    
    Your user authorization file should be one-way encrypted (there are a
    number of algorithms around).  The authentication program applies the
    same algorithm used to make the file to the supplied username and
    password and checks for a match.
    
>   4. if after three attempts the user has not entered a correct
>      username and password the application writes the illegal
>      username and password used to a journal file and then trashes
>      the Security file so it cannot be read. To recreate the security
>      file, one must access another utility from the WB. To access
>      this utility, one must have the product registration number
>      (supplied with disk) and the password selected by the person
>      who initially boots up the disk.
    
    NO!  Sometimes the penetrator's goal is to deny service to legitimate
    users.  A successful login should render the application usable. 
    Failure should not maim the system, though it might be reasonable to
    disable the user until the next boot.
    
>    5. If a correct username/password is entered the application makes
>       note of a privilege mask associated with said username. 1=READ
>       2=READ/WRITE,3=READ/WRITE/PRINT and 4=READ/WRITE/PRINT/DELETE.
>       it is this priviliege "mask" that must be poked into a memory
>       location. Each module that is loaded, checks this memory address
>       and takes steps to ensure that only those with the right privilege
>       may perform certain actions from within the application.
    
    This can be subverted, though not simply.  Disassembly of any one
    module could yield the "magic" location, compromising the whole scheme. 
    If you're going to bother to do all this, you need to make it harder to
    crack.

Bill
    
    Many thanks for your constructive comments...

>>   1. The disk auto boots and loads to WB
    
>    If the user can ^D out of the boot sequence, they can also circumvent
>    your authentication mechanism.  If they CAN'T, then you could do
>    authentication prior to starting the workbench.
    
how can this be disabled? I intend to remove the CLI object fro the
disk, once everything is completed so the user will NOT be able to access
the CLI from the disk...however the point you make is quite correct
how can this be fixed?
    
>>   2. User selects icon to start application.
    
>    OK.  Alternately, a LOGIN program could be provided that renders the
>    application usable (via volatile storage).

    Actually - this is what has been done (sorry about that - I keep
    forgetting people can only read what I type - not what I think)
    The initial program is in fact a login program which then loads
    the title screen, checks the printer and then loads the main menu.
        
>>   3. Security screen appears and asks for username and Password.
    
>    Your user authorization file should be one-way encrypted (there are a
>    number of algorithms around).  The authentication program applies the
>    same algorithm used to make the file to the supplied username and
>    password and checks for a match.

     Could you be more specific? do you have an example of such an 
     algorithm? I have no idea what an algorithm is or what it does
     (Pardon my ignorance)
        
>>   4. if after three attempts the user has not entered a correct
>>      username and password the application writes the illegal
>>      username and password used to a journal file and then trashes
>>      the Security file so it cannot be read. To recreate the security
>>      file, one must access another utility from the WB. To access
>>      this utility, one must have the product registration number
>>      (supplied with disk) and the password selected by the person
>>      who initially boots up the disk.
    
>    NO!  Sometimes the penetrator's goal is to deny service to legitimate
>    users.  A successful login should render the application usable. 
>    Failure should not maim the system, though it might be reasonable to
>    disable the user until the next boot.

    Actually - it only trashes the first record - and saves all other
    records (including the original first one) the login program reads
    the file. If it finds the first record is in a certain format it
    comes to a complete stop, explaining what has to be done to rectify
    the suituation...ie: loading the rebuild program (which asks for
    it's own password) While I agree with you on this one, I have to
    do what is asked for by my friend. But I will try and convince him
    that your idea is a better one. 
        
>>    5. If a correct username/password is entered the application makes
>>       note of a privilege mask associated with said username. 1=READ
>>       2=READ/WRITE,3=READ/WRITE/PRINT and 4=READ/WRITE/PRINT/DELETE.
>>       it is this priviliege "mask" that must be poked into a memory
>>       location. Each module that is loaded, checks this memory address
>>       and takes steps to ensure that only those with the right privilege
>>       may perform certain actions from within the application.
    
>    This can be subverted, though not simply.  Disassembly of any one
>    module could yield the "magic" location, compromising the whole scheme. 
>    If you're going to bother to do all this, you need to make it harder to
>    crack.

     Once completed all images will be compiled into objects which should
     make it very hard for an average hacker to get around the protection
     scheme (though I doubt it is anywhere near impossible).
    
     By the way - I can't compile the program that loads the title screen
    and get it to work. The program uses the LOADACBM program, found
    in the BASIC extras disk. It compiles ok but when it runs it doesnt
    display the ACBM screen (previously converted from IFF to ACBM by
    the LoadILBM-SaveACBM program as per the instructions in the program.)

    
    Any help you can give me on all this is appreciated - thanks
    again for your response