Last Ninja Acorn Archimedes version?

[alexh]

Any chance of making Laffer some ADF files of his disks or are they copyprotected?

[Charlie]

I've found my copy of Deepcopy II - ahem.
It managed Axis, so should manage LN ok.

Laffer: If you're interested I'll pm you some instructions.

[alexh]

Laffer doesnt have the disks (or an Acorn) they are with Interceptor (or they were).

[Interceptor]

i've made ADFs and sent them to laffer, however they dont work as the disks are copy protected.

i'll be sending the disks back to laffer next week, along with loads of other disks i have to send back!

[IFW]

We'll see about that...
[genuine read errors that is]

[Interceptor]

its track 79 head 1 sectors 0 thru 4

its the same on both disks.

the reason the ADF he already has is a 1600k adf is because whoever cracked it couldnt fit it back on the disk.

also, i'm pretty certain that the graphics glitch is an emulation problem, the sprite is fine until you change screen.

[laffer]

The thing is, that glitch doesn't happen in the demo.

[Interceptor]

yes, i remember you saying that now.

perhaps a bad crack then :\

[laffer]

Yes probably.. Charlie tested it on real hardware too -

-Try in A3020 -> It works, kind-of...
...runs too fast & right edge of sprites are occ missing...

So it seems it definitely is a bad crack.

[tomcat666]

So any Acorn crackers around here or should we send the uncracked ADF's to someone on some Archie board ?

[Charlie]

I'd gladly have a go if laffer wants to trust me with his precious discs.

I'm a long way from being an Acorn cracker but have had some success with both Axis & FTT. (Arc games with copy-protection)

Axis is in the Zone on .adf
FTT, I have successfully copied but am still working on a functioning .adf

I'd be very happy to be proved wrong but given the lack of any 'RiscOS scene' at the platform's height finding a hacker may be quite hard.
(woki may qualify)

Back to the subject of getting good LN .adf's I can 'talk' laffer through a few techniques that may work...

No Acorn hardware to read the discs? No problem.
or
Same offer to Interceptor if he still has them.

[Interceptor]

i'm listening....

[alexh]

If the disks were standard Acorn format except for one track, the ADF files that Interceptor made for Laffer which didn't work should be enough to crack from?

[Charlie]

@ alexh:
Good question - it would be down to the form of copy-protection used - I'd give it a go.
TBH the clever stuff is beyond me, what I've been doing is only slight sneakiness:
Get an accurate-enough image of the floppy via the RiscOS APIs & the copy-protection doesn't notice.

This simple approach is aided by some aspects of the platform:
-The floppy controller isn't anywhere near as programmable as the Amiga's
-The OS makes low-level access to media quite easy & treats all blocks of data the same regardless of their source. (shame my RiscOS command-line skills are so rusty)
-I've yet to come across any RiscOS software that uses other than the built-in OS APIs for disc access so copying via the same route should produce something functional.

Laffer, Interceptor: pm me if you're interested - I'll gladly share my meager knowledge.

[alexh]

Eh? I dont understand what you've done at all then?

This will probably be some form of copylock or something like that and will require binary changes and decrunching etc.

[IFW]

jfyi: I've seen decent enough protection on some Acorn images, that are very unlikely to use the OS for checking...

[Charlie]

I've only just started 'playing this game' so I wouldn't be surprised if some RiscOS software came with 'proper' copy-protection rather than the 'basic' techniques I've seen so far...

I guess I`m being my usual opaque self.
I'm doing nothing clever at all! Just utilising a potential frailty of many copy-protection systems on RiscOS.
On the Amiga the most trivial protection would be beyond me because the "floppy controller" is so flexible & so may custom approaches were used to write game data - quite beyond me.
Not so the Arc.
Generally its the standard ADFS with a few "dodgy" sectors containing non-ADFS data that the software can use to ID an original rather than a copy. These sectors are still being accessed by the low-level API of ADFS not by any custom code.

So?
Use ADFS to copy the disc and it fails to copy the 'dodgy' sectors because they are 'invisible' to the high-level API as it doesn't recognise them as valid data. Their absence then kicks-off the copy-protection.

Un-copyable? No.
These sectors are still being accessed by the low-level API of ADFS which is fully available to the user via the command-line. The low-level API doesn't care about the 'sense' of the data, so copies everything! You get a perfect / functioning copy - the tricky bit is knowing how to use said command-line.

Only good for direct copies, then? No (hopefully)
At a low level ADFS makes no distinction between the types of media it's accessing. Floppy, HDD, image-file, it's all the same commands. So in theory at least no protection scheme using the low-level API can tell the difference between a real floppy and an image.

I'm not hacking the games at all - just making very good copies from the POV of the RiscOS file-system.

This worked like a charm for AXIS. Floppy -> .adf & the copy-protection hasn't noticed.
With FTT I've used this 'technique' to make a physical copy (floppy -> floppy) that doesn't set off that game's protection. Sadly, so far, I've not made a good .adf. This is testing my very poor knowledge of such things severely but it should be doable:
-The low-level API only sees blocks of data - floppy/adf are the same.
-The floppy controller isn't 'smart' enough to hide data 'between sectors' as you can with the Amiga so a .adf shouldn't be missing anything.
-Emulation of this platform was unheard of when these games were written so I'm hopeful that FTT isn't testing the hardware in other ways that emulation could break. I can check that by writing the .adf back to a floppy.

Potential B.S. warning!
There are people on this thread who know far more about this than I ever will...
If the above is true for LN then it should be possible to make a good .adf from the originals by using the RiscOS API to do the copying.

Why?
-A copy can be highly accurate but if not perfect may fail - the .adfs Interceptor has made..?
-A 'less accurate' copy may work because that copy was made using the same routines the copy-protection uses to work its own magic'. We can see the 'errors' but it can't.
The proof-of-the-pudding will be in the success of any copies.


Rambling again...

[Interceptor]

the questions are, why are those tracks bad, are they simply long or short tracks, are they just bogus tracks designed to fail? are are they something more complex (which most protections are)

if it isnt a proper copy protection as you say, why did someone else have to crack it?

isnt ADF just a sector dump? all you can do with thise is either give the data to the emulator, or corrupt the data so it doesnt make logical sense, if either of these conditions isnt what LN is looking for, i cant see any fudging working here.

that said, i currently have laffers disks here, and the ADFs, and a now correctly working Archimedes A3010 (despite its resistence to my fixing it), so if you have some suggestions by all means make them, either here on send me a message, whichever, and i'll give them a go.

if not, the forthcoming IPF image will eliminate these kinda of problems anyway.

[IFW]

Most copy protected disks are written using professional duplication devices.
Those can write anything to a disk and are not limited in any way by the capabilities of the intended host platform.

[alexh]

Interceptor analysed the dump and said it wasn't written with a Trace Machine.