Hello, anyone know how deprotect basic loaders?.
I take a look to north &south tape, but i think it have basic code camuflated, not assembler. But i not know about the basic protections.
I need it to know where the program is loaded.
north & south - les tuniques bleues © infogrames (1989) (http://www.cpc-power.com/index.php?page=detail&onglet=dumps&num=138) (split version).
Quote from: dragon on 11:28, 11 June 16
Hello, anyone know how deprotect basic loaders?.
There's a program from AA53 type ins that deprotects basic files.
AA53 = amstrad action number 53 maybe?.
Quote from: dragon on 11:50, 11 June 16
AA53 = amstrad action number 53 maybe?.
Yeah that's the one.
Programming:Unlocking a protected basic file - CPCWiki (http://www.cpcwiki.eu/index.php/Programming:Unlocking_a_protected_basic_file)
Or Transmat (http://www.cpc-power.com/index.php?page=detail&num=10272) will do it, too!
Thanks all, but i not speak about of protected basic files with ,p
The file is unprotected. But when i made a list. Y only displays lines from 5 to 0 with a copyright of the game text . I thing the rest are in basic but hidden. I search view all code :) .
Quote from: dragon on 11:28, 11 June 16
Hello, anyone know how deprotect basic loaders?.
If you are deprotecting under windows and emulators there is a trick that is use "ManageDsk" it has a fancy option that let you list the file on varios format "asm", "Basic", "scr"...
ok, you have to put the tape loader on disk... but for some nasty basic loader (with no lines or lines that were erased for listing, or any bin loader into a basic loader, etc) take a look of the listing that managedsk does is very very interesting sometimes...
Quote from: Joseman on 12:06, 11 June 16
If you are deprotecting under windows and emulators there is a trick that is use "ManageDsk" it has a fancy option that let you list the file on varios format "asm", "Basic", "scr"...
ok, you have to put the tape loader on disk... but for some nasty basic loader (with no lines or lines that were erased for listing, or any bin loader into a basic loader, etc) take a look of the listing that managedsk does is very very interesting sometimes...
Perfect thanks!
5 :'
4 :' NORTH & SOUTH
3 :' (C) 1990 BY INFOGRAMES
2 :' AMSTRAD VERSION BY
1 :' NEW FRONTIER
0 :'
16713 IF PEEK(375)=77 THEN GOTO 110
20600 BORDER 0:PAPER 0:PEN 1:INK 0,0:INK 1,26:MODE 1:LOCATE 1,25:PRINT "Loading..."
36555 MEMORY &3FFF:LOAD "!",&4000:CALL &4000
100 STOP
110 :'
120 :' MASTER MAKER TAPE
130 :'
140 MEMORY &7FFF:LOAD "NORTH",&8000
150 RESTORE 200:READ DIR,VALOR
160 WHILE DIR<>-1
170 POKE DIR,VALOR:READ DIR,VALOR
180 WEND
190 ùTAPE.OUT:PRINT "Insert tape & press any key":CALL &BB18:SAVE "!NORTH":SAVE "!& SOUTH",B,&8000,&C00,&8000:LOAD"domaster":CALL &D000
200 DATA 375,32,370,5,379,4,404,3,434,2,462,1,487,0,485,35,486,21,492,85,493,82,494,73,495,65,517,32,518,45,519,120,520,80,572,43,573,66,574,203,575,142,-1,-1
JavaCPC has the "Ignore ,P protection" option in system-configuration ;)
If someone is interested how to protect basic listings like this, here is a short description how I did this for my stuff in the 80s:
As you may already know, the first basic-line in RAM begins at 0x170. First two bytes represent the length of the line.
A short basic-program:
10 'This is a little basic-protection demonstration
20 pen 3
30 print "The code is still here"
Now you need the length of the first byte for later deprotecting the file.
type: print peek(&170) to get the value (in decimal). In our case the result is 54.
You don't need to, but if you also want to manipulate adress &171 (second byte of the line-length), you need to peek this too.
You are ready now to protect your listing.
type: poke &170,&A
I mostly used 0x0A (LineFeed) because it gets a fancy result. But you are free to use any number between 1-255.
When you now type list, you'll get the following result:
10 'This is a little basic-protection demonstration
8307 a little basic-protection demonstration
But when you type run, oh wonder, the code is still there.
You can also patch the second byte of the length if you want.
What I did also was the following: I patched the line-number, too:
poke &172,255 (for example)
(and if you want &173)
Sometimes I had the case that a complex basic-program did not work after patching. So I included following first line after the comments:
15 POKE &170,37:POKE &172,5:POKE &BDEE,&C9:KEY DEF 66,0,0:CALL &BC02
(The 37 and 5 for the two pokes are only examples in our case here it's 54 (from the peek) and 5 for the correct line-number)
Here I patched back the basic-file and prevented pressing ESC.
Perhaps this stuff's useful for someone....
Damn. I wish I'd known about that like trick for deprotecting Basic files on a 464 back in the day.
My method was far more long-winded and needed 3 tapes: Tape 1 ( had the P Basic file), Tape 2 ( had a cassette header reader program), and Tape 3 ( blank)
Method:
Insert tape 2 and LOAD the header reader. Eject tape and insert Tape 1. Run the header reader. As soon as the tape stops, eject it ( Do NOT rewind).
The header reader displays the exact length of the file. Create a dummy Basic program of the exact same length ( REM statements full of random characters). Save this, unprotected, on tape 3 ( any filename you like). Rewind THIS tape.
Reset 464.
Type LOAD"
As soon as the header is read ( tone from speaker drops in pitch), whack the pause button ( it's quicker and needs less force than Stop button), then stop and eject tape. Now insert tape 1 and hit play.
Et Voila....
( You might have to experiment with the timing on hitting pause).
This method has 2 advantages:
a: without any modification, it works on any CPC with a tape drive.
b: it can be used on protected binaries, if the save is done on an area memory with the correct start address and length ( instead of saving a dummy Basic program).
Alan.
Battle tested method from article from Polish magazine "Bajtek" issue from 1986 / 09 https://archive.org/details/bajtek198609/page/n13/mode/2up
which did allow loading Basic protected files.
The descriptions doesn't go into details how it exactly works but clearly it's some kind of Basic(?) routine patch. The article mentions
CTRL-SHIFT-ESC reset or using DISC or TAPE will deactivate the patch, but it can be reapplied with CALL &BC08.
Type in Basic code
10 DATA 2177BC11DAB006031A4E777912231310F7C9C3ddb0E5D5C5CDC8B0C1D1E1CD77BCE5D5C5F5CDC8B0E37CD200167E3F1C1D1E1C9
20 s=0:READ a$
30 FOR k=0 TO 51
40 byte=VAL("&"+MID$(a$,k$2+1,2))
50 POKE &B0C8+k,byte:s=s+byte
60 NEXT k
70 IF s<>7900 THEN PRINT "popraw DATA !!!":END
80 CALL &BC08
Rough disassembly of the code in data (obviously not an easily available luxury back in the day)
ld hl,0xbc77
ld de,0xb0da
ld b,0x03
ld a,(de)
ld c,(hl)
ld (hl),a
ld a,c
ld (de),a
inc hl
inc de
djnz 0x0008
ret
jp 0xb0dd
push hl
push de
push bc
call 0xb0c8
pop bc
pop de
pop hl
call 0xbc77
push hl
push de
push bc
push af
call 0xb0c8
ex (sp),hl
ld a,h
jp nc,0x1600
ld a,(hl)
ccf
inc e
dec e
ld e,0x1c
sub b
The ending is kinda weird, maybe at some point it's not code, but data.
It doesn't help that there are typos/OCR errors in your listing as posted. That much was obvious to me since the machine code ends in C9 but your disassembly doesn't end in a RET. Here's a corrected listing:
10 DATA 2177BC11DAB006031A4E777912231310F7C9C3ddb0E5D5C5CDC8B0C1D1E1CD77BCE5D5C5F5CDC8B0E37C3D200167E3F1C1D1E1C9
20 s=0:READ a$
30 FOR k=0 TO 51
40 byte=VAL("&"+MID$(a$,k*2+1,2))
50 POKE &B0C8+k,byte:s=s+byte
60 NEXT k
70 IF s<>7900 THEN PRINT "popraw DATA !!!":END
80 CALL &B0C8
Which disassembles to:
b0c8: 21 77 bc ld hl,0xbc77
b0cb: 11 da b0 ld de,0xb0da
b0ce: 06 03 ld b,0x03
b0d0: 1a ld a,(de)
b0d1: 4e ld c,(hl)
b0d2: 77 ld (hl),a
b0d3: 79 ld a,c
b0d4: 12 ld (de),a
b0d5: 23 inc hl
b0d6: 13 inc de
b0d7: 10 f7 djnz 0xb0d0
b0d9: c9 ret
b0da: c3 dd b0 jp 0xb0dd
b0dd: e5 push hl
b0de: d5 push de
b0df: c5 push bc
b0e0: cd c8 b0 call 0xb0c8
b0e3: c1 pop bc
b0e4: d1 pop de
b0e5: e1 pop hl
b0e6: cd 77 bc call 0xbc77
b0e9: e5 push hl
b0ea: d5 push de
b0eb: c5 push bc
b0ec: f5 push af
b0ed: cd c8 b0 call 0xb0c8
b0f0: e3 ex (sp),hl
b0f1: 7c ld a,h
b0f2: 3d dec a
b0f3: 20 01 jr nz,0xb0f6
b0f5: 67 ld h,a
b0f6: e3 ex (sp),hl
b0f7: f1 pop af
b0f8: c1 pop bc
b0f9: d1 pop de
b0fa: e1 pop hl
b0fb: c9 ret
Mostly it's a somewhat goofy way to hook CAS_IN_OPEN so that it can execute it's own code immediately after any call to it; that code then modifies the file type returned from the firmware function if it is 1 (Protected Basic) to 0 (ordinary basic).
There is also an alternative using DISCOLOGY, the file copier part.
You can disable "loading protection" and set it to LEAVE.
This will remove protection from Basic listings.
One could simply run the protected BASIC program in an emulator e.g. CPCE and make a memory dump. Then extract the token-ized (no longer encrypted) BASIC program from 0x170 onwards e.g. by your own de-tokenizer. That's how I did it when re-discovering the CPC and trying to understand its memory structure for BASIC programs (entering a listing, saving it via ,P and then de-protecting it; sounds kind of unnecessary work, but teaches a lot :) )