Hi, I've found a usefull utility in AA February 1990. The program is called "DE-PROTECT": It will load protected Basic listings and resave them without protection. Well, there's an error in it, which I can't solve.
Thanks for your help
1 REM BASIC DE-PROTECTOR
2 REM by Adrian Forbes
3 REM for Amstrad Action February 1990
4 REM |SP,"FILENAME" or a$="FILENAME"
10 tot=0
20 for a=&B000 to &b066
30 read a$:poke a,VAL("&"+a$)
40 tot=tot+VAL("&"+a$)
50 next
60 IF tot=&2878 THEN CALL &B000 ELSE PRINT"**ERROR DATA**"
70 DATA 21,0a,b0,01,0e,b0,cd,d1
80 DATA bc,c9,fc,a6,0e,b0,13,b0
90 DATA 18,04,c9,44,d0,00,dd,6e
100 DATA 00,0d,6b,01,7e,32,0d,50
110 DATA 23,5e,23,56,ed,53,01,50
120 DATA 3a,00,50,47,2a,01,50,11
130 DATA 00,9d,cd,77,bc,ed,43,03
140 DATA 50,21,00,10,cd,83,bc,cd
150 DATA 7a,bc,3e,07,cd,5a,bb,cd
160 DATA 18,bb,3a,00,50,47,2a,01
170 DATA 50,11,00,90,cd,8c,bc,21
180 DATA 00,10,ed,5b,03,50,3e,00
190 DATA cd,98,bc,cd,8f,bc,c9
Maybe it's because of the bad quality of scan
Line 70: Looks like 'D1' should be the last data statement.
Line 90, second last: not 'i0' (there's no i in hex). It's bloody hard to make out, might be 'DD'?
Line 100: second entry might also be 'DD'.
Line 190: third last looks like '8F'.
Quote from: CPCIak on 17:54, 02 January 10
Hi, I've found a usefull utility in AA February 1990. The program is called "DE-PROTECT": It will load protected Basic listings and resave them without protection. Well, there's an error in it, which I can't solve.
Thanks for your help
1 REM BASIC DE-PROTECTOR
2 REM by Adrian Forbes
3 REM for Amstrad Action February 1990
4 REM |SP,"FILENAME" or a$="FILENAME"
10 tot=0
20 for a=&B000 to &b066
30 read a$:poke a,VAL("&"+a$)
40 tot=tot+VAL("&"+a$)
50 next
60 IF tot=&2878 THEN CALL &B000 ELSE PRINT"**ERROR DATA**"
70 DATA 21,0a,b0,01,0e,b0,cd,01
80 DATA bc,c9,fc,a6,0e,b0,13,b0
90 DATA 18,04,c9,44,d0,00,t0,6e
100 DATA 00,0d,6b,01,7e,32,0d,50
110 DATA 23,5e,23,56,ed,53,01,50
120 DATA 3a,00,50,47,2a,01,50,11
130 DATA 00,9d,cd,77,bc,ed,43,03
140 DATA 50,21,00,10,cd,83,bc,cd
150 DATA 7a,bc,3e,07,cd,5a,bb,cd
160 DATA 18,bb,3a,00,50,47,2a,01
170 DATA 50,11,00,90,cd,8c,bc,21
180 DATA 00,10,ed,5b,03,50,3e,00
190 DATA cd,98,bc,cd,bf,bc,c9
Maybe it's because of the bad quality of scan
Thanx - I've corrected line 70
Whats up with line 90: Data ....00,i0,6e?
-> Type mismatch in line 30 ???
Add line 90 correction, I think. All fixes in my original reply.
And a few other, that's all I could spot so far. Hope that helps.
Indeed a bad scan. Can't you scan it with a higher resolution? 300dpi should do here.
I haven't got the original mag - it's a screenshot of a pdf document.
Well, in the German section "Listings" I've posted the TypeChecker for AA listings.
This one isn't compatible with it, because TypeChecker was published later.
1 REM BASIC DE-PROTECTOR
2 REM by Adrian Forbes
3 REM for Amstrad Action February 1990
4 REM |DP,"FILENAME" or a$="FILENAME":|DP,@a$
10 tot=0
20 FOR a=&B000 TO &B066
30 READ a$:POKE a,VAL("&"+a$)
40 tot=tot+VAL("&"+a$)
50 NEXT
60 IF tot=&2878 THEN CALL &B000 ELSE PRINT "**ERROR DATA**"
70 DATA 21,0A,B0,01,0E,B0,CD,D1
80 DATA BC,C9,FC,A6,0E,B0,13,B0
90 DATA 18,04,C9,44,D0,00,D0,6E
100 DATA 00,DD,66,01,7E,32,0D,50
110 DATA 23,5E,23,56,ED,53,01,50
120 DATA 3A,00,50,47,2A,01,50,11
130 DATA 00,90,CD,77,BC,ED,43,03
140 DATA 50,21,00,10,CD,83,BC,CD
150 DATA 7A,BC,3E,07,CD,5A,BB,CD
160 DATA 18,BB,3A,00,50,47,2A,01
170 DATA 50,11,00,90,CD,8C,BC,21
180 DATA 00,10,ED,5B,03,50,3E,00
190 DATA CD,98,BC,CD,8F,BC,C9
;; JavaCPC disassembled binary
;; disassembled from B000 to B066
;; Sat Jan 02 20:18:21 CET 2010
ORG #B000
LD HL,#B00A
LD BC,#B00E
CALL #BCD1
RET
CALL M,#0EA6
OR B
INC DE
OR B
JR #B016
RET
LD B,H
RET NC
NOP
RET NC
LD L,(HL)
NOP
LD H,(IX+#01)
LD A,(HL)
LD (#500D),A
INC HL
LD E,(HL)
INC HL
LD D,(HL)
LD (#5001),DE
LD A,(#5000)
LD B,A
LD HL,(#5001)
LD DE,#9000
CALL #BC77
LD (#5003),BC
LD HL,#1000
CALL #BC83
CALL #BC7A
LD A,#07
CALL #BB5A
CALL #BB18
LD A,(#5000)
LD B,A
LD HL,(#5001)
LD DE,#9000
CALL #BC8C
LD HL,#1000
LD DE,(#5003)
LD A,#00
CALL #BC98
CALL #BC8F
RET
Thank you Devilmarkus :D
Quote from: CPCIak on 20:39, 02 January 10
Thank you Devilmarkus :D
The code is still bad.
line 100 makes problems in my code here...
This should work
100 DATA 00,DD,66,01,7E,32,00,50
If you are using an emulator, is a lot easier to install the Utopia rom and use the command - |load -
Here it is:
1 ' BASIC de-protector
2 ' by Adrian Forbes
3 ' |DP,"FILENAME" or a$="FILENAME":|DP,@a$
10 tot=0
20 FOR a=&B000 TO &B066
30 READ a$:POKE a,VAL("&"+a$)
40 tot=tot+VAL("&"+a$)
50 NEXT
60 IF tot=&2878 THEN CALL &B000 ELSE PRINT"** Error in data **"
70 DATA 21,0A,B0,01,0E,B0,CD,D1
80 DATA BC,C9,FC,A6,0E,B0,13,B0
90 DATA 18,04,C9,44,D0,00,DD,6E
100 DATA 00,DD,66,01,7E,32,00,50
110 DATA 23,5E,23,56,ED,53,01,50
120 DATA 3A,00,50,47,2A,01,50,11
130 DATA 00,90,CD,77,BC,ED,43,03
140 DATA 50,21,00,10,CD,83,BC,CD
150 DATA 7A,BC,3E,07,CD,5A,BB,CD
160 DATA 18,BB,3A,00,50,47,2A,01
170 DATA 50,11,00,90,CD,8C,BC,21
180 DATA 00,10,ED,5B,03,50,3E,00
190 DATA CD,98,BC,CD,8F,BC,C9
Checksums:
(http://cpc-live.com/screen.png)
BTW.: JavaCPC has a "Override ,P protection" feature in misc. settings.
Heheheh the screen printout is cool :D
But, the scan is not so bad. The corrections mentioned were quite easy to spot! Come on guys, we're not that old just yet...
Ah yes, protected files ;D I recall being really impressed by the "protecting" of the files and if you could "crack" it somehow. After learning a bit of machinecode it wasnt as impressive anymore ;)
Ive know ive been doing a bit of commercial for the AA tape no. 22 (issue 88) but here i go again. Its a nice tape as it has that nice filecopy (and diskcopy) tool JL-copy that also can handle copy of protected files to unprotected (or unprotected to protected).
Tape also has the nice DMON tool on it that allows you to your edit your discs as much as you like. Really one of the most usefull AA tapes ever i think.
IIRC from a discussion in the Zone, the 'protected' bit doesn't protect anything at all, really, it just tells the *system* that this file is protected so you can't list it etc...
Quote from: Gryzor on 15:03, 05 January 10
IIRC from a discussion in the Zone, the 'protected' bit doesn't protect anything at all, really, it just tells the *system* that this file is protected so you can't list it etc...
I know that the firmware 'encrypts' a protected file when it is written to cassette or disc. That's why it takes longer to load a protected file into memory.
If you can find a BASIC program with some text in it, save it to a blank disc as both an unprotected BASIC program (
i.e. SAVE"filename"), and a protected BASIC program (
i.e. SAVE"filename",P). Then use a disc sector editor, such as
DMon, to examine the contents of the files, and notice the difference in the way the two files are stored on the disc.
Quote from: Gryzor on 10:04, 04 January 10
But, the scan is not so bad. The corrections mentioned were quite easy to spot! Come on guys, we're not that old just yet...
Not everyone on this forum can recognise Z80 op-codes in hexadecimal, Gryzor! ;)
Quote from: Nich on 14:47, 16 January 10
Not everyone on this forum can recognise Z80 op-codes in hexadecimal, Gryzor! ;)
Nahhhh I have stacks of printouts I read while in the bathroom :D
Quote from: Nich on 14:44, 16 January 10
I know that the firmware 'encrypts' a protected file when it is written to cassette or disc. That's why it takes longer to load a protected file into memory.
I have checked that my program CDTMaster has a problem because this. Protected files from DSK are recovered "encrypted".
Because I need to "decrypt" them outside of a Amstrad or emulation, do you know which algorithm used or some place where it was described?
I notice that cpcxfs has the same problem. You can not remove the protected flags without corrupt them.
JavaCPC has an "Ignore ,P protection" option in system settings.
Enable it to load any ,P protected BASIC program (from DSK or CDT)
Quote from: Devilmarkus on 14:01, 26 August 15
JavaCPC has an "Ignore ,P protection" option in system settings.
Enable it to load any ,P protected BASIC program (from DSK or CDT)
I know how to make an emulator to not apply the protection.
There is a code in the wiki.
Programming:Unlocking a protected basic file - CPCWiki (http://www.cpcwiki.eu/index.php/Programming:Unlocking_a_protected_basic_file)
But I want to know which algorithm is used to "encrypt" the files to add the funcionality to my program CDTMaster to unprotect the files directly.
Only from DSK and C# code.
Here is a piece of source code ManageDSK, which decodes a protected basic program :
static BYTE DproBasic[ 128 ] =
{
0xAB, 0x2C, 0xED, 0xEA, 0x6C, 0x37, 0x3F, 0xEC,
0x9B, 0xDF, 0x7A, 0x0C, 0x3B, 0xD4, 0x6D, 0xF5,
0x04, 0x44, 0x03, 0x11, 0xDF, 0x59, 0x8F, 0x21,
0x73, 0x7A, 0xCC, 0x83, 0xDD, 0x30, 0x6A, 0x30,
0xD3, 0x8F, 0x02, 0xF0, 0x60, 0x6B, 0x94, 0xE4,
0xB7, 0xF3, 0x03, 0xA8, 0x60, 0x88, 0xF0, 0x43,
0xE8, 0x8E, 0x43, 0xA0, 0xCA, 0x84, 0x31, 0x53,
0xF3, 0x1F, 0xC9, 0xE8, 0xAD, 0xC0, 0xBA, 0x6D,
0x93, 0x08, 0xD4, 0x6A, 0x2C, 0xB2, 0x07, 0x27,
0xC0, 0x99, 0xEE, 0x89, 0xAF, 0xC3, 0x53, 0xAB,
0x2B, 0x34, 0x5C, 0x2F, 0x13, 0xEE, 0xAA, 0x2C,
0xD9, 0xF4, 0xBC, 0x12, 0xB3, 0xC5, 0x1C, 0x68,
0x01, 0x20, 0x2C, 0xFA, 0x77, 0xA6, 0xB5, 0xA4,
0xFC, 0x9B, 0xF1, 0x32, 0x5B, 0xC3, 0x70, 0x77,
0x85, 0x36, 0xBE, 0x5B, 0x8C, 0xC8, 0xB5, 0xC2,
0xF0, 0x0B, 0x98, 0x0F, 0x36, 0x9D, 0xD8, 0x96
};
static BYTE GetByte( BYTE * BufFile, int Pos, int Deprotect )
{
return( BYTE )( BufFile[ Pos ] ^ ( DproBasic[ Pos & 0x7F ] * Deprotect ) );
}
The Deprotect variable is 0 for a normal basic program, and 1 for a protected basic program ;)
Quote from: demoniak on 16:41, 26 August 15
Here is a piece of source code ManageDSK, which decodes a protected basic program :
static BYTE DproBasic[ 128 ] =
{
0xAB, 0x2C, 0xED, 0xEA, 0x6C, 0x37, 0x3F, 0xEC,
0x9B, 0xDF, 0x7A, 0x0C, 0x3B, 0xD4, 0x6D, 0xF5,
0x04, 0x44, 0x03, 0x11, 0xDF, 0x59, 0x8F, 0x21,
0x73, 0x7A, 0xCC, 0x83, 0xDD, 0x30, 0x6A, 0x30,
0xD3, 0x8F, 0x02, 0xF0, 0x60, 0x6B, 0x94, 0xE4,
0xB7, 0xF3, 0x03, 0xA8, 0x60, 0x88, 0xF0, 0x43,
0xE8, 0x8E, 0x43, 0xA0, 0xCA, 0x84, 0x31, 0x53,
0xF3, 0x1F, 0xC9, 0xE8, 0xAD, 0xC0, 0xBA, 0x6D,
0x93, 0x08, 0xD4, 0x6A, 0x2C, 0xB2, 0x07, 0x27,
0xC0, 0x99, 0xEE, 0x89, 0xAF, 0xC3, 0x53, 0xAB,
0x2B, 0x34, 0x5C, 0x2F, 0x13, 0xEE, 0xAA, 0x2C,
0xD9, 0xF4, 0xBC, 0x12, 0xB3, 0xC5, 0x1C, 0x68,
0x01, 0x20, 0x2C, 0xFA, 0x77, 0xA6, 0xB5, 0xA4,
0xFC, 0x9B, 0xF1, 0x32, 0x5B, 0xC3, 0x70, 0x77,
0x85, 0x36, 0xBE, 0x5B, 0x8C, 0xC8, 0xB5, 0xC2,
0xF0, 0x0B, 0x98, 0x0F, 0x36, 0x9D, 0xD8, 0x96
};
static BYTE GetByte( BYTE * BufFile, int Pos, int Deprotect )
{
return( BYTE )( BufFile[ Pos ] ^ ( DproBasic[ Pos & 0x7F ] * Deprotect ) );
}
The Deprotect variable is 0 for a normal basic program, and 1 for a protected basic program ;)
Where do you find INT Deprotect?
Quote from: Devilmarkus on 16:45, 26 August 15
Where do you find INT Deprotect?
The Deprotect variable is a parameter set when ManageDsk detect that the basic program is protected, and reset otherwise.
For deprotect protected basic programs only, you can simply forget this variable :
static BYTE GetByte( BYTE * BufFile, int Pos )
{
return ( BYTE )( BufFile[ Pos ] ^ DproBasic[ Pos & 0x7F ] );
}
Thank you very much.
I consider simple algorithms like this, but there is some garbage in 0x40-0x80 position (data begins 0x80-) and I was assuming on debugging, that data begins on 0x40. This garbage misled me.
So, a very simple algorithm. I hope this "garbage" (like at the end) is really garbage and I could omit even if I write another different data to the DSK image again.
It's no garbage, but part of the AMSDOS Header...
But the read could be made OK.
Mission accomplished 8) . On next version of CDTMaster, Protected BASIC will be copied OK from DSK to CDT (on tapes, Protected Basic is not masked).
There was a RSX Library called Ten-Bars from AA56, which had 2 RSXes for Encoding or Decoding Data.
The user would enter a code number to Encode/Decode - along with the start/end address.
Thread resurrection FTW!
Ah, good thing too since Sourceforge didn't list any changes for the new CDTMaster version...