Talk:Decompiling Maps: Difference between revisions
Jump to navigation
Jump to search
(Viva vmex!) |
No edit summary |
||
| Line 1: | Line 1: | ||
Better the make it public | Please don't bash Rof, what he has provided has helped thousands of Source mappers. Valve has a good attitude about Vmex and as he stated there are protection methods. --[[User:Mark WiseCarver|wisemx]] 15:38, 4 Feb 2006 (PST) | ||
Better the make it public then have a few people spread it by word of mouth. Maybe it'll get changed faster this way. Public knowledge is the best way to get things changed. Its the same theory that all these books are comming out now a days about hacking and computer security. --[[User:Red comet|Red Comet]] 16:05, 4 Feb 2006 (PST) | |||
*Um, as I say on [http://www.geocities.com/cofrdrbob/faq.html my faq page], using a no_decomp key is the easiest to bypass of the protection methods, which is why I also have texture-based and brush-based checks. Brush-based is best, but any method can be defeated by someone with sufficient determination. Ultimately, they could write their own decompiler which ignores all checks. --[[User:Rof|Rof]] 15:25, 4 Feb 2006 (PST) | *Um, as I say on [http://www.geocities.com/cofrdrbob/faq.html my faq page], using a no_decomp key is the easiest to bypass of the protection methods, which is why I also have texture-based and brush-based checks. Brush-based is best, but any method can be defeated by someone with sufficient determination. Ultimately, they could write their own decompiler which ignores all checks. --[[User:Rof|Rof]] 15:25, 4 Feb 2006 (PST) | ||
** I was unaware of these other methods of security you added, so I edited my comment, and yes, you are right that any system you use could be bypassed, but at its current state, all three of your protections are simple to by pass. Java is the easiest language I have ever seen to be decompiled. --[[User:Red comet|Red Comet]] 16:05, 4 Feb 2006 (PST) | |||
Should this article really be discussing how to bypass the "no_decomp" 1 flag? It's purposely violating the author's intent when you remove that keyvalue. --'''[[User:Campaignjunkie|Campaignjunkie]]''' <sup>([[User talk:Campaignjunkie|talk]])</sup> 13:44, 4 Feb 2006 (PST) | Should this article really be discussing how to bypass the "no_decomp" 1 flag? It's purposely violating the author's intent when you remove that keyvalue. --'''[[User:Campaignjunkie|Campaignjunkie]]''' <sup>([[User talk:Campaignjunkie|talk]])</sup> 13:44, 4 Feb 2006 (PST) | ||
Revision as of 17:05, 4 February 2006
Please don't bash Rof, what he has provided has helped thousands of Source mappers. Valve has a good attitude about Vmex and as he stated there are protection methods. --wisemx 15:38, 4 Feb 2006 (PST)
Better the make it public then have a few people spread it by word of mouth. Maybe it'll get changed faster this way. Public knowledge is the best way to get things changed. Its the same theory that all these books are comming out now a days about hacking and computer security. --Red Comet 16:05, 4 Feb 2006 (PST)
- Um, as I say on my faq page, using a no_decomp key is the easiest to bypass of the protection methods, which is why I also have texture-based and brush-based checks. Brush-based is best, but any method can be defeated by someone with sufficient determination. Ultimately, they could write their own decompiler which ignores all checks. --Rof 15:25, 4 Feb 2006 (PST)
- I was unaware of these other methods of security you added, so I edited my comment, and yes, you are right that any system you use could be bypassed, but at its current state, all three of your protections are simple to by pass. Java is the easiest language I have ever seen to be decompiled. --Red Comet 16:05, 4 Feb 2006 (PST)
Should this article really be discussing how to bypass the "no_decomp" 1 flag? It's purposely violating the author's intent when you remove that keyvalue. --Campaignjunkie (talk) 13:44, 4 Feb 2006 (PST)