Quick technical question...

I presume this is to prevent the malware from making an infected binary called profile, which is the Trojan itself?

If so, what's to stop a future attack from using a differently named, or self mutating, file?

Just curious as to how effective this is, given the fact we are talking about root exploits, which can be programmed to overcome most limitations like this.

Or am I missing something here? (reading from my phone so I could have missed a bit of something)

out curiosity how do you know who the publisher of a certain app is? is it the name the appears right under the app in the market place?

the reason i ask is because i have chess for android and pewpew but neither say anything about Myournet being the publisher.

Yes the name.under the apologize is the developer

Originally Posted by pxldtz

out curiosity how do you know who the publisher of a certain app is? is it the name the appears right under the app in the market place?

the reason i ask is because i have chess for android and pewpew but neither say anything about Myournet being the publisher.

Sent From My Evo Killer!

Originally Posted by pulser_g2

Quick technical question...

I presume this is to prevent the malware from making an infected binary called profile, which is the Trojan itself?

If so, what's to stop a future attack from using a differently named, or self mutating, file?

Just curious as to how effective this is, given the fact we are talking about root exploits, which can be programmed to overcome most limitations like this.

Or am I missing something here? (reading from my phone so I could have missed a bit of something)

I'm fairly sure this particular fix is just for this particular strain. I highly doubt it will thwart any pre-existing, alternate malware nor any futures.

Can my phone (HTC Desire Z with 1.82 firmware) be infected?
I don't have root and even with the psneuter temproot method I cannot create the blank profile file.
Thanks

Niggling technicality:

Using 'adb shell' or terminal emulator (should work on any phone)

Using 'adb shell' or terminal emulator (should work on any ROOTED phone)

Isn't that right? Can't "su" without rooting. (Can you "su" from adb shell without rooting?)

(In fact, as an old Unix guy, I'm nervous about this whole "su with null password" business in Android. Seems to me that exploits like this could be prevented by installing a root password.)

Originally Posted by fsc137

Niggling technicality:

Using 'adb shell' or terminal emulator (should work on any phone)

Using 'adb shell' or terminal emulator (should work on any ROOTED phone)

Isn't that right? Can't "su" without rooting. (Can you "su" from adb shell without rooting?)

(In fact, as an old Unix guy, I'm nervous about this whole "su with null password" business in Android. Seems to me that exploits like this could be prevented by installing a root password.)

Most devices I know of can open adb shell after enabling usb debugging. No su or remount unless ro.secure=0.

You cannot su from adb shell without root, as you need root to reflash boot.img to set ro.secure=0.

Root password wouldn't help IMHO, as the suid could still be set, AND... root exploit grants you root, regardless of the length of said password.

It seems to me that the whole "outside developers" idea is, at present, based on the existence of a root exploit, so if all the root exploits were fixed, these wonderful ROMs would not be available.

A better way to go, in the long term, would be to fix the root exploits and then have the outside developer software loaded (at least initially) through Odin. That would be more secure, requiring that someone actually hold down "1" while rebooting, rather than allowing root to ever be achieved through software.

Originally Posted by fsc137

Niggling technicality:

Using 'adb shell' or terminal emulator (should work on any phone)

Using 'adb shell' or terminal emulator (should work on any ROOTED phone)

Isn't that right? Can't "su" without rooting. (Can you "su" from adb shell without rooting?)

(In fact, as an old Unix guy, I'm nervous about this whole "su with null password" business in Android. Seems to me that exploits like this could be prevented by installing a root password.)

You're right! I have updated the OP to clarify that. Thanks.

Originally Posted by pulser_g2

Most devices I know of can open adb shell after enabling usb debugging. No su or remount unless ro.secure=0.

You cannot su from adb shell without root, as you need root to reflash boot.img to set ro.secure=0.

Root password wouldn't help IMHO, as the suid could still be set, AND... root exploit grants you root, regardless of the length of said password.

root permissions do not get called from any password based authentication on android

Originally Posted by fsc137

It seems to me that the whole "outside developers" idea is, at present, based on the existence of a root exploit, so if all the root exploits were fixed, these wonderful ROMs would not be available.

A better way to go, in the long term, would be to fix the root exploits and then have the outside developer software loaded (at least initially) through Odin. That would be more secure, requiring that someone actually hold down "1" while rebooting, rather than allowing root to ever be achieved through software.

Correct again! Developers could easily extract, modify, inject, and release a hacked up initramfs with root built-in an Odin .tar (or any stock image flashing program). On the same note though not much is going to prevent a malicious apk from reflashing the kernel of unsuspecting users and then on reboot have a go at the info they want. I guess my point is anything is possible given the time and determination.