Obfuscating MonoTouch Projects

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Obfuscating MonoTouch Projects

Intrawebs
I was wondering if it's possible to obfuscate MonoTouch projects?  I was looking into a rather large project/game that uses some 3rd party web services (private API keys etc) as well as the code itself needing to be obfuscated.  Does anyone have experience with this?  I'm new to MonoDevelop so I don't know whats available there that will work with obfuscating an iOS app.

Thanks
Reply | Threaded
Open this post in threaded view
|

Re: Obfuscating MonoTouch Projects

Nic Wise
why do you need to obfuscate it?

Whats on the device is object code - ARM assembly - so unless someone
looks into it and finds the API keys.... you should be safe. It's the
same as a true windows .exe (not a .NET one) - it's processor code.

If you want to avoid this, maybe put the strings in the app encoded,
and decode them when the app is running. Even something as base64
encoding them or just reversing the string would be enough to prevent
somone using "strings" to get it out. If someone is somehow debugging
your running app on the device, there isn't a good way to stop them
getting it.

Being you have to use these on the device, I don't see a good way to
have them 100% "secure"., unless you encrypted them with a key, and
then downloaded that key off your server before use (which would suck
if your user was underground, eg the london tube). But even then, the
unencrypted string is still in memory, so if someone has gone to this
length, they would be able to get it anyway.

So, the chances of going from arm code back to usable c# code is
minimal. The .dll / .exe's in the .app bundle don't have code in them,
as far as I know, they just have debug info. Aside from knowing that
your class is called "foo" and it has a method "bar", there isn't
anything in there.

Obfuscation is seldom a real answer, if you actually have the problem.
Most people think they have the problem.... even if they don't.

assuming it's a private API, have you also thought about someone
running a packet sniffer? If it's not over HTTPS, they'll get the key
easily. If it IS over HTTPS, it's not too hard to do a
man-in-the-middle attack using something like Charles, being you have
control over the proxy on the client and could accept the "new"
certificate to make it valid on the device.


On Sat, May 7, 2011 at 01:48, Intrawebs <[hidden email]> wrote:

> I was wondering if it's possible to obfuscate MonoTouch projects?  I was
> looking into a rather large project/game that uses some 3rd party web
> services (private API keys etc) as well as the code itself needing to be
> obfuscated.  Does anyone have experience with this?  I'm new to MonoDevelop
> so I don't know whats available there that will work with obfuscating an iOS
> app.
>
> Thanks
>
> --
> View this message in context: http://monotouch.2284126.n4.nabble.com/Obfuscating-MonoTouch-Projects-tp3504648p3504648.html
> Sent from the MonoTouch mailing list archive at Nabble.com.
> _______________________________________________
> MonoTouch mailing list
> [hidden email]
> http://lists.ximian.com/mailman/listinfo/monotouch
>



--
Nic Wise
t.  +44 7788 592 806 | @fastchicken | http://www.linkedin.com/in/nicwise
b. http://www.fastchicken.co.nz/ | http://www.flickr.com/photos/nicwise

mobileAgent (for FreeAgent): get your accounts in your pocket.
http://goo.gl/IuBU
Trip Wallet: Keep track of your budget on the go: http://goo.gl/ePhKa
London Bike App: Find the nearest Boris Bike, and get riding! http://goo.gl/Icp2
_______________________________________________
MonoTouch mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/monotouch
Reply | Threaded
Open this post in threaded view
|

Re: Obfuscating MonoTouch Projects

Nic Wise
Oh, if I didn't mention (being I just did it now for another app)

If you call a URL, even over HTTPS, and it has a private key in it,
then it can be seen by a user if they want to. For example, I was
looking at an app which talks to a service over HTTPS. I put in a
proxy for my WIFI (the proxy is on my mac, using Charles -
http://www.charlesproxy.com/ ). I added an exception in Charles for
their server and port, and I'd already installed the Chales SSL cert
on my phone.

The request came up in the proxy in plaintext. SSL WILL NOT STOP
PEOPLE SEEING YOUR TRAFFIC if the user has control over the client,
which they do in this case.

Just so ya know.

On Sat, May 7, 2011 at 13:02, Nic Wise <[hidden email]> wrote:

> why do you need to obfuscate it?
>
> Whats on the device is object code - ARM assembly - so unless someone
> looks into it and finds the API keys.... you should be safe. It's the
> same as a true windows .exe (not a .NET one) - it's processor code.
>
> If you want to avoid this, maybe put the strings in the app encoded,
> and decode them when the app is running. Even something as base64
> encoding them or just reversing the string would be enough to prevent
> somone using "strings" to get it out. If someone is somehow debugging
> your running app on the device, there isn't a good way to stop them
> getting it.
>
> Being you have to use these on the device, I don't see a good way to
> have them 100% "secure"., unless you encrypted them with a key, and
> then downloaded that key off your server before use (which would suck
> if your user was underground, eg the london tube). But even then, the
> unencrypted string is still in memory, so if someone has gone to this
> length, they would be able to get it anyway.
>
> So, the chances of going from arm code back to usable c# code is
> minimal. The .dll / .exe's in the .app bundle don't have code in them,
> as far as I know, they just have debug info. Aside from knowing that
> your class is called "foo" and it has a method "bar", there isn't
> anything in there.
>
> Obfuscation is seldom a real answer, if you actually have the problem.
> Most people think they have the problem.... even if they don't.
>
> assuming it's a private API, have you also thought about someone
> running a packet sniffer? If it's not over HTTPS, they'll get the key
> easily. If it IS over HTTPS, it's not too hard to do a
> man-in-the-middle attack using something like Charles, being you have
> control over the proxy on the client and could accept the "new"
> certificate to make it valid on the device.
>
>
> On Sat, May 7, 2011 at 01:48, Intrawebs <[hidden email]> wrote:
>> I was wondering if it's possible to obfuscate MonoTouch projects?  I was
>> looking into a rather large project/game that uses some 3rd party web
>> services (private API keys etc) as well as the code itself needing to be
>> obfuscated.  Does anyone have experience with this?  I'm new to MonoDevelop
>> so I don't know whats available there that will work with obfuscating an iOS
>> app.
>>
>> Thanks
>>
>> --
>> View this message in context: http://monotouch.2284126.n4.nabble.com/Obfuscating-MonoTouch-Projects-tp3504648p3504648.html
>> Sent from the MonoTouch mailing list archive at Nabble.com.
>> _______________________________________________
>> MonoTouch mailing list
>> [hidden email]
>> http://lists.ximian.com/mailman/listinfo/monotouch
>>
>
>
>
> --
> Nic Wise
> t.  +44 7788 592 806 | @fastchicken | http://www.linkedin.com/in/nicwise
> b. http://www.fastchicken.co.nz/ | http://www.flickr.com/photos/nicwise
>
> mobileAgent (for FreeAgent): get your accounts in your pocket.
> http://goo.gl/IuBU
> Trip Wallet: Keep track of your budget on the go: http://goo.gl/ePhKa
> London Bike App: Find the nearest Boris Bike, and get riding! http://goo.gl/Icp2
>



--
Nic Wise
t.  +44 7788 592 806 | @fastchicken | http://www.linkedin.com/in/nicwise
b. http://www.fastchicken.co.nz/ | http://www.flickr.com/photos/nicwise

mobileAgent (for FreeAgent): get your accounts in your pocket.
http://goo.gl/IuBU
Trip Wallet: Keep track of your budget on the go: http://goo.gl/ePhKa
London Bike App: Find the nearest Boris Bike, and get riding! http://goo.gl/Icp2
_______________________________________________
MonoTouch mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/monotouch
Reply | Threaded
Open this post in threaded view
|

Re: Obfuscating MonoTouch Projects

NokNok Developer
Ahhh- way around that is pretty simple....

Key from WebServer gets returned using encryption (many kinds all work),
using the REQUEST IP ADDRESS and PORT as the secret.

Only the client receiving the data back (the true client) will be able
to decrypt it...




On 5/7/2011 9:49 AM, Nic Wise wrote:

> Oh, if I didn't mention (being I just did it now for another app)
>
> If you call a URL, even over HTTPS, and it has a private key in it,
> then it can be seen by a user if they want to. For example, I was
> looking at an app which talks to a service over HTTPS. I put in a
> proxy for my WIFI (the proxy is on my mac, using Charles -
> http://www.charlesproxy.com/ ). I added an exception in Charles for
> their server and port, and I'd already installed the Chales SSL cert
> on my phone.
>
> The request came up in the proxy in plaintext. SSL WILL NOT STOP
> PEOPLE SEEING YOUR TRAFFIC if the user has control over the client,
> which they do in this case.
>
> Just so ya know.
>
> On Sat, May 7, 2011 at 13:02, Nic Wise<[hidden email]>  wrote:
>> why do you need to obfuscate it?
>>
>> Whats on the device is object code - ARM assembly - so unless someone
>> looks into it and finds the API keys.... you should be safe. It's the
>> same as a true windows .exe (not a .NET one) - it's processor code.
>>
>> If you want to avoid this, maybe put the strings in the app encoded,
>> and decode them when the app is running. Even something as base64
>> encoding them or just reversing the string would be enough to prevent
>> somone using "strings" to get it out. If someone is somehow debugging
>> your running app on the device, there isn't a good way to stop them
>> getting it.
>>
>> Being you have to use these on the device, I don't see a good way to
>> have them 100% "secure"., unless you encrypted them with a key, and
>> then downloaded that key off your server before use (which would suck
>> if your user was underground, eg the london tube). But even then, the
>> unencrypted string is still in memory, so if someone has gone to this
>> length, they would be able to get it anyway.
>>
>> So, the chances of going from arm code back to usable c# code is
>> minimal. The .dll / .exe's in the .app bundle don't have code in them,
>> as far as I know, they just have debug info. Aside from knowing that
>> your class is called "foo" and it has a method "bar", there isn't
>> anything in there.
>>
>> Obfuscation is seldom a real answer, if you actually have the problem.
>> Most people think they have the problem.... even if they don't.
>>
>> assuming it's a private API, have you also thought about someone
>> running a packet sniffer? If it's not over HTTPS, they'll get the key
>> easily. If it IS over HTTPS, it's not too hard to do a
>> man-in-the-middle attack using something like Charles, being you have
>> control over the proxy on the client and could accept the "new"
>> certificate to make it valid on the device.
>>
>>
>> On Sat, May 7, 2011 at 01:48, Intrawebs<[hidden email]>  wrote:
>>> I was wondering if it's possible to obfuscate MonoTouch projects?  I was
>>> looking into a rather large project/game that uses some 3rd party web
>>> services (private API keys etc) as well as the code itself needing to be
>>> obfuscated.  Does anyone have experience with this?  I'm new to MonoDevelop
>>> so I don't know whats available there that will work with obfuscating an iOS
>>> app.
>>>
>>> Thanks
>>>
>>> --
>>> View this message in context: http://monotouch.2284126.n4.nabble.com/Obfuscating-MonoTouch-Projects-tp3504648p3504648.html
>>> Sent from the MonoTouch mailing list archive at Nabble.com.
>>> _______________________________________________
>>> MonoTouch mailing list
>>> [hidden email]
>>> http://lists.ximian.com/mailman/listinfo/monotouch
>>>
>>
>>
>> --
>> Nic Wise
>> t.  +44 7788 592 806 | @fastchicken | http://www.linkedin.com/in/nicwise
>> b. http://www.fastchicken.co.nz/ | http://www.flickr.com/photos/nicwise
>>
>> mobileAgent (for FreeAgent): get your accounts in your pocket.
>> http://goo.gl/IuBU
>> Trip Wallet: Keep track of your budget on the go: http://goo.gl/ePhKa
>> London Bike App: Find the nearest Boris Bike, and get riding! http://goo.gl/Icp2
>>
>
>
_______________________________________________
MonoTouch mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/monotouch
Reply | Threaded
Open this post in threaded view
|

Re: Obfuscating MonoTouch Projects

Robert Jordan
On 07.05.2011 17:34, NokNok Developer wrote:
> Ahhh- way around that is pretty simple....
>
> Key from WebServer gets returned using encryption (many kinds all work),
> using the REQUEST IP ADDRESS and PORT as the secret.
>
> Only the client receiving the data back (the true client) will be able
> to decrypt it...

How does the server know that REQUEST IP ADDRESS and PORT are
originating from a trusted client? :)

Robert

>
>
>
>
> On 5/7/2011 9:49 AM, Nic Wise wrote:
>> Oh, if I didn't mention (being I just did it now for another app)
>>
>> If you call a URL, even over HTTPS, and it has a private key in it,
>> then it can be seen by a user if they want to. For example, I was
>> looking at an app which talks to a service over HTTPS. I put in a
>> proxy for my WIFI (the proxy is on my mac, using Charles -
>> http://www.charlesproxy.com/ ). I added an exception in Charles for
>> their server and port, and I'd already installed the Chales SSL cert
>> on my phone.
>>
>> The request came up in the proxy in plaintext. SSL WILL NOT STOP
>> PEOPLE SEEING YOUR TRAFFIC if the user has control over the client,
>> which they do in this case.
>>
>> Just so ya know.
>>
>> On Sat, May 7, 2011 at 13:02, Nic Wise<[hidden email]>   wrote:
>>> why do you need to obfuscate it?
>>>
>>> Whats on the device is object code - ARM assembly - so unless someone
>>> looks into it and finds the API keys.... you should be safe. It's the
>>> same as a true windows .exe (not a .NET one) - it's processor code.
>>>
>>> If you want to avoid this, maybe put the strings in the app encoded,
>>> and decode them when the app is running. Even something as base64
>>> encoding them or just reversing the string would be enough to prevent
>>> somone using "strings" to get it out. If someone is somehow debugging
>>> your running app on the device, there isn't a good way to stop them
>>> getting it.
>>>
>>> Being you have to use these on the device, I don't see a good way to
>>> have them 100% "secure"., unless you encrypted them with a key, and
>>> then downloaded that key off your server before use (which would suck
>>> if your user was underground, eg the london tube). But even then, the
>>> unencrypted string is still in memory, so if someone has gone to this
>>> length, they would be able to get it anyway.
>>>
>>> So, the chances of going from arm code back to usable c# code is
>>> minimal. The .dll / .exe's in the .app bundle don't have code in them,
>>> as far as I know, they just have debug info. Aside from knowing that
>>> your class is called "foo" and it has a method "bar", there isn't
>>> anything in there.
>>>
>>> Obfuscation is seldom a real answer, if you actually have the problem.
>>> Most people think they have the problem.... even if they don't.
>>>
>>> assuming it's a private API, have you also thought about someone
>>> running a packet sniffer? If it's not over HTTPS, they'll get the key
>>> easily. If it IS over HTTPS, it's not too hard to do a
>>> man-in-the-middle attack using something like Charles, being you have
>>> control over the proxy on the client and could accept the "new"
>>> certificate to make it valid on the device.
>>>
>>>
>>> On Sat, May 7, 2011 at 01:48, Intrawebs<[hidden email]>   wrote:
>>>> I was wondering if it's possible to obfuscate MonoTouch projects?  I was
>>>> looking into a rather large project/game that uses some 3rd party web
>>>> services (private API keys etc) as well as the code itself needing to be
>>>> obfuscated.  Does anyone have experience with this?  I'm new to MonoDevelop
>>>> so I don't know whats available there that will work with obfuscating an iOS
>>>> app.
>>>>
>>>> Thanks
>>>>
>>>> --
>>>> View this message in context: http://monotouch.2284126.n4.nabble.com/Obfuscating-MonoTouch-Projects-tp3504648p3504648.html
>>>> Sent from the MonoTouch mailing list archive at Nabble.com.
>>>> _______________________________________________
>>>> MonoTouch mailing list
>>>> [hidden email]
>>>> http://lists.ximian.com/mailman/listinfo/monotouch
>>>>
>>>
>>>
>>> --
>>> Nic Wise
>>> t.  +44 7788 592 806 | @fastchicken | http://www.linkedin.com/in/nicwise
>>> b. http://www.fastchicken.co.nz/ | http://www.flickr.com/photos/nicwise
>>>
>>> mobileAgent (for FreeAgent): get your accounts in your pocket.
>>> http://goo.gl/IuBU
>>> Trip Wallet: Keep track of your budget on the go: http://goo.gl/ePhKa
>>> London Bike App: Find the nearest Boris Bike, and get riding! http://goo.gl/Icp2
>>>
>>
>>
> _______________________________________________
> MonoTouch mailing list
> [hidden email]
> http://lists.ximian.com/mailman/listinfo/monotouch
>

_______________________________________________
MonoTouch mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/monotouch
Reply | Threaded
Open this post in threaded view
|

Re: Obfuscating MonoTouch Projects

NokNok Developer
what we do

client ip: 1.2.3.4
proxy ip: 6.7.8.9

client -> service            encrypted request, key used for encryption
= client ipaddress/port, or simply ipaddress: (1.2.3.4)

service gets request, attempts to decrypt request based on source IP
address in the http.request (6.7.8.9)

service fails to decrypt its because their is a "man in the middle" who
re-originated the request (a proxy server), replies 403 forbidden

If the communication is un-obstructed, then the packet will decrypt
because http.request.host = 1.2.3.4, and can be parsed. and response
sent using same key

as for being a trusted client, we usually have a shared secret which is
built based on user information.  so in the actual request body, which
is encrypted with the key, we have some other information.  we respond
providing a "session token" to be used in every further request.

unless the proxy in the middle knows your method of encryption and key
used, the data will mean nothing.



On 5/7/2011 1:53 PM, Robert Jordan wrote:

> On 07.05.2011 17:34, NokNok Developer wrote:
>> Ahhh- way around that is pretty simple....
>>
>> Key from WebServer gets returned using encryption (many kinds all work),
>> using the REQUEST IP ADDRESS and PORT as the secret.
>>
>> Only the client receiving the data back (the true client) will be able
>> to decrypt it...
> How does the server know that REQUEST IP ADDRESS and PORT are
> originating from a trusted client? :)
>
> Robert
>
>>
>>
>>
>> On 5/7/2011 9:49 AM, Nic Wise wrote:
>>> Oh, if I didn't mention (being I just did it now for another app)
>>>
>>> If you call a URL, even over HTTPS, and it has a private key in it,
>>> then it can be seen by a user if they want to. For example, I was
>>> looking at an app which talks to a service over HTTPS. I put in a
>>> proxy for my WIFI (the proxy is on my mac, using Charles -
>>> http://www.charlesproxy.com/ ). I added an exception in Charles for
>>> their server and port, and I'd already installed the Chales SSL cert
>>> on my phone.
>>>
>>> The request came up in the proxy in plaintext. SSL WILL NOT STOP
>>> PEOPLE SEEING YOUR TRAFFIC if the user has control over the client,
>>> which they do in this case.
>>>
>>> Just so ya know.
>>>
>>> On Sat, May 7, 2011 at 13:02, Nic Wise<[hidden email]>    wrote:
>>>> why do you need to obfuscate it?
>>>>
>>>> Whats on the device is object code - ARM assembly - so unless someone
>>>> looks into it and finds the API keys.... you should be safe. It's the
>>>> same as a true windows .exe (not a .NET one) - it's processor code.
>>>>
>>>> If you want to avoid this, maybe put the strings in the app encoded,
>>>> and decode them when the app is running. Even something as base64
>>>> encoding them or just reversing the string would be enough to prevent
>>>> somone using "strings" to get it out. If someone is somehow debugging
>>>> your running app on the device, there isn't a good way to stop them
>>>> getting it.
>>>>
>>>> Being you have to use these on the device, I don't see a good way to
>>>> have them 100% "secure"., unless you encrypted them with a key, and
>>>> then downloaded that key off your server before use (which would suck
>>>> if your user was underground, eg the london tube). But even then, the
>>>> unencrypted string is still in memory, so if someone has gone to this
>>>> length, they would be able to get it anyway.
>>>>
>>>> So, the chances of going from arm code back to usable c# code is
>>>> minimal. The .dll / .exe's in the .app bundle don't have code in them,
>>>> as far as I know, they just have debug info. Aside from knowing that
>>>> your class is called "foo" and it has a method "bar", there isn't
>>>> anything in there.
>>>>
>>>> Obfuscation is seldom a real answer, if you actually have the problem.
>>>> Most people think they have the problem.... even if they don't.
>>>>
>>>> assuming it's a private API, have you also thought about someone
>>>> running a packet sniffer? If it's not over HTTPS, they'll get the key
>>>> easily. If it IS over HTTPS, it's not too hard to do a
>>>> man-in-the-middle attack using something like Charles, being you have
>>>> control over the proxy on the client and could accept the "new"
>>>> certificate to make it valid on the device.
>>>>
>>>>
>>>> On Sat, May 7, 2011 at 01:48, Intrawebs<[hidden email]>    wrote:
>>>>> I was wondering if it's possible to obfuscate MonoTouch projects?  I was
>>>>> looking into a rather large project/game that uses some 3rd party web
>>>>> services (private API keys etc) as well as the code itself needing to be
>>>>> obfuscated.  Does anyone have experience with this?  I'm new to MonoDevelop
>>>>> so I don't know whats available there that will work with obfuscating an iOS
>>>>> app.
>>>>>
>>>>> Thanks
>>>>>
>>>>> --
>>>>> View this message in context: http://monotouch.2284126.n4.nabble.com/Obfuscating-MonoTouch-Projects-tp3504648p3504648.html
>>>>> Sent from the MonoTouch mailing list archive at Nabble.com.
>>>>> _______________________________________________
>>>>> MonoTouch mailing list
>>>>> [hidden email]
>>>>> http://lists.ximian.com/mailman/listinfo/monotouch
>>>>>
>>>>
>>>> --
>>>> Nic Wise
>>>> t.  +44 7788 592 806 | @fastchicken | http://www.linkedin.com/in/nicwise
>>>> b. http://www.fastchicken.co.nz/ | http://www.flickr.com/photos/nicwise
>>>>
>>>> mobileAgent (for FreeAgent): get your accounts in your pocket.
>>>> http://goo.gl/IuBU
>>>> Trip Wallet: Keep track of your budget on the go: http://goo.gl/ePhKa
>>>> London Bike App: Find the nearest Boris Bike, and get riding! http://goo.gl/Icp2
>>>>
>>>
>> _______________________________________________
>> MonoTouch mailing list
>> [hidden email]
>> http://lists.ximian.com/mailman/listinfo/monotouch
>>
> _______________________________________________
> MonoTouch mailing list
> [hidden email]
> http://lists.ximian.com/mailman/listinfo/monotouch
_______________________________________________
MonoTouch mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/monotouch
Reply | Threaded
Open this post in threaded view
|

Re: Obfuscating MonoTouch Projects

Nic Wise
How do you handle people who actually DO have a proxy (eg, I do if I'm
at work), or if an ISP/Telco has a transparent proxy or NAT router?

Actually, how would you handle a NAT router? My phone's ip is 192.xxx
but the router is 98.xxx

On Sat, May 7, 2011 at 19:14, NokNok Developer <[hidden email]> wrote:

> what we do
>
> client ip: 1.2.3.4
> proxy ip: 6.7.8.9
>
> client -> service            encrypted request, key used for encryption
> = client ipaddress/port, or simply ipaddress: (1.2.3.4)
>
> service gets request, attempts to decrypt request based on source IP
> address in the http.request (6.7.8.9)
>
> service fails to decrypt its because their is a "man in the middle" who
> re-originated the request (a proxy server), replies 403 forbidden
>
> If the communication is un-obstructed, then the packet will decrypt
> because http.request.host = 1.2.3.4, and can be parsed. and response
> sent using same key
>
> as for being a trusted client, we usually have a shared secret which is
> built based on user information.  so in the actual request body, which
> is encrypted with the key, we have some other information.  we respond
> providing a "session token" to be used in every further request.
>
> unless the proxy in the middle knows your method of encryption and key
> used, the data will mean nothing.
>
>
>
> On 5/7/2011 1:53 PM, Robert Jordan wrote:
>> On 07.05.2011 17:34, NokNok Developer wrote:
>>> Ahhh- way around that is pretty simple....
>>>
>>> Key from WebServer gets returned using encryption (many kinds all work),
>>> using the REQUEST IP ADDRESS and PORT as the secret.
>>>
>>> Only the client receiving the data back (the true client) will be able
>>> to decrypt it...
>> How does the server know that REQUEST IP ADDRESS and PORT are
>> originating from a trusted client? :)
>>
>> Robert
>>
>>>
>>>
>>>
>>> On 5/7/2011 9:49 AM, Nic Wise wrote:
>>>> Oh, if I didn't mention (being I just did it now for another app)
>>>>
>>>> If you call a URL, even over HTTPS, and it has a private key in it,
>>>> then it can be seen by a user if they want to. For example, I was
>>>> looking at an app which talks to a service over HTTPS. I put in a
>>>> proxy for my WIFI (the proxy is on my mac, using Charles -
>>>> http://www.charlesproxy.com/ ). I added an exception in Charles for
>>>> their server and port, and I'd already installed the Chales SSL cert
>>>> on my phone.
>>>>
>>>> The request came up in the proxy in plaintext. SSL WILL NOT STOP
>>>> PEOPLE SEEING YOUR TRAFFIC if the user has control over the client,
>>>> which they do in this case.
>>>>
>>>> Just so ya know.
>>>>
>>>> On Sat, May 7, 2011 at 13:02, Nic Wise<[hidden email]>    wrote:
>>>>> why do you need to obfuscate it?
>>>>>
>>>>> Whats on the device is object code - ARM assembly - so unless someone
>>>>> looks into it and finds the API keys.... you should be safe. It's the
>>>>> same as a true windows .exe (not a .NET one) - it's processor code.
>>>>>
>>>>> If you want to avoid this, maybe put the strings in the app encoded,
>>>>> and decode them when the app is running. Even something as base64
>>>>> encoding them or just reversing the string would be enough to prevent
>>>>> somone using "strings" to get it out. If someone is somehow debugging
>>>>> your running app on the device, there isn't a good way to stop them
>>>>> getting it.
>>>>>
>>>>> Being you have to use these on the device, I don't see a good way to
>>>>> have them 100% "secure"., unless you encrypted them with a key, and
>>>>> then downloaded that key off your server before use (which would suck
>>>>> if your user was underground, eg the london tube). But even then, the
>>>>> unencrypted string is still in memory, so if someone has gone to this
>>>>> length, they would be able to get it anyway.
>>>>>
>>>>> So, the chances of going from arm code back to usable c# code is
>>>>> minimal. The .dll / .exe's in the .app bundle don't have code in them,
>>>>> as far as I know, they just have debug info. Aside from knowing that
>>>>> your class is called "foo" and it has a method "bar", there isn't
>>>>> anything in there.
>>>>>
>>>>> Obfuscation is seldom a real answer, if you actually have the problem.
>>>>> Most people think they have the problem.... even if they don't.
>>>>>
>>>>> assuming it's a private API, have you also thought about someone
>>>>> running a packet sniffer? If it's not over HTTPS, they'll get the key
>>>>> easily. If it IS over HTTPS, it's not too hard to do a
>>>>> man-in-the-middle attack using something like Charles, being you have
>>>>> control over the proxy on the client and could accept the "new"
>>>>> certificate to make it valid on the device.
>>>>>
>>>>>
>>>>> On Sat, May 7, 2011 at 01:48, Intrawebs<[hidden email]>    wrote:
>>>>>> I was wondering if it's possible to obfuscate MonoTouch projects?  I was
>>>>>> looking into a rather large project/game that uses some 3rd party web
>>>>>> services (private API keys etc) as well as the code itself needing to be
>>>>>> obfuscated.  Does anyone have experience with this?  I'm new to MonoDevelop
>>>>>> so I don't know whats available there that will work with obfuscating an iOS
>>>>>> app.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> --
>>>>>> View this message in context: http://monotouch.2284126.n4.nabble.com/Obfuscating-MonoTouch-Projects-tp3504648p3504648.html
>>>>>> Sent from the MonoTouch mailing list archive at Nabble.com.
>>>>>> _______________________________________________
>>>>>> MonoTouch mailing list
>>>>>> [hidden email]
>>>>>> http://lists.ximian.com/mailman/listinfo/monotouch
>>>>>>
>>>>>
>>>>> --
>>>>> Nic Wise
>>>>> t.  +44 7788 592 806 | @fastchicken | http://www.linkedin.com/in/nicwise
>>>>> b. http://www.fastchicken.co.nz/ | http://www.flickr.com/photos/nicwise
>>>>>
>>>>> mobileAgent (for FreeAgent): get your accounts in your pocket.
>>>>> http://goo.gl/IuBU
>>>>> Trip Wallet: Keep track of your budget on the go: http://goo.gl/ePhKa
>>>>> London Bike App: Find the nearest Boris Bike, and get riding! http://goo.gl/Icp2
>>>>>
>>>>
>>> _______________________________________________
>>> MonoTouch mailing list
>>> [hidden email]
>>> http://lists.ximian.com/mailman/listinfo/monotouch
>>>
>> _______________________________________________
>> MonoTouch mailing list
>> [hidden email]
>> http://lists.ximian.com/mailman/listinfo/monotouch
> _______________________________________________
> MonoTouch mailing list
> [hidden email]
> http://lists.ximian.com/mailman/listinfo/monotouch
>



--
Nic Wise
t.  +44 7788 592 806 | @fastchicken | http://www.linkedin.com/in/nicwise
b. http://www.fastchicken.co.nz/ | http://www.flickr.com/photos/nicwise

mobileAgent (for FreeAgent): get your accounts in your pocket.
http://goo.gl/IuBU
Trip Wallet: Keep track of your budget on the go: http://goo.gl/ePhKa
London Bike App: Find the nearest Boris Bike, and get riding! http://goo.gl/Icp2
_______________________________________________
MonoTouch mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/monotouch
Reply | Threaded
Open this post in threaded view
|

Re: Obfuscating MonoTouch Projects

NokNok Developer
place an "X-Source: 192.xxx.xxx.xxx" header... in the request header ad
key off that...



On 5/7/2011 3:45 PM, Nic Wise wrote:

> How do you handle people who actually DO have a proxy (eg, I do if I'm
> at work), or if an ISP/Telco has a transparent proxy or NAT router?
>
> Actually, how would you handle a NAT router? My phone's ip is 192.xxx
> but the router is 98.xxx
>
> On Sat, May 7, 2011 at 19:14, NokNok Developer<[hidden email]>  wrote:
>> what we do
>>
>> client ip: 1.2.3.4
>> proxy ip: 6.7.8.9
>>
>> client ->  service            encrypted request, key used for encryption
>> = client ipaddress/port, or simply ipaddress: (1.2.3.4)
>>
>> service gets request, attempts to decrypt request based on source IP
>> address in the http.request (6.7.8.9)
>>
>> service fails to decrypt its because their is a "man in the middle" who
>> re-originated the request (a proxy server), replies 403 forbidden
>>
>> If the communication is un-obstructed, then the packet will decrypt
>> because http.request.host = 1.2.3.4, and can be parsed. and response
>> sent using same key
>>
>> as for being a trusted client, we usually have a shared secret which is
>> built based on user information.  so in the actual request body, which
>> is encrypted with the key, we have some other information.  we respond
>> providing a "session token" to be used in every further request.
>>
>> unless the proxy in the middle knows your method of encryption and key
>> used, the data will mean nothing.
>>
>>
>>
>> On 5/7/2011 1:53 PM, Robert Jordan wrote:
>>> On 07.05.2011 17:34, NokNok Developer wrote:
>>>> Ahhh- way around that is pretty simple....
>>>>
>>>> Key from WebServer gets returned using encryption (many kinds all work),
>>>> using the REQUEST IP ADDRESS and PORT as the secret.
>>>>
>>>> Only the client receiving the data back (the true client) will be able
>>>> to decrypt it...
>>> How does the server know that REQUEST IP ADDRESS and PORT are
>>> originating from a trusted client? :)
>>>
>>> Robert
>>>
>>>>
>>>>
>>>> On 5/7/2011 9:49 AM, Nic Wise wrote:
>>>>> Oh, if I didn't mention (being I just did it now for another app)
>>>>>
>>>>> If you call a URL, even over HTTPS, and it has a private key in it,
>>>>> then it can be seen by a user if they want to. For example, I was
>>>>> looking at an app which talks to a service over HTTPS. I put in a
>>>>> proxy for my WIFI (the proxy is on my mac, using Charles -
>>>>> http://www.charlesproxy.com/ ). I added an exception in Charles for
>>>>> their server and port, and I'd already installed the Chales SSL cert
>>>>> on my phone.
>>>>>
>>>>> The request came up in the proxy in plaintext. SSL WILL NOT STOP
>>>>> PEOPLE SEEING YOUR TRAFFIC if the user has control over the client,
>>>>> which they do in this case.
>>>>>
>>>>> Just so ya know.
>>>>>
>>>>> On Sat, May 7, 2011 at 13:02, Nic Wise<[hidden email]>      wrote:
>>>>>> why do you need to obfuscate it?
>>>>>>
>>>>>> Whats on the device is object code - ARM assembly - so unless someone
>>>>>> looks into it and finds the API keys.... you should be safe. It's the
>>>>>> same as a true windows .exe (not a .NET one) - it's processor code.
>>>>>>
>>>>>> If you want to avoid this, maybe put the strings in the app encoded,
>>>>>> and decode them when the app is running. Even something as base64
>>>>>> encoding them or just reversing the string would be enough to prevent
>>>>>> somone using "strings" to get it out. If someone is somehow debugging
>>>>>> your running app on the device, there isn't a good way to stop them
>>>>>> getting it.
>>>>>>
>>>>>> Being you have to use these on the device, I don't see a good way to
>>>>>> have them 100% "secure"., unless you encrypted them with a key, and
>>>>>> then downloaded that key off your server before use (which would suck
>>>>>> if your user was underground, eg the london tube). But even then, the
>>>>>> unencrypted string is still in memory, so if someone has gone to this
>>>>>> length, they would be able to get it anyway.
>>>>>>
>>>>>> So, the chances of going from arm code back to usable c# code is
>>>>>> minimal. The .dll / .exe's in the .app bundle don't have code in them,
>>>>>> as far as I know, they just have debug info. Aside from knowing that
>>>>>> your class is called "foo" and it has a method "bar", there isn't
>>>>>> anything in there.
>>>>>>
>>>>>> Obfuscation is seldom a real answer, if you actually have the problem.
>>>>>> Most people think they have the problem.... even if they don't.
>>>>>>
>>>>>> assuming it's a private API, have you also thought about someone
>>>>>> running a packet sniffer? If it's not over HTTPS, they'll get the key
>>>>>> easily. If it IS over HTTPS, it's not too hard to do a
>>>>>> man-in-the-middle attack using something like Charles, being you have
>>>>>> control over the proxy on the client and could accept the "new"
>>>>>> certificate to make it valid on the device.
>>>>>>
>>>>>>
>>>>>> On Sat, May 7, 2011 at 01:48, Intrawebs<[hidden email]>      wrote:
>>>>>>> I was wondering if it's possible to obfuscate MonoTouch projects?  I was
>>>>>>> looking into a rather large project/game that uses some 3rd party web
>>>>>>> services (private API keys etc) as well as the code itself needing to be
>>>>>>> obfuscated.  Does anyone have experience with this?  I'm new to MonoDevelop
>>>>>>> so I don't know whats available there that will work with obfuscating an iOS
>>>>>>> app.
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> --
>>>>>>> View this message in context: http://monotouch.2284126.n4.nabble.com/Obfuscating-MonoTouch-Projects-tp3504648p3504648.html
>>>>>>> Sent from the MonoTouch mailing list archive at Nabble.com.
>>>>>>> _______________________________________________
>>>>>>> MonoTouch mailing list
>>>>>>> [hidden email]
>>>>>>> http://lists.ximian.com/mailman/listinfo/monotouch
>>>>>>>
>>>>>> --
>>>>>> Nic Wise
>>>>>> t.  +44 7788 592 806 | @fastchicken | http://www.linkedin.com/in/nicwise
>>>>>> b. http://www.fastchicken.co.nz/ | http://www.flickr.com/photos/nicwise
>>>>>>
>>>>>> mobileAgent (for FreeAgent): get your accounts in your pocket.
>>>>>> http://goo.gl/IuBU
>>>>>> Trip Wallet: Keep track of your budget on the go: http://goo.gl/ePhKa
>>>>>> London Bike App: Find the nearest Boris Bike, and get riding! http://goo.gl/Icp2
>>>>>>
>>>> _______________________________________________
>>>> MonoTouch mailing list
>>>> [hidden email]
>>>> http://lists.ximian.com/mailman/listinfo/monotouch
>>>>
>>> _______________________________________________
>>> MonoTouch mailing list
>>> [hidden email]
>>> http://lists.ximian.com/mailman/listinfo/monotouch
>> _______________________________________________
>> MonoTouch mailing list
>> [hidden email]
>> http://lists.ximian.com/mailman/listinfo/monotouch
>>
>
>
_______________________________________________
MonoTouch mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/monotouch
Reply | Threaded
Open this post in threaded view
|

Re: Obfuscating MonoTouch Projects

Intrawebs
Thanks Nick and Nok, I wasn't aware about Charles, makes SSL moot in this situation and similar.  I like the suggestions, makes sense.  Coming from a .net world where without obfuscation one can simply look at the dll and decipher how that "shared secret" is built and easily write something to build their own to spoof the server into false positives.  The game will be for WP7, iPhone and Android (I have 3 WP7 games in the marketplace so far)....it seems the solution for this on iOS will have to be completely different than WP7 as obfuscation will help with making the creation of the shared key difficult to determine and that fact that I have ARM like you mentioned to help me some on iOS.  

To make things even more difficult I also need to find a way to make sure that only one "game account" exists and can log in from the device, I don't want real people playing with more than one account at a time (think Eve Online...your subscription enables you to have only one account with one active player training his/hers skills at a time).  WP7 has a device ID and Anon ID (jailbroken WP7 devices don't have an Anon ID, so using both of these together helps).  Not sure how to go about this on iOS, especially in the context of someone registering a device, playing my game, selling the device, and the new person on that same device wanting to play as well.

All of this seems way overly complex than it needs to be, I wonder how Pocket Legends handles all this.  Thats for iPhone and Android.
Reply | Threaded
Open this post in threaded view
|

Re: Obfuscating MonoTouch Projects

Jonathan Pryor
In reply to this post by Nic Wise
On May 7, 2011, at 8:02 AM, Nic Wise wrote:
> Whats on the device is object code - ARM assembly - so unless someone
> looks into it and finds the API keys.... you should be safe. It's the
> same as a true windows .exe (not a .NET one) - it's processor code.

While true, this is not necessarily a complete answer. It's not exactly difficult to run a disassembler on ARM/x86/whatever machine code to get assembly code, then investigate the assembly to see how it works. This is fairly common to do [0], with a multitude of high-end ($$$) debuggers designed to simplify this process.

In short, native code is not 100% secure either, it's just another form of obfuscation, and can't be expected to stop those who want to spend time/resources to figure out how your app works.

I don't believe that there is a 100% safe solution here (see also Playstation 3 Linux/Wii/XBox/etc., and ~every DRM/crypto system currently in existence), but that doesn't mean it won't be "good enough" to keep most of your customers honest...

 - Jon

[0] think: debugging w/o debug symbols, which isn't too unusual for Microsoft Windows developers trying to see why an app "broke", or those bypassing game DRM)

_______________________________________________
MonoTouch mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/monotouch
Reply | Threaded
Open this post in threaded view
|

Re: Obfuscating MonoTouch Projects

Nic Wise
> While true, this is not necessarily a complete answer. It's not exactly difficult to run a disassembler on ARM/x86/whatever machine code to get assembly code, then investigate the assembly to see how it works. This is fairly common to do [0], with a multitude of high-end ($$$) debuggers designed to simplify this process.
>
> In short, native code is not 100% secure either, it's just another form of obfuscation, and can't be expected to stop those who want to spend time/resources to figure out how your app works.
>

In my opinion, and I suspect a lot of people would disagree: if
someone is going to go to this length, then they are welcome to it.
It's more effort to protect from this than it's worth.

If someone is disasm'ing c# code which has been AOT'ed into ARM, and
can read the ARM code and work out whats really going on - well, thats
a level of protection I'm unwilling to invest in.

Last time I used obfuscation (xenocode) it stopped people stealing the
app (at an app level), but it cost us maybe 10-50x the cost of "theft"
which happened before, in added support costs. Maybe we weren't doing
it right, but still: it was a big hassle for very very little return.

--
Nic Wise
t.  +44 7788 592 806 | @fastchicken | http://www.linkedin.com/in/nicwise
b. http://www.fastchicken.co.nz/ | http://www.flickr.com/photos/nicwise

mobileAgent (for FreeAgent): get your accounts in your pocket.
http://goo.gl/IuBU
Trip Wallet: Keep track of your budget on the go: http://goo.gl/ePhKa
London Bike App: Find the nearest Boris Bike, and get riding! http://goo.gl/Icp2
_______________________________________________
MonoTouch mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/monotouch
Reply | Threaded
Open this post in threaded view
|

Re: Obfuscating MonoTouch Projects

Jonathan Pryor
On May 9, 2011, at 9:47 AM, Nic Wise wrote:
>> While true, this is not necessarily a complete answer. It's not exactly difficult to run a disassembler on ARM/x86/whatever machine code to get assembly code, then investigate the assembly to see how it works. This is fairly common to do [0], with a multitude of high-end ($$$) debuggers designed to simplify this process.
>>
>> In short, native code is not 100% secure either, it's just another form of obfuscation, and can't be expected to stop those who want to spend time/resources to figure out how your app works.
>
> In my opinion, and I suspect a lot of people would disagree: if
> someone is going to go to this length, then they are welcome to it.
> It's more effort to protect from this than it's worth.

That doesn't sound like disagreement. That sounds like agreement and acceptance.

You _cannot_ protect your code 100%, and additional protections have additional costs as well:

> Last time I used obfuscation (xenocode) it stopped people stealing the
> app (at an app level), but it cost us maybe 10-50x the cost of "theft"
> which happened before, in added support costs. Maybe we weren't doing
> it right, but still: it was a big hassle for very very little return.

Exactly. Thus, you've determined that 100% security is a bad investment, and have opted to instead accept some "theft" in an effort to avoid the costs of the copy protection. This is sane, and I can't argue.

 - Jon

_______________________________________________
MonoTouch mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/monotouch
Reply | Threaded
Open this post in threaded view
|

Re: Obfuscating MonoTouch Projects

Nic Wise
> That doesn't sound like disagreement. That sounds like agreement and acceptance.
>
> You _cannot_ protect your code 100%, and additional protections have additional costs as well:
>

Yup, very true

> Exactly. Thus, you've determined that 100% security is a bad investment, and have opted to instead accept some "theft" in an effort to avoid the costs of the copy protection. This is sane, and I can't argue.
>

Oddly enough, we only had one case beforehand, and none after.
Management just paniced.


--
Nic Wise
t.  +44 7788 592 806 | @fastchicken | http://www.linkedin.com/in/nicwise
b. http://www.fastchicken.co.nz/ | http://www.flickr.com/photos/nicwise

mobileAgent (for FreeAgent): get your accounts in your pocket.
http://goo.gl/IuBU
Trip Wallet: Keep track of your budget on the go: http://goo.gl/ePhKa
London Bike App: Find the nearest Boris Bike, and get riding! http://goo.gl/Icp2
_______________________________________________
MonoTouch mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/monotouch