Secure? No, but much more so than protected BASIC programmes on tape, which merely had a single field set in the tape header that triggered the run once then NEW behaviour. It would definitely have slowed down most bedroom crackers, but if you had a sector editor, a printer and a good eye for detail, you could probably work it out quite quickly. As Ken has said, you only need the byte sequence, you don't need to know the source.
As a quick demo of how one might retrieve the key, consider the following BASIC programme:
10 REM 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
20 REM 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
30 END
(that is, several lines of REM statements of maximum length, all holding the same byte value)
The first 512 bytes of this programme when saved look like:
00000000: 0050 524f 542d 4220 2042 4153 0000 0000 .PROT-B BAS....
00000010: 0000 0000 0070 0100 0602 0000 0000 0000 .....p..........
00000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000040: 0602 004b 031e 0098 0000 001a 4220 2024 ...K........B $
00000050: 2424 ff00 ff00 0000 0000 0000 0000 0000 $$..............
00000060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000080: ff00 0a00 c520 3030 3030 3030 3030 3030 ..... 0000000000
00000090: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000
000000a0: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000
000000b0: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000
000000c0: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000
000000d0: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000
000000e0: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000
000000f0: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000
00000100: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000
00000110: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000
00000120: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000
00000130: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000
00000140: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000
00000150: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000
00000160: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000
00000170: 3030 3030 3030 3030 3030 3030 3030 00ff 00000000000000..
00000180: 0014 00c5 2030 3030 3030 3030 3030 3030 .... 00000000000
00000190: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000
000001a0: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000
000001b0: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000
000001c0: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000
000001d0: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000
000001e0: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000
000001f0: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000
When saved via SAVE "PROT-P.BAS",P
they look like:
00000000: 0050 524f 542d 5020 2042 4153 0000 0000 .PROT-P BAS....
00000010: 0000 0100 0070 0100 0602 0000 0000 0000 .....p..........
00000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000040: 0602 005a 03b5 2c75 ea6c 3725 3030 3030 ...Z..,u.l7%0000
00000050: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000
00000060: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000
00000070: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000
00000080: 542c e7ea a917 0fdc abef 4a3c 0be4 5dc5 T,........J<..].
00000090: 3474 3321 ef69 bf11 434a fcb3 ed00 5a00 4t3!.i..CJ....Z.
000000a0: e3bf 32c0 505b a4d4 87c3 3398 50b8 c073 ..2.P[....3.P..s
000000b0: d8be 7390 fab4 0163 c32f f9d8 9df0 8a5d ..s....c./.....]
000000c0: a338 e45a 1c82 3717 f0a9 deb9 9ff3 639b .8.Z..7.......c.
000000d0: 1b04 6c1f 23de 9a1c e9c4 8c22 83f5 2c58 ..l.#......"..,X
000000e0: 3110 1cca 4796 8594 ccab c102 6bf3 4047 1...G.......k.@G
000000f0: b506 8e6b bcf8 85f2 c03b a83f 06ad e8a6 ...k.....;.?....
00000100: 9b1c ddda 5c07 0fdc abef 4a3c 0be4 5dc5 ....\.....J<..].
00000110: 3474 3321 ef69 bf11 434a fcb3 ed00 5a00 4t3!.i..CJ....Z.
00000120: e3bf 32c0 505b a4d4 87c3 3398 50b8 c073 ..2.P[....3.P..s
00000130: d8be 7390 fab4 0163 c32f f9d8 9df0 8a5d ..s....c./.....]
00000140: a338 e45a 1c82 3717 f0a9 deb9 9ff3 639b .8.Z..7.......c.
00000150: 1b04 6c1f 23de 9a1c e9c4 8c22 83f5 2c58 ..l.#......"..,X
00000160: 3110 1cca 4796 8594 ccab c102 6bf3 4047 1...G.......k.@G
00000170: b506 8e6b bcf8 85f2 c03b a83f 06ad d869 ...k.....;.?...i
00000180: ab38 ed2f 4c07 0fdc abef 4a3c 0be4 5dc5 .8./L.....J<..].
00000190: 3474 3321 ef69 bf11 434a fcb3 ed00 5a00 4t3!.i..CJ....Z.
000001a0: e3bf 32c0 505b a4d4 87c3 3398 50b8 c073 ..2.P[....3.P..s
000001b0: d8be 7390 fab4 0163 c32f f9d8 9df0 8a5d ..s....c./.....]
000001c0: a338 e45a 1c82 3717 f0a9 deb9 9ff3 639b .8.Z..7.......c.
000001d0: 1b04 6c1f 23de 9a1c e9c4 8c22 83f5 2c58 ..l.#......"..,X
000001e0: 3110 1cca 4796 8594 ccab c102 6bf3 4047 1...G.......k.@G
000001f0: b506 8e6b bcf8 85f2 c03b a83f 06ad e8a6 ...k.....;.?....
Very quickly, you can see repeat patterns: look at the sequences at &110 and &190 where the ASCII representation shows 4t3!
… Realizing that most of the bytes in the source file are &30, XORing the result with &30 would be a good guess for recovering the key:
…
00000080: 641c d7da 9927 3fec 9bdf 7a0c 3bd4 6df5 d....'?...z.;.m.
00000090: 0444 0311 df59 8f21 737a cc83 dd30 6a30 .D...Y.!sz...0j0
000000a0: d38f 02f0 606b 94e4 b7f3 03a8 6088 f043 ....`k......`..C
000000b0: e88e 43a0 ca84 3153 f31f c9e8 adc0 ba6d ..C...1S.......m
000000c0: 9308 d46a 2cb2 0727 c099 ee89 afc3 53ab ...j,..'......S.
000000d0: 2b34 5c2f 13ee aa2c d9f4 bc12 b3c5 1c68 +4\/...,.......h
000000e0: 0120 2cfa 77a6 b5a4 fc9b f132 5bc3 7077 . ,.w......2[.pw
000000f0: 8536 be5b 8cc8 b5c2 f00b 980f 369d d896 .6.[........6...
00000100: ab2c edea 6c37 3fec 9bdf 7a0c 3bd4 6df5 .,..l7?...z.;.m.
00000110: 0444 0311 df59 8f21 737a cc83 dd30 6a30 .D...Y.!sz...0j0
00000120: d38f 02f0 606b 94e4 b7f3 03a8 6088 f043 ....`k......`..C
00000130: e88e 43a0 ca84 3153 f31f c9e8 adc0 ba6d ..C...1S.......m
00000140: 9308 d46a 2cb2 0727 c099 ee89 afc3 53ab ...j,..'......S.
00000150: 2b34 5c2f 13ee aa2c d9f4 bc12 b3c5 1c68 +4\/...,.......h
00000160: 0120 2cfa 77a6 b5a4 fc9b f132 5bc3 7077 . ,.w......2[.pw
00000170: 8536 be5b 8cc8 b5c2 f00b 980f 369d e859 .6.[........6..Y
00000180: 9b08 dd1f 7c37 3fec 9bdf 7a0c 3bd4 6df5 ....|7?...z.;.m.
00000190: 0444 0311 df59 8f21 737a cc83 dd30 6a30 .D...Y.!sz...0j0
000001a0: d38f 02f0 606b 94e4 b7f3 03a8 6088 f043 ....`k......`..C
000001b0: e88e 43a0 ca84 3153 f31f c9e8 adc0 ba6d ..C...1S.......m
000001c0: 9308 d46a 2cb2 0727 c099 ee89 afc3 53ab ...j,..'......S.
000001d0: 2b34 5c2f 13ee aa2c d9f4 bc12 b3c5 1c68 +4\/...,.......h
000001e0: 0120 2cfa 77a6 b5a4 fc9b f132 5bc3 7077 . ,.w......2[.pw
000001f0: 8536 be5b 8cc8 b5c2 f00b 980f 369d d896 .6.[........6...
00000200: ab2c edea 6c37 3fec 9bdf 7a0c 3bd4 6df5 .,..l7?...z.;.m.
00000210: 0444 0311 df59 8f21 737a cc83 dd30 6a30 .D...Y.!sz...0j0
00000220: d38f 02f0 606b 94e4 b7f3 03a8 6088 f043 ....`k......`..C
…
And there it is, the start of the key at &100 and again at &200, beginning with the byte sequence:
&ab, &2c, &ed, &ea, &6c, &37, &3f, &ec,
&9b, &df, &7a, &0c, &3b, &d4, &6d, &f5, …
Since the 255 byte maximum line length may kibosh pulling the key out in one piece, you might need a longer sample programme to extract the key. The above bytes match the key used in the ManageDSK source, as listed in this other forum thread: Unprotecting Programs - CPCWiki Forum.
The above is an example of a known-plaintext attack (KPA).