There IS NO REINSTALLING ROOTKIT!!!!
Don't you get it? It is simply WRITE PROTECTED with REDIRECTED WRITES!
[DISCUSSION][SOLVED] ROOTING G2 Vision T-mobile
- Thread starter tubaking182
- Start date
- Status
There IS NO REINSTALLING ROOTKIT!!!!
Don't you get it? It is simply WRITE PROTECTED with REDIRECTED WRITES!
Ahh, makes sense, too bad. So I was gonna pm u as to not clog this theard with other info to ask how I can fix this so ican have flash back, but then decided it might be good to have in here since others might have done something similar...so what should I do? Thanks
That doesn't mean rooting is impossible. Someone will find a way to trick it into believing that nothing has been changed.
Sent from my SAMSUNG-SGH-I897 using XDA App
There's a 2Gb version of this chip, the SDIN5D2-2G. Another option is that it's the same chip, but being marketed differently so that people aren't screaming about their missing 2 gigs. After all, it's not like T-Mobile is known for their savvy marketing skills.
I didn't read all 49 pages, but i understood by the title what is the meaning if this topic: if we spoof the root or the custom rom?
Hey, reminds me of my ex wife!
Keep going team, I know that XDA will crack the G2 egg wide open
There's a 2Gb version of this chip, the SDIN5D2-2G. Another option is that it's the same chip, but being marketed differently so that people aren't screaming about their missing 2 gigs. After all, it's not like T-Mobile is known for their savvy marketing skills.
Exactly what I'm saying! It's reasonable to think that the Z has the 2GB chip and doesn't participate in these shenanigans and the G2 has the 4GB chip to make room for the extra partition. The end result is the same amount of user-accessible space.
Ah ok, i understand.
So what happens when the phone is running normally and it tries to do a write to a directory within the read-only system image? Does the write simply get re-directed to the remote location. If you then go to read that, how does the system know its in the remote location and not in the system image partition. What makes it different?
( and why would a write be allowed in the first place if its a read-only partition ? )
I don't have my G2 yet so I can't exactly test this, but has anyone tried patching the running kernel, ala ksplice?
Since we can get temp root, and its the software, the kernel thats doing the redirects writes, can we objdump the kernel, dig in a little deeper to where its happening, and patch the kernel while its running to disable that functionality?
Just throwing ideas out there ..
Since we can get temp root, and its the software, the kernel thats doing the redirects writes, can we objdump the kernel, dig in a little deeper to where its happening, and patch the kernel while its running to disable that functionality?
Just throwing ideas out there ..
if we will spoof the custom rom in the way that system will recognize it as stock rom, will it work?
that requires a signature for the rom which is part of the whole problem. we dont have one to use to overwrite what's on that partition.
I'm a new Android user and the G2 is my first Android device (couldn't be happier) but i just wanna say a big "THANK YOU" to those that are working hard to ROOT the damn thing!
Your efforts are appreciated by all G2 lovers!
Your efforts are appreciated by all G2 lovers!
So let me see if I have this straight.
When you make changes, any change that would have gone to the actual (write-protected) location gets redirected to a remote location.
When you reboot the phone, that remote location gets wiped and the phone gets the original data from the write-protected location?
As someone pointed out, isn't that a LOT of writes to the NAND just to ensure that the phone retains the original data?
It seems that the remote location is a cache of sorts. Perhaps this is what is happening (just speculation):
1) Phone starts up
2) Phone copies data from write-protected location to rmt_storage
3) User makes changes which are actually made in the rmt_storage area and not the write-protected area.
4) User reboots.
5) Go to 1.
Do I have it straight so far?
When you make changes, any change that would have gone to the actual (write-protected) location gets redirected to a remote location.
When you reboot the phone, that remote location gets wiped and the phone gets the original data from the write-protected location?
As someone pointed out, isn't that a LOT of writes to the NAND just to ensure that the phone retains the original data?
It seems that the remote location is a cache of sorts. Perhaps this is what is happening (just speculation):
1) Phone starts up
2) Phone copies data from write-protected location to rmt_storage
3) User makes changes which are actually made in the rmt_storage area and not the write-protected area.
4) User reboots.
5) Go to 1.
Do I have it straight so far?
One thing noone has directly pointed out is that rooting this and stopping the constant writes to the inand should make the device last longer and possibly be more stable.
One thing I do remember is that several types of volatile memory can only be written to a "set" number of times before they die. If that is the case here then inand dead = check failure and then device = paperweight.(possibly)
Correct me if I am wrong but tricking the system into thinking this might be a loophole as they may have set up some sort of redundant subroutine to handle this exception. Then again, if it sounds to good ....
One thing I do remember is that several types of volatile memory can only be written to a "set" number of times before they die. If that is the case here then inand dead = check failure and then device = paperweight.(possibly)
Correct me if I am wrong but tricking the system into thinking this might be a loophole as they may have set up some sort of redundant subroutine to handle this exception. Then again, if it sounds to good ....
This is why I was thinking of the ksplice method.
Get temporary root, patch the running, already verified and signed kernel, and disable the rewriting of changes to the other partition.
With the rewrites disabled, you can now write to the real partition and changes there should now hold after reboots.
That is unless there is some hardware doing the rewrites, but so far I've only heard reference to it being a software problem, which once you have root you can fix that?
Yup. However, a quick look around the web seems to imply that depending on the type of NAND, it can be as low as 5K write cycles or as much as 100K write cycles before you start to question the integrity of the memory block.
Even then, some controller either keep aside space to use as a replacement for bad blocks ( Bad block management ), or they monitor the number of times a block has been written and then dynamically re-assign address spaces to different physical blocks of memory ( wear levelling )
I'd imagine that the stuff in phones would be at the higher end of the write cycles .... so that would equate to a lot of re-boots.
I read a few of the earlier posts and I'm wondering. Has anyone been able to get an image of mmcblk0p13 and mmcblk0p14?
Maybe first we can get an image of both on start up and store them in mmcblk0p13.startup.img and mmcblk0p14.startup.img. Then make some changes, and get an image again. This time, storing them in mmcblk0p13.changed.img and mmcblk0p14.changed.img. Finally, reboot the image and get another set of images, this time dumping the image to mmcblk0p13.after_reboot.img and mmcblk0p14.after_reboot.img.
If rmt_storage is what we all think it might be, examining the dumps for differences may give us some clues? I will see if I can do this when I get home tonight.
Thoughts?
Maybe first we can get an image of both on start up and store them in mmcblk0p13.startup.img and mmcblk0p14.startup.img. Then make some changes, and get an image again. This time, storing them in mmcblk0p13.changed.img and mmcblk0p14.changed.img. Finally, reboot the image and get another set of images, this time dumping the image to mmcblk0p13.after_reboot.img and mmcblk0p14.after_reboot.img.
If rmt_storage is what we all think it might be, examining the dumps for differences may give us some clues? I will see if I can do this when I get home tonight.
Thoughts?
if those are the temporary storage partitions then when you reboot they will simply disappear so will you be able to get a logcat of the phone overwriting those images or what?
- Status
Similar threads
Top Liked Posts
-
There are no posts matching your filters.
-
1Has anyone considered the possibility of a system.img that's being unpacked on boot? The root filesystem on our phones is unpacked from boot.img every time the phone is booted which is why there's trouble with the SGS and people rooting it by placing the su binary in /sbin...
Back on topic, the root filesystem can be changed at runtime, but reboot, and it all goes away. That's what sounds like is going on with the G2, but I don't have one to mess with.
