| |
bugjam
Registered: Apr 2003
Posts: 2476 |
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: 2476 |
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: 72 |
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: 72 |
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: 72 |
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: 72 |
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" ;) |
| |
Trash
Registered: Jan 2002
Posts: 122 |
Quote: 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" ;)
I get the idea, but I think it wont be enough to cover all versions timecruncher and other commonly used crunchers with x^55 different versions. I believe that at least footprinting the the primary depacker and possibly the intro should be the way to go. That way (if you just footprint the irq-part of the intro) you also get a nice database of what intro is used for a certain release.
But as I said, it would be hard with emphasis on every single letter in hard... |
| |
j0x
Registered: Mar 2004
Posts: 215 |
I'd recommend having a chat with MdZ. I think his PreserveC64DB V.1.2 might be capable of large scale sys-line harvesting. |
| Previous - 1 | 2 | 3 - Next |
