| |
Knight Rider
Registered: Mar 2005
Posts: 116 |
If it were 1987 again....
I was watching Robin's video https://youtu.be/yVtKKb3wkYc regarding cracking from an original cassette. And it stirred a little interest in me again. To be honest I can't even remember how now but I cracked Wizball from original cassette using a Trilogic Expert (2nd version with botched ESM daughter board) and very likely V2.9 of the monitor software.
I did this again now on real hardware (as I wasn't having much luck with WinVICE 3.7), just for laughs and to try to stir up memories of way back then. Defeating Freeload now was much easier for me than back then.
I used the following packers:
MCC Compressor
then
Card Cruncher V4 (no idea who lent me this cartridge, but probably Tork&Torky)
(usual one was Matcham Time Cruncher V3.1 or a hacked version which ended up becoming Time Cruncher V3.1)
I ended up with 182 blocks incl. intro in Wizball
So it leads me to the next question, back in the day (for me) the best cracks had the smallest disk block size.
What packers did you use then on a real C64 in 1987, and what would you use now on real hardware (a. released upto 1987 and then anytime). What block size can you achieve ?
Exomizer V3.02 gives 144 blocks when no additional parameters are given.
TRIAD Wizball + is 166 with intro
Krejzi Packer $005E-$FFFF + Matcham Time Cruncher V3.1 gives 161 blocks
MCC Compressor + Matcham Time Cruncher V3.1 gives 165 blocks
Beast-Link/64k + Byte Boiler 256k V1.0 gives 148 blocks
Byte-Buster V4.1 + Byte Boiler 256k V1.0 gives 148 blocks |
|
... 84 posts hidden. Click here to view all posts....
|
| |
ws
Registered: Apr 2012
Posts: 235 |
on isepics and some other freezes i noticed that ram was actually entirely filled with "garbage" (noticeable through repeating patterns and garbage in areas that were actually unused by the code).. my guess was, this was done to hamper any repack effort.
are there famous tools that attempt to create "uncrunchable" data?
would it be possible to fill ram with a pattern that would serve as some kind of "freeze+crunch" protection, even for exomizer?
(i always tried and cleaned those files manually for repack) |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1382 |
Well, truly random data is uncompressible by definition. The fun part would be getting the game to care if the random data has been tampered with (eg zeroed out, or replaced with some pseudorandom data that looks like noise but is easy to regenerate with a small code fragment) |
| |
Boogaloo
Registered: Aug 2019
Posts: 21 |
Quote: on isepics and some other freezes i noticed that ram was actually entirely filled with "garbage" (noticeable through repeating patterns and garbage in areas that were actually unused by the code).. my guess was, this was done to hamper any repack effort.
are there famous tools that attempt to create "uncrunchable" data?
would it be possible to fill ram with a pattern that would serve as some kind of "freeze+crunch" protection, even for exomizer?
(i always tried and cleaned those files manually for repack)
Wasn't that pattern used to detect the parts or RAM that were untouched? |
| |
Bansai
Registered: Feb 2023
Posts: 36 |
Quoting wson isepics and some other freezes i noticed that ram was actually entirely filled with "garbage" (noticeable through repeating patterns and garbage in areas that were actually unused by the code).. my guess was, this was done to hamper any repack effort.
are there famous tools that attempt to create "uncrunchable" data?
would it be possible to fill ram with a pattern that would serve as some kind of "freeze+crunch" protection, even for exomizer?
(i always tried and cleaned those files manually for repack) I might be misremembering, but I thought some of the early freezers had a mem prep phase prior to loading of the protected software where they wrote some kind of well-defined pattern (to the freezer, that is) to tag uninitialized mem so they could spot the patterns at freeze time to identify usable working areas for the unfreeze code to work out of and use. |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Quote: Quoting wson isepics and some other freezes i noticed that ram was actually entirely filled with "garbage" (noticeable through repeating patterns and garbage in areas that were actually unused by the code).. my guess was, this was done to hamper any repack effort.
are there famous tools that attempt to create "uncrunchable" data?
would it be possible to fill ram with a pattern that would serve as some kind of "freeze+crunch" protection, even for exomizer?
(i always tried and cleaned those files manually for repack) I might be misremembering, but I thought some of the early freezers had a mem prep phase prior to loading of the protected software where they wrote some kind of well-defined pattern (to the freezer, that is) to tag uninitialized mem so they could spot the patterns at freeze time to identify usable working areas for the unfreeze code to work out of and use.
Some used to, but games started to test for this and fail. So eventually some used other methods, like tracking where RAM was written by using external RAM. :) |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Quote: Tell more.... which cruncher
Using this one with -c64b option: https://github.com/martinpiper/C64Public/blob/master/bin/LZMPi... |
| |
chatGPZ
Registered: Dec 2001
Posts: 11154 |
Quote:So eventually some used other methods, like tracking where RAM was written by using external RAM. :)
There is no freezer that does this (it can't be done in the first place, not with classic cartridges anyway). There are easier and much more effective ways to protect against freezing too :) |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Quote: Quote:So eventually some used other methods, like tracking where RAM was written by using external RAM. :)
There is no freezer that does this (it can't be done in the first place, not with classic cartridges anyway). There are easier and much more effective ways to protect against freezing too :)
No hardware *that you know of* you mean...
Professional hardware debuggers could, back in the day.
Then even a few years ago there were things like this: https://www.lemon64.com/forum/viewtopic.php?t=75387
"64K ram spy mode:
all bus writes are stored on ram, so you can save memory to flash or to the upper 64K of the 128K ram"
etc. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11154 |
Quote:No hardware *that you know of* you mean...
Professional hardware debuggers could, back in the day.
Oh boy >_< |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Yes, there were all sorts of debug systems back then. An in-circuit emulator (ICE) was really quite rare and expensive, but it would be able to tell you what the CPU was doing, or stop of a hardware breakpoint at a specific address. Even more fancy would be the ability to constantly record the RAM data bus and see what the memory was doing, which given enough debug RAM would be capable of recording the usage of the entire address range. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 - Next |
