Mini Office II disk protection (Split from: Legacy of the BBC Micro User magazine / Database Publications Ltd)

discussion of beeb/electron applications, languages, utils and educational s/w
User avatar
Rich Talbot-Watkins
Posts: 1117
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca

Mini Office II disk protection (Split from: Legacy of the BBC Micro User magazine / Database Publications Ltd)

Postby Rich Talbot-Watkins » Tue Nov 14, 2017 2:25 pm

(Split off from this post)

Kevin Edwards wrote:You can find more information about Database Publications / Europress here:-

https://en.wikipedia.org/wiki/Europress


Playing 'follow the links' from that Wikipedia page led me here:

https://en.wikipedia.org/wiki/Mini_Office_II

...which contains this pioneering bit of 20th century thinking:
The word processor on Mini Office II allows the user, after having loaded the word processor and created a word file and saved it, to load the word file directly from the tape without re-loading the word processor. If the user has a word file on tape it therefore loads in about three seconds.

One day, maybe all word processors will work like that...

Kevin Edwards
Posts: 61
Joined: Tue Mar 14, 2006 9:16 pm

Re: Legacy of the BBC Micro User magazine / Database Publications Ltd

Postby Kevin Edwards » Tue Nov 14, 2017 2:37 pm

Amazing!

Mini Office sold like hot-cakes and made them a small fortune - much cheaper than the View suite or Inter-series from CC. Not sure how they compare in terms of quality or features.

I just had a flashback and remember working on Micro Olympics for Database - about 1984ish? Totally forgot about that one...not that it was any good. :P

User avatar
Rich Talbot-Watkins
Posts: 1117
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca

Re: Legacy of the BBC Micro User magazine / Database Publications Ltd

Postby Rich Talbot-Watkins » Tue Nov 14, 2017 2:51 pm

...and of course it had a famously evil disk protection system, which (as far as I know) you had nothing to do with! :D

(Mini Office II that is, don't think I've even heard of Micro Olympics!)

Kevin Edwards
Posts: 61
Joined: Tue Mar 14, 2006 9:16 pm

Re: Legacy of the BBC Micro User magazine / Database Publications Ltd

Postby Kevin Edwards » Tue Nov 14, 2017 2:57 pm

I doubt it had ANY protection on it.

I vaguely remember helping out on the Spectrum and possibly C64 versions for a week or two. It was a pretty awful game that tried to copy Hyper-Sports ( arcade ). Looks like it was written in BASIC, but actually used some machine code IIRC!

User avatar
Rich Talbot-Watkins
Posts: 1117
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca

Re: Legacy of the BBC Micro User magazine / Database Publications Ltd

Postby Rich Talbot-Watkins » Tue Nov 14, 2017 3:10 pm

Kevin Edwards wrote:I doubt it had ANY protection on it.

Sorry, I was talking about Mini Office II (edited my other post for clarity)!

I remember I had a disc copying program (might've been Vector 2) which had a special option just for Mini Office II!

Kevin Edwards
Posts: 61
Joined: Tue Mar 14, 2006 9:16 pm

Re: Legacy of the BBC Micro User magazine / Database Publications Ltd

Postby Kevin Edwards » Tue Nov 14, 2017 3:23 pm

Ah, OK. I don't know who did the protection for MOII - pretty sure it wasn't me. :-)

I left Database to write Galaforce before MOII was finished. Probably had the obligatory duff track / sector somewhere!

ghbearman
Posts: 245
Joined: Sun Apr 16, 2006 4:51 pm
Location: England

Re: Legacy of the BBC Micro User magazine / Database Publications Ltd

Postby ghbearman » Tue Nov 14, 2017 3:27 pm

I once wrote and had published a disk protection that relied on track 81 being readable! you can't even run this in an emulator, lol.

User avatar
billcarr2005
Posts: 1094
Joined: Fri Sep 09, 2005 3:01 pm
Location: UK
Contact:

Re: Legacy of the BBC Micro User magazine / Database Publications Ltd

Postby billcarr2005 » Tue Nov 14, 2017 3:28 pm

I have a feeling that Disc Duplicator III (the freeware version) had additional "finishers" to make copies of Mini Office II and AMX Pagemaker (amongst others - perhaps something by Clares) work correctly... although I can't find the disk image anywhere at the moment...

EDIT: Found DD3 on 8BS, BBC-132
http://8bs.com/catalogue.htm

DD3 DEDICATED.png


Also, for reference, the offending tracks on Mini Office II had the following format

Code: Select all

Tr.#  No.S  Sec.# Tr.ID Head# SecID IDsiz REsiz Error

00    0A    00    00    00    00    0100  0100  OK
            01    00    00    01    0100  0100  OK
            02    00    00    06    0100  0100  OK
            03    00    00    03    0100  0100  OK
            04    00    00    04    0100  0100  OK
            05    00    00    05    0100  0100  OK
            06    00    00    02    0100  0100  OK
            07    00    00    03    0100  0100  OK
            08    00    00    04    0100  0100  OK
            09    00    00    05    0100  0100  OK

01    10    00    01    00    00    0080  0100  OK
            01    01    00    02    0080  0080  OK
            02    01    00    03    0080  0080  OK
            03    01    00    04    0080  0080  OK
            04    01    00    05    0080  0080  OK
            05    01    00    06    0080  0080  Deleted data
            06    01    00    07    0080  0080  Deleted data
            07    01    00    08    0080  0080  Deleted data
            08    01    00    09    0080  0080  Deleted data
            09    01    00    0A    0080  0080  Deleted data
            0A    01    00    0B    0080  0080  Deleted data
            0B    01    00    0C    0080  0080  OK
            0C    01    00    0D    0080  0080  OK
            0D    01    00    0E    0080  0080  OK
            0E    01    00    0F    0080  0080  OK
            0F    01    00    10    0080  0080  OK


As well as having 42 tracks (although only CONVERT was on the spillover).
!BOOT occupied the same sector as a file called MINI also... :)

ghbearman wrote:I once wrote and had published a disk protection that relied on track 81 being readable! you can't even run this in an emulator, lol.

Could make an FSD out of it! :P

Kevin Edwards
Posts: 61
Joined: Tue Mar 14, 2006 9:16 pm

Re: Legacy of the BBC Micro User magazine / Database Publications Ltd

Postby Kevin Edwards » Tue Nov 14, 2017 3:43 pm

Ah, track 1 has mixed sector sizes 128 and 256 byte with some normal and deleted data sectors.
Additional sectors added due to 128 byte ones being used.

Track 1, Sector 00 is interesting
01 10 00 01 00 00 0080 0100 OK

For sector 0 the CHRN has been set as a 128 byte sector ( on format ), but actually has a readable 256 byte sector?

This could cause big problems on some DDFS systems when performing OSWORD &7F calls.

What Disk Analysis software created the sector dump, by the way?

I had a really cool TRACE DFS that would print out the OSWORD &7F calls that were performed and told you the results ( erros ). So useful for hacking disk formats!

ghbearman
Posts: 245
Joined: Sun Apr 16, 2006 4:51 pm
Location: England

Re: Legacy of the BBC Micro User magazine / Database Publications Ltd

Postby ghbearman » Tue Nov 14, 2017 3:45 pm

yeah it was only meant as something simple but defeated Howard Spurr's copier.

User avatar
Rich Talbot-Watkins
Posts: 1117
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca

Re: Legacy of the BBC Micro User magazine / Database Publications Ltd

Postby Rich Talbot-Watkins » Tue Nov 14, 2017 3:54 pm

And track 0 has duplicated sector IDs! That's a more tricky one to defeat! I guess you need to sync with the index hole (how?) and read N-1 sectors (or perhaps, better, N-1 sector IDs), and then read the sector you want as a second step, now that the disk is more or less in the right place.

Kevin Edwards
Posts: 61
Joined: Tue Mar 14, 2006 9:16 pm

Re: Legacy of the BBC Micro User magazine / Database Publications Ltd

Postby Kevin Edwards » Tue Nov 14, 2017 4:04 pm

I missed the duplicated sectors. Interesting.

It depends what they try and do with them during the load.

Do they simply check for duplicate sectors ( read CHRN values ) or do they actually read and use data from the duplicate sector IDs?

I think on some disk controllers you can actually write the entire track as one lump. Perhaps this is how they generated the disk format they require - with unique data in matching sectors - not sure how you would be able to read the same sector to get the different data through so seems unlikely that they do have different data in the duplicated sectors - no guarantee that you can read them individually. However, there is a read track command, but I don't think that exists on 8271? I don't have the datasheets to hand to check.

I'm guessing they simply read the CHRNs and check for duplicate sectors rather than attempt to read their contents.

I found that Disk Duplicator 3 > Vector 2 > Basil Blooms Copy All.

When used together, these three would copy MOST protected disks.

User avatar
billcarr2005
Posts: 1094
Joined: Fri Sep 09, 2005 3:01 pm
Location: UK
Contact:

Re: Legacy of the BBC Micro User magazine / Database Publications Ltd

Postby billcarr2005 » Tue Nov 14, 2017 5:09 pm

Kevin Edwards wrote:What Disk Analysis software created the sector dump, by the way?


It's a BBC BASIC for Windows program that just looks at the FSD file and produces a report. The format is heavily borrowed / copied from Enigma Disc Imager's *IDDUMP, as is the FSD maker program!

Kevin Edwards wrote:I think on some disk controllers you can actually write the entire track as one lump. Perhaps this is how they generated the disk format they require - with unique data in matching sectors - not sure how you would be able to read the same sector to get the different data through so seems unlikely that they do have different data in the duplicated sectors - no guarantee that you can read them individually.


MINI0, the loading / menu MODE7 screen is at absolute (logical) sector 002, and !BOOT & MINI occupy sector 006 (physical sector 2), so they have unique data.
It's a while since I imaged the disk (January 2013), so not entirely sure of the details, but with the FSDBeebEM emulation, i have a "last sector read" value, so the next read just picks up from there and it seems to work :?
The main thing was, most (all?) off the shelf copiers couldn't handle the format, and I've never attempted to rewrite it, but it can be reproduced in an FSD :)

User avatar
Rich Talbot-Watkins
Posts: 1117
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca

Re: Legacy of the BBC Micro User magazine / Database Publications Ltd

Postby Rich Talbot-Watkins » Tue Nov 14, 2017 5:35 pm

I think the disk format can be reproduced easily - just by specifying duplicate sector IDs in the format command. The difficulty is getting an 8271 to read it, as it uses the logical sector number, not the physical sector number, to match the requested sector ID.

Just looking at the 8271 datasheet, you can read the required one by using the Read ID command (which always starts at the index mark) to read N-1 IDs (N being the physical sector you want to read), then a Read Data command to read the sector itself.

I think the tricky one is writing sectors whose sizes don't match the ID size on a 1770... far as I know there's no way to reproduce that (even though you can read them OK).

User avatar
Rich Talbot-Watkins
Posts: 1117
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca

Re: Legacy of the BBC Micro User magazine / Database Publications Ltd

Postby Rich Talbot-Watkins » Wed Nov 15, 2017 10:35 am

billcarr2005 wrote:Also, for reference, the offending tracks on Mini Office II had the following format

Code: Select all

Tr.#  No.S  Sec.# Tr.ID Head# SecID IDsiz REsiz Error

00    0A    00    00    00    00    0100  0100  OK
            01    00    00    01    0100  0100  OK
            02    00    00    06    0100  0100  OK
            03    00    00    03    0100  0100  OK
            04    00    00    04    0100  0100  OK
            05    00    00    05    0100  0100  OK
            06    00    00    02    0100  0100  OK
            07    00    00    03    0100  0100  OK
            08    00    00    04    0100  0100  OK
            09    00    00    05    0100  0100  OK

etc

Out of curiosity, when building these sector dumps, how do you determine how many sectors a track has? There's no way of reading that as far as I can tell - you just have to use 8271 command &5B to read sector IDs, and you have to specify how many you want. I assume if you specify more than there are, it'll wrap around and you'll get the first ones again. So how can you distinguish wrap around from new sectors with duplicate IDs? Are you adding up the real sector sizes (not from the IDs) and stopping when you reach full track capacity? Never struck me until now how complicated it is to determine something so simple!

User avatar
Kecske Bak
Posts: 676
Joined: Wed Jul 13, 2005 7:03 am
Location: Treddle's Wharf, Chigley
Contact:

Re: Legacy of the BBC Micro User magazine / Database Publications Ltd

Postby Kecske Bak » Wed Nov 15, 2017 6:50 pm

Rich Talbot-Watkins wrote:(Mini Office II that is, don't think I've even heard of Micro Olympics!)

IIRC The Micro User ran a news story boasting Micro Olympics featured paid-for advertising on the advertising hoardings in the game and claimed this was a first.

Kevin Edwards
Posts: 61
Joined: Tue Mar 14, 2006 9:16 pm

Re: Mini Office II disk protection (Split from: Legacy of the BBC Micro User magazine / Database Publications Ltd)

Postby Kevin Edwards » Wed Nov 15, 2017 10:45 pm

Yes, i remember that. Good bit of journalistic marketing!

AJH
Posts: 75
Joined: Sun Sep 22, 2002 10:47 am

Re: Mini Office II disk protection (Split from: Legacy of the BBC Micro User magazine / Database Publications Ltd)

Postby AJH » Sat Dec 09, 2017 1:12 pm

billcarr2005 wrote:
the offending tracks on Mini Office II had the following format

Code: Select all
Tr.# No.S Sec.# Tr.ID Head# SecID IDsiz REsiz Error

00 0A 00 00 00 00 0100 0100 OK
01 00 00 01 0100 0100 OK

My 8271 disk copy program had a similar display but was very slow (it read/wrote one sector at a time). Every time a new disk wouldn't copy it got tweaked and the display was my debugging.
Mini Office II was the hardest disk to copy because of duplicate sector ID's (I never got track 42 as my drive couldn't read that many tracks).

ghbearman wrote:
I once wrote and had published a disk protection that relied on track 81 being readable! you can't even run this in an emulator, lol.

Thats a failure of the emulator. I remember looking at BeebEm years ago and it just dimensioned 80 tracks (200K) of space. standard DFS has a limit of 256K (10 bit sector numbers).
Most of the disks I formatted had 41 tracks which was the most my drive would do.
P.S. Elite relied on a low track number being unformatted (but you can write a single sector bigger than the track length to overwrite the sector ID.)

Rich Talbot-Watkins wrote:
I think the disk format can be reproduced easily - just by specifying duplicate sector IDs in the format command. [edit] you can read the required one by using the Read ID command (which always starts at the index mark) to read N-1 IDs (N being the physical sector you want to read), then a Read Data command to read the sector itself.

Thats how I did it (and BASIC was plenty fast enough).

Rich Talbot-Watkins wrote:
Out of curiosity, when building these sector dumps, how do you determine how many sectors a track has? There's no way of reading that as far as I can tell

Given that the smallest sector size is 128 bytes (from memory) I think I just requested twice as many sector ID's as would physically fit and looked for the list repeating itself (I cant remember if I factored in sector size as well).
This isn't 100% foolproof.

User avatar
billcarr2005
Posts: 1094
Joined: Fri Sep 09, 2005 3:01 pm
Location: UK
Contact:

Re: Mini Office II disk protection (Split from: Legacy of the BBC Micro User magazine / Database Publications Ltd)

Postby billcarr2005 » Sat Dec 09, 2017 4:12 pm

AJH wrote:My 8271 disk copy program had a similar display but was very slow (it read/wrote one sector at a time). Every time a new disk wouldn't copy it got tweaked and the display was my debugging.

The FSD transfer works on a sector a time and you're right, having a display does quickly help pinpoint any problem areas.
When transferring disks over, I now know a standard 40 track disk will be 104929 bytes compared to the SSD of 102400, a modest increase of 2529, although plenty of disks are shorter because of unformatted tracks,


Rich Talbot-Watkins wrote:
Out of curiosity, when building these sector dumps, how do you determine how many sectors a track has? There's no way of reading that as far as I can tell

AJH wrote:Given that the smallest sector size is 128 bytes (from memory) I think I just requested twice as many sector ID's as would physically fit and looked for the list repeating itself (I cant remember if I factored in sector size as well).
This isn't 100% foolproof.


The FSD program reads 32 sector headers (I think this is the maximum per DFS track) and then has a loop to check for repeats, although I lifted it wholesale from Enigma Disc Imager, so just copied / pasted and it worked! It's only now that I've actually looked how the code works.
It reads how far it's got into the headers in memory then divides the result by 4 to get the number of sectors.
If it assumes that there are 10 sectors, then it should get the same result 40 bytes forward in the 128 bytes it's checking, if not it can work on it being different.

User avatar
Rich Talbot-Watkins
Posts: 1117
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca

Re: Mini Office II disk protection (Split from: Legacy of the BBC Micro User magazine / Database Publications Ltd)

Postby Rich Talbot-Watkins » Mon Dec 11, 2017 10:26 am

Good to see you back AJH!

I guess the other thing you need to do when trying to make a sector dump is to try reading each sector with every possible sector size, not just the one reported in the IDs. (I presume you get an error when trying to read a sector with a different size to its actual size?). So once you've determined each sector size, you can add up the total data size so far and keep going through the read sector IDs until you hit the track limit, though even this could be abused (by leaving a portion of the track unformatted). It's a surprisingly tricky problem to find loops in a set of data, but there are definitely ways you could format a disk to leave it absolutely ambiguous whether you had looped round or not (without literally comparing the sector data itself).

User avatar
billcarr2005
Posts: 1094
Joined: Fri Sep 09, 2005 3:01 pm
Location: UK
Contact:

Re: Mini Office II disk protection (Split from: Legacy of the BBC Micro User magazine / Database Publications Ltd)

Postby billcarr2005 » Mon Dec 11, 2017 12:52 pm

Rich Talbot-Watkins wrote:I guess the other thing you need to do when trying to make a sector dump is to try reading each sector with every possible sector size, not just the one reported in the IDs. (I presume you get an error when trying to read a sector with a different size to its actual size?).

A "Data CRC error" will occur if reading with a different size, since the CRC is the two bytes immediately following the data.
I suppose you could create a 2048 byte sector which will give an accurate CRC with every read, by having the correct CRC after 128, 256, 512 and 1024 bytes.

Rich Talbot-Watkins wrote:So once you've determined each sector size, you can add up the total data size so far and keep going through the read sector IDs until you hit the track limit, though even this could be abused (by leaving a portion of the track unformatted).

Any data within a track has to be accessible via the sector headers, even if they are overread (on the 8271) so I've never seen a program which calculates the track length based on adding up the reported data sizes.

Rich Talbot-Watkins wrote:It's a surprisingly tricky problem to find loops in a set of data, but there are definitely ways you could format a disk to leave it absolutely ambiguous whether you had looped round or not (without literally comparing the sector data itself).

If you had a track with 20 sectors, 0 -9 followed by 0-9, I think that would defeat Enigma's way of computing the number, would probably upset a great number of DFSs too though.
I guess a certain number of protections would've been implemented deliberately to circumvent the different copiers that were out there.
Enigma baulks at the idea of a track having different track numbers specified in the sector headers, so just bypasses reading it... 3D pool uses this to it's advantage by having data which needs to be read contained within that track

User avatar
Rich Talbot-Watkins
Posts: 1117
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca

Re: Mini Office II disk protection (Split from: Legacy of the BBC Micro User magazine / Database Publications Ltd)

Postby Rich Talbot-Watkins » Mon Dec 11, 2017 3:17 pm

billcarr2005 wrote:A "Data CRC error" will occur if reading with a different size, since the CRC is the two bytes immediately following the data.
I suppose you could create a 2048 byte sector which will give an accurate CRC with every read, by having the correct CRC after 128, 256, 512 and 1024 bytes.

Did you ever come across that in the wild? That would be an interesting form of obfuscation. Even if a sector is overread and it has the right CRC, you'll get mark bytes where they're not expected. Doesn't that cause a different kind of error (clock error?)?

billcarr2005 wrote:If you had a track with 20 sectors, 0 -9 followed by 0-9, I think that would defeat Enigma's way of computing the number, would probably upset a great number of DFSs too though.
I guess a certain number of protections would've been implemented deliberately to circumvent the different copiers that were out there.
Enigma baulks at the idea of a track having different track numbers specified in the sector headers, so just bypasses reading it... 3D pool uses this to it's advantage by having data which needs to be read contained within that track

Not sure if you can format a track with 20 sectors can you? I had a feeling that 18 128 byte sectors was pretty much the limit.

One thing I wonder is whether it was possible to exploit 'illegal' behaviour in the 8271 to do things you couldn't ordinarily do. For example, if you want to format a track with different sized sectors, could you send a new format command with different parameters while the first one was being executed, in order to change its internal parameter registers? And what would happen? The datasheet says "issuing a command while another command is in progress is illegal" - but that doesn't mean you can't do it, or that it doesn't have a predictable result :twisted: I wonder if anyone ever tried it.

User avatar
billcarr2005
Posts: 1094
Joined: Fri Sep 09, 2005 3:01 pm
Location: UK
Contact:

Re: Mini Office II disk protection (Split from: Legacy of the BBC Micro User magazine / Database Publications Ltd)

Postby billcarr2005 » Mon Dec 11, 2017 10:54 pm

Rich Talbot-Watkins wrote:Not sure if you can format a track with 20 sectors can you? I had a feeling that 18 128 byte sectors was pretty much the limit.


I think i must've got the idea from the following

Code: Select all

The most significant 3 bits of the number stored in parameter block &09
contain the sector size code (column 2 of figure 3). The least significant
5 bits contain the number of sectors per track.


from http://mdfs.net/Docs/Comp/BBC/DFSOsword/Part02 , which would give a maximum of 31 sectors per track, although that would be a theoretical maximum based on the number which can be stored! It also tied in with Enigma reading 32 sector headers, to make sure it had got them all possible...

However, as figure 3 shows

Code: Select all

+-------------+-----------+--------+------+------+------+------+------+
| No. Sectors | Size code | Length | Gap1 | Gap2 | Gap3 | Gap4 | Gap5 |
+-------------+-----------+--------+------+------+------+------+------+
|     18      |     0     |   128  |  16  |  11  |  11  |   24 |   0  |
|     10      |     1     |   256  |  16  |  11  |  21  |   30 |   0  |
|      5      |     2     |   512  |  16  |  11  |  74  |   88 |   0  |
|      2      |     3     |  1024  |  16  |  11  | 255  |  740 |   0  |
|      1      |     4     |  2048  |  16  |  11  |   0  | 1028 |   0  |
+-------------+-----------+--------+------+------+------+------+------+


Does go someway to explaining Track 02 of 3D Pool though, which is reported as

Code: Select all

02    12    00    02    00    09    0100
            01    02    00    08    0100
            02    02    00    07    0100
            03    02    00    06    0100
            04    02    00    05    0100
            05    02    00    04    0100
            06    02    00    03    0100
            07    02    00    02    0100
            08    02    00    01    0100
            09    02    00    00    0100
            0A    00    00    00    0080
            0B    00    00    00    0080
            0C    00    00    00    0080
            0D    00    00    00    0080
            0E    00    00    00    0080
            0F    00    00    00    0080
            10    00    00    00    0080
            11    00    00    00    0080


but since the track IDs are different, Enigma would usually just skip over it... the reported size for the sectors is misreported as 256 bytes, and all 18 sectors will be 128, but with some headers zeroed out!


Return to “software: other”

Who is online

Users browsing this forum: No registered users and 5 guests