| |
bugjam
Registered: Apr 2003
Posts: 2589 |
WANTED: SYS-lines from common packers
Hi all,
as the problem pops up time and again that cracks are added here with their attribution to a certain group based on the SYS-line, where it turns out that it is just packed with the group's packer, I'd like to request that we gather as much info on such packers as possible with the respective SYS-lines that they produce; the list could then be even added to the csdb rules, to avoid such confusion in the future (at least to be cautious in such cases and look for further evidence).
I've made that mistake myself several times, and it is very frustrating to create entries only to delete them afterwards, because one didn't know.
What do you guys think?
Best,
Bugjam |
|
... 12 posts hidden. Click here to view all posts....
|
| |
bugjam
Registered: Apr 2003
Posts: 2589 |
That was pretty exactly my intention when opening this thread. :) |
| |
Xiny6581
Registered: Feb 2004
Posts: 73 |
Bugjam / Dymo: This sounds very great indeed :)
I think it would be great to make a spunk compatible database too, so we can link it to that database or at least make an export(let us keep this on ice to begin with).
?How about a nice structure like:
<groupname> <sys-line> <packer> <note>
!Eg.
"The New Light" - "sys2064 TNL" <Time Cruncher V5.0> <Earlier cracks from 1989 also used Visiomizer V6.0 and A few cracks from 1992 used a variation of Cruel Cruncher 2.1. Most of the cracks uses Crosslinker V2.0 or Beast Linker>
I really like as much details as possible.
and As mentioned above in the thread it was very common the groups/crackers renamed the sys-line just to make it a bit more personal or/and even modified the packer/linker for their own usages. Still, it's possible to trace-back most of the altered sys-lines, as I have done this many times to allocate fake or re-cracks. :-P
Best regards,
Xiny6581 |
| |
bugjam
Registered: Apr 2003
Posts: 2589 |
Hi Xiny6581,
hang on, I think you are shooting too far here - although your concept (as I understand it) would be also very useful. I think you want to compile a list of which group used mostly which packers/crunchers and which SYS line?
My idea was to have a list of generic SYS-lines generated by packers, which contain the grup name of the packer-releasing group by default - and therefore create confusion because it is easy to think that whatever was packed with the respective program (and thus has a SYS-line mentioning the group name), was actually released itself by the respective group.
Your suggestion for a standard structure is very good, but I would suggest <SYS-line (including line number)> <packer which creates that SYS-line> <packer-releasing group> <notes>
Thus, when a program has a certain SYS-line, you can easily go through the list and compare if it was a generic SYS-line or not. |
| |
Xiny6581
Registered: Feb 2004
Posts: 73 |
bugjam: Heh, yeah I went ecstatic here. Now I perfectly understand what you mean.
//<SYS-line (including line number)> <packer which creates that SYS-line> <packer-releasing group> <notes>//
That's a even better structure and it is stronger when you wish to find/pars a specific group/packer.
Now, how to make this possible? :)
If we get some examples and being able to work out the fundamental things, so to say. I can see this getting really awesome. |
| |
Trash
Registered: Jan 2002
Posts: 122 |
Quote: bugjam: Heh, yeah I went ecstatic here. Now I perfectly understand what you mean.
//<SYS-line (including line number)> <packer which creates that SYS-line> <packer-releasing group> <notes>//
That's a even better structure and it is stronger when you wish to find/pars a specific group/packer.
Now, how to make this possible? :)
If we get some examples and being able to work out the fundamental things, so to say. I can see this getting really awesome.
I think I'd start with a lib containing a lot of .d64 and / or .tap files and write a parser that could extract filename and sys-line into a simple database and work some magic from that point... |
| |
Xiny6581
Registered: Feb 2004
Posts: 73 |
Quote: I think I'd start with a lib containing a lot of .d64 and / or .tap files and write a parser that could extract filename and sys-line into a simple database and work some magic from that point...
Trash: Yes, that's exactly the magic of SPUNK, however it does more than just checking the sys-lines.
The parser is kind of easy but furthermore sometimes the actual .prg must be unpacked to reveal the real packer too or at least collide with an unpack database.
That is the main hook to deal with :) |
| |
Zyron
Registered: Jan 2002
Posts: 2381 |
I guess Unp64 V2.32 might be of help. |
| |
Trash
Registered: Jan 2002
Posts: 122 |
Quote: Trash: Yes, that's exactly the magic of SPUNK, however it does more than just checking the sys-lines.
The parser is kind of easy but furthermore sometimes the actual .prg must be unpacked to reveal the real packer too or at least collide with an unpack database.
That is the main hook to deal with :)
So, somekind of 6510-emulator that one could listen to in order to determine that a set of code ends with a jmp (to possible the next depacker orelse to the intro) and store a footprint for the code before that jmp...
Sounds hard, especially since games from before 1990 typically was first packed (<- RLE) and then crunched (<- lzX or huffman, cant remember if anyone made a arithmetic encoder) and more often than not the intro also executed some kind of decrunch...
In my mind it sounds doable but very very hard, surely there are smarter people out there than me that could have a solution fitting my thoughts... |
| |
Xiny6581
Registered: Feb 2004
Posts: 73 |
Quote: I guess Unp64 V2.32 might be of help.
Yes, that's the magic-tool. Using it all the time to get to the bottom with some wack-releases. To unpack and see what's going on :) |
| |
Xiny6581
Registered: Feb 2004
Posts: 73 |
Trash:
Both yes and no.
To make an automated process would require a bit of clever programming and well to get the whole parser and unpacker to cooperate. That way I haven't really thought about.
But to make it manually would be something like this:
-Check the sys-line. If sys-line seems "okay" and hasn't been altered. Get sys-line store into Database where table is "group" and "sys-line.
ELSE
-unpack %filname.prg% check packername... etc :P
Yeah this is very bread and butter explanation but the main thing is to map the packer used.
Hope you get my "idea" ;) |
| Previous - 1 | 2 | 3 - Next |
