I have a class that performs some sensitive I/O operations across an entire disk volume. By sensitive I mean if the operation goes wrong, it can potentially corrupt the target volume.
During some post-release testing, I found that the process can be corrupted using reflection to manipulate private fields. The class is not sealed
by design so that consumers of the library can create derivatives.
Is there a way to secure private members to prevent modification via reflection (from derived or consumer code)?
UPDATE: I found a comment from Hans Passant to an old question mentioning [ReflectionPermission]
. Looking into that now.
There is no way to hide your field from Reflection. It can be used to access and manipulate any field on a type. There are steps you can take like obfuscation which make it harder to identify fields and in turn harder to change via Reflection. This is only a speed bump though. A determined developer can use Reflection to beat any work arounds you have
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With