ID:133017
 
Two possible routes for this idea, but first, the reason for this idea:
Right now it is possible to extract other people's icons from their game files. This is bad. I realize that both of these suggestions would not be fool proof, but it would still be better than nothing.

Idea 1: Encrypt the .RSC file, only to be decrypted by the appropriate password stored inside the .dmb.

Idea 2: Simply 'lock' the .RSC file in BYOND itself from being accessed by a DMB unless it has the same 'key' generated by dream maker or key the owner typed into dream maker. Doesn't really matter. Obviously this would leave it open to being decompiled just like .dmbs can be, but not everyone can do this.


I preempted this statement with "I know it wont be fool proof", and I'm going to end with the same. Nothing in the computer world is unbeatable, but it would still be nice to give protection that is better than nothing.
Stripping data out of RSCs is only a problem currently because the people who develop tools for this stuff made the mistake of naively handing this tool out. It is not a mistake that will be made again. Had it been a decompiler, we could rename this "DMB Encryption".

Both methods can be broken with relative ease, you'd only be protecting against people who don't actually have the technical capability to read the RSC layout as it currently is.

Re-arrange the contents of the RSC entry header if it's really a concern, that'll break the currently released tool without incurring a pretty pointless performance penalty. An entire feature aimed at one user is flattering, but he can't actually maintain his tool anyway.

Based on previous discussion though, I don't think Tom or Lummox are bothered by this, and I don't blame them.
Actually, you can just pull them straight out of the DMB if you fancied. Given we can watch the release notes for a version change bringing this in, a quick comparison of DMBs between the versions would reveal this plain as day.
In response to Stephen001
Stephen001 wrote:
Stripping data out of RSCs is only a problem currently because the people who develop tools for this stuff made the mistake of naively handing this tool out. It is not a mistake that will be made again. Had it been a decompiler, we could rename this "DMB Encryption".

Uh... Whats stopping me from hosting my own game that has a verb to send me icons out of the .rsc and just doing that? This is what I was referring to, not using standalone programs.
Inuyashaisbest wrote:
It's still possible to decompile Rsc files even without DarkWizards using nothing but BYOND itself, it's jsut more time consuming.

This is what I was referring to, and I can't see this as taking too much time to do....
In response to AJX
Nothing, because that's your developer perogative. The encryption would still be transparent, so I don't see what the difference is from that respect.
In response to Stephen001
Stephen001 wrote:
Nothing, because that's your developer perogative. The encryption would still be transparent, so I don't see what the difference is from that respect.

...?
The point is you put a key in your code that would then be compiled into your .dmb. (Or perhaps a key that is generated when you create the world initially) and if someone tries to access the .rsc with the incorrect key == fail.
In response to AJX
You're covering a corner case for reasons I don't even know why. Maybe I'm missing this plethora of icon trading games that just feed from other people's RSCs.
In response to AJX
AJX wrote:
Uh... Whats stopping me from hosting my own game that has a verb to send me icons out of the .rsc and just doing that? This is what I was referring to, not using standalone programs.

How do you figure that's going to work?
In response to Falacy
...
mob/icon='iconiwantstosteel.dmi'
mob/verb/Geefmitehiconz() usr<<ftp(icon)

would be a starter.
In response to AJX
AJX wrote:
...
mob/icon='iconiwantstosteel.dmi'
mob/verb/Geefmitehiconz() usr<<ftp(icon)

would be a starter.

That only works if you have the host files and somehow know the name of the icon file you want.
In response to Falacy
you dont need the host files all you need to do is log into the game once and you can get the dmi file names with a text editor
In response to Soldierman
Soldierman wrote:
you dont need the host files all you need to do is log into the game once and you can get the dmi file names with a text editor

You still will need the host files which is where the .rsc files are.

And finding out the dmi names is not difficult.
In response to Soldierman
Soldierman wrote:
you dont need the host files all you need to do is log into the game once and you can get the dmi file names with a text editor

Yea, I guess that's true, forgot BYOND caches everything into a generic .rsc. This topic is pretty pointless though, its been brought up countless times before, but the BYOND staff refuses to provide any type of security for its developers.
In response to AJX
AJX wrote:

You still will need the host files which is where the .rsc files are.

Nope, all you have to do is go into the byond cache folder and copy the byond.rsc. Then create a new environment called byond and overwrite the current rsc with the one from the cache. To get the file names just open the rsc file in a text editor and search for .dmi
In response to Soldierman
Soldierman wrote:
AJX wrote:

You still will need the host files which is where the .rsc files are.

Nope, all you have to do is go into the byond cache folder and copy the byond.rsc. Then create a new environment called byond and overwrite the current rsc with the one from the cache. To get the file names just open the rsc file in a text editor and search for .dmi

Well crap. We are less protected than I thought. :p Oh well.
Inuyashaisbest wrote:
Here's the thing, the resource would have to execute code itself to verify the dmb has the key before the resource would be given however if code is added to a resource file to execute the function to find the key its no longer a resource but an executable

Why would the resource have to execute anything at all? All it would have to do is store an encrypted version of the password.
Both you and Falacy misunderstood the idea here, which was to encrypt the RSC file's contents using a certain key (the key is needed in order to unencrypt it later). This key doesn't need to be stored in the RSC file; it's only specified by the developer to Dream Maker, which will use that key to try and decompile the file.
But of course this is all extra work for the BYOND Staff for not enough benefit.