Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
 Welcome to our latest new user Brizio ! (Registered 2017-08-20) You are not logged in 
CSDb User Forums


Forums > Requests > WANTED: SYS-lines from common packers
2017-02-21 19:10
bugjam

Registered: Apr 2003
Posts: 1228
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....
 
2017-02-27 15:56
bugjam

Registered: Apr 2003
Posts: 1228
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.
2017-02-27 18:58
Xiny6581

Registered: Feb 2004
Posts: 48
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.
2017-02-28 13:10
Trash

Registered: Jan 2002
Posts: 87
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...
2017-02-28 13:30
Xiny6581

Registered: Feb 2004
Posts: 48
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 :)
2017-02-28 13:42
Zyron

Registered: Jan 2002
Posts: 2035
I guess Unp64 2.32 might be of help.
2017-02-28 14:06
Trash

Registered: Jan 2002
Posts: 87
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...
2017-02-28 14:24
Xiny6581

Registered: Feb 2004
Posts: 48
Quote: I guess Unp64 2.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 :)
2017-02-28 14:30
Xiny6581

Registered: Feb 2004
Posts: 48
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" ;)
2017-02-28 16:48
Trash

Registered: Jan 2002
Posts: 87
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...
2017-03-01 08:33
j0x

Registered: Mar 2004
Posts: 207
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
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Dr.j/Delysid
Powerslave/Tronix
The Overkiller/Hokut..
Zorch
E$G/I-IokutO ForcE
sailor/Triad
Rebok
Guests online: 55
Top Demos
1 Uncensored  (9.7)
2 Edge of Disgrace  (9.7)
3 Coma Light 13  (9.6)
4 The Shores of Reflec..  (9.6)
5 Lunatico  (9.6)
6 Comaland 100%  (9.5)
7 Incoherent Nightmare  (9.5)
8 Wonderland XII  (9.5)
9 Comaland  (9.5)
10 Wonderland XIII  (9.5)
Top onefile Demos
1 Veterans of Style  (9.5)
2 Dawnfall V1.1  (9.5)
3 Daah, Those Acid Pil..  (9.5)
4 Treu Love [reu]  (9.4)
5 Dawnfall  (9.3)
6 SidRok  (9.3)
7 F1 Evolution  (9.3)
8 One-Der  (9.2)
9 Tunnel Vision  (9.2)
10 Game of Thrones [2sid]  (9.1)
Top Groups
1 Pond  (10)
2 Booze Design  (9.4)
3 Censor Design  (9.4)
4 Oxyron  (9.4)
5 Crest  (9.3)
Top Coders
1 Axis  (9.8)
2 Crossbow  (9.8)
3 Graham  (9.8)
4 HCL  (9.8)
5 Lft  (9.7)

Home - Disclaimer
Copyright © No Name 2001-2017
Page generated in: 1.379 sec.