AW: [bf1942] 1.4 and disablin mods????

[Andrew von Niederhausern]

But i don't see how this would elimate the client-side cheating.. this
would only secure the RFA's from extraction.. if a user wished to make a
client side cheat (textures or what not), he would also be able to make a
secure RFA and use it.. i don't really think the RFA security is the issue
here, its the ability to limit which RFA is being used to match that of the
server. (if i read this wrong please correct me)

granted this would be more of an issue of limiting the piggy back of cheats
with certain RFA's but by no means eliminates the core issue.. 

the other solution would be a better solution (in your previous email)
about trying to get DICE to sortof give them an unofficial expansion pack
status.. but then you run into the issue of everyone who makes a new skin
and wants to use it has to go through DICE to get this kindof approval..
wow talk about a headache waiting to happen.  this might be a viable
solution if you can convince DICE to do it and release periodic updates to
this. I would probably venture to say this would even be a headache for
MC/others.. each time they update their textures they would have to be run
through DICE approved, tested, released. but then ofcourse you run into
versioning problems. which version is the server running, which version do
you have installed.. getting those to sync up outside of the 3-4 month
cycle for patches could be a headache.

Maybe the solution is as simple as asking DICE to impliment an any and all
solution, valid RFA solution. where the server can have many different
RFA's for skins and what not. And the client can use any of these. If the
client has a texture set that the server does not then it reverts to the
standard. This would allow servers to pick RFA's (mods) that they approve
for use on their server. 

Over time i imagine server packs being released with reviewed and approved
texture packs. this would also not put these texture packs in direct
competition with the major mods as the server would not be a strict MC mod.

either way the server side is the solution they are going with, to get
support from DICE/EA for it.. it would have to be an easy solution. I doubt
they would put a lot of effort and money into something just for the few
client side mods. It is a trade off and i image that the DICE/EA team had
extensive arguements about the Pros and Cons of it. In the end their
solution was this and the trade off, in their opinion, was worth it. 



At 12:35 PM 4/21/2003 -0700, you wrote:
>And here is a more in-depth explanation of solution....
>
>"Dice create a RFA compiler / decompiler for public release.
>RFA compiler has an option for user to input a 10 digit code. Based on this
>code, the 10 digit code gets split up into 3-5 pieces based on the 20 digit
>secret code and is placed in hidden various sections of the RFA compile code
>(only Dice knows where the locations are). When RFA compiler generates a 20
>digit secret code at random, not seen to user compiling RFA.  When a server
>is running Desert Combat, it will knows that it should be looking for the 20
>digit secret code and the 10 digit secret code within 3-5 places MUST match
>within the range of the assigned 20 digit code. If it does not, it fails the
>client load to server.
>
>Now, every modder compiling their RFAs can come up with their own 10 digit
>secret code each compile and only they will know it. And are totaly unaware
>of the 20 digit secret code and
>the fact the 10 and 20 digit code are split up in various sections.
>Granted when a modder wishes to decompile the RFA, they must
>input the 10 digit secret code that was originally used.  Every mod is
>secure this way.. and unique.
>
>Now if you want to add more security into this...  you can compile RFAs
>within a range of numbers 0000000001.rfa 0000000002.rfa  etc and they the
>"new patch or release" of RFAs could vary on each one for various 10 digit
>secret codes but the 20 digit secret codes are within tolerance range. Thus
>when the server checks... it sees all the RFAs and check the ranges of them
>all also.
>
>Now if you want to add even more security you could allow the user to input
>the "LOCATION BIT". This will randomize or place the segments of the 10
>digits randomly in the compile. Thus when the compiler uses a LocationBit of
>4, and their 10 digit number, it will get split 4 times and then placed
>randomly. On decompile, it will look at this for greater security on the RFA
>before opening it. Granted the LocationBit could be just the 11th digit on
>the 10 digit number.
>
>Is this even feasible?"
>
>Jon Wolberg
>www.ECGNetwork.Com
>----- Original Message -----
>From: "Scratch Monkey" <ScratchMonkey at SewingWitch.com>
>To: <bf1942 at icculus.org>
>Sent: Monday, April 21, 2003 11:38 AM
>Subject: Re: AW: [bf1942] 1.4 and disablin mods????
>
>
>> --On Monday, April 21, 2003 11:32 AM -0700 Jon <MMmmGood at cox.net> wrote:
>>
>> > He e-mailed DICE with this solution two months ago to no avail.  His
>e-mail
>> > was more extensive than the description above for obvious reasons.  It
>> > included a fix to the problem that would let true modders still be able
>to
>> > make client-side mods but the cheats would stop working.  He was
>ignored.
>>
>> "Obvious reasons"? Do you mean security by obscurity? How would other mod
>> writers learn how to do this? Just what is his solution?
>>
>