Exploitee.rs

Hey everyone,

We've decided that since we are now fighting a future revue update which will fix this functionality we will release dan rosenberg's revue exploit "as is" with a giant warning label. Essentially this root is un-stable and needs a form of persistence to continue beyond a reboot. The problem is that all the partitions that would allow a suid binary are either signed, which means we are unable to change without logitech's private key, or are marked nosuid. This creates a hurdle as there is no way for us to leave a binary that will grant us root when we need it without actually needing to re-run the exploit. So you may ask why not just run the exploit every time? The reason we don't want to do this is that when running the exploit the box becomes unstable until it is rebooted. So we are left without a way to modify the system files that would allow us to unlock the box and with an exploit that creates an unstable environment.

Along with the root are 2 other scripts, one which disables code signing for loaded modules (codesign) and one of which that marks the system partitions that are RO (Read Only) as RW (Read/Writeable) which is known as (blockwrite). Using these additional files is not recommended unless you are working on creating a module or looking to write to a partition that isn't signed. This is probably not the case for 99.9% of you.

So there it is, that's why the release of the exploit has been delayed since we got back. We've been working on some ideas to get around the signed partitions most of which may be riskier than most of you would probably want to go through, but we will continue to do so until we either run out of ideas or make a breakthrough. Regardless of which we know its a race until the Logitech update comes out so keep checking back here, our wiki, and our twitter (@gtvhacker) for updates. If all else fails we will let people know when we hear of updates rolling out and users can disconnect their revues from the internet until a work-around is found.

Link to exploit on wiki
http://gtvhacker.com/index.php/Revue_software_root

Thanks,
Zenofex

Like I said.... Don't hold your breath!

zenofex wrote:Hey everyone,

We've decided that since we are now fighting a future revue update which will fix this functionality we will release dan rosenberg's revue exploit "as is" with a giant warning label.....

Did they say they were on the ball with fixing this or did I miss something?

zenofex wrote:We've been working on some ideas to get around the signed partitions most of which may be riskier than most of you would probably want to go through, but we will continue to do so until we either run out of ideas or make a breakthrough.

Which are the ideas? I have some technical knowledge about such things and I'm very interested, because I don't have a idea.

I think I've found a way to permanently root Logitech Revue.
After you got root-access using nandpwn, execute this two commands: This replaces a folder on the data-partition with a symlink to /dev/mem.
Because "/data/av_timing_logs" is chmod'd to 777 inside init.rc, you'll get full access to /dev/mem even without root-privileges.
This way it should be possible to write another root-exploit which doesn't make the system unstable.

M1cha wrote:I think I've found a way to permanently root Logitech Revue.
After you got root-access using nandpwn, execute this two commands:

Code: Select all

rm -R /data/av_timing_logs
ln -s /dev/mem /data/av_timing_logs

This replaces a folder on the data-partition with a symlink to /dev/mem.
Because "/data/av_timing_logs" is chmod'd to 777 inside init.rc, you'll get full access to /dev/mem even without root-privileges.
This way it should be possible to write another root-exploit which doesn't make the system unstable.

M1cha, it's a great idea for persistence, however it does still take us back to square one, at least on this update.

This may prove to be very useful if another update comes out, namely if the permissions of devmem are changed. However right now we don't have another exploit apart from nandpwn, so nandpwn would still need to be run against devmem - which would make the symlink on this firmware version not too relevant.

Now, this would be great if we could leverage some sort of execution, but we can't. Whatever we can write to (data, really) is mounted nosuid, so we can't even drop a nice binary to escalate privelages.

So we can get temp root, and run codesign to load modules. Would the following be useful at that point to come up with a more permanent solution? http://www.xda-developers.com/android/l ... snapshots/

cj_000 wrote:M1cha, it's a great idea for persistence, however it does still take us back to square one, at least on this update.

This may prove to be very useful if another update comes out, namely if the permissions of devmem are changed. However right now we don't have another exploit apart from nandpwn, so nandpwn would still need to be run against devmem - which would make the symlink on this firmware version not too relevant.

Now, this would be great if we could leverage some sort of execution, but we can't. Whatever we can write to (data, really) is mounted nosuid, so we can't even drop a nice binary to escalate privelages.

Right, and I tried to access /dev/mem, but still with 777 the kernel denies user-access.
Any other devnodes which would be useful?

And: just to archive:
- we can chmod anything to 777 with "/data/av_timing_logs"
- we can delete any file with "/data/debug/dumps"
- we can create directories at any location which is mounted rw

All that during boot-process through init-script hooks.
But the bad thing is that all this can't help us to execute anything(as root).

Since the root is not persistent, and I understand the goal is to stay on 3.1, my question is, do we have anyway to flash back to 2.1 Rooted for now. Just too keep logitech from locking us out of the boxes, until the 3.1 problem can be figured out?

I have another idea for permanent root and I'll try it soon:
We could place a binary somewhere like on /data-partition.
Then set the owner to root and give him the +s flag so it will be always executed as root.

If we do that with a binary like busybox we should be able todo everything as root without exploits.