Spoofing can be prevented with digital signatures . These enable the server to verify that a result packet indeed comes from a volunteer. They can also be used in the other direction, to assure a volunteer that an applet really comes from the server, and not from a spoofer. Digital signatures are most useful in protecting non-anonymous volunteer systems, such as forced volunteer networks or NOIAs, from external attack. Unfortunately, however, digital signatures are ineffective against internal saboteurs, and thus useless in true volunteer systems where anyone, even saboteurs, are allowed to volunteer. This is because digital signatures can only authenticate the source of a data packet, not its content.
One way to authenticate the content of a data packet is to include a checksum computation in the code. This way, if the node does not run the code, or runs it incorrectly, the checksum will not match, and the server can be alerted. In most cases, checksums will catch both unintentional errors, and simple malicious attacks such as returning random packets. We can also use checksums to authenticate sources (and prevent spoofing) by transmitting a different checksum key with each work packet. This way, an external spoofer would not know the correct key to use, and cannot forge bogus result packets.
Digital signatures and checksums are only useful against malicious attacks if volunteers are forced to compute them and cannot compute them independently of the work. This is true for NOIAs, where the node hardware and firmware can prevent users from disassembling or modifying the bytecodes they receive from the server. In general, however, it is possible for sophisticated malicious volunteers to disassemble the bytecode they receive, identify the signature and checksum generating code, and use these to forge a result packet containing arbitrary data. One way to guarantee that a node cannot fake a checksum computation is to prevent it from disassembling the code. This is not an easy task, but in some cases, it may be possible to apply encrypted computation techniques, such as those that  proposes to use against spying.
If cryptographically preventing disassembly is not possible, we can resort to dynamic obfuscation techniques to make understanding the disassembled code and isolating the checksum code as difficult as possible. Dynamic obfuscation extends the idea of static obfuscation (such as done in Borland's JBuilder ) by continously obfuscating code dynamically in time. For example, we can randomly vary the checksum formula and its location within the bytecode from work packet to work packet. This would prevent hackers from manually disassembling and modifying the bytecode once and for all. We can also insert dummy code at varying locations. These schemes are inspired by polymorphic computer viruses, which use them to hide themselves from anti-virus programs .
Although very difficult, de-obfuscating polymorphic viruses is not impossible because viruses, being self-reproductive (by definition), contain the obfuscating code. Thus, once one version has been cracked and disassembled, it is possible to reverse engineer this code and develop an ``antidote'' which can disassemble other instances of the viruses. Dynamic obfuscation in volunteer computing, however, has the advantage of using the server to do the obfuscation. This should make it possible to constantly and arbitrarily replace the code, and make it impossible for hackers to catch up. Provided that the volunteer computing system allows the work code to change from packet to packet, dynamic obfuscation may be easier to implement and more generally applicable than encrypted computation.