Link to home
Create AccountLog in
Avatar of James Hancock
James HancockFlag for United States of America

asked on

Banning java reflection in coding

Hi

In my project, I am disallowing code entries to use reflection on other objects to steal data.
Is it possible to see in a split second if this cheating has occurred?
If one class extends a class, if I make all the data I want to conceal, private / protected from children. Reflection can be used to discern this data? But, Must I just disallow anything that starts "import java.lang.reflect." ? Then private and protected will be enforced in the parent class?

Is reflection the only way to steal data members from other objects in the JVM?

Thanks
ASKER CERTIFIED SOLUTION
Avatar of CEHJ
CEHJ
Flag of United Kingdom of Great Britain and Northern Ireland image

Link to home
membership
Create an account to see this answer
Signing up is free. No credit card required.
Create Account
Avatar of James Hancock

ASKER

Do I create the security manager in the class constructor? to completely protect its data? What does it do to the JVM?

I have a game class that maintains the state of a game (position of objects)

I dont want any classes that extend this class to be able to see its data (game state)
If I do private, protected data members, reflection can sniff them out?

What else is there?

What does the data protection code look like? Does the JVM then know who to protect?
Thanks
Thanks CEHJ

I may be wrong, but that link seemed only to be a good discussion.

How do I guarantee that a class A that extends B can't read any of the specified data members in class B, even with reflection, so, private is truly meaningful, even for extending classes.

Do I specify this in B's constructor, or in main() ?
Can I ban any descendants, extenders that use java.lang.reflect  ?
how?
what would any of this code be?
Maybe I can make the class B completely unreadable, and only have accessor methods?

Thanks
SOLUTION
Link to home
membership
Create an account to see this answer
Signing up is free. No credit card required.
Create Account
Well, here are the definitions on wikipedia

private -
The private keyword is used in the declaration of a method, field, or inner class; private members can only be accessed by other members of their own class.
protected -
The protected keyword is used in the declaration of a method, field, or inner class; protected members can only be accessed by members of their own class, that class's subclasses or classes from the same package.[18]

That sounds like private is what I want, cause children can't see its data.

So, if my game state Class's Object locations are private, the extending class can't see that data without accessing methods? How do I disallow reflection?
Does the security manager have a checkUsage type method for classes that extend themselves, reflection?
SOLUTION
Link to home
membership
Create an account to see this answer
Signing up is free. No credit card required.
Create Account
SOLUTION
Link to home
membership
Create an account to see this answer
Signing up is free. No credit card required.
Create Account
So, the very first line in the game-state class's constructor?
Sounds right

It looks like..


System.setSecurityManager(new SecurityManager());

Makes it so that children need

Field field = getClass().getSuperclass().getDeclaredField("privateField");
            field.setAccessible(true);
            return field.getInt(this);

To access private data members,
Does byte code disclose the precise names of data members? What if a cheat doesn't know the exact name of my data members? So, all my spiderX[] spiderY[] arrays are safe if they don't know the data member's name?

Thx
SOLUTION
Link to home
membership
Create an account to see this answer
Signing up is free. No credit card required.
Create Account
So, the very first line in the game-state class's constructor?
Sounds right
No! That could well be too late. Some malicious code could still have retrieved a reference to the game state's "class" which is used to find the private data members and to get a reference to them and make them accessible BEFORE the constructor of that game state class is called.

Also, as I said that SecurityManager affects the ENTIRE application, so it would make sense to install it in a place that is more common to the entire application. I don't know anything of the architecture of your code but I would say that early on in a "main()" function would be an appropriate location.
What if a cheat doesn't know the exact name of my data members?
There is also a ".getDeclaredFields()" method so that code can get an array of ALL fields, from which they could get the names & types of the fields and then potentially deduce what are the important ones.
So, in all,

this code to attempt illegal action :

public int attemptRestrictedAccess() throws SecurityException, NoSuchFieldException, IllegalArgumentException, IllegalAccessException {
            Field field = getClass().getSuperclass().getDeclaredField("privateField");
            field.setAccessible(true);
            }

Tries to steal 'privateField' from its super, but then designates it as accessible,

Should I steal all of my wanted-secure data members and set them all as
 field.setAccessible(false); - maybe do it in its own constructor?

Will the getDeclaredFields() still show up my secret fields once they are false-accessible?

?

The simulations will be run on my machines, so native code or similar is not really possible.

Thanks
SOLUTION
Link to home
membership
Create an account to see this answer
Signing up is free. No credit card required.
Create Account
An interesting question is, in what scenario/context are you thinking about all these issues? From previous questions, I am assuming that this "game state" that you are worried about exists only on your server? So how would any malicious code be running that code potentially even attempt to access your private data?
I am realizing that for a big war RTS, like a typical huge Starcraft game, my game state arrays can't fit in the unit x, y locations and other needed game state data easily into a UDP packet. - With a 4 byte integer. What if 200 plus units' data needs to be transferred. So, I am thinking of sticking with the simpler, game state on clients concept, only because sending just keyboard and mouse directives is simpler than an entire game state. Or am I not thinking right? Giant games don't seem practical with game state on server? Also, huge UDP messages are risky.
?
What if 200 plus units' data needs to be transferred.
You only need to send the game state deltas, using some kind of binary diff system

So, I am thinking of sticking with the simpler, game state on clients concept
That will simply give you a different problem - that of making the clients responsible for synching state. How are you going to do that - p2p or through the server? If the latter, the burden is not much different, and could even be heavier
Thx
When I did it before,

The server distributes movement messages from a client to each other client. Every client knows what the other clients were doing in that frame and updates their game state from small UDP messages. A movement message must be received at each client per frame. When I did it this way once, it worked perfectly, massive unit movement was not a problem. I didn't send deltas, only destination X's and Y's, the client updating the unitX[], unitY[] per frame.
Either way, x,y on server, or this, the clients maintain unitX[] and unitY[]

I only want to make the unitX[] and unitY[] arrays unreadable by extending classes, and apparently private or protected isn't enough. If I send just the deltas, which is appealing, then can't the unitX[] still be reflected or stolen?

Thanks
Can I instruct a class to be un-reflection-able ?
Can I instruct a class to be un-reflection-able ?
We're going around in circles. You can only do it to a certain extent, by using ... a SecurityManager

I only want to make the unitX[] and unitY[] arrays unreadable
That's a bit confusing - isn't that precisely what's holding the game state (or part of it)? The clients will have to read it to use it won't they?
Yes, the clients themselves will need to read it, so private there will be relevant,

but I don't want anyone that extends the client to read unitX outright. What if that unit is in the fog of war?
because the person extending the client class could decide to make a radar like window revealing all the locations of the objects, even unseeable objects.
As CEHJ touched on, once all this code is on the client side, a malicious user can do much more than just "extend your class"! They could rewrite it, they could run it without using a SecurityManager, they could just implement their own code that emulates your network protocol to build their own view of the game state, etc, etc, etc. All those things are why you would have initially been advised about keeping the game state on the server, IF minimising cheating was one of your higher priorities.
Indeed, though why they would do that is mysterious ...
I said elsewhere that I was unhappy with sending UDP packets of the game state and was corrected by only needing to send deltas. So, I only need deltas for units that have moved out of the fog of war? What if 100s or dozens of units are seeable. It will blowout my packet size. That makes the old "Send the server only user keyboard /  mouse commands to be bounced to other clients." - more appealing.

Another problem is that I only have 2 machines on my desk. I'm using my Macbook to code my server, and a PC for the clients. The PC clients often blow up with errors, on lines dealing with serverSocket.receive() etc. So, hosting 2 clients on one machine must be a problem.

How do pro's do this sort of thing?
I mean clientSocket.receive() blows up on client coding machine. Sorry.
That's all very vague ;) We need to see exceptions etc. (in a new question)
Thanks
:)