2

I have a java server that communicates with a java client via json-rpc. The client is supposed to report internal stats to the server which modifies the servers behaviour. Both client and server compenents are written in house so I can control what the client does and how it reports stats but is there a way I can verify that the client code hasn't been modified? If it has it will still service the client but using some default behaviours.

The clients will be publicly available so it's not a big deal for someone to decompile them and alter behaviours.

Simply having the client send a signature of the code no good because could be easily spoofed by keeping an original copy of the client alongside the modified one.

Steve
  • 21
  • 2
  • 1
    I don't think you can. Imagine you had such a purported network message which you would accept as valid. How could you distinguish it from a recording played back by some other client? – Kerrek SB Jun 27 '11 at 23:52

3 Answers3

4

You can't. You essentially have no way of knowing what code is running on the client, and none of your program logic should rely on treating the client as "trusted". All access control, validation etc should be done on the server (or in both places).

Certain specialist environments (e.g. code embedded on a smart card, or devices such as games consoles whoes OS is designed to only run signed code) give you a bit more of a guarantee because of the increased difficulty of reverse engineering/gaining appropriate control of the device. But even these aren't infallible (look at the iPhone or any console and see how long it took for the devices to be 'cracked' compared with the interest in doing so to give you an idea of the level of security).

Neil Coffey
  • 21,615
  • 7
  • 62
  • 83
0

You cannot verify that the client was not modified with a client-server architecture.

You should never trust the input from a client unless an authenticated user (login + password match) is talking to you over a secure connection (e.g. SSL).

The client has to just call the logic instead of sending it to the sever.

ayckoster
  • 6,707
  • 6
  • 32
  • 45
  • 2
    Still be careful, though. "Was able to send a correct login over SSL" does not mean "Is sending that login using the code I think it's using". – Neil Coffey Jun 28 '11 at 00:02
0

First thing that comes to mind would be for the client to send both a signature file (within code) and a hash of itself.

But, like you say, it can be spoofed.

If you are trying to relly on the client's authenticity to do stuff on the server: don't! Rethink you logic. If this is just an extra safety measure (go with it).

Frankie
  • 24,627
  • 10
  • 79
  • 121