Root i'll help find a root method if...

[jjfriede]

Wow!

Did you verify the immutable bit was set (i.e., via lsattr)?

Hmm, there's some really weird/wild stuff going on there...something's "watching" the /system partition? (sounds kind of extreme for a manufacturer that seems doesn't usually go this far...)

:dontknow:

Here i tried it again:

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Program Files (x86)\Minimal ADB and Fastboot>adb shell
shell@android:/ $ su
su
127|shell@android:/ # busybox lsattr /system/xbin/su
busybox lsattr /system/xbin/su
-----i--A---- /system/xbin/su
shell@android:/ #

It looks like it is set. this time, the superuser app shows that the binary is correctly installed but i couldn't get the root version of greenify to work so i went back to adb and tried running the su command to make sure the binary command was there and i got this:

C:\Program Files (x86)\Minimal ADB and Fastboot>adb shell
shell@android:/ $ su
su
Segmentation fault
139|shell@android:/ $

This 'Segmentation fault' error has happened to me before and after i remounted /system as read only the binary disappeared again. Even after applying that attribute, the binary seems to be behaving the same way as it was before when we were trying to achieve root.

 

[scary alien]

How about after a reboot?

Is it still there (and is it still secured as "-rwsr-sr-x" (06755))?

 

[jjfriede]

How about after a reboot?

Is it still there (and is it still secured as "-rwsr-sr-x" (06755))?

C:\Program Files (x86)\Minimal ADB and Fastboot>adb shell
shell@android:/ $ ls -l /system/xbin
ls -l /system/xbin
-rwxr-xr-x root shell 55664 2008-08-01 07:00 dexdump
shell@android:/ $

Nope, it's not there. You said that if it still didn't survive with the i attribute then it must mean that it is a ghost partition?

 

[scary alien]

C:\Program Files (x86)\Minimal ADB and Fastboot>adb shell
shell@android:/ $ ls -l /system/xbin
ls -l /system/xbin
-rwxr-xr-x root shell 55664 2008-08-01 07:00 dexdump
shell@android:/ $

Nope, it's not there. You said that if it still didn't survive with the i attribute then it must mean that it is a ghost partition?

Or some other shennanigans...(I think it was stayboogy that first coined that term/idea here to describe what's going on). I've never seen this done before :dontknow:.

jjfriede, I think your tests pretty much confirm that concept (i.e., /system is loaded "virtually" in the sense that changes to it are not permanent, implying that the true source is elsewhere).

Other/side note: have you looked at the logcat and/or kernel messages (i.e., especially when the "weird" behavior is going on)? Can you fire-up a separate adb window on your PC and capture the messages from either / both of those sources and see if you can see any funny business going on with regard to /system?

 

[jjfriede]

Or some other shennanigans...(I think it was stayboogy that first coined that term/idea here to describe what's going on). I've never seen this done before :dontknow:.

jjfriede, I think your tests pretty much confirm that concept (i.e., /system is loaded "virtually" in the sense that changes to it are not permanent, implying that the true source is elsewhere).

Other/side note: have you looked at the logcat and/or kernel messages (i.e., especially when the "weird" behavior is going on)? Can you fire-up a separate adb window on your PC and capture the messages from either / both of those sources and see if you can see any funny business going on with regard to /system?

Glad to know at least something is confirmed. I think that is pretty ridiculous for them to waste so much time securing a budget phone.

Also, is there any way i can filter the output of these messages? The reports are full of battery and signal info constantly being reported.

 

[jjfriede]

After "rooting" i got this output from dmesg:

<6>[11-11 04:01:58.399] [2054: busybox]EXT4-fs (mmcblk0p19): re-mounted. Opts: data=ordered

This is the only interesting line i could pick out from the massive amounts of seemingly useless information. I'm not sure if this remount is because of the remount as rw I used to push the su binary or a remount having to do with restoring the original contents to /system

 

[scary alien]

Also, is there any way i can filter the output of these messages? The reports are full of battery and signal info constantly being reported.

LOL, yeah, there's lots and lots of things recorded in the logcat just by itself...

I'd use the grep command to search for certain strings like "/system" and/or it's device name (I don't recall it at the moment)--not sure you know Linux/Unix or Cygwin, etc. to use that.

Be cautious about posting-up a full logcat on an open board since there's often personal or identifying info recorded in there. I don't think the kernel logs usually record things like that, but it's been a while since I've scanned

There's no guarantee of actually finding a smoking gun since it certainly could be a timing thing (i.e., catching something that is recorded in the logs) or if there's anything being recorded at all.

Let me know if you want some help scanning through them.

 

[scary alien]

<6>[11-11 04:01:58.399] [2054: busybox]EXT4-fs (mmcblk0p19): re-mounted. Opts: data=ordered

That looks like it's from you using busybox to remount /system in read-write mode (i.e., Android wouldn't be using busybox) so this is probably just from your actions.

 

[jjfriede]

That looks like it's from you using busybox to remount /system in read-write mode (i.e., Android wouldn't be using busybox) so this is probably just from your actions.

I can't seem to find anything related to the system partition other than my own actions. One more thing is that simply remounting /system completely restores the partition.

 

[jjfriede]

Here are some outputs of dmesg. Thank you for the warning about the possibility of personal info being stored in the logs but i didn't see any so i think i'm safe :thumbup:

I believe there are some remounts of /system (aka mmcblk0p19) that i did not initiate myself. The only other partitions i find mentioned were mmcblk0p10 which i think is /persist and there is mmcblk0p22 which is for the user data.

It was too long to post in plain text so i uploaded it as a text document instead.

 

[mrfeh]

I tried it and the binary still went away after about 5 min before i could install supersu without even rebooting my phone. I wonder what happened there.

I've witnessed the same behavior (I think it's also mentioned on a previous page).

I obtained root as I mentioned above. I then did something else and just left the phone be for a while (still logged in as root)...when I came back I had been kicked out of the rooted shell and the su binary/link was gone.

So, it appears there is some kind of watchdog process that remounts /system periodically.

 

[2BitGary]

First off, I want to thank everyone for not giving up on this!
Second, and forgive me if this is noobish...could it be an app that is causing root to not stick?
One of the things I do with my devices is disable crap I don't need, on the zte there were some apps that I couldn't. Wiper, mipower,milauncher and the task manager to name a few. Since jjfriede said it disappeared even without rebooting makes me think this.

Looking forward to rooting this thing.

Many thanks.

 

[werewolfboy]

The milauncher you need for the home screen to run. Just to let you know.

 

[2BitGary]

The milauncher you need for the home screen to run. Just to let you know.

Correct, but I've replaced it with smart launcher, but still can't disable it and when i did use it, it would never remember how i had it set up, which is why i replaced it. I would suspect the wiper app to be the culprit though.

 

[miltblue]

First let me say how much I've learned about Android devices and app development just from reading the posts in this thread. You guys are good! There is no doubt that you will get to the root of this problem. Pun intended!!
It took me a while to get up to speed on all things Android,ADB, Java Developement and the tools used like fastboot and busybox. After I got my Ubuntu box up and running with everything installed I thought I'd give trying to root by Valet a try. By Valet has the heartbleed patch applied. I studied Unkn0wn0nes Root my Valet apk until I thought I had a pretty good understanding of it and then tried going thru all the steps manually using ADB and the ADB shell. I Had installed SuperSU and Root Checker. After I finished the Root MY Valet process manually I fired up SuperSU. IT opened and told me that the binary needed to be updated. I hit the update button several times but the response was always update failed. I then checked for root with root checker, and like you guys have said it showed that root was not properly installed. But SuperSU kept showing update the binary. I rebooted to see if SuperSU would still see the binary after that, and the binary was gone. I tried the process again to see if I could still push the binary and it failed. Haven't been able to push it again and I made several changes to the Root MY valet process in those tries. This proves two things 1. The binary can be pushed to /system/xbin with the heartbleed patch installed. 2 Whatever ZTE is using to watch the system partition guards against you doing again after it reverts the changes after the heartbleed patch is applied. Keep up the good work guys. I operate on the theory that no machine is smarter than man. Got to take a little more time to get in to dumping and reading images, but I shall return.

 

[jjfriede]

First let me say how much I've learned about Android devices and app development just from reading the posts in this thread. You guys are good! There is no doubt that you will get to the root of this problem. Pun intended!!
It took me a while to get up to speed on all things Android,ADB, Java Developement and the tools used like fastboot and busybox. After I got my Ubuntu box up and running with everything installed I thought I'd give trying to root by Valet a try. By Valet has the heartbleed patch applied. I studied Unkn0wn0nes Root my Valet apk until I thought I had a pretty good understanding of it and then tried going thru all the steps manually using ADB and the ADB shell. I Had installed SuperSU and Root Checker. After I finished the Root MY Valet process manually I fired up SuperSU. IT opened and told me that the binary needed to be updated. I hit the update button several times but the response was always update failed. I then checked for root with root checker, and like you guys have said it showed that root was not properly installed. But SuperSU kept showing update the binary. I rebooted to see if SuperSU would still see the binary after that, and the binary was gone. I tried the process again to see if I could still push the binary and it failed. Haven't been able to push it again and I made several changes to the Root MY valet process in those tries. This proves two things 1. The binary can be pushed to /system/xbin with the heartbleed patch installed. 2 Whatever ZTE is using to watch the system partition guards against you doing again after it reverts the changes after the heartbleed patch is applied. Keep up the good work guys. I operate on the theory that no machine is smarter than man. Got to take a little more time to get in to dumping and reading images, but I shall return.

As of now I don't think the apk is going to do much for us but how we might get this rooted is by modifying a kernel setting in the boot image to allow native adb root. Although when it was tested before by mainefungi, his phone was rooted, but it was also the first time any permanent changes were made to system files. Also, there was a mistake in packing the boot image that was flashed so if it is done right there is a chance that we'll have permanent access to a native adb root session which would root or at least give us the upper hand in rooting the phone.

And you are correct, the method we're using for temp root still works after the heartbleed update, but stayboogy said that after the update, the boot image was changed to an irregular format that might interfere with modifying that kernel setting within the image. that would make it hard to extract for the way he's trying to root the phone. However, i went through a couple boot-image pack/unpacking tools and some failed on the updated boot image but i also found one that worked so i repacked a boot image with the modified kernel setting (ro.secure 0) and it is possible that if i flashed this to my phone, i could gain adb root but this is the first time I've ever messed with boot images so I'm not prepared to try it on my phone because i do not have any backup phone.

Also, I have dumped about every partition to my computer and I could open some but not others. I was hoping to find a copy of the files on the /system partition since we're 99% sure now that the /system partition is being "ghosted" or something of that sort. i couldn't find anything though and i couldn't find a way to view all of the disk images. The only ones I could view was a partition with the processor drivers on it and the "persist partition." Even if we get root through adb from flashing the boot image, we still might have to find out what's up with this crazy /system partition.

Anyways right now were waiting for stayboogy to post his modified boot.img for the old firmware (before the heartbleed fix) and see how far that goes.

 

[miltblue]

I've downloaded a few boot image tools. I'm going to work on using them tonight and the near future. Also have to get an idea of what I'll be looking at and how to interpret it. Might take me a day or two. I have my old LG Tracfone for a backup, so that's not a problem. I'm not so sure that they're using a ghost partition because some posts say that the binary disappears from the /system/xbin folder with the phone just sitting. To me that would indicates that something is checking the system partition for changes. Periodically and before writing the recovery at shutdown and erasing any changes. It could be running from a ghost partition though if there is one. I'm still in learning mode here, but I've been doing this since going to work for IBM in 1977. The most important thing I've learned is these machines can't think outside their box, but we can. Thanks to you Mfreh, Stayboogie, Unkn0wn0ne, scary alien and all the other posters for showing me where to look and what I should be studying. WE will win and we're close.

 

[scary alien]

@jjfriede,

Finally had a chance to look more closely at the dmesg (kernel) log greps you posted last night (sorry I crashed before being able to look at them ).

Anyway, I noticed from your greps that the your busybox mount of /system (at 04:48:11) includes the "Opts" of "data=ordered".

Now, bear with me and keep in mind that I am by no/any means an expert in ext4 filesystems, mounting, etc., but this made me wonder about what the "data=ordered" mount option--and other mount options and differences that the init.target.rc script does at boot time (and apparently, later) do.

I found a reference that says:

ordered

This is the default mode. All data is forced directly
out to the main file system prior to its metadata being
committed to the journal.​

​

This made me question if the issue that you guys are seeing is not that the /system partition is being "ghost" mounted, but is simply that the changes made while that partition was re-mounted in read-write mode are simply being discarded--i.e., the metadata is NOT being committed to the journal.

This is not necessarily because your busybox mount is doing the (default) behavior of setting "data=ordered" (as the kernel log clearly shows), but possibly because of the differences between that mount command and the subsequent one that shows-up at 04:59:46 (automatically done because the system (Android) sees / detects that /system's mount mode has changed and he needs to re-mount it back to what was originally done in the init script.

The other obvious difference between your busybox mount command what is done by the init.target.rc script is the "barrier=1" switch says this:

barrier=0 / barrier=1 / barrier / nobarrier

This enables/disables the use of write barriers in the jbd code.
barrier=0 disables, barrier=1 enables. This also requires an IO
stack which can support barriers, and if jbd gets an error on a
barrier write, it will disable again with a warning. Write bar-
riers enforce proper on-disk ordering of journal commits, making
volatile disk write caches safe to use, at some performance
penalty. If your disks are battery-backed in one way or
another, disabling barriers may safely improve performance. The
mount options "barrier" and "nobarrier" can also be used to
enable or disable barriers, for consistency with other ext4
mount options.​

Which seems to be a performance setting when barrier=0 (the setting from your busybox r/w remount since that option is omitted?) vs. the "safe" (write stuff to disk safely) mode of barrier=1 [note: this is purely my interpretation of the above--I may be all wet here ].

Anyway, perhaps a different remount command (and subsequent sync?) would be enough to truly get your changes (install the su binary) to "stick" to the /system partition (i.e., with barrier=1)?

:dontknow:

 

[miltblue]

Though I have no Idea what you are talking about my sense of logic tells me you could very be on to something good.

 

[jjfriede]

@jjfriede,

Finally had a chance to look more closely at the dmesg (kernel) log greps you posted last night (sorry I crashed before being able to look at them ).

Anyway, I noticed from your greps that the your busybox mount of /system (at 04:48:11) includes the "Opts" of "data=ordered".

Now, bear with me and keep in mind that I am by no/any means an expert in ext4 filesystems, mounting, etc., but this made me wonder about what the "data=ordered" mount option--and other mount options and differences that the init.target.rc script does at boot time (and apparently, later) do.

I found a reference that says:

ordered

This is the default mode. All data is forced directly
out to the main file system prior to its metadata being
committed to the journal.​

​

This made me question if the issue that you guys are seeing is not that the /system partition is being "ghost" mounted, but is simply that the changes made while that partition was re-mounted in read-write mode are simply being discarded--i.e., the metadata is NOT being committed to the journal.

This is not necessarily because your busybox mount is doing the (default) behavior of setting "data=ordered" (as the kernel log clearly shows), but possibly because of the differences between that mount command and the subsequent one that shows-up at 04:59:46 (automatically done because the system (Android) sees / detects that /system's mount mode has changed and he needs to re-mount it back to what was originally done in the init script.

The other obvious difference between your busybox mount command what is done by the init.target.rc script is the "barrier=1" switch says this:

barrier=0 / barrier=1 / barrier / nobarrier

This enables/disables the use of write barriers in the jbd code.
barrier=0 disables, barrier=1 enables. This also requires an IO
stack which can support barriers, and if jbd gets an error on a
barrier write, it will disable again with a warning. Write bar-
riers enforce proper on-disk ordering of journal commits, making
volatile disk write caches safe to use, at some performance
penalty. If your disks are battery-backed in one way or
another, disabling barriers may safely improve performance. The
mount options "barrier" and "nobarrier" can also be used to
enable or disable barriers, for consistency with other ext4
mount options.​

Which seems to be a performance setting when barrier=0 (the setting from your busybox r/w remount since that option is omitted?) vs. the "safe" (write stuff to disk safely) mode of barrier=1 [note: this is purely my interpretation of the above--I may be all wet here ].

Anyway, perhaps a different remount command (and subsequent sync?) would be enough to truly get your changes (install the su binary) to "stick" to the /system partition (i.e., with barrier=1)?

:dontknow:

haha don't worry about it. What you're saying about the data never truly being written to the system partition sounds like something stayboogy was saying before. That would make sense given the behavior we're seeing.

You're right that the original command used by the init.target.rc script specifies the barrier=1 option: wait ext4 /dev/block/platform/msm_sdcc.3/by-num/p19
mount ext4 /dev/block/mmcblk0p19 /system ro barrier=1



So i've been trying different commands to mount /system and i've tried

busybox mount -o rw,barrier=1,remount /system
busybox mount -o rw,data=ordered,remount /system
busybox mount -o rw,barrier=1,data=ordered,remount /system

but none of these commands seem to change the behavior we've been seeing. Am i not doing something right?

Also, you probably read it in a previous post, but does an "input/output" error when trying to copy the su binary mean anything specific that could give us some insight to what is going on?

Spoiler

C:\Program Files (x86)\Minimal ADB and Fastboot>adb shell
shell@android:/ $ /data/local/tmp/./roothandler
/data/local/tmp/./roothandler
ro.build.product=seanplus
ro.build.id=JRO03C
search kallsyms...
1 2 3 4 5 6 7 8 9 10 11 12
(kallsyms_addresses=c066fba0)
(kallsyms_num_syms=00010e24)
kernel dump...
1 2 3 4 5 6 7 8 9

prepare_kernel_cred=c00b14c8
commit_creds=c00b113c
ptmx_fops=c09f5698

Succeeded in getroot!

Entering character mode
Escape character is '^]'.


shell@android:/ # busybox su
busybox su
su: unknown user root
1|shell@android:/ # busybox mount -o rw,data=ordered,barrier=1,remount /system
red,barrier=1,remount /system <
127|shell@android:/ # busybox cp /data/local/tmp/su /system/xbin
busybox cp /data/local/tmp/su /system/xbin
cp: can't create '/system/xbin/su': Input/output error
1|shell@android:/ # mount
mount
rootfs / rootfs ro,relatime 0 0
tmpfs /dev tmpfs rw,nosuid,relatime,mode=755 0 0
devpts /dev/pts devpts rw,relatime,mode=600 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
none /acct cgroup rw,relatime,cpuacct 0 0
tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0
tmpfs /mnt/obb tmpfs rw,relatime,mode=755,gid=1000 0 0
none /dev/cpuctl cgroup rw,relatime,cpu 0 0
/dev/block/mmcblk0p19 /system ext4 ro,relatime,data=ordered 0 0
/dev/block/platform/msm_sdcc.3/by-num/p22 /data ext4 rw,nosuid,nodev,relatime,no
auto_da_alloc,data=ordered 0 0
/dev/block/mmcblk0p10 /persist ext4 rw,nosuid,nodev,relatime,data=ordered 0 0
/dev/block/mmcblk0p21 /cache ext4 rw,nosuid,nodev,relatime,data=ordered 0 0
/dev/fuse /storage/sdcard1 fuse rw,nosuid,nodev,relatime,user_id=1023,group_id=1
023,default_permissions,allow_other 0 0
/dev/block/vold/179:33 /storage/sdcard0 vfat rw,dirsync,nosuid,nodev,noexec,rela
time,uid=1000,gid=1015,fmask=0002,dmask=0002,allow_utime=0020,codepage=cp437,ioc
harset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
/dev/block/vold/179:33 /mnt/secure/asec vfat rw,dirsync,nosuid,nodev,noexec,rela
time,uid=1000,gid=1015,fmask=0002,dmask=0002,allow_utime=0020,codepage=cp437,ioc
harset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
tmpfs /storage/sdcard0/.android_secure tmpfs ro,relatime,size=0k,mode=000 0 0
shell@android:/ #

 

[scary alien]

Yeah, I think your mount commands look right...but like I said before, I'm no expert .

But I didn't see that you verified that /system actually got remounted in r/w mode before you tried to install the su binary (not trying to nit-pick--just trying to be sure we don't miss a detail).

Also, doing an ls -l on /system/xbin/su after your copy would be helpful, too (i.e., to reinforce that the copy command worked).

[are you also doing a "chmod 06755 /system/xbin/su", too? I know it's moot if we're not getting the su binary to stay/stick, but thought I'd ask ]

By the way, you can also use "cat /data/local/tmp/su > /system/xbin/su" in lieu of a copy command (it's a quick and dirty equivalent to the copy (cp) command when you don't have that available).

Those "input/output" errors might be an artifact of /system getting auto-remounted as "r/o" (by the system) as your mount output immediately afterwards show.

You could also try some variations using "barrier=0", too...:dontknow:

Also, a "toolbox sync" or "busybox sync" after the remount and copy of the su binary to /system might be helpful.

I was just hoping to find some plausible reason for what you guys are experiencing and a small window to sneak in and truly get /system updated.

<still-crossing-fingers>

 

[jjfriede]

Yeah, I think your mount commands look right...but like I said before, I'm no expert .

But I didn't see that you verified that /system actually got remounted in r/w mode before you tried to install the su binary (not trying to nit-pick--just trying to be sure we don't miss a detail).

Also, doing an ls -l on /system/xbin/su after your copy would be helpful, too (i.e., to reinforce that the copy command worked).

[are you also doing a "chmod 06755 /system/xbin/su", too? I know it's moot if we're not getting the su binary to stay/stick, but thought I'd ask ]

By the way, you can also use "cat /data/local/tmp/su > /system/xbin/su" in lieu of a copy command (it's a quick and dirty equivalent to the copy (cp) command when you don't have that available).

Those "input/output" errors might be an artifact of /system getting auto-remounted as "r/o" (by the system) as your mount output immediately afterwards show.

You could also try some variations using "barrier=0", too...:dontknow:

Also, a "toolbox sync" or "busybox sync" after the remount and copy of the su binary to /system might be helpful.

I was just hoping to find some plausible reason for what you guys are experiencing and a small window to sneak in and truly get /system updated.

<still-crossing-fingers>

First time i tried again with another error:

Spoiler

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Program Files (x86)\Minimal ADB and Fastboot>adb shell
shell@android:/ $ /data/local/tmp/./roothandler
/data/local/tmp/./roothandler
ro.build.product=seanplus
ro.build.id=JRO03C
search kallsyms...
1 2 3 4 5 6 7 8 9 10 11 12
(kallsyms_addresses=c066fba0)
(kallsyms_num_syms=00010e24)
kernel dump...
1 2 3 4 5 6 7 8 9

prepare_kernel_cred=c00b14c8
commit_creds=c00b113c
ptmx_fops=c09f5698

Succeeded in getroot!

Entering character mode
Escape character is '^]'.


shell@android:/ # busybox su
busybox su
su: unknown user root
1|shell@android:/ # busybox mount -o rw,barrier,remount /system
busybox mount -o rw,barrier,remount /system
shell@android:/ # mount
mount
rootfs / rootfs ro,relatime 0 0
tmpfs /dev tmpfs rw,nosuid,relatime,mode=755 0 0
devpts /dev/pts devpts rw,relatime,mode=600 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
none /acct cgroup rw,relatime,cpuacct 0 0
tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0
tmpfs /mnt/obb tmpfs rw,relatime,mode=755,gid=1000 0 0
none /dev/cpuctl cgroup rw,relatime,cpu 0 0
/dev/block/mmcblk0p19 /system ext4 rw,relatime,data=ordered 0 0
/dev/block/platform/msm_sdcc.3/by-num/p22 /data ext4 rw,nosuid,nodev,relatime,no
auto_da_alloc,data=ordered 0 0
/dev/block/mmcblk0p10 /persist ext4 rw,nosuid,nodev,relatime,data=ordered 0 0
/dev/block/mmcblk0p21 /cache ext4 rw,nosuid,nodev,relatime,data=ordered 0 0
/dev/fuse /storage/sdcard1 fuse rw,nosuid,nodev,relatime,user_id=1023,group_id=1
023,default_permissions,allow_other 0 0
/dev/block/vold/179:33 /storage/sdcard0 vfat rw,dirsync,nosuid,nodev,noexec,rela
time,uid=1000,gid=1015,fmask=0002,dmask=0002,allow_utime=0020,codepage=cp437,ioc
harset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
/dev/block/vold/179:33 /mnt/secure/asec vfat rw,dirsync,nosuid,nodev,noexec,rela
time,uid=1000,gid=1015,fmask=0002,dmask=0002,allow_utime=0020,codepage=cp437,ioc
harset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
tmpfs /storage/sdcard0/.android_secure tmpfs ro,relatime,size=0k,mode=000 0 0
shell@android:/ # busybox cp /data/local/tmp/su /system/xbin/su
busybox cp /data/local/tmp/su /system/xbin/su
cp: can't create '/system/xbin/su': Input/output error
1|shell@android:/ # ls -l /system/xbin
ls -l /system/xbin
-rwxr-xr-x root shell 55664 2008-08-01 07:00 dexdump
shell@android:/ #

I'll try again and I'll post as soon as i can get the binary to copy without that i/o error

 

[miltblue]

Hey Guys! I thought that scary alien was on to something with that barrier=0/1 thing in the ext4 filesystem options so I spent well in to the morning trying to get some type of understanding of what the hell a ext4 filesystem or any ext filesystem options are and what they do. It seems that by using the JDB or JDB2 journalling system with the ext4 filesystem you can control which users entries into the journal actually get written when it is time to actually write to the filesystem on the disk. You can control which users can write the disk. They can also be parsed and flushed from the journal according to UUID. This would explain the disappearing su from /system/xbin and the unknown user su. Had to go to bed finally and still don't know what I'm doing or if its right. But that just maybe it. Here's a link to what I was reading. Maybe you guys can make some since of it. I gotta get a 18 holes of golf in today because its suppose to get cold for a while in NC. Linux/Documentation/filesystems/ext4.txt - Linux Cross Reference - Free Electrons

 

[mrfeh]

Hey Guys! I thought that scary alien was on to something with that barrier=0/1 thing in the ext4 filesystem options so I spent well in to the morning trying to get some type of understanding of what the hell a ext4 filesystem or any ext filesystem options are and what they do. It seems that by using the JDB or JDB2 journalling system with the ext4 filesystem you can control which users entries into the journal actually get written when it is time to actually write to the filesystem on the disk. You can control which users can write the disk. They can also be parsed and flushed from the journal according to UUID. This would explain the disappearing su from /system/xbin and the unknown user su. Had to go to bed finally and still don't know what I'm doing or if its right. But that just maybe it. Here's a link to what I was reading. Maybe you guys can make some since of it. I gotta get a 18 holes of golf in today because its suppose to get cold for a while in NC. Linux/Documentation/filesystems/ext4.txt - Linux Cross Reference - Free Electrons

A little quick background - I've been working w/ linux for 20 years. I have a fair amount of experience w/ mount options and file systems. A lot of that carries over to android, but not everything, and I'm relatively new to the android world.

I will attempt to experiment as miltblue has been, but I'm not sure when I'll have a chunk of time to dig into this. Might be several days.

 

[Raptor_Jesus]

I just did a little experiment.
- mount -o remount,rw /system
- echo testcontent > /system/testfile
- dd if=/dev/block/mmcblk0p19 of=/storage/sdcard0/dump.bin (512 MB copied)
- confirmed /system/testfile still exists
Now I opened dump.bin on my pc and checked for the existence of the strings "testfile" and "testcontent". They were there! So files get written to /dev/block/mmcblk0p19. Tomorrow I will check if the partition got wiped, and if that happened, if maybe "testcontent" is still on there. If testfile is gone and testcontent is still there, it means that the file got wiped. If both are gone, it means that either it was never written or that the full 512 MB got overwritten.

update:
After running "mount -o remount,ro /system", testfile was gone instantly. I again dumped /dev/block/mmcblk0p19 to /storage/sdcard0/dump.bin and the "testcontent" was gone too. It is impossible that all 512 MB got overwritten from a recovery partition so quickly. So, everything seems as if you can write to disk, but in the end, you haven't been able to touch anything.

Maybe a technique such as PCI Data Recovery Disk Protection Card - Free Shipping - DealExtreme is used; see http://www.experts-exchange.com/Hardware/Misc/Q_21252094.html for details.

Here is the full partition table:

/sys # fdisk -l /dev/block/mmcblk0

Disk /dev/block/mmcblk0: 3909 MB, 3909091328 bytes
1 heads, 16 sectors/track, 477184 cylinders
Units = cylinders of 16 * 512 = 8192 bytes

              Device Boot      Start         End      Blocks  Id System
/dev/block/mmcblk0p1   *        1025        2048        8192  4d Unknown
Partition 1 does not end on cylinder boundary
/dev/block/mmcblk0p2            2049        3072        8192  45 Unknown
Partition 2 does not end on cylinder boundary
/dev/block/mmcblk0p3            3073        4096        8192  46 Unknown
Partition 3 does not end on cylinder boundary
/dev/block/mmcblk0p4            4097      477184     3784704   5 Extended
Partition 4 does not end on cylinder boundary
/dev/block/mmcblk0p5            5121        6144        8192  58 Unknown
/dev/block/mmcblk0p6            6145        7168        8192  b1 Unknown
/dev/block/mmcblk0p7            7169        8192        8192  b1 Unknown
/dev/block/mmcblk0p8            8193       10240       16384  b1 Unknown
/dev/block/mmcblk0p9           10241       14336       32768  b1 Unknown
/dev/block/mmcblk0p10          14337       16384       16384  83 Linux
/dev/block/mmcblk0p11          16385       17408        8192  4a Unknown
/dev/block/mmcblk0p12          17409       18432        8192  4b Unknown
/dev/block/mmcblk0p13          18433       26624       65536   c Win95 FAT32 (LB
A)
/dev/block/mmcblk0p14          26625       27648        8192  5d Unknown
/dev/block/mmcblk0p15          27649       28672        8192  47 Unknown
/dev/block/mmcblk0p16          28673       30720       16384  48 Unknown
/dev/block/mmcblk0p17          30721       32768       16384  60 Unknown
/dev/block/mmcblk0p18          32769       34816       16384  d1 Unknown
/dev/block/mmcblk0p19          34817      100352      524288  83 Linux
/dev/block/mmcblk0p20         100353      101376        8192  63 GNU HURD or Sys
V
/dev/block/mmcblk0p21         101377      139776      307200  83 Linux
/dev/block/mmcblk0p22         140289      451584     2490368  83 Linux
/dev/block/mmcblk0p23         451585      477184      204800  83 Linux

/system is on p19 and is 87% full, so no partition is large enough to keep a copy (p22 is for the user to store data). This just confirms that the data isn't restored from a hidden recovery partition.

dmesg shows that /dev/block/mmcblk0 has type number 'SJS00M', which means it is Samsung flash memory found on several other phones. It loads the driver 'smsc911x' version 2008-10-21, which is nothing special.