treesh@bach.helios.nd.edu (09/19/90)
The Super Snap Shot Cartridge can do something that next to incredible! It can hide itself so well, then I can not for the life of me write any software code at all that tell if someone has the cartridge in the port or not. This concerns me, and several people in my area use this device to pirate software. I will openly admit Im a hacker myself when in comes to copy protection, but I do it for my own use, and my own thrill of cracking. Half the time cracking the protection is more fun then the game itslef! Well, since Super Snap Shot came along, anyone can be a hacker. You pop that cartridge into your computer, pull up the menu, and select DISABLE, and by gosh-n-by-golly, that sucker is GONE!! That is untill you press the button on it, and WAHAM! your software is now fully frozen, and can be viewd by the monitor programs, or worse yet...SAVED onto disk!! What kind of hacking is that??? I have worked hours and hours trying to figure out a way to tell via software if that cart is in there or not. You can easly tell if its in there if the user forgets to disable it. You can tell with one-hundred peeks to upper I/O addresing space. This number will not stay constant if the port is empty. It will lockonto one value and stay that way if you put in any other cartridge. My question is this: Can anyone tell me how via software to activate a deactivated cartridge in the port? Is there ANYWAY AT ALL to write to the PLA??? Switch the ROML or ROMH hardware lines? Switch the GAME or EXROM lines via software??? It seems what they have done is completely pulled the ROM off the buss, and durring a power-up, or RESET signal it pops back into the memory map. But those things are hardware generated. PLEASE SOMEOME!! ANYONE!! Tell me the secret!! ctfm
kudla@pawl.rpi.edu (Robert J. Kudla) (09/23/90)
>>>>> On 18 Sep 90 18:09:37 GMT, treesh@bach.helios.nd.edu said:
t> Can anyone tell me how via software to activate a deactivated
t> cartridge in the port? Is there ANYWAY AT ALL to write to the
t> PLA??? Switch the ROML or ROMH hardware lines? Switch the GAME or
t> EXROM lines via software???
As far as I can tell, it was *meant* to be hard to detect. (I haven't
played with a SS5.0, but I want to.... I want to be able to fastload
Ghosts'n'Goblins, dammit, and Final Cartridge won't touch it!)
Basically, when you push the "activate" button, my guess is it *then*
takes over the bus. There's no reason for any of it to be detectable
at any other time, since the user activates the cartridge with
external hardware, not software.
As a result, so far as I know, there's also no way to activate a
disabled cartridge without using the hardware. Such is life.... if
you're writing code to take advantage of the cartridge, presumably the
user would leave it enabled. I've had programs that wouldn't work
when my FC was plugged in and "totally invisible", as in even its
freeze button wouldn't work, though, so maybe it's trashing a few
bytes of the cartridge area or something....kudla@pawl.rpi.edu (Robert J. Kudla) (09/23/90)
>>>>> On 18 Sep 90 18:09:37 GMT, treesh@bach.helios.nd.edu said:
t> Can anyone tell me how via software to activate a deactivated
t> cartridge in the port? Is there ANYWAY AT ALL to write to the
t> PLA??? Switch the ROML or ROMH hardware lines? Switch the GAME or
t> EXROM lines via software???
As far as I can tell, it was *meant* to be hard to detect. (I haven't
played with a SS5.0, but I want to.... I want to be able to fastload
Ghosts'n'Goblins, dammit, and Final Cartridge won't touch it!)
Basically, when you push the "activate" button, my guess is it *then*
takes over the bus. There's no reason for any of it to be detectable
at any other time, since the user activates the cartridge with
external hardware, not software.
As a result, so far as I know, there's also no way to activate a
disabled cartridge without using the hardware. Such is life.... if
you're writing code to take advantage of the cartridge, presumably the
user would leave it enabled. I've had programs that wouldn't work
when my FC was plugged in and "totally invisible", as in even its
freeze button wouldn't work, though, so maybe it's trashing a few
bytes of the cartridge area or something....
Oh yeah, could you possibly use word wrap or hit return after each
line? I like some of what you have to say, but it's a bitch to read
with all the backslashes (I use Emacs) and whatnot.treesh@bach.helios.nd.edu (09/24/90)
Sorry about the word wrapping problem, Im used to auto wordwarping and this ascii terminal Im using does not support it very well. Anyways, you say that some of your software does not work with the cart plugged in, even if its in disabled mode right? Thats just want Im looking for. I am not trying to get my software to make use of the routines inside the cart, Im just trying to let my software know if the user has that cart plugged in, so that if it does see it, it will erase itself!! The snapshot cartridge is the most amazing tool I have ever used, but my problem with it is that its makes ANYONE a hacker. Im trying to write code that can not be vied in the montior, saved to the disk. I guess you would say Im sorta an anti-hacker! Im more into the protection then the breaking of the protection! ctfm
leblanc@eecg.toronto.edu (Marcel LeBlanc) (09/25/90)
treesh@bach.helios.nd.edu writes: > The Super Snap Shot Cartridge can do something that next to incredible! It > can hide itself so well, then I can not for the life of me write any > software code at all that tell if someone has the cartridge in the port or > not. > ... > Well, since Super Snap Shot came along, anyone can be a hacker. You pop > that cartridge into your computer, pull up the menu, and select DISABLE, and > by gosh-n-by-golly, that sucker is GONE!! Thanks for the compliments! :-) But seriously, that's the way it was meant to work. When I designed the SS hardware, I went to great pains to make sure that the hardware would not be detectable when SS is disabled. We wanted to be able to (truthfully) make the claim that the cart. is invisible when disabled! Other snapshot type carts are STILL visible to clever software even when the software disables itself (including Final Cart., Action Replay, etc...). I haven't found ANY programs that won't work when SS V5.22 is disabled. In fact, if anybody can write a program to detect SS V5 (when disabled), I'd love to hear about it, because I consider this to be impossible. > That is untill you press the button on it, and WAHAM! your software is now > fully frozen, and can be viewd by the monitor programs, or worse yet...SAVED > onto disk!! What kind of hacking is that??? Progress. :-) > Can anyone tell me how via software to activate a deactivated cartridge in > the port? Is there ANYWAY AT ALL to write to the PLA??? Switch the ROML or > ROMH hardware lines? Switch the GAME or EXROM lines via software??? > > It seems what they have done is completely pulled the ROM off the buss, and > durring a power-up, or RESET signal it pops back into the memory map. But > those things are hardware generated. PLEASE SOMEOME!! ANYONE!! Tell me > the secret!! > > ctfm Marcel A. LeBlanc -- Electrical Eng. Computer Group, Univ. of Toronto ----------------------------------------------------------------------- leblanc@eecg.toronto.edu else: uunet!utcsri!eecg!leblanc
leblanc@eecg.toronto.edu (Marcel LeBlanc) (09/25/90)
kudla@pawl.rpi.edu (Robert J. Kudla) writes: ... >As a result, so far as I know, there's also no way to activate a >disabled cartridge without using the hardware. Such is life.... if >you're writing code to take advantage of the cartridge, presumably the >user would leave it enabled. I've had programs that wouldn't work >when my FC was plugged in and "totally invisible", as in even its >freeze button wouldn't work, though, so maybe it's trashing a few >bytes of the cartridge area or something.... As you've noticed, FC is never totally invisible. Even when the software disables itself, the ROM is still visible at $DE00-DFFF. Most of the time, this really doesn't make a difference, so your software won't be upset. But then, there's the occasional program that attempts to protect itself against FC and other carts by writing to $DExx or $DFxx. FC must be removed with these programs. Marcel A. LeBlanc -- Electrical Eng. Computer Group, Univ. of Toronto ----------------------------------------------------------------------- leblanc@eecg.toronto.edu else: uunet!utcsri!eecg!leblanc
yorkw@stable.ecn.purdue.edu (Willis F York) (09/25/90)
{}
Well Im Convinced to Buy one of these SS cartridges, How much are they?
(For my little brother ya know.......)
Actually I'd like to see a Comparison of ALL the Hacker Cartridges
out there.
I just hate it when i game disk goes bad!. oops $30+ down the drain
(not to mention the drive allways getting out of allingment!)
,
--
yorkw@stable.ecn.purdue.edu Willis F York
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This Space For Rent....roger@stretch.cs.mun.ca (Roger White) (09/26/90)
In article <443@news.nd.edu> treesh@bach.helios.nd.edu writes: >Anyways, you say that some of your software does not work with the cart plugged >in, even if its in disabled mode right? Thats just want Im looking for. >I am not trying to get my software to make use of the routines inside the >cart, Im just trying to let my software know if the user has that cart >plugged in, so that if it does see it, it will erase itself!! I have used Super Snapshot V3 for the past few years, and have tried all available ways to find it in memory when it is disabled... you can't! I don't know about the other carts but SS is invisible when totally disabled (no "special" features activated). > >The snapshot cartridge is the most amazing tool I have ever used, but my >problem with it is that its makes ANYONE a hacker. Im trying to write code >that can not be vied in the montior, saved to the disk. > >I guess you would say Im sorta an anti-hacker! Im more into the protection >then the breaking of the protection! > >ctfm > The only way I found to defeat the cartridge is to write some code to the drive's memory early in the program (ideally in a "boot" program) and then read this information once in a while within the main program. The Snapshot cart only saves computer memory and not the drive's memory, so when the program is "snapped" all that is saved is your program in computer memory. When the "snap" is run later the drive's memory will not be correct, your program can then do what it wishes to the disk/computer. That is one advantage to having a "smart" disk drive. I feel that this is the best method to overcoming any memory dumping technique. That is why you can't (normally) snapshot GEOS, it uses a special fast loader installed in the drive that isn't copied over to a snapshot. Thus locking up the computer when the snap is run. Of course that (and any) technique will only stop the inexperienced, anybody skilled in programming/de-protecting will be able to defeat ANY protection scheme in time. Roger. ------------------------------------------------------------------------------ | | Roger White | | ...treat her like a lady, | roger@stretch.mun.edu, roger@stretch.cs.mun.ca| | and she will always bring |-----------------------------------------------| | you home -- Bones | Memorial University of Newfoundland | | | St. John's, Newfoundland, Canada | ------------------------------------------------------------------------------
treesh@darwin.helios.nd.edu (09/26/90)
Yes, the Final Cart can be detected via software even in invisable mode. Its really not that hard to do, as a matter of fact it can be done in basic if you want to. What I do is set up a loop to read one byte of the i/o addresing up there in the high areas of the memory map. Then I check the value that was 'peeked' from that address over 200 times, if it does not change, then you can be sure someone has a cart in the cart port. However, the SuperSnapShot in invisable mode does not fall victim to this protection scheem at all! The only hope I have had is this: I have been able to write code that 'confuses' the snapshot cart even in invisable mode. What happens is that when you press the buttom, instead of freezing the software, its crashes the computer. This is kinda nice for a cheep protections aginst SuperSnapShot, but doing a full computer reset recovers from the crash, with SuperSnapShot enabled, AND your ram is still intact, so it really did not acomplish much at all. I have heard rumors of really killer copy protection routines thaat use the video chip as a sync rigistar. If a program is Snapshotted and then loaded, the video chip's timming will be off from the programs internal time keeping routines, and thus the copy is detected. I have never seen code that could really pull this off, but I have heard about it being done. Any comments welcome! ctfm
arpepper@watmath.waterloo.edu (Adrian Pepper) (09/26/90)
In article <449@news.nd.edu> treesh@darwin.helios.nd.edu writes: > >I have heard rumors of really killer copy protection routines thaat use >the video chip as a sync rigistar. If a program is Snapshotted and then >loaded, the video chip's timming will be off from the programs internal >time keeping routines, and thus the copy is detected. I have never seen >code that could really pull this off, but I have heard about it being done. I must say that simple minds such as mine do wonder about how snapshot cartridges manage to restore the values of write-only registers. I suppose some of the signals must be readable indirectly somewhere, somehow. I have heard that some programs when snapshooten take a while to regain their proper sound. Of course, if true write-only registers are used for timing, or such, it won't be necessary to detect the copying; the program could merely be allowed to continue to function badly as the write-only values are assumed and not refreshed. The problem with this could be that part of the potential consumer market may end up evaluating the product based on the "snapshotted" version, rather than a legitimate version. In short, it's probably better to arrange to detect a certain means of copying if you aim to detect it, so that you can make sure the copy fails in a convincing fashion. I'm not sure if this is a commonly practised principle of copy-detection, or not. >Any comments welcome! So I did. Adrian.
leblanc@eecg.toronto.edu (Marcel LeBlanc) (09/26/90)
treesh@darwin.helios.nd.edu writes: ... >I have been able to write code that 'confuses' the snapshot cart even in >invisable mode. What happens is that when you press the buttom, instead of >freezing the software, its crashes the computer. This is kinda nice for a >cheep protections aginst SuperSnapShot, but doing a full computer reset >recovers from the crash, with SuperSnapShot enabled, AND your ram is still >intact, so it really did not acomplish much at all. Check the version number of your Super Snapshot cartridge (type ">TV" in BASIC). The version you have (from 5.0 to 5.20) has a silly little bug that would cause SS to lock up when interrupting a few programs. This was corrected as of V5.21 (V3 and V4 were fine!). Subsequent versions (V5.22 is the latest) should be able to interrupt ANY programs (there are still a few times that it won't be able to resume from the interrupt, but if you are careful, you won't have any problems). Marcel A. LeBlanc -- Electrical Eng. Computer Group, Univ. of Toronto ----------------------------------------------------------------------- leblanc@eecg.toronto.edu else: uunet!utcsri!eecg!leblanc
yorkw@stable.ecn.purdue.edu (Willis F York) (09/26/90)
> >I have heard rumors of really killer copy protection routines thaat use >the video chip as a sync rigistar. If a program is Snapshotted and then >loaded, the video chip's timming will be off from the programs internal >time keeping routines, and thus the copy is detected. I have never seen >code that could really pull this off, but I have heard about it being done. Well All this Babbling about making a Program Pirate Proof, Here's What ya Do. Have the Program read Data files offa the Disk as it needs them, (at each level ect..) and have it Chewck COPY protection (Disk based) (Or my favorite manual) each time, thus ya snap Shot the prog Fine, Wait till it needs the next level,Sound,screen,ect... there ya Happy, now ya can Defeat ONE use of the SS cartridge. This is the reason i havent Bought a SS cart "Thingie" for my amiga, The games often Check Prot Several times/or use files. (If they just checked ONCE the Device Sould Work Fine..) Well Just My babbling to Counter your Babbling... . -- yorkw@stable.ecn.purdue.edu Willis F York ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This Space For Rent....
borgen@stud.cs.uit.no (Boerge Noest) (09/26/90)
In article <449@news.nd.edu> treesh@darwin.helios.nd.edu writes: >I have heard rumors of really killer copy protection routines thaat use >the video chip as a sync rigistar. If a program is Snapshotted and then >loaded, the video chip's timming will be off from the programs internal >time keeping routines, and thus the copy is detected. I have never seen >code that could really pull this off, but I have heard about it being done. > >Any comments welcome! > >ctfm > Hmm.. How about this: These cartridges must have SOME problems with timing when they restart, so how about having an interrupt that fixes the NMI vector(previously pointing to a memory-clearing routine) and gets interrupted by the NMI before it has time to return(tight timing), then the NMI routine does something (useful?) and the NMI vectors are set back to the memory-clearing routine. OR: Have an NMI routine that doesn't continue triggering - but sets itself up for a new interrupt - (is this called one-shot ?) that fixes/destroys something, which the rasterinterrupt continuosly undoes (with an INC?). It could be possible to get values out of sync(perhaps giving a crash). BTW, I have one of these cartridges myself. It's name is The Expert Cartridge, and it has an off mode, an on mode, and a programming mode; the last one is for loading in it's program onto a RAM-chip inside, which afterwards behaves as ROM. The cartridge is triggered by NMI interrupts through the restore key, but some programs seems to be able to disconnect the restore key. Does anyone know how to do this? (Of course there is a HW add-on to stop these programs as well :-) ) Does anyone have any information on how to program it and use your own programs? -- _____________________________________________________________________________ |/// borgen@stud.cs.uit.no (Borge Nost) \\\| |// ...and then there was AMIGA... \\| |/ studying at the worlds northernmost university \|
root@zswamp.fidonet.org (Geoffrey Welsh) (09/28/90)
> From: treesh@darwin.helios.nd.edu > Message-ID: <449@news.nd.edu> > > I have heard rumors of really killer copy protection routines thaat use > the video chip as a sync rigistar. If a program is Snapshotted and then > loaded, the video chip's timming will be off from the programs internal > time keeping routines, and thus the copy is detected. I have never seen > code that could really pull this off, but I have heard about it being done. Snapshot is wonderful for taking pictures of running code. If, on the other hand, the code first sets up something critical to the operation of the rest of the program and then erases itself, the snapshot will not result in a working, free-standing copy. This doesn't mean you *can't* break it, only that it doesn't become trivial. -- UUCP: watmath!xenitec!zswamp!geoff | 602-66 Mooregate Crescent Internet: geoff@zswamp.fidonet.org | Kitchener, Ontario FidoNet: SYSOP, 1:221/171 | N2M 5E6 CANADA Data: (519) 742-8939 | (519) 741-9553 "Experience talks... and talks... and talks..."
d89-zke@dront.nada.kth.se (Zoltan Kelemen) (09/28/90)
As already mentioned, the easiest way to protect against snapshot cartridges is to use write-only registers. That is a common method used in many games, for example The Last Ninja. The programmer of that game, John Twiddy, is also the author of the Expert cartridge. I take two concrete examples: the real time clock and the timers of the 6526 chip. You may program the alarm (which is a write-only register) to a value only known by your program. When a snapshot cartridge freezes your game, it cannot read the setting of the alarm. The only thing your program has to do to check, is to set the real-time-clock to this value, and see if it triggers an alarm. There is another way (among many) involving two timers of the 6526. You start both timers, but the trick is to start the second timer a bit later than the first. The time-distance between the timers is only known by your program. A snapshot-cartridge will probably not take that in account. Now your program may periodically check that this time-distance is kept. Unfortunately, these methods are not future-proof, because if the author of a snapshot cartridge knows about them, he can update his software to handle them. He can for example read the alarm by setting the clock to all possible values, and see which one triggers the alarm. Perhaps this is already done in the cartridges, it was a couple of years ago I was in the protection business. /Zoltan (d89-zke@nada.kth.se)
kudla@pawl.rpi.edu (Robert J. Kudla) (09/29/90)
>>>>> On 24 Sep 90 15:11:46 GMT, treesh@bach.helios.nd.edu said:
t> Anyways, you say that some of your software does not work with the
t> cart plugged in, even if its in disabled mode right? Thats just
t> want Im looking for. I am not trying to get my software to make
t> use of the routines inside the cart, Im just trying to let my
t> software know if the user has that cart plugged in, so that if it
t> does see it, it will erase itself!!
Aha, but I'm using an old version of the Final Cartridge, not Super
Snapshot. There's a *big* difference.... the FC had little ROM and no
RAM, so it had to use the computer's resources and was *never* fully
transparent. It also did trash the cartridge ROM bytes, I believe.
t> problem with it is that its makes ANYONE a hacker. Im trying to write code
t> that can not be vied in the montior, saved to the disk.
That's nice, so I just disassemble the damn thing and reconstruct the
object module as it would exist in the machine while it's running.
Then again, I suppose that's a little more complicated than pushing
the button.
t> I guess you would say Im sorta an anti-hacker! Im more into the protection
t> then the breaking of the protection!
Yeah, but you're fighting a losing battle. If a program can be
executed, it can be copied - it might take an inordinate effort, but
then, that's what makes hacking fun, no?treesh@bach.helios.nd.edu (09/30/90)
Please mail me at address: Treesh@darwin.cc.nd.edu with more detials on this dual-6526 timmer routine. Im a bit foggy at to what your trying to accomplish by setting the timmers a bit off and then having the program check for the proper time delay. Will the SuperSnapShot acutally have an effect of this delay? What happens when you freeze it? Those 6526 chips continue to count rigth? So, how does the detection come into play? ctfm
treesh@bach.helios.nd.edu (09/30/90)
like what for example?? maybe setting up an irq then erasing the setup?? ctfm