Undocumented SWIs (was something else)

Undocumented SWIs (was something else)

Post by Iain » Tue, 14 Nov 1995 04:00:00



> This article converted by News2Mail 1.02 (c) Iain Price for the Archimedes

> > While we're on this subject does anybody else know about any
> > undocumented/half documented (This swi is for internal use only, etc)
> > calls?  I've got all the ones from ScreenBlanker 'cos I reverse engineered
> > it to see how it works.....

> * :-)

> Anyway, anyone know what OS_SerialOp 7 does? !Spooler calls it on startup,
> it's not in the RO3 PRMs, but it's in the errata as "internal use". It's
> called with R0=4 and everything else (R1 to R4 at least) =0.

> OS_SerialOp 8 is listed (can't remember what it does, probably not useful).

> Or how about Parallel_HardwareAddress? No entry requirements, returns
> a hardware address in R0 (I *think* it's the address of the parallel
> data register) and a pointer to some code in the ROM in R1.

> --
> David Long                   Disclaimer: I'm free to say whatever I, whatever

> ... Fatal internal error: no humorous taglines

No taglines cos I ain't implemented them yet. :)
Some time soon :)

-----
Iain Price (IRC:Keydisc)

[long sig snipped]

 
 
 

Undocumented SWIs (was something else)

Post by Neil Coff » Tue, 14 Nov 1995 04:00:00


Quote:> While we're on this subject does anybody else know about any
> undocumented/half documented (This swi is for internal use only, etc)
> calls?  I've got all the ones from ScreenBlanker 'cos I reverse engineered
> it to see how it works.....

Well come on, then, give us the details...

Quote:>Or how about Parallel_HardwareAddress? No entry requirements, returns
>a hardware address in R0 (I *think* it's the address of the parallel
>data register) and a pointer to some code in the ROM in R1.

I notice also that FSLock_Version returns in R1 a pointer to the module's
workspace. This is clearly in order to allow you to peek it and find
out the current password, but, has anybody actually reverse engineered
the FSLock module and found out precisely how it stores the password?

 
 
 

Undocumented SWIs (was something else)

Post by Andrew Mil » Tue, 14 Nov 1995 04:00:00


Neil Coffey (n...@ccsware.demon.co.uk) wrote:

: > While we're on this subject does anybody else know about any
: > undocumented/half documented (This swi is for internal use only, etc)
: > calls?  I've got all the ones from ScreenBlanker 'cos I reverse engineered
: > it to see how it works.....

: Well come on, then, give us the details...

Okay, okay, here goes:

                                                        ScreenBlanker_Control
                                                                 (SWI &43100)

   General purpose call to control the screen blanking

On entry

   R0 = Action code (0-4)
   R1, R2 - as required by individual actions

On exit

   R0, R1, R2 - as returned by individual actions

Interrupts

   Interrupts are not defined
   Fast interrupts are enabled

Processor Mode

   Processor is in SVC mode

Re-entrancy

   SWI is re-entrant

Use

   This call controls the screen blanker.  The particular action of
   ScreenBlanker_Control is given by the reason code in R0 as follows:

   R0     Action                             Page

   0      Blank screen                       Undocumented-3
   1      Reinstate screen                   Undocumented-4
   2      Flash screen                       Undocumented-5
   3      Set blanking time                  Undocumented-6
   4      Read blanking time                 Undocumented-7

   This call is not available in RISC OS 2.

Related SWIs

   None

Related vectors

   WrchV

                                                      ScreenBlanker_Control 0
                                                                 (SWI &43100)

   Blanks the screen

On entry

   R0 = 0

On exit

   R0 = Time of inactivity before screen blanking in 20 centisecond periods

Use

   This call blanks the screen until there is activity (ie keyboard or mouse
   input is received, and - with the W option - there is writing to the
   screen).

Related reason codes

   1 (page Undocumented-4)

                                                      ScreenBlanker_Control 1
                                                                 (SWI &43100)

   Reinstates the screen

On entry

   R0 = 1

On exit

   R0 = Time of inactivity before screen blanking in 20 centisecond periods

Use

   This call reinstates the screen after it has been blanked.

Related reason codes

    0 (page Undocumented-3)

                                                      ScreenBlanker_Control 2
                                                                 (SWI &43100)

   Flashes the screen

On entry

   R0 = 2
   R1 = Mark time in centiseconds
   R2 = Space time in centiseconds

On exit

   R0-R2 preserved

Use

   This call flashes the screen until there is activity (ie keyboard or
   mouse input is received, and - with the W option - there is writing to
   the screen).  It is used by the Portable module to alert the user that
   the battery is running low.  R1 and R2 are used to set the mark:space
   ratio of the flashing.

Related reason codes

   None

                                                      ScreenBlanker_Control 3
                                                                 (SWI &43100)

   Sets the time of inactivity before the screen blanks

On entry

   R0 = 3
   R1 = Time of inactivity before screen blanking in centiseconds

On exit

   R0 = Time of inactivity before screen blanking in 20 centisecond periods
   R1 preserved

Use

   This call sets the time in centiseconds before the screen blanks. If
   during this time, there is no activity (ie no keyboard or mouse input,
   and - with the W option - there is no writing to the screen) the screen
   then blanks.  This saves 'burn in' on the phosphor of your monitor, which
   occurs when the monitor consistently displays a particular image, such as
   the desktop.  The value in R1 is rounded to a whole number of seconds
   which are greater or equal to 5 seconds.

Related reason codes

   4 (page Undocumented-7)

                                                      ScreenBlanker_Control 4
                                                                 (SWI &43100)

   Reads the time of inactivity before the screen blanks

On entry

   R0 = 4

On exit

   R0 = Time of inactivity before screen blanking in 20 centisecond periods
   R1 = Time of inactivity before screen blanking in seconds

Use

   This call reads the time in seconds before the screen blanks. If during
   this time, there is no activity  (ie no keyboard or mouse input, and -
   with the W option - there is no writing to the screen) the screen then
   blanks. This saves 'burn in' on the phosphor of your monitor, which
   occurs when the monitor consistently displays a particular image, such as
   the desktop.

Related reason codes

   3 (page Undocumented-6)

                                                         Addition to PaletteV
                                                                 (Vector &23)

On entry

   Clear/Restore palette

   R0 = 0 (restore palette)
      = 1 (blank palette)
   R4 = 6 (reason code)

                                                     Parallel_HardwareAddress
                                                                 (SWI &42EC0)

   Returns various hardware addresses

On entry

   -

On exit

 R0 = Address of parallel data register (If 710/711 controller present
      otherwise 0)
 R1 = Address of routine to alter control registers (If 710/711 controller
      present otherwise 0)

Interrupts

   Interrupts are not defined
   Fast interrupts are enabled

Processor Mode

   Processor is in SVC mode

Re-entrancy

   SWI is re-entrant

Use

   This call returns the addresses of the parallel data register and a
   routine which can write the current state of the parallel control
   register.  On entry to the routine the new state is determined by:

      new state = (old state AND R1) EOR R0

   This call is not available in RISC OS 2.  This call is obsolete, you
   should use Parallel_Op instead.

Related SWIs

   Parallel_Op (page 2-480)

Related vectors

   None

Happy now?  ScreenBlanker_Control,2,10,10 is good for knackering the
relays in monitors with power saving modes :)  There should be a way to
claim Wrch detection using the swis like *blanktime W but I can't find
it.....

: >Or how about Parallel_HardwareAddress?

Did that for you an all :)  Now how about the ones in ColourPicker, ADFS,
OS_SerialOp, Font, service call Print, und zu weiter

: I notice also that FSLock_Version returns in R1 a pointer to the module's
: workspace. This is clearly in order to allow you to peek it and find
: out the current password, but, has anybody actually reverse engineered
: the FSLock module and found out precisely how it stores the password?

I think the password is stored the same as UNIX stores it's password's, so
its uncrackable within this universe's time....:(  However, i've written
a nice little utility which bypasses fslock without the password, but
thats naughty and so what I just said was a figment of your imagination :)
It uses Fslock_version btw which I thought was very handy :)

Andrew
--
Andrew D Miles

WWW : http://whirligig.ecs.soton.ac.uk/~adm94/home.html

Documentation - The worst part of programming.

 
 
 

Undocumented SWIs (was something else)

Post by Matthew Wilc » Wed, 15 Nov 1995 04:00:00


: > While we're on this subject does anybody else know about any
: > undocumented/half documented (This swi is for internal use only, etc)
: > calls?  I've got all the ones from ScreenBlanker 'cos I reverse engineered
: > it to see how it works.....

: * :-)

[some examples snipped]

Personally, I'm rather interested in the undocumented two OS_FSControls.
I have a feeling they're something to do with the SIN (System Internel
Number) - probably converting it to/from path name.  Does anyone know if
the SIN comes up anywhere apart from OS_GBPB 11?

--
Bill Gates and Rupert Murdoch are  || I don't even know what York
the Information Superhighwaymen    || University's opinions are.


 
 
 

Undocumented SWIs (was something else)

Post by Iain » Thu, 16 Nov 1995 04:00:00


This article converted by News2Mail 1.02 (c) Iain Price for the Archimedes


> : I notice also that FSLock_Version returns in R1 a pointer to the module's
> : workspace. This is clearly in order to allow you to peek it and find
> : out the current password, but, has anybody actually reverse engineered
> : the FSLock module and found out precisely how it stores the password?

> I think the password is stored the same as UNIX stores it's password's, so
> its uncrackable within this universe's time....:(  However, i've written
> a nice little utility which bypasses fslock without the password, but
> thats * and so what I just said was a figment of your imagination :)
> It uses Fslock_version btw which I thought was very handy :)

Try resouces:$.resources.fslock.messages
Look for the adfs::4.$.public line and change it to adfs::4.$
I you know how (hint, get a resourcefs maker)

PS> I aint tried this - whats the point!

-----
Iain Price (IRC:Keydisc)

[long sig snipped]

 
 
 

Undocumented SWIs (was something else)

Post by Dave » Thu, 16 Nov 1995 04:00:00


Quote:>                                                      Parallel_HardwareAddress
>                                                                  (SWI &42EC0)

Thanks for this one.

Quote:>  R0 = Address of parallel data register (If 710/711 controller present
>       otherwise 0)

I was right! Good guess or what? :-)

Quote:> Did that for you an all :)  Now how about the ones in ColourPicker, ADFS,
> OS_SerialOp, Font, service call Print, und zu weiter

Don't fancy doing OS_SerialOp 7 (or whatever the undoc'ed one is) for me,
do you? I'm trying to write a better version of !Spooler, and Desktop
Hacker tells me it calls this on startup, but it's not documented. And
don't go telling me to disassemble it - if you can convert ABC code back
to Basic, I'd be surprised.

Quote:> : I notice also that FSLock_Version returns in R1 a pointer to the module's
> : workspace. This is clearly in order to allow you to peek it and find
> : out the current password, but, has anybody actually reverse engineered
> : the FSLock module and found out precisely how it stores the password?

> I think the password is stored the same as UNIX stores it's password's, so
> its uncrackable within this universe's time....:(  However, i've written
> a nice little utility which bypasses fslock without the password, but
> thats * and so what I just said was a figment of your imagination :)
> It uses Fslock_version btw which I thought was very handy :)

Unix uses hashing functions, which are basically like CRCs - they don't
encrypt the data, they store some sort of checksum which isn't likely to
be used by a close guess. You can really only get through these by brute
force - reversing the hashing function won't get you far.

Are we going to have a competition of "who can crack FSLock in the shortest
number of lines?"-type thing? ;-)

--
David Long                                          (no witty comments today)

 
 
 

Undocumented SWIs (was something else)

Post by Martin Thorp » Sat, 18 Nov 1995 04:00:00



> I think there ought to be a jumper in the machine to stop shift
> boots for use in schools etc...

If you think FSLock is bad, take a look at ClassROM ;->

Martin Thorpe
Laser-Scan Limited, Cambridge Science Park, Milton Road, Cambridge CB4 4FY, UK

 
 
 

Undocumented SWIs (was something else)

Post by Philip R. Ban » Sat, 18 Nov 1995 04:00:00



> Are we going to have a competition of "who can crack FSLock in the shortest
> number of lines?"-type thing? ;-)

   Possibly not a wise idea. I can bypass it one line. Interestingly enough the
reasons for my solution working would appear to lie deep in the guts of RISC OS.

    Philip

--





 
 
 

Undocumented SWIs (was something else)

Post by Andrew Hodgkins » Sat, 18 Nov 1995 04:00:00




Damn! VProtect missed that one... Does anyone know how to get rid of it?

TTFN, Andrew

"Hold on tight lad, and think of Lancashire Hotpot!"
                                                     - A Grand Day Out
Hi there! I am an anti signature virus utility. Copy me into your
signature to use me!

 
 
 

Undocumented SWIs (was something else)

Post by Iain » Sat, 18 Nov 1995 04:00:00


This article converted by News2Mail 1.02 (c) Iain Price for the Archimedes


> : Don't fancy doing OS_SerialOp 7 (or whatever the undoc'ed one is) for me,
> : do you?I'm trying to write a better version of !Spooler, and Desktop

> I had a look at it, after I eventually found the code for it, it's in
> SerialDeviceSupport, I thought it would be in the Utility module so I
> tried disasembling that (not a good idea).  As far as I can see it seems
> to do exactly the same thing as OS_Byte 156, but I can't be sure...

> : Are we going to have a competition of "who can crack FSLock in the shortest
> : number of lines?"-type thing? ;-)

> It's not difficult....


I think there ought to be a jumper in the machine to stop shift
boots for use in schools etc...

-----
Iain Price (IRC:Keydisc)

[long sig snipped]

 
 
 

Undocumented SWIs (was something else)

Post by Mike Smi » Mon, 27 Nov 1995 04:00:00



Quote:> [If you're wondering, in a fit of stupidity last week, I managed to FSLock my
> machine and forget the password within about 5 seconds of each other :-(.  I
> wrote a quick program which allowed me to choose a new password by hashing

Hell I just would have done a delete+switch-on, much easier.....

if that didn't work you could open the macine and move LK5

At my school we have started cable tie-ing the covers on for this reason
and an 8Mb Simms dissappeared.

--
Mike Smith

A Californian living in Plymouth, Devon, England :)

I miss root beer, Paydays, and Prime Rib, but the USA
needs more fish 'n' chips and indian curries.

Devon = http://www.dcs.ex.ac.uk/wcol/counties/devon.html
Plymouth = http://www.cs.ucl.ac.uk/misc/uk/plymouth.html

 
 
 

1. Undocumented SWIS

FSLock certainly isn't difficult to bypass (in terms of rendering it
ineffective.) Now, as regards cracking its password system, that's more
difficult. Having said that, why do you need to crack the password system
if you can just work round it?

The partitioner module on ClassROM (does anyone use ClassROM?) handles the
disk protection. What's clever is the way that RMKilling the partitioner
prevents you from accessing the disks. What's not so clever is how the
protection data is stored: it's probably no easier to crack the passwords
but it's about as easy to bypass as FSLock.

Martin Thorpe
Laser-Scan Limited, Cambridge Science Park, Milton Road, Cambridge CB4 4FY, UK

2. New IDL User Questions

3. Am I doing something wrong

4. test

5. Am I missing something?

6. ZYXEL: phone answering machine?

7. Undocumented 6502 opcodes

8. Junkmailed!

9. Undocumented features in RO4!

10. Undocumented AOF relocation directives?

11. Undocumented Calls (again)

12. Undocumented TI85 features?

13. Undocumented features of TI cartridges