Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Making reverse engineering impossible

 
Svend Rost
Ranch Hand
Posts: 904
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

Let's start with a motivation example:


Now to my app.:

Let's assume, the application is publicly available.

Im working on an application, in which there will be transfered sensitive
data between the phone and a server. The communication between the client
and the server is encrypted, however how does the server ensure, that the
version hasn't been corrupted ?


Advice, references to papers ect. will be appriciated.

Thanks in advance,

/Svend Rost
 
Fred Grott
Ranch Hand
Posts: 346
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
refer to goolge and lookup how http works for the explanation of why the communication from device and server via http is not corrupted..
 
peter wooster
Ranch Hand
Posts: 1033
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This is a standard problem with any system running on any platform. There is no guarantee that the user with hands on the device has not modified the code running on that device. No matter the language or platform you chose, if the user can physically access the computer, they can change its programming. You can lock things up and obscure the code, but its a losing battle to prevent reverse engineering. This situation is not new, it hasn't changed appreciably in over 40 years.

For this reason any system like the one you describe would be implemented on the server. The client should do no more than the presentation layer. This approach is usually refered to as a thin client and is the only one that is safe for secure applications. In your example all the client would do with scores would be to display them to the user, and who cares if it lies about what it shows.
 
Svend Rost
Ranch Hand
Posts: 904
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

Thanks for your replies.

A thin client would do the job, and would also be the approach that I
normaly choose - had this not been a mobile app.

WAP is not an option btw.

I had not really considered using a thin client on mobile devices, because
it would mean, that the user had to be "online" all the time which can be
costly (I assume, that you eighter pay per min. or per downloaded MB).

I think I'll try to make a thin client and then test how expensive it would
be for the user to use this app.

/Svend Rost
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic