These forums have been archived and are now read-only.

The new forums are live and can be found at https://forums.eveonline.com/

EVE General Discussion

 
  • Topic is locked indefinitely.
 

EVE mobile: Android or Apple (eww)
Author
Previous Topic Next Topic
Flamespar
State War Academy
Caldari State
#1 - 2013-10-23 08:35:17 UTC
Anyone know which OS the EVE mobile ap that CCP is developing is going to be released on?
Solstice Project
Sebiestor Tribe
Minmatar Republic
#2 - 2013-10-23 08:47:24 UTC
Hopefully for the better plattform and not for the zombies (c) NSA.
Marcus Caspius
#3 - 2013-10-23 09:11:31 UTC
Whatever it is I hope it's native and not this HTML5 knock-offs...

Grammatical error and spelling mistakes are included for your entertainment!
Arduemont
Rotten Legion
#4 - 2013-10-23 11:26:56 UTC  |  Edited by: Arduemont
Android will make reverse engineering very easy and Apple are terrible. No one should use Apple (Microsoft are terrible too).

Basically they shouldn't waste resources on it. If they're going to make something which is limited by it's own API (to stop someone like me reading about their server details on an Android app), then they might as well leave it for third party developers.

They should be able to do it for both, but (although I hate them) Apple are the clear choice for security reasons. But like I say, they should just update the API and leave it for 3rd party developers. Unless of course they mean they want to release Eve itself on tablets, in which case that really is a terrible terrible idea. Especially considering the amount of work that would have to go into it.

The whole thing is a massive waste of development effort almost any way you look at it.

"In the age of information, ignorance is a choice." www.stateofwar.co.nf
Karak Terrel
Foundation for CODE and THE NEW ORDER
#5 - 2013-10-23 11:48:47 UTC
Arduemont wrote:
Android will make reverse engineering very easy and Apple are terrible. No one should use Apple (Microsoft are terrible too).

Basically they shouldn't waste resources on it. If they're going to make something which is limited by it's own API (to stop someone like me reading about their server details on an Android app), then they might as well leave it for third party developers.

They should be able to do it for both, but (although I hate them) Apple are the clear choice for security reasons. But like I say, they should just update the API and leave it for 3rd party developers. Unless of course they mean they want to release Eve itself on tablets, in which case that really is a terrible terrible idea. Especially considering the amount of work that would have to go into it.

The whole thing is a massive waste of development effort almost any way you look at it.

Why should they hide the details? If a service is only secure if you hide the details of it's functionality then this service should not run in the first place. Decades of closed source gaming and obfuscated network protocols could not eliminate cheating, so why should this be considered a necessary thing?
Arduemont
Rotten Legion
#6 - 2013-10-23 12:00:56 UTC
Karak Terrel wrote:

Why should they hide the details? If a service is only secure if you hide the details of it's functionality then this service should not run in the first place. Decades of closed source gaming and obfuscated network protocols could not eliminate cheating, so why should this be considered a necessary thing?


Android apps are stored as .apk files, which are a mash-up of the normal java .jar files. So, basically they are zip files. Means anyone can unzip it with normal decompression software (comes standard with windows) and see the entirety of their code with little to no effort. All services are only secure if you hide the details, otherwise they are manipulatable to the nth degree.

If, for example, I were to find their SQL server login details stored in the code somewhere (in Java most network protocal API stores those details in a file called persistence.xml), I could literally delete Eve. As in, everything. So when you ask why security is important, that is why.

"In the age of information, ignorance is a choice." www.stateofwar.co.nf
Karak Terrel
Foundation for CODE and THE NEW ORDER
#7 - 2013-10-23 12:22:33 UTC
Arduemont wrote:
Android apps are stored as .apk files, which are a mash-up of the normal java .jar files. So, basically they are zip files. Means anyone can unzip it with normal decompression software (comes standard with windows) and see the entirety of their code with little to no effort. All services are only secure if you hide the details, otherwise they are manipulatable to the nth degree.

If, for example, I were to find their SQL server login details stored in the code somewhere (in Java most network protocal API stores those details in a file called persistence.xml), I could literally delete Eve. As in, everything. So when you ask why security is important, that is why.

I apologize, you seam to be quite the professional, I got my little knowledge about this magic IT stuff from wikipedia.

Say, what quality software where you developing again, that stores database credentials client side and achieves high security by compressing the application in a not widely known format?
Arduemont
Rotten Legion
#8 - 2013-10-23 12:31:55 UTC  |  Edited by: Arduemont
Karak Terrel wrote:

Say, what quality software where you developing again, that stores database credentials client side and achieves high security by compressing the application in a not widely known format?


I develop business management software. I'm fairly young to development, but I know that JPA (Java's most popular and most used persistence API) always stores it's database credentials in this fashion. Applications like this usually create further levels of obfuscation by wrapping the jar file into an exe, which makes reverse engineering more difficult.

That's not possible with Android apps because it has to be in apk. format to be executed by the tablet/phone.

Edit: The login credential files' contents are usually serialized for further protection, but that doesn't stop someone from printing the credentials from a modified client.

Karak Terrel wrote:
I apologize, you seam to be quite the professional, I got my little knowledge about this magic IT stuff from wikipedia.


I assume by, what seems like sarcasm, you are an IT professional of some description. If you think what I have said is wrong I am happy to be corrected.

"In the age of information, ignorance is a choice." www.stateofwar.co.nf
Johnny Marzetti
Imperial Shipment
Amarr Empire
#9 - 2013-10-23 12:54:24 UTC
Let's make sure it's the one that sperglords feel strongly about. Oh, good news, that's both of them!
Cerile Audeles
University of Caille
Gallente Federation
#10 - 2013-10-23 12:56:22 UTC
Arduemont wrote:
Karak Terrel wrote:

Say, what quality software where you developing again, that stores database credentials client side and achieves high security by compressing the application in a not widely known format?


I develop business management software. I'm fairly young to development, but I know that JPA (Java's most popular and most used persistence API) always stores it's database credentials in this fashion. Applications like this usually create further levels of obfuscation by wrapping the jar file into an exe, which makes reverse engineering more difficult.

That's not possible with Android apps because it has to be in apk. format to be executed by the tablet/phone.

Edit: The login credential files' contents are usually serialized for further protection, but that doesn't stop someone from printing the credentials from a modified client.

Karak Terrel wrote:
I apologize, you seam to be quite the professional, I got my little knowledge about this magic IT stuff from wikipedia.


I assume by, what seems like sarcasm, you are an IT professional of some description. If you think what I have said is wrong I am happy to be corrected.


Why would anyone store login info for a db user that can access non public information on a client application? Why would anyone allow direct db access for non public data from client software for that matter?
Lucas Kell
Solitude Trading
S.N.O.T.
#11 - 2013-10-23 12:56:58 UTC  |  Edited by: Lucas Kell
Arduemont wrote:
I develop business management software. I'm fairly young to development, but I know that JPA (Java's most popular and most used persistence API) always stores it's database credentials in this fashion. Applications like this usually create further levels of obfuscation by wrapping the jar file into an exe, which makes reverse engineering more difficult.

That's not possible with Android apps because it has to be in apk. format to be executed by the tablet/phone.

Edit: The login credential files' contents are usually serialized for further protection, but that doesn't stop someone from printing the credentials from a modified client.

Karak Terrel wrote:
I apologize, you seam to be quite the professional, I got my little knowledge about this magic IT stuff from wikipedia.


I assume by, what seems like sarcasm, you are an IT professional of some description. If you think what I have said is wrong I am happy to be corrected.
Dunno about him, but I'll be happy to correct you.
At no point in time should a client side application be storing (in any form) the database credentials. You would not expose your database to the outside world, and anyone that even did should be shot, not just fired.

When you have a client-server architecture, the server exposes the functionality you wish to use allowing you to log in with your own credentials and only exposing what you need. Take for example a web server. You are only exposed to whatever functionality is provided to you by the application hosting the service, so you go to this forum for example, and you log in to the app, not the database. Their server fetches what you need and gives it to you.
The EVE client works in the same way, your client doesn't have access to the database directly, it only has access to what the server is willing to provide you.

The likelihood is, to provide the functionality to a mobile app, web services would be used, providing you only the functions the app would use and only when the function is called providing a valid login certificate. Even with the source code, you'd not be able to do anything beyond what the server provided as services.

As for the apks, you are right, they are essentially zips, and java code is jit compiled, so you'd relatively easily be able to turn their intermediate classes back into java. That said, almost every executable is easily restored to readable C++, with .NET classes able to be restored to C#/VB. EVE itself has a lot of python elements easily readable. The ability to reverse engineer the code doesn't help you do anything special though (see above about server services)

And finally, should they for some reason expose their database ports and their database credentials and you successfully managed to log in, chances are it would be a restricted login, and you would not be able to "delete eve".

The Indecisive Noob - EVE fan blog.

Wholesale Trading - The new bulk trading mailing list.
Arduemont
Rotten Legion
#12 - 2013-10-23 13:13:25 UTC
Lucas Kell wrote:
Dunno about him, but I'll be happy to correct you.
At no point in time should a client side application be storing (in any form) the database credentials. You would not expose your database to the outside world, and anyone that even did should be shot, not just fired.

When you have a client-server architecture, the server exposes the functionality you wish to use allowing you to log in with your own credentials and only exposing what you need. Take for example a web server. You are only exposed to whatever functionality is provided to you by the application hosting the service, so you go to this forum for example, and you log in to the app, not the database. Their server fetches what you need and gives it to you.
The EVE client works in the same way, your client doesn't have access to the database directly, it only has access to what the server is willing to provide you.

The likelihood is, to provide the functionality to a mobile app, web services would be used, providing you only the functions the app would use and only when the function is called providing a valid login certificate. Even with the source code, you'd not be able to do anything beyond what the server provided as services.

As for the apks, you are right, they are essentially zips, and java code is jit compiled, so you'd relatively easily be able to turn their intermediate classes back into java. That said, almost every executable is easily restored to readable C++, with .NET classes able to be restored to C#/VB. EVE itself has a lot of python elements easily readable. The ability to reverse engineer the code doesn't help you do anything special though (see above about server services)

And finally, should they for some reason expose their database ports and their database credentials and you successfully managed to log in, chances are it would be a restricted login, and you would not be able to "delete eve".


Thank you. In which case, I stand corrected, and admit defeat.

That does of course require a log in. Without a login and a three tier architecture, this is impossible. But then it was probably naive of me to assume it would be made without a login.

"In the age of information, ignorance is a choice." www.stateofwar.co.nf
Lucas Kell
Solitude Trading
S.N.O.T.
#13 - 2013-10-23 13:19:49 UTC
Arduemont wrote:
Thank you. In which case, I stand corrected, and admit defeat.

That does of course require a log in. Without a login and a three tier architecture, this is impossible. But then it was probably naive of me to assume it would be made without a login.
Wow, that's a first on the EVE forums. I was expecting a 200 page threadnaught concluding with negative opinions of my mother and a thread lock. Have a like.

By the way, was there an announcement I missed where they said this was in the works, or is the whole thread just speculation?
If they do make it, I'd be surprised if it didn't hit both Android and Apple devices, but I'll hold out hope for Win8 devices.

The Indecisive Noob - EVE fan blog.

Wholesale Trading - The new bulk trading mailing list.
Karak Terrel
Foundation for CODE and THE NEW ORDER
#14 - 2013-10-23 13:21:41 UTC  |  Edited by: Karak Terrel
Arduemont wrote:

Thank you. In which case, I stand corrected, and admit defeat.

That does of course require a log in. Without a login and a three tier architecture, this is impossible. But then it was probably naive of me to assume it would be made without a login.

Great, now I feel bad for my attempt to ridicule you Sad Sorry
Arduemont
Rotten Legion
#15 - 2013-10-23 13:27:37 UTC
Apparently John Lander is working on it now.

I can't remember where that was announced by there was confirmation somewhere in the recent Eve Vegas livestream.

Also, likes all round. I wasn't lying when I said I was happy to be corrected. Everyone makes mistakes.

"In the age of information, ignorance is a choice." www.stateofwar.co.nf
Lucas Kell
Solitude Trading
S.N.O.T.
#16 - 2013-10-23 13:30:15 UTC
Arduemont wrote:
Apparently John Lander is working on it now.

I can't remember where that was announced by there was confirmation somewhere in the recent Eve Vegas livestream.

Also, likes all round. I wasn't lying when I said I was happy to be corrected. Everyone makes mistakes.
Ooh! exciting! I want a feature list!
Does anyone have a link to a post of a youtube vid of anything like that?

The Indecisive Noob - EVE fan blog.

Wholesale Trading - The new bulk trading mailing list.