All you need to do is extract this and run the "runme.bat"
Code:
echo off
cls
echo *********************************
echo * Please plug the USB into Nook *
echo *********************************
pause
adb kill-server
adb devices
echo *******************
echo * Blocking Update *
echo *******************
adb shell mount -o remount,rw /dev/block/mmcblk0p5 /system
adb push block-1.1.sh /system/media
adb shell sh /system/media/block-1.1.sh
ping -n 5 127.0.0.1 >NUL
echo Success
adb reboot
adb kill-server
echo *****************************
echo * You nook is rebooting *
echo * Disconnect the USB cable! *
echo * Wait until rebooted... *
echo * *
echo * BN 1.1 Update Blocked *
echo * *
echo *****************************
pause
exit
Download
Can you release an "Undo" script as well that undoes what this does?
I was under the impression that the otacert rename was a dud and the build.prop was very questionable???
found this and replied to the discussion on the subject.
IMO, Until the OTA is squashed we are going to have a repetitive debockle of blowing up everyones rooted work and would think addressing this would be of significant value:
-cut-n-paste-
I was wondering what you folks thought of this 'prevent' 1.1 hack??
http://forum.xda-developers.com/showthread.php?t=930477
seems reasonable to me, adding:
127.0.0.1 csqaint.barnesandnoble.com
(looks to be the primary check for updates?)
and
127.0.0.1 bncs.barnesandnoble.com
(just for good measure but might have unwanted consequences?)
to /etc/hosts file
I would personally like to be able to put an end to this 'forced' OTA update behind us and be able to sideload any updates from bn manually at our convienence in the future.
how bout u??????
In reviewing the script it appears to apply the build.prop spoof update?
I thought this was questionalble in overall effectiveness?? and even if it worked would have to be reapplied after every update from bn???
I noticed an interesting reply from ixampl as follows:
What I did when the first scare of an update arose was:
a) Checked in /data/data/com.bn.nook.devicemanager/databases/ for an sql file
b) Pulled the sql file.
c) Dump its contents with sqlite3.
d) In it there's an entry for OTAs... with value "auto"
e) Changed that value to "manual"
f) Pushed the modified database file to the device.
I never got any OTA updates. Still on first OS version.
This is exactly what I'm lookin for, a permenant block unless of course the database update got reversed back to auto?????
is this normal? i go into settings/device info/about your nook color. it still shows 1.0.1? where do i have to go to verify this is blocked?
C:\NC - Auto Config Script 1.0.1>adb push block-1.1.sh /system/media
32 KB/s (506 bytes in 0.015s)
C:\NC - Auto Config Script 1.0.1>adb shell sh /system/media/block-1.1.sh
cp: not found
sed: not found
sed: not found
sed: not found
sed: not found
john10101 said:
is this normal? i go into settings/device info/about your nook color. it still shows 1.0.1? where do i have to go to verify this is blocked?
C:\NC - Auto Config Script 1.0.1>adb push block-1.1.sh /system/media
32 KB/s (506 bytes in 0.015s)
C:\NC - Auto Config Script 1.0.1>adb shell sh /system/media/block-1.1.sh
cp: not found
sed: not found
sed: not found
sed: not found
sed: not found
Click to expand...
Click to collapse
You dont have busybox installed on the NC?
bonzer2u said:
In reviewing the script it appears to apply the build.prop spoof update?
I thought this was questionalble in overall effectiveness?? and even if it worked would have to be reapplied after every update from bn???
I noticed an interesting reply from ixampl as follows:
What I did when the first scare of an update arose was:
a) Checked in /data/data/com.bn.nook.devicemanager/databases/ for an sql file
b) Pulled the sql file.
c) Dump its contents with sqlite3.
d) In it there's an entry for OTAs... with value "auto"
e) Changed that value to "manual"
f) Pushed the modified database file to the device.
I never got any OTA updates. Still on first OS version.
This is exactly what I'm lookin for, a permenant block unless of course the database update got reversed back to auto?????
Click to expand...
Click to collapse
Can you elaborate a little further on what commands you used so I might be able to add it into a script.
i dont think so... what installs busybox?
No offense, but this isn't a worry any more anyway. We already have a CWM flashable update.zip that updates you to 1.1, but does not harm your root or installed aps. Why are people bothering with all this "blocking" nonsense?
From this thread:
http://forum.xda-developers.com/showthread.php?t=874871
Attached is a working sqlite3 binary. Copy it to /system/bin and you will be able to edit sqlite databases on the nook itself.
--------------------------------------------------------------------------------
Attached Files sqlite3.7z (11.9 KB, 56 views)
-----------------------------------------------------------------------------
And I found a sqlite3 sample that will need to be edited like somthing as follows:
In your terminal,
$ adb pull /data/data/com.bn.nook.devicemanager/databases/settings.db settings.db
$ sqlite3 settings.db
sqlite> update secure set value='manual' where name='an entry for OTAs???-Dont know the parameter here'
;
sqlite> .q
$ adb push /data/data/com.bn.nook.devicemanager/databases/settings.db settings.db
$ adb reboot
Hope this helps, I dont know the input name for placeholder.
xboxexpert said:
You dont have busybox installed on the NC?
Click to expand...
Click to collapse
Ok i installed busy box off the market, and ran the script!!! success. when i rebooted it told me that 1.1.0 has been installed. and it now shows 1.1.0 in the about.
i suggest noting busy box in the original post.
Divine_Madcat said:
No offense, but this isn't a worry any more anyway. We already have a CWM flashable update.zip that updates you to 1.1, but does not harm your root or installed aps. Why are people bothering with all this "blocking" nonsense?
Click to expand...
Click to collapse
not everyone wants to upgrade to 1.1, or has cwm installed.
john10101 said:
Ok i installed busy box off the market, and ran the script!!! success. when i rebooted it told me that 1.1.0 has been installed. and it now shows 1.1.0 in the about.
i suggest noting busy box in the original post.
Click to expand...
Click to collapse
It says 1.1 is installed but its really not. (Spoofed it)
john10101 said:
not everyone wants to upgrade to 1.1, or has cwm installed.
Click to expand...
Click to collapse
Uh... why? What is there about 1.1 not to want? And if you are ok with doing all of this to block an update, there is no reason not to have CWM (which is quite stable). Sorry, but this really is all just wasted effort..
Divine_Madcat said:
Uh... why? What is there about 1.1 not to want? And if you are ok with doing all of this to block an update, there is no reason not to have CWM (which is quite stable). Sorry, but this really is all just wasted effort..
Click to expand...
Click to collapse
Took me 2 seconds to throw together...took longer to upload then anything. Its just for people who want it. If you dont want it I dont want you to have it :/
xboxexpert said:
Took me 2 seconds to throw together...took longer to upload then anything. Its just for people who want it. If you dont want it I dont want you to have it :/
Click to expand...
Click to collapse
Don't get me wrong, im not knocking your work, just people's reasoning for wanting it done in the first place. I understand before the update.zip was developed, since it would break root and mess up your apps. But now, there is no reason not to take the update; thus the continued demand for this is puzzling.
If you really want the OTA update to stop, take a look at the updater-script inside the sideload_update.zip file from B&N. The first two lines read:
Code:
assert(getprop("ro.product.device") == "zoom2" ||
getprop("ro.build.product") == "zoom2");
I think those are set in the build.prop file. Change either ro.build.product or ro.product.device to something other than zoom2 (say zoom2a), and the rest of the script won't continue. This is what people are seeing when the file gets downloaded OTA and then disappears without being applied. If for some reason you must avoid it, make that change and you will stop the update cold. Not sure what the side effects of making the change are, but there would be an easy way to revert by undoing the edits, if you need to.
Wasn't this already available from another forum member?
http://forum.xda-developers.com/showthread.php?t=930382
Seems a lot easier to just copy and replace build.prop with a filemanager.
Divine_Madcat said:
Uh... why? What is there about 1.1 not to want? And if you are ok with doing all of this to block an update, there is no reason not to have CWM (which is quite stable). Sorry, but this really is all just wasted effort..
Click to expand...
Click to collapse
Yah go ahead and read thru the cwm thread and try to convince anyone in this forum that it is 100% stable. Not to suggest that anyones efforts are not welcome and appreciated but if you asked the actual devs involved I would bet they would not suggest so as well.
I for one have rooted twice (1.0 and 1.0.1) with autoroot and am 100% stable, never had a crash or the pleasure to have to restore/rebuild, not interested in the stock browser or anything else bn has to offer, quite happy and perhaps lucky with the way its workin now. I also dont appreciate being strong armed an update without a confirmation, hell even microbuddies doesnt have that kinda gawl.
I guess it will take one of the next of many 'future forced' updates from bn that bothches all the work that you have put into your NC and for whatever reason your recovery doesnt work and you are forced to rebuild from scratch before you realize that if you had a permenant block in place, you could have the time for outstanding efforts of the local devs to stabilize an upgrade path before you pulled the trigger?
The database hack appears to be best way to permanently kill OTA, no need for future updated spoof build.prop scripts (before you get hit) and no worries about being updated and possibly blown up while your sleepin and bn pushes an update out before you get the news.
or maybe its just me..........
Exactly! If you are not diligently checking the forum everyday, you wouldn't know BN is pushing out 1.1 update and you wouldn't know there is a pre-nootered 1.1 version available. BN will update you OTA before you know any better and screw up your rooted setup. Hence the need for a permanent update block.
Related
Do not use the lagfix anymore voodoo will be incorporated into our new kernels very soon. Thanks
Kept the attachments so you can remove if needed!
I keep getting permission errors when I try this. I found another way to update busybox but the script doesn't work
With the current limited root I have, I could not write to /system/bin. I just woke up and I didn't feel like figuring that out, so I copied stuff to the sdcard, then I used cat to write the file to /system/bin as shown above (steps below). I would suggest before starting, download Quadrant Standard from the Market, run the full benchmark and see where your device is on the list. Mine was below the Galaxy S before starting.
This is what I did (on Mac) to get busybox in place:
Code:
./adb shell
su
mkdir /sdcard/lag_fix/
exit
exit
./adb push ~/Downloads/busybox /sdcard/lag_fix/
./adb shell
su
cat /sdcard/lag_fix/busybox > /system/bin/busybox
cd /system/bin/
chmod 755 busybox
ls -l (check the permissions)
exit
exit
Now busybox is in it's right place with the right permissions.
Now, I have to manually execute the steps in the lagfixme.bat file, because I'm not on a PC and I don't feel like re-writing the script, because I just woke up.
Before pushing the files, I edited lines 35 and 36 in the createlagfix.txt file to fit my sdcard folder path. I like to keep my SD card organized, so I put all the files from the zip into the /sdcard/lag_fix folder I created above. Here is what my line 35 and 36 look like before I push createlagfix.txt to the SD card:
busybox cp /sdcard/lag_fix/playlogos1 /system/bin/playlogos1
busybox cp /sdcard/lag_fix/userinit.sh /system/bin/userinit.sh
Now, I know the folder paths below looks ugly, but that's because I just pushed the files directly from my Downloads folder. Hopefully you guys can see what I did here. If not, let me know and I'll edit the post to read better. These are basically the lines in the batch file written out manually for Mac users:
Code:
./adb kill-server
./adb push ~/Downloads/RyanZAEXT2LagFix\ ALPHA\ 1/createlagfix.txt /sdcard/lag_fix/createlagfix.sh
./adb push ~/Downloads/RyanZAEXT2LagFix\ ALPHA\ 1/playlogos1 /sdcard/playlogos1
./adb push ~/Downloads/RyanZAEXT2LagFix\ ALPHA\ 1/userinit.sh /sdcard/userinit.sh
./adb shell su -c "/system/bin/sh /sdcard/lag_fix/createlagfix.sh"
Once the process is complete, run Quadrant Standard again and you'll see your device as the fastest one in the list.
Many thanks to Dirrk!!
Worked just fine for me.
Thanks for this and your root instructions!
Guys, is the phone actually laggy, or are you just assuming it's laggy because of complaints with the other models? I mean, you've only had them a day or two, right? Took me longer to notice lag than that on my i9000.
I'm tempted to grab a Fascinate, but all the issues I've had with the i9000 and it's a tough call.
I've seen it lag sometimes under high load, but I thought that was normal.
I've tested it with GroceryIQ, to compare against the last 30 seconds or so of this video ( http://www.youtube.com/watch?v=10ox35vMS78 ) and the Fascinate is nowhere near as bad at lagging. That video was 8/21/2010, so they may have updated their application by now, not sure.
Edit - Anyway, it works just fine. Nice work Dirrk! 2,191 !
Yep, worked like a charm! My Quadrant score jumped to 2125 after the fix. Phone is much snappier too. Thanks Dirrk!
i've been trying this but i keep getting permission denied.
can someone take me step by step on how to do this?
So, after running this, I am now getting a notification that internal storage is nearly full. Any ideas?
spotmark said:
So, after running this, I am now getting a notification that internal storage is nearly full. Any ideas?
Click to expand...
Click to collapse
If you have root, you can now remove many of the bloatware apps that you do not use (this fix uses 1gb of your internal storage - performance is expensive)
m2cool2go said:
If you have root, you can now remove many of the bloatware apps that you do not use (this fix uses 1gb of your internal storage - performance is expensive)
Click to expand...
Click to collapse
Whoa, careful there. That's a quick way to brick your phone. Try removing Verizon Backup Assistant and you're bricked.
C:\sdk\tools>adb shell
$ su
su
# cat /sdcard/busybox > /system/xbin/busybox
cat /sdcard/busybox > /system/xbin/busybox
cannot create /system/xbin/busybox: read-only file system
Any ideas why I'm getting this error? It looks like I'm screwing up something very simple...
namebrandon said:
Whoa, careful there. That's a quick way to brick your phone. Try removing Verizon Backup Assistant and you're bricked.
Click to expand...
Click to collapse
Really? I removed Backup Assistant and I'm not bricked. Am I missing something?
Removing VZW backup assistant will absolutely not brick your phone. Its one of the first things to go on all my android phones since the eris.
undo lagfix
Hello. I want to undo this for now, due to running out of space for apps. I assumed running unlagfixme would do the trick, but it hasn't given me back the 1 gb it used. Am I doing it wrong, or is it stuck like this now? Thanks for your help!
is there a list of apps someone can recommend to remove that's just bloat? thanks....and ive ran this quadrant score, im averaging 871 three times testing now with minimal apps (used task killer...) - and ive got 177mb left on my phone hehe...
Nevermind, figured it out
xirnibor said:
is there a list of apps someone can recommend to remove that's just bloat? thanks....and ive ran this quadrant score, im averaging 871 three times testing now with minimal apps (used task killer...) - and ive got 177mb left on my phone hehe...
Click to expand...
Click to collapse
You screwed up if your only getting 871 thats stock. Open up a shell on your phone and type mount and place the results in here
Whitepaint said:
Removing VZW backup assistant will absolutely not brick your phone. Its one of the first things to go on all my android phones since the eris.
Click to expand...
Click to collapse
Thanks for the info, and my bad on the post!
I heard that removing this on the Droid X was bricking phones.
If people want to share what they've been successful in removing/renaming, that would be helpful.
namebrandon said:
Thanks for the info, and my bad on the post!
I heard that removing this on the Droid X was bricking phones.
If people want to share what they've been successful in removing/renaming, that would be helpful.
Click to expand...
Click to collapse
I am waiting on rom manager so I can make a back up before I continue removing stuff
I'm posting this here for visibility for Fascinate users and ROM developers. In the following thread you can find all the information, as well as how to download and apply the patch files:
http://forum.xda-developers.com/showthread.php?t=977154
I'm sure it will be incorporated into the major ROM's soon. However, if you install apps from unverified sources, or regularly try out new apps from the market, you shouldn't wait.
Patching via CWM:
imnuts said:
Here are two zips if people want them and don't feel like going to another thread/page/topic/whatever.
DroidDreamMalwarePatch_pre-edify.zip
DroidDreamMalwarePatch_edify.zip
Click to expand...
Click to collapse
Patching via ADB or terminal emulator:
Alternatively, probably the quickest way (and if you copy and paste, the most fool-proof) if you are rooted and know how to use ADB, is to open up a command prompt or a terminal emulator on the phone to access the adb shell. If on a PC, type:
Code:
adb shell su
Then type the following lines, omitting the $ and # (if you are on a terminal emulator, start here):
Code:
$ su
# mount -o rw,remount /dev/block/stl9 /system
# touch /system/bin/profile
# chmod 444 /system/bin/profile
You are now protected from the current iteration of DroidDream Malware. Consider installing a security program like LookOut to protect against future vulnerabilities.
Original Post:
Rodderik said:
[Patch][Rom]Malware Exploit for all pre-Gingerbread phones
Who is affected? All phones pre-gingerbread
Who should act? Users and developers using pre-gingerbread roms
How do I fix? Flash attached .zip at the bottom of this post or use one of the alternate methods down there
What if I think I was infected? Completely wipe your device, format sdard, go back to stock and re-apply rom, then flash the attached .zip (before installing any apps)
Why should I care? read below...
http://www.androidpolice.com/2011/0...your-phone-steal-your-data-and-open-backdoor/
Link to publishers apps here. I just randomly stumbled into one of the apps, recognized it and noticed that the publisher wasn’t who it was supposed to be.
Super Guitar Solo for example is originally Guitar Solo Lite. I downloaded two of the apps and extracted the APK’s, they both contain what seems to be the "rageagainstthecage" root exploit – binary contains string "CVE-2010-EASY Android local root exploit (C) 2010 by 743C". Don’t know what the apps actually do, but can’t be good.
I appreciate being able to publish an update to an app and the update going live instantly, but this is a bit scary. Some sort of moderation, or at least quicker reaction to malware complaints would be nice.
EDIT: After some dexing and jaxing, the apps seem to be at least posting the IMEI and IMSI codes to http://184.105.245.17:8080/GMServer/GMServlet, which seems to be located in Fremont, CA.
I asked our resident hacker to take a look at the code himself, and he’s verified it does indeed root the user’s device via rageagainstthecage or exploid. But that’s just the tip of the iceberg: it does more than just yank IMEI and IMSI. There’s another APK hidden inside the code, and it steals nearly everything it can: product ID, model, partner (provider?), language, country, and userID. But that’s all child’s play; the true pièce de résistance is that it has the ability to download more code. In other words, there’s no way to know what the app does after it’s installed, and the possibilities are nearly endless.
Click to expand...
Click to collapse
The offending apps from publisher Myournet:
* Falling Down
* Super Guitar Solo
* Super History Eraser
* Photo Editor
* Super Ringtone Maker
* Super Sex Positions
* Hot Sexy Videos
* Chess
* ????_Falldown
* Hilton Sex Sound
* Screaming Sexy Japanese Girls
* Falling Ball Dodge
* Scientific Calculator
* Dice Roller
* ????
* Advanced Currency Converter
* App Uninstaller
* ????_PewPew
* Funny Paint
* Spider Man
* ???
Click to expand...
Click to collapse
http://www.androidpolice.com/2011/0...-android-nightmare-and-weve-got-more-details/
Now, on to some more details of the virus. We should point out that this vulnerability was patched with Gingerbread, meaning any device running Android 2.3+ should be fine. In other words, if you’re looking to play the blame game (which I’m not, but having read all the comments on the original post, many people are), then there’s plenty to go around. The hole was fixed by Google, but it’s relatively useless since many phones aren’t yet running a version of Android that is protected. It’s noteworthy that some manufacturers released updates that patched the exploit for devices without updating to Gingerbread; unfortunately, it appears that minority is quite a small one.
Perhaps most important is the question of what infected users can do about their situation; unfortunately, the answer is not much of anything. Because the virus opens up a backdoor and can bring in new code at any time, the only way to really rid an infected device of any damage is to completely wipe the device – not exactly the optimal solution, but it looks like the only one available, at least for now.
Finally, Justin notes that ROM developers working with pre-Gingerbread versions of Android can prevent the virus from backdooring in code by putting a dummy file at /system/bin/profile.
Click to expand...
Click to collapse
As you can see androidpolice.com reports on this backdoor and roots and steals personal information. The apps are removed from the market but that doesn't mean they got them all. Attached is a flashable fix as suggested by androidpolice.com
So users can flash this .zip or simply create a blank file called profile and place it in /system/bin/ (developers are encouraged to include this file in future releases. A blank file is not going to affect performance at all)
Alternate methods:
Using 'adb shell' or terminal emulator (should work on any ROOTED phone) as suggest by xaueious here
Code:
$ su
su
# remount rw
Remounting /system (/dev/stl9) in read/write mode
# touch /system/bin/profile
# chmod 644 /system/bin/profile
#
Alternate 2:
Download blank profile file from here (or create one and name it profile)
Use a program like Root Explorer to copy it to /system/bin/
Then longpress on it and check the permissions should be read/write for user, read for group, and read for others.
Alternate 3:
cyansmoker has put together an apk for the patch here https://market.android.com/details?id=com.voilaweb.mobile.droiddreamkiller
Thanks for pointing this out photoframd and androidpolice.com for investigating and reporting!
UPDATE: I renamed the .zip file and reuploaded it (350 hits wow). Also in the edify scripted version I added 644 permissions to the file (but if you already flashed it then it should have defaulted to that). I also added a pre-edify version of the patch thanks to xaueious for people using a recovery that does not yet understand edify.
Click to expand...
Click to collapse
Thanks
Sent from my Rocking dj05, themed superdark w/o swype mod, voodoo 5, with custom boot and shutdown.. With premium xda app.
I would also recommend installing the free Lookout Mobile Security app. I find it to be very non-intrusive on my phone, no negligible battery drain or performance issues. Just scans any app you install, looking for bad stuff. Also does weekly full system scans, contact backup, and provides phone lock/alarm/location tracking features in case you lose it. Premium version has even more bells and whistles.
Posted from my EB01 SuperClean Fascinate with Voodoo
This has been stuck for the time being as it seems to be affected a BOATLOAD of users. Thanks for the linkage!
Here are two zips if people want them and don't feel like going to another thread/page/topic/whatever.
adb shell busybox touch /system/bin/profile
is all you need. Most fascinate kernels (of recent) have a bug, and /system is mounted as r/w.
So everyone should flash this no matter what rom you are using? Should we flash the new cwr also?
sorry delete
jcase said:
adb shell busybox touch /system/bin/profile
is all you need. Most fascinate kernels (of recent) have a bug, and /system is mounted as r/w.
Click to expand...
Click to collapse
adb shell chmod 644 /system/bin/profile
also?
NOsquid said:
adb shell chmod 644 /system/bin/profile
also?
Click to expand...
Click to collapse
This would probably be a good thing. Basically locks the file from being written to, right? Should I add it to the first post?
lasportsfan said:
So everyone should flash this no matter what rom you are using? Should we flash the new cwr also?
Click to expand...
Click to collapse
Yes.
All this is is a quick fix that will create a blank file. The current iteration of the malware checks to see if it already exists. This file fools it into thinking it already exists, so it moves on.
As you might guess, the author needs to only update his code to bypass this, in order for this to be an issue again.
And now that this is out, someone else will probably try it. Someone who is a little more thorough.
Moral of the story?
Be careful.
Consider running something like LookOut.
Backup your important data regularly.
As far as CWM goes, is there some kind of connection to the malware thing? Or just in general?
(If just in general, it's better to ask elsewhere as to not derail the thread).
Otherwise, I don't believe the newest (orange) clockwork recovery from ROM manager is fully compatible yet. Last I heard, it still had some bad binaries and 1 bad mounting point. Stick with the Red from JT's thread (which is the same bundled into SuperClean). Other than a couple superficial bugs that don't hurt anything, it works wonderfully and has more features than the orange CWM currently has.
GizmoDroid said:
This would probably be a good thing. Basically locks the file from being written to, right? Should I add it to the first post?
Click to expand...
Click to collapse
I dunno, it was in Rodderik's post but jcase didn't mention it. He's smarter than me, that's why I asked...
444 or 000 would be safer as that would prevent the file from being overwritten at all. 444 for read-only, 000 for no access.
If I never downloaded any of the apps in the list and have lookout on my phone is this neccesary to download or should i not be worried?
italysfinest327 said:
If I never downloaded any of the apps in the list and have lookout on my phone is this neccesary to download or should i not be worried?
Click to expand...
Click to collapse
Who should act? Users and developers using pre-gingerbread roms
Click to expand...
Click to collapse
I'd say that means you should be worried. Those apps listed are just the ones that were found on the market with them from one publisher. Just how virus's can get put into any application on a PC, the same can be done on phones.
Remember folks, our phones are just as exploitable as any other computer, so be careful!
good thing the patch came out!
imnuts said:
444 or 000 would be safer as that would prevent the file from being overwritten at all. 444 for read-only, 000 for no access.
Click to expand...
Click to collapse
Not sure whether Android interprets permissions differently from desktop Linux, but even if a file is 000 the owner can delete it on Debian. And root definitely can. If the file needs to be there for the root exploit to work, then this prevents it, but if they can run the root exploit and get root while this file is there then changing permissions on it will do nothing.
iofthestorm said:
Not sure whether Android interprets permissions differently from desktop Linux, but even if a file is 000 the owner can delete it on Debian. And root definitely can. If the file needs to be there for the root exploit to work, then this prevents it, but if they can run the root exploit and get root while this file is there then changing permissions on it will do nothing.
Click to expand...
Click to collapse
This is just another reason why I see this as a quick fix for what will need to have a much better one in the future.
If anyone hears of a more robust solution (besides using LookOut), let us know!
I navigated through Root Explorer to system/bin/profile and found a file there that reports
"01 Aug 08 06:00:00 rwxr-xr-x 0 bytes".
The 2008 date has me worried, although the 0 bytes means it is empty. Does anybody know if this is put there by FrankenClean 2.8 as a fix for this issue, or am I the only one on SuperClean seeing this (which would be bad!)
SupraLance said:
I navigated through Root Explorer to system/bin/profile and found a file there that reports
"01 Aug 08 06:00:00 rwxr-xr-x 0 bytes".
The 2008 date has me worried, although the 0 bytes means it is empty. Does anybody know if this is put there by FrankenClean 2.8 as a fix for this issue, or am I the only one on SuperClean seeing this (which would be bad!)
Click to expand...
Click to collapse
It is included in SC2.8. The 0 bytes is the best indicator that you are clean, since this patch is merely an empty file.
If you were infected, that file would actually have code in it.
For CWM 2.5.x.x DJ05, which one do you flash? or both?
DroidDreamMalwarePatch_pre-edify.zip
DroidDreamMalwarePatch_edify.zip
Thanks and sorry for the trouble, just wanted to be sure.
Hey guys, I came up with a basic set of tools which I find useful. You may redistribute , include in any custom ROMs and/or distributions.
This includes:
Rewrite /default.prop for ADB
Install and deploy busybox in /system/xbin
install bash, ipctool, strace, tcpdump, and viewmem binaries.
To install, you must be rooted.
Unzip the attached file
place it on your nook.
cd to the folder you installed
Run the following
Code:
sh /sdcard/BHT/run.sh
Please note, I use Android Market app QuickSSH to get into my nook terminal, your results may very.. I hope someone else grabs these files and makes it all more user friendly. I've got too many other things going on.
I encourage other developers to include these valuable debugging tools in their packages.
You, sir, are a monster! You get my vote.
Sent from my Nexus S using xda premium
AdamOutler said:
Hey guys, I came up with a basic set of tools which I find useful. You may redistribute , include in any custom ROMs and/or distributions.
This includes:
Rewrite /default.prop for ADB
Install and deploy busybox in /system/xbin
install bash, ipctool, strace, tcpdump, and viewmem binaries.
To install, you must be rooted.
Unzip the attached file
place it on your nook.
cd to the folder you installed
Run the following
Code:
sh /sdcard/BHT/run.sh
Please note, I use Android Market app QuickSSH to get into my nook terminal, your results may very.. I hope someone else grabs these files and makes it all more user friendly. I've got too many other things going on.
I encourage other developers to include these valuable debugging tools in their packages.
Click to expand...
Click to collapse
I can turn this into an apk, if you don't mind. By turn on adb with this method, adb will be rooted and the device will still be allowed to sleep?
brianf21 said:
I can turn this into an apk, if you don't mind. By turn on adb with this method, adb will be rooted and the device will still be allowed to sleep?
Click to expand...
Click to collapse
By all means. Please do.
My vote too. I just hope after you win that you keep up the great work on the Nook Tablet. The last two weeks or so have looked very promising towards getting custom roms on here and a lot of that has to do with Adam's hard work along with a few others
Nearly all of these are already in snowball-mod, but I'll include ipctool, and viewmem for the next release.
cfoesch said:
Nearly all of these are already in snowball-mod, but I'll include ipctool, and viewmem for the next release.
Click to expand...
Click to collapse
How did you get default.prop reread into memory? The only think I can see is the 2nd init hijack? Am I missing something a lot easier?
brianf21 said:
How did you get default.prop reread into memory? The only think I can see is the 2nd init hijack? Am I missing something a lot easier?
Click to expand...
Click to collapse
Note, I said "nearly all". I don't really see though how changing /default.prop would keep over reboots... rootfs is stored in memory and recreated every time, isn't it?
I've added the binaries to NT Hidden Settings. I have not implemented /default.prop swap yet. I have to play with hijacking init before I do. Thanks again.
brianf21 said:
I've add the binaries to NT Hidden Settings. I have not implemented /default.prop swap yet. I have to play with hijacking init before I do. Thanks again.
Click to expand...
Click to collapse
cool. where are you hosting that binary? I currently have a mirror set up at nook1.adamoutler.com for easy access... When someone gets a new device, they need to download 3 things onto their device to make it a real tablet.. nook1=hidden settings, nook2=homecatcher, nook3=market.. I may change 3 to launcherpro, but hidden settings is the number1 tool required for the nook Tablet.
AdamOutler said:
cool. where are you hosting that binary? I currently have a mirror set up at nook1.adamoutler.com for easy access... When someone gets a new device, they need to download 3 things onto their device to make it a real tablet.. nook1=hidden settings, nook2=homecatcher, nook3=market.. I may change 3 to launcherpro, but hidden settings is the number1 tool required for the nook Tablet.
Click to expand...
Click to collapse
Homecatcher? I mean, I understand if you want to keep using the B&N store and stuff, but if you don't care about the B&N stuff, then the hacked SystemUI.apk is a way better option than Homecatcher.
But then, you're advancing "launcher pro", while I would more generally say "any non-B&N launcher"...
I added another option to nt hidden settings to run adb as root. It doesn't require a reboot and it automatically turns off auto mount. I am using nemith's adbd.
remount / as rw
stop adbd
replace /sbin/adbd
remount / as ro
setprop to turn off auto mount
start adbd as root
It's not persistent after reboot, but it works and doesn't kill the battery. I am not going to bother with hkvc's hijacking init method, because it looks like you, hkvc, bauwks, and nemith will be able to replace the os soon. Thanks.
I have just updated my Prime and I did not have rooted it with ICS. Is possible to root JB without previous rooting?
No. You must back up root using OTA Rootkeeper in order to regain root in JB. There is no known exploit for JB yet.
without restoring root with ota rootkeeper, try http://matthill.eu/mobile/root-trans...lybean-update/ and follow the instructions, follow the links for the files you need
tonesy said:
without restoring root with ota rootkeeper, try http://matthill.eu/mobile/root-trans...lybean-update/ and follow the instructions, follow the links for the files you need
Click to expand...
Click to collapse
lol, must be a joke.... dead link.
I have been actively pursuing this. Without bootloader unlock i dont beleive so.
If you Unlock the Bootloader or already have an Unlocked Bootloader, you can get root.
I haven't seen any exploits posted for the Prime in JB yet, so this may be your only way for now.
hx4700 Killer said:
lol, must be a joke.... dead link.
I have been actively pursuing this. Without bootloader unlock i dont beleive so.
Click to expand...
Click to collapse
He posted a bad link but doesnt work if you have no root access at all. This is just a "regain root if you have partial root" guide:
http://matthill.eu/?s=jelly+bean
Thread moved
Thread moved. This is clearly belonging into Q&A. Please post in correct Sub-Forum.
peace
jotha - forum moderator
Does any one know if one person with development capabilty is trying to find a way to root JB ?
I talked to bin4ry about his root method in hopes of working with him on modifications for the prime but he is telling me his mod is making the change he is exploiting according to what I am seeing but possibly ASUS disabled the emulator mode in this version of the OS. This is what would give you root access via ADB so changes can be made.
I couldnt get out of him what exactly his "restore timing exploit" is but I understand everthing after that
Outside of anything coming up I would say if you must have it now and don't mind voiding your warranty then use the unlocker tool and follow one of many guides on here to do it from an unlocked device.
Perhaps we can turn this thread into, or possibly start a new one about the different things people(devs and/or the technically savy) are finding in the quest for an exploit...
We could start with a list of what is known. Of particular interest would be the differences between the complete stock (me btw), was rooted but lost it, was rooted and kept it, and of course anybody who has managed to root it by messing around but not taken notes along the way.
here's what I have found.
from the PC, creating an adb shell allows me to ls /data/local/tmp/ but from a tablet's terminal emulator (shell?) I cant.
Typing id from both it becomes obvious why
From adb shell I get
Code:
uid=2000(shell) gid=2000(shell) groups=1003(graphics),1004(input),1007(log),1009
(mount),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt)
,3003(inet),3006(net_bw_stats)
from the tablet I get
Code:
uid=10126(u0_a126) gid=10126(u0_a126) groups=1015(sdcard_rw), 1028(sdcard_r),
3003(inet)
I was getting excited last night (burnt the midnight oil) trying what I thought might be a possible exploit with an android supplied command called "run-as". Its limitaions became obvious when I looked at the source code for it. You need an application pakage that is debugable and it cd's to its directory to run the command and a bunch of other things, so I compiled it on C4droid using just the main functions setresuid() and setresgid() but they both failed no matter what value was plugged into them based on UID and GID found here
http://forum.xda-developers.com/showthread.php?t=442557
I have yet to exhaust this avenue. I might be able to create an empty package and sign it as a system app, make it debugable and see what that yeilds but its looking like a convoluted process, espicially considering that run as may not work as intended on prime's JB
PS I want to state that I know precious little about linux and even less about the android layer above it...
Just as an FYI the way bin4rys tool is supposed to work is an exploit in which it makes a symlink to /data/local.prop and injects ro.kernel.qemu=1 in to local.prop then reboots.
This is supposed to put the device in emulator mode and when you connect with adb shell you get a root shell prompt. All the rest is fairly straightforward/standard. Remount file system as RW, install SU and superuser.apk with their permissions set properly in the proper places then break the symlink to local.prop and reboot.
What would help a lot is if someone who is already rooted can make the attempt, set qemu = 1 in the relinked local.prop then adb shell connect to see if you get a root prompt. Trying to confirm that emulator mode is enabled and you get root access as shell to see if this is even worth pursuing.
I would just use the unlocker tool but I am 2 weeks in to ownership of a new unit.
yes I have seen that typing adb root gives the message
Code:
adbd cannot run as root in production builds
it would indeed be interesting to see if changing "qemu" flags it as a non-production build. My sgs is rooted with CM10 nightlies might try toggling the value on that and see what adb says
Run-as
abazz said:
I was getting excited last night (burnt the midnight oil) trying what I thought might be a possible exploit with an android supplied command called "run-as". Its limitaions became obvious when I looked at the source code for it. You need an application pakage that is debugable and it cd's to its directory to run the command and a bunch of other things, so I compiled it on C4droid using just the main functions setresuid() and setresgid() but they both failed no matter what value was plugged into them based on UID and GID found here
http://forum.xda-developers.com/showthread.php?t=442557
Click to expand...
Click to collapse
Yes. I noticed the permissions on that file as well. I'm not an android person, so I don't know how that end works, but the permissions do look correct (setuid root, and runnable as group shell [which we get via adb, but not locally on terminal].
Based on the little bit that I have read, it seems that it may be getting the permissions assigned to the apk and running the command line with those permissions.
If that is correct, then running it via something with c4droid probably won't work, as it's permissions are whatever group it (c4droid?) was assigned at install.
So, how do does one / can one specify that the package is supposed to be root (uid 0). I'd guess (from a standard UNIX security perspective) that you can't just push arbitrary apps to the machine with 'run me as root' permissions. Otherwise, this would be a completely non-issue. But, is there a package which is pre-installed that we can exploit the permissions of to do this? I don't know yet.
Also, if my readings / assumptions were correct above, we probably don't want to do a setreuid(), but rather call bash/busybox as the 'command' issued in the name of the apk (since it would then run as root, or the uid of the package). Either that, or a system command(s) to chown/chmod the su binary that we can upload via adb (but which comes in as shell.shell).
Did you find the source for run-as somewhere? It would be interesting to look at to see if such a thing is possible. Failing that, it would be interesting to see if there were any sorts of buffer overflows that could be run against it. I've never tried such on arm7, but I've done it under UNIX on x86 and Sparc.
Thanks
Schemm
elschemm said:
Yes. I noticed the permissions on that file as well. I'm not an android person, so I don't know how that end works, but the permissions do look correct (setuid root, and runnable as group shell [which we get via adb, but not locally on terminal].
Based on the little bit that I have read, it seems that it may be getting the permissions assigned to the apk and running the command line with those permissions.
If that is correct, then running it via something with c4droid probably won't work, as it's permissions are whatever group it (c4droid?) was assigned at install.
Click to expand...
Click to collapse
Yes you are correct. setresuid() function will not give you permissions greater than the process its running in
So, how do does one / can one specify that the package is supposed to be root (uid 0). I'd guess (from a standard UNIX security perspective) that you can't just push arbitrary apps to the machine with 'run me as root' permissions. Otherwise, this would be a completely non-issue. But, is there a package which is pre-installed that we can exploit the permissions of to do this? I don't know yet.
Click to expand...
Click to collapse
Its worse than that, the package also has to be debuggable
There is some info out there on how to sing a package with the appropriate system permissions so it would be interesting to actually do this and see what, if anything can be done.
I downloaded the asus unlock package and passed it through the apk tool to see what it does, as it obviously would need root access. As root access is all i require the code it shows is irrelevant really, its the fact that it gains root access with its signature and also the uid that is set in the manifest android.sharedUserID="adroid.uid.system". This and, most importantly android.permission.MOUNT_UNMOUNT_FILESYSTEMS. WIthoput these things we cant change anything in the directories we need
Also, if my readings / assumptions were correct above, we probably don't want to do a setreuid(), but rather call bash/busybox as the 'command' issued in the name of the apk (since it would then run as root, or the uid of the package). Either that, or a system command(s) to chown/chmod the su binary that we can upload via adb (but which comes in as shell.shell).
Click to expand...
Click to collapse
Yes thats what we would do from the run-as command. What I was attempting to see was if I could get a root uid by creating a c program that uses the setresuid() function call thereby bypassing the need to have an appropriate package installed. As it didn't work I'm having dounts whether it would work even if the right package was there. run-as did make reference to package.h which I haven't looked at, so unless there are some system parameters that package.c extracts from the apk I dont really see how this will work...
Did you find the source for run-as somewhere? It would be interesting to look at to see if such a thing is possible. Failing that, it would be interesting to see if there were any sorts of buffer overflows that could be run against it. I've never tried such on arm7, but I've done it under UNIX on x86 and Sparc.
Thanks
Schemm
Click to expand...
Click to collapse
Yeah found the source here
I also searched for linux exploits, there are massive lists of them, most of them patched by now but I assume the linux base in JB would be somewhat different to whats getting around on X86 systems
On anather note I have tried bin4ry's "root many" method , using the restore timing exploit but had no luck.
HX... I looked through the scripts and all the misc files in bin4ry's zip package and could not find anything remotely indicating an injection of the qemu value. It make a symbolic link to the build.prop in com.android.settings...../file99, which was succesfull after pressing restore but thats about it. perhaps I should fire up ubuntu and try the linux script instead of the windows .bat file
Interestingly, this guys root method for the Razr M makes use of Run-as if you look at the batch file.
He is essentially doing a "fake package" install then runs an exe that is some sort of exploit. Finally he uses run-as against what I have to assume is the bug report feature of the droid and asks you to trigger a bug report with a button sequence.
So it seems he is getting something that has root privileges (bug report) to do something that grants SU and also implimenting run-as
http://forum.xda-developers.com/showthread.php?p=32889627#post32889627
I fear that remained a few developers interested in finding a way to root transformer prime with jelly bean, because all of them had tablet already rooted with ics and managed in mantaining rooting across upgrade.
First time posting and I wanted to say thank you to all the excellent talent here on XDA! None of this would have been done without the work of so many people.
I have a Moto G Play (2021) (XT2093-4) that I recently purchased (Best Buy - $159 US/Carrier Unlocked) and I wanted to document my adventure in to rooting, making '/system' RW, and fixing the missing LED notification light (hint: I used the charging light) (hint^2: It's not required to make '/system' RW in order to fix the LED notification light - I just wanted more control over my phone).
First, "OEM unlocking" was greyed out for me, but became available after several days of having the phone online with a SIM card.
I followed the instructions here to unlock the bootloader and root with Magisk (Non-TWRP). Along with these instructions.
Once bootloader is unlocked, you will need the 'boot.img' file from your stock firmware. I used the "Rescue and Smart Assistant" utility to grab a copy of the stock firmware (GUAMNA_RETAIL_QZAS30.Q4_39_35_9_subsidy_DEFAULT_regulatory_DEFAULT_CFC.xml) and extracted the "boot.img" file for the next steps.
Continue installing Magisk (Filenames may be different! Don't just copy and paste.):
Code:
adb install Magisk-v23.0.apk
adb push boot.img /sdcard/Download
(Follow the instruction on your phone to patch 'boot.img' in Magisk)
adb pull /sdcard/Download/magisk_patched-23000_aKKMt.img
adb reboot bootloader
fastboot flash boot_a magisk_patched-23000_aKKMt.img
fastboot flash boot_b magisk_patched-23000_aKKMt.img
You should now have a working, rooted Moto G Play. You can just stop here and have fun with your phone, but I noticed that even with root, the system partition was not RW.
I followed these instructions to make '/system' writable (Note: you will need the 'sysrw_repair.zip' that's included in the bundle and a Linux system):
Code:
adb push systemrw_1.32_flashable.zip /data/local/tmp/
adb shell
su
cd /data/local/tmp/
unzip systemrw_1.32_flashable.zip
cd systemrw_1.32/
chmod +x systemrw.sh
./systemrw.sh in=`ls -l /dev/block/by-name/super | awk '{print $NF}'` out=/data/local/tmp/systemrw_1.32/img/super_original.bin size=50
The phone doesn't have enough space to complete 'lpmake' on the device and will end with an "Error 73" code. Running the "sysrw_repair_v1.32" tool on a Linux machine was a workaround because it pulls the '*.img" files to your local machine then combines them in to a single '.bin' file. But, before I did that, and because it's really annoying, I made some room to stop the phone from complaining about a lack of space:
(Still on the phone's adb)
Code:
rm ./img/super_original.bin
Now, on the Linux machine, I unzipped 'sysrw_repair_v1.32_proper.zip' then commented out line 39 (where it calls the "flash()" function) of the script (sysrw_repair.sh) because I wanted to flash the "super" partition myself.
(On another Linux terminal)
Code:
cd /path/to/unzipped/sysrw_repair/dir/
chmod +x sysrw_repair.sh
./sysrw_repair.sh
This results in a new folder (img) with a rather large bin file (super_original.bin).
(Back on the phone adb)
Code:
exit # Exit root
exit # Exit adb
adb reboot bootloader
Now it's time to flash the fixed bin file to the "super" partition:
Code:
cd /path/to/unzipped/sysrw_repair/dir/
fastboot flash super ./img/super_original.bin
fastboot reboot
You should be able to login and have a writable '/system':
Code:
adb shell
su
mount -o rw,remount /
No errors should appear.
Last, I like having an LED indicator that tells me that I have an SMS/MMS notification waiting. Motorola thought it would be wise to eliminate that feature altogether instead of having the option to enable it. So, I forced it back on using a startup script that dumps the notifications and greps for some key words. And, if it finds something, it "breaths" the charging LED. The script loops until the notification is gone, then keeps checking for new notifications every 30 seconds. (Note: the "/data/adb/service.d/" directory is used by Magisk like an INIT service):
(Still root on the phones adb)
Code:
cd /data/adb/service.d/
cat <<EOF > ledfix.sh
#!/bin/sh
while true; do
if dumpsys notification | egrep NotificationRecord | egrep sms > /dev/null
then
if [[ $(cat /sys/class/leds/charging/breath) == 0 ]]
then
echo 1 > /sys/class/leds/charging/breath
sleep 2
continue
else
sleep 2
continue
fi
elif egrep 'Charging' /sys/class/power_supply/battery/status > /dev/null
then
if [[ $(cat /sys/class/leds/charging/breath) -ne 0 && $(cat /sys/class/leds/charging/brightness) -ne 0 ]]
then
echo 0 > /sys/class/leds/charging/breath
echo 255 > /sys/class/leds/charging/brightness
elif [[ $(cat /sys/class/leds/charging/breath) == 0 && $(cat /sys/class/leds/charging/brightness) == 0 ]]
then
echo 255 > /sys/class/leds/charging/brightness
else
continue
fi
else
echo 0 > /sys/class/leds/charging/breath
echo 0 > /sys/class/leds/charging/brightness
fi
sleep 30
done
EOF
chown 0.0 ledfix.sh
chmod 0755 ledfix.sh
reboot
Now, the charging light will fade off and on about every 2 seconds if there's an SMS/MMS notification waiting. And will check for notifications every 30 seconds. I'm sure someone can come up with a better way of doing this, but this was a nice quick-and-dirty way to get what I wanted.
Hope this helps!
I created an account to say thank you for this, I have already done a good portion, having unlocked the bootloader, the problem is the Rescue Smart Assistant, it won't let me log in, it keeps telling me it can't connect, and the GUI is different because of an update, there is no download button inside the program, only a greyed out rescue button. How did you manage to make the backup Boot.img? Maybe you are using a different OS, and/or version of the program (Not the app, that is already auto-installed), I'm using Windows 10, are you on Linux? I might just need to try from Linux, maybe in a VM.
I was trying to do this before I found this post, and have already installed ADB, the SDK, fastboot, and Motorola Drivers, I just need a way to get the Boot.img, and to patch it, also figure out how to flash it. The last android I rooted with a custom rom was the HTC EVO 4G with Oreo/Jellybean, so I'm a little rusty, but am able to understand technical jargon.
If anyone could help, that would be awesome. I've reinstalled different versions of Rescue Smart Assistant as well, they always upgrade on boot, same problem. I've added exceptions to my firewall and everything.
UPDATE: Was about to post this when I had updated from android 10 to 11 and decided to try logging in again a little closer to my router, to see if the connection was timing out, I think that was the cause, as I can now sign in, and the GUI seems correct from the first appearance. I don't see why I should have any trouble following the rest of the guide, but feel I should share my trials and frustrations anyways, for anyone else experiencing the same,
Thanks again.
PROFSLM said:
I created an account to say thank you for this, I have already done a good portion, having unlocked the bootloader, the problem is the Rescue Smart Assistant, it won't let me log in, it keeps telling me it can't connect, and the GUI is different because of an update, there is no download button inside the program, only a greyed out rescue button. How did you manage to make the backup Boot.img? Maybe you are using a different OS, and/or version of the program (Not the app, that is already auto-installed), I'm using Windows 10, are you on Linux? I might just need to try from Linux, maybe in a VM.
I was trying to do this before I found this post, and have already installed ADB, the SDK, fastboot, and Motorola Drivers, I just need a way to get the Boot.img, and to patch it, also figure out how to flash it. The last android I rooted with a custom rom was the HTC EVO 4G with Oreo/Jellybean, so I'm a little rusty, but am able to understand technical jargon.
If anyone could help, that would be awesome. I've reinstalled different versions of Rescue Smart Assistant as well, they always upgrade on boot, same problem. I've added exceptions to my firewall and everything.
UPDATE: Was about to post this when I had updated from android 10 to 11 and decided to try logging in again a little closer to my router, to see if the connection was timing out, I think that was the cause, as I can now sign in, and the GUI seems correct from the first appearance. I don't see why I should have any trouble following the rest of the guide, but feel I should share my trials and frustrations anyways, for anyone else experiencing the same,
Thanks again.
Click to expand...
Click to collapse
You can also get the firmware from
Lolinet Mirrors
https://t.me/MotoUpdatesTracker
Search for Firmware by codename, software channel, Software Version, and build #
So I wasn't going crazy when I could swear a LED notification light in the upper right side above the screen blinked once whenever I rebooted the phone?
Why would Motorola include such a thing and not utilize it for more than merely a boot up indicator? Like I dont even get to see it come on while charging, it literally only blinks once during boot and that's it.
mario0318 said:
So I wasn't going crazy when I could swear a LED notification light in the upper right side above the screen blinked once whenever I rebooted the phone?
Why would Motorola include such a thing and not utilize it for more than merely a boot up indicator? Like I dont even get to see it come on while charging, it literally only blinks once during boot and that's it.
Click to expand...
Click to collapse
I know!
I don't know what triggers that light to come on. I even waited until the battery was at 6% and the light still never came on.
So, I updated the script above to make the light go full brightness if the battery is charging. The order matters, so if a notification comes in while charging, it'll "breath" the LED. Also, if the battery is full, then the light will turn off. Kind of telling you that it's time to unplug.
I followed these steps and my touch screen stopped working. I had previously installed twrp already on it while trying to learn how to root it, and when i boot into fastboot it goed through twrp, i also used the boot.img file from lolinet, not sure which of these caused the issue. Interestingly though, the touch screen does work whilst in twrp. any suggestions on how to fix or what would be causing it? Phone does work with usb mouse over OTG
jorduino said:
I followed these steps and my touch screen stopped working. I had previously installed twrp already on it while trying to learn how to root it, and when i boot into fastboot it goed through twrp, i also used the boot.img file from lolinet, not sure which of these caused the issue. Interestingly though, the touch screen does work whilst in twrp. any suggestions on how to fix or what would be causing it? Phone does work with usb mouse over OTG
Click to expand...
Click to collapse
Are you absolutely sure you used the correct boot.img from an image version exactly matching your phone variant version?
mario0318 said:
Are you absolutely sure you used the correct boot.img from an image version exactly matching your phone variant version?
Click to expand...
Click to collapse
Im not completely sure how to get the right file, but I think the first time it was the wrong one, but then when i got what i thought was the right one, it just didn't work at all and I had to recovery flash it. I had just updated so maybe the correct image wasn't available yet. Im going to try again though
Oh! Hello @latentspork. Thanks for your interest in my SystemRW project. I just came across this thread randomly...
I'm happy you got my script to work on your Motorola device by using the included sysrw_repair script
Please feel free to send me your log files from script folder. Thanks. It's useful for further development of the script
latentspork said:
The phone doesn't have enough space to complete 'lpmake' on the device and will end with an "Error 73" code. Running the "sysrw_repair_v1.32" tool on a Linux machine was a workaround because it pulls the '*.img" files to your local machine then combines them in to a single '.bin' file. But, before I did that, and because it's really annoying, I made some room to stop the phone from complaining about a lack of space:
Click to expand...
Click to collapse
That's not 100% accurate. Lpmake error 73 means CAN'T_CREATE and has nothing to do with error 70 (insufficient space).
To this day I still don't know exactly what causes error 73 on some devices (mostly Motorola and others) but it looks like some kind of kernel panic. If anyone knows how to avoid this error 73 in Android please let me know! Thanks!
Yes that's true the included sysrw_repair script (Linux only) pulls the image files from the phone to your computer and attempts to run the same lpmake command with the same arguments that just failed with error 73 on the phone itself and now all of a sudden it just works in Linux. Go figure.
latentspork said:
(Still on the phone's adb)
Code:
rm ./img/super_original.bin
Click to expand...
Click to collapse
Why would you delete the super_original.bin ? That's your stock read-only super image which by default is automatically dumped by script for backup purposes in case you ever get a bootloop.
And if you launch the script by specifying a custom input value (in=x) like in your example above then you won't even have a super_original.bin file to begin with because script will skip the whole dumping of original super image process.
latentspork said:
This results in a new folder (img) with a rather large bin file (super_original.bin).
Click to expand...
Click to collapse
I think you mean super_fixed.bin
latentspork said:
Now it's time to flash the fixed bin file to the "super" partition:
Code:
cd /path/to/unzipped/sysrw_repair/dir/
fastboot flash super ./img/super_original.bin
fastboot reboot
Click to expand...
Click to collapse
Here in your instructions you are manually flashing the wrong file. Shouldn't you be flashing super_fixed.bin to your super partition?
Usually I only flash the super_original.bin to get back out of a bootloop...
latentspork said:
Now, on the Linux machine, I unzipped 'sysrw_repair_v1.32_proper.zip' then commented out line 39 (where it calls the "flash()" function) of the script (sysrw_repair.sh) because I wanted to flash the "super" partition myself.
Click to expand...
Click to collapse
See that's why I included that automatic flash() function in the repair script. Then you don't have to worry about manually flashing the wrong file to your super partition
Enjoy a fully read/write-able device!
Great news! New SystemRW version coming soon!
@lebigmac
I really appreciate the reply and the tool! It did work really well on my model (XT2093-4).
That's not 100% accurate. Lpmake error 73 means CAN'T_CREATE and has nothing to do with error 70 (insufficient space).
To this day I still don't know exactly what causes error 73 on some devices (mostly Motorola and others) but it looks like some kind of kernel panic. If anyone knows how to avoid this error 73 in Android please let me know! Thanks!
Click to expand...
Click to collapse
I only assumed that "Error 73" was caused by insufficient space, because the phone really did run out of space. I noticed that the phone was out of space because I got a home screen notification warning, asking me to free up space. I confirmed it with a "df -h" at the shell. Apparently, the OS takes up almost 15GB. When you add the ".img" files, there's only about 5GB left. There wasn't enough room to complete the ".bin" file. Maybe I could have used an SD card or something.
You're probably correct in that "Error 70" is the correct error for that, but on my phone, I never saw that error. I did notice that the tool was still trying to write data as the phone ran out of space, then it would throw the "Error 73". Maybe it didn't register the lack of space, or just an oddity with my model? No idea.
Why would you delete the super_original.bin ?
Click to expand...
Click to collapse
This is the file that was created when I initially ran the "./systemrw.sh" command on the phone. The result of running the command on the phone were several ".img" files and a very large "super_original.bin", but it was incomplete because the command threw an "Error 73". I was following your instructions, and I noticed that the output name of the file was "original" instead of "fixed". I probably could of outputted it to a new name to reduce confusion, but I didn't really care too much about the name as long as I had a working file.
I think you mean super_fixed.bin
...
Shouldn't you be flashing super_fixed.bin...
Click to expand...
Click to collapse
Normally, yes. But the Linux script also outputted the filename "super_original.bin". Again, as long as it worked, I was okay with it. The commands I used above were the exact commands that I ran at the time. I copied them from the terminal consoles I was using. So I don't know why it wasn't outputting the correct filename (again, I was following your instructions and was a little confused that the names came out differently - I just figured I was doing something wrong like not use the proper output command or something).
Then you don't have to worry about manually flashing the wrong file to your super partition...
Click to expand...
Click to collapse
I was really just being cautious because my previous phone broke and I didn't have a fallback.
But, at no point were there two bin files (original and fixed), so there wasn't much confusion. Where I originally had just ".img" files before running the script, I now had a single ".bin" file. I knew that was the file I needed.
But again, thank you for all the hard work on this tool! I was reading that it's worked on lots of different model phones, and it's always good to see the open source community doing things that help all kinds of people.
For moto notification for this phone at least use https://play.google.com/store/apps/details?id=br.com.itsmeton.motoledreborn or moto led reborn from the play store it just works
Hi, sorry. This can be removed. I put it in place because I was having issues with the xda app. For whatever reason, every time I tried to share this particular post, it would share a link for the post which I used originally, rather than the current post. I knew that if I commented I could get back here easily on my PC.
So what is the place holder for