NOTE: DO NOT DO THIS UNLESS YOU KNOW WHAT YOU ARE DOING, YOU CAN EASILY SCREW UP YOUR SYSTEM, AND THIS WON'T HELP YOU.
BACKUP FIRST, AND MAKE SURE YOU HAVE A SETUID SH AS ROOT SO YOU CAN RECOVER FROM BACKUPS IF NECESSARY.
First you have to re-sign framework-res.apk using testkeys. This will allow you to use testkeys for system uid packages.
Next step is to re-sign all other apks that use shared uid system.
That is: bootinfo, Fota, GoogleCheckin, GoogleSubscribedFeedsProvider, NetworkLocation, ServiceMenu, Settings, SettingsProvider, VpnServices
Next you have to re-sign all apks that use the platform key, which turns out to be the shared uid phone - these require implicit permissions from the platform like DEVICE_POWER:
TelephonyProvider, Stk, semc-backup-rachael, Phone
Finally, I think GoogleEnhancedSearch also needs it or something otherwise a settings menu will fc.
The nice part about re-signing is that you don't actually need to deodex the files.
One important thing is that in the new versions, the fota.action.DEBUG_ENTRY is actually disabled, and moreover, requires special permissions that aren't granted. This is where re-signing comes in.
Now, you need to deodex fota.apk, modify the manifest to remove permissions required for DEBUG_ENTRY, and finally, force enable the debug menu:
In com/sonyericsson/android/fota/common/fotaview/FotaDebugEntry.smali,
find "debug UI is not available!"
a few lines above, there is if-nez v0 :cond_0
change it to if-eqz v0 :cond_0
This forces it to enable the debug menu.
Now we re-smali the Fota.apk, re-sign, then push it on to the phone along with the rest of the modified packages.
Repush all the files to the phone and it's done
problem !
baksmali gives an error at fota.apk
can you post your deodex scrypt
Why is this required?
TechGuru_x10 said:
Why is this required?
Click to expand...
Click to collapse
So that you won't have to keep re-flashing the older firmware to root (and keep re-installing stuff afterwards), and it should save time in repairing your firmware if you mess system files up.
It should also allow us to upgrade to newer firmwares from the current one, so we don't have to lose all of our apps/settings when rooting our phones again with a newer firmware.
Is this right guys? Anyway, thanks and good luck!
jerpelea said:
problem !
baksmali gives an error at fota.apk
can you post your deodex scrypt
Click to expand...
Click to collapse
You need to add the classpath by deodexing everything in the framework folder and including it.
zephyrix said:
You need to add the classpath by deodexing everything in the framework folder and including it.
Click to expand...
Click to collapse
oki
will try
thanks
found my error
i was using smali1.2.2 tested with 1.2.3 and is working
jerpelea said:
oki
will try
thanks
found my error
i was using smali1.2.2 tested with 1.2.3 and is working
Click to expand...
Click to collapse
Could these steps be made into a script, to run everything at once? Or at least in sections?
Daneshm90's autodeodexer 2.3 modified by me for X10
http://hotfile.com/dl/53736770/16a1bc8/Deodexer_2_3_SE.rar.html
So eventually (with this) we can take a newer build and run this script thus allowing us to then run the files necessary for root?
what do you mean by newer builds like R2BA020
Sorry if Im being a noob but lets say I mess up a framework file and get stuck at the bootscreen. When I try to use adb to push my backup it says permission denied. Will this allow me to make the changes?
Well what I've done is use a modified adb which runs as root and replaces on boot. However, I believe you could use a setuid sh and achieve the same result.
i.e. cp /system/bin/sh /system/bin/rootsh
chmod 6755 /system/bin/rootsh
then you can push to a folder where you can normally write, and use rootsh and move it.
Great thanks, I'm going to wait until I have to try it...
Related
HI all I have my Eris flashed to Cricket or Metro PCS, and I want to put a new rom on it. The guy who flashed it put a 2.1 update on it for me and told me he couldn't add the rom I gave him on my phone because it was flashed. So my question is am I stuck with the version I'm running or can I load different custom roms along with it being flashed??
Thanks
i have mine flashed to cricket. and I have changed to several roms, i of course was able to root the phone. so if yours is rooted then you should be able to switch roms.. i am not expert so if i am wrong please somebody correct me
Okay thanks for the reply, So can you help me out because I don't know where to start as far as adding a new rom. Do I need to re-flash to cricket after adding a new a new rom or will the flash still work and its just replacing certain things?
jcaf77 said:
i have mine flashed to cricket. and I have changed to several roms, i of course was able to root the phone. so if yours is rooted then you should be able to switch roms.. i am not expert so if i am wrong please somebody correct me
Click to expand...
Click to collapse
Okay thanks for the reply, So can you help me out because I don't know where to start as far as adding a new rom. Do I need to re-flash to cricket after adding a new a new rom or will the flash still work and its just replacing certain things? SORRY FOR DOUBLE POST!!!!
Puxxie said:
Okay thanks for the reply, So can you help me out because I don't know where to start as far as adding a new rom. Do I need to re-flash to cricket after adding a new a new rom or will the flash still work and its just replacing certain things?
Click to expand...
Click to collapse
power off your phone, once off, hold the volume down key while you press the power button if you see a recovery menu telling you, reboot, install from sd card, wipe etc.. then all you do is wipe the data and then install the rom...
but the main thing is to know that you have root access and recovery image
It will not erase what was written with QPST but the proxy will have to be setup again. I use many roms and just run the same setup for getting the proxy on there working.
jcaf77 said:
power off your phone, once off, hold the volume down key while you press the power button if you see a recovery menu telling you, reboot, install from sd card, wipe etc.. then all you do is wipe the data and then install the rom...
but the main thing is to know that you have root access and recovery image
Click to expand...
Click to collapse
Okay I know that much, how do I now if I have root access and recovery image?
jcaff77's advice is missing a whole lot.
YES, Before you flash ANY ROM, boot into Recovery (power off your phone, then power it on with Volume Up + Power) then go to Backup/Restore, then do a nand backup.
THIS way, you can ALWAYS go back to the flash that you're on. The guy that gave you that flash has NO idea what he's doing, and shouldn't be charging people money to flash things. Tell him he's basically a hack and a con artist because the information to do this is FREE and ALL around the internet. Tell him you're never going to ask for his help again, because he didn't really help you, he just took your money.
Anyway,
I posted a full tutorial that token419 from HowardForums put together to do this to ANY ROM. Your phone will stay on Cricket in general through flashing ROMs, but to make ANY ROM work FULLY on Cricket, follow this:
(from http://androidforums.com/all-things...ully-cricket-root-reqd.html?highlight=cricket )
Requirements:
Rooted Rom
Autostart (Root) from android market (free)
u2nl.zip from white rabbits site whiterabbit.org (hit Android stuff at the bottom, then get the pre-compiled Droid binary - Eris is included in that file)
Following Brandon's Guide and replace the internet portion with the steps listed below
Step 2. Setting up
What you need: u2nl.zip from white rabbits site whiterabbit.org
install Autostart (Root) from android market
Unzip the u2nl.zip to your androidsdk/tools folder so that u2nl and autostart.sh are in your androidsdk/tools folder. (use the autostart.sh that's in the Eris folder, not the one in the Droid folder!)
adb shell su
(look on phone to push 'Allow' or 'Always Allow' if it pops up - if not, then move to the next line)
mount -o rw,remount /dev/block/mtdblock3 /system
cd /data/
mkdir opt
chmod 0777 /data/opt/
chmod 0777 /system/bin/
exit
adb remount
adb push autostart.sh /data/opt/autostart.sh
adb push u2nl /system/bin/u2nl
adb shell
chmod 0777 /data/opt/autostart.sh
chmod 0777 /system/bin/u2nl
reboot
click always allow on the prompt to allow the Autostart app to run at system startup
Reply or PM me if you need help with it especially. Go ahead and flash a ROM with it. If you can't get all of this done, your phone will STILL WORK, just not all the apps, Browser Only. For a temporary Browser Only fix, just download AnyCut from the Market on your current phone flash, use AndroZip or ES File Explorer or IO File Manager or ANY program that can 'back up' apps, to back it up, then flash the NEW ROM you want, and Market won't work (until you do the instructions above). Again, to get Web to work, make a shortcut with AnyCut > Activity > Proxy, and click the Proxy shortcut you made. Set Proxy to wap.mycricket.com port 8080.
Like I said, I'll follow this thread, so just reply if you get stuck on any of those steps.
@pkopalek thanks..yeah I had a feeling he didn't know what he was doing and he was just trying to get paid. Well I'm going to try what you posted for me now and will be back to post mt status or PM and THANK YOU for you help I appreciate it.
Puxxie said:
@pkopalek thanks..yeah I had a feeling he didn't know what he was doing and he was just trying to get paid. Well I'm going to try what you posted for me now and will be back to post mt status or PM and THANK YOU for you help I appreciate it.
Click to expand...
Click to collapse
Yeah, just write back, I'll see it for sure. I did this to my girlfriend's phone, and many others, for free.
Enjoy.
this is funny
You'll also want to make sure you extract your telephony.db from /data/data/com.android.providers.telephony/databases/ to maintain MMS functionality with a new ROM, since the ROMs you'll use will probably be built for Sprint or Verizon.
You'll need RootExplorer on your phone to go to the above directory -> copy -> paste to your sdcard. Restore it to the same directory once you're new ROM is installed OR download and setup AndroidSDK (google it) and use adb to pull the file;
Code:
adb remount
adb pull /data/data/com.android.providers.telephony/databases/telephony.db
The file will end up in your /tools/ directory of the AndroidSDK.
Once you're new ROM is installed, you can use the SDK to push it back as well;
Code:
adb remount
adb push telephony.db /data/data/com.android.providers.telephony/databases/
adb reboot
That should restore MMS to your phone once you have the new ROM installed
-mak
.mak said:
You'll also want to make sure you extract your telephony.db from /data/data/com.android.providers.telephony/databases/ to maintain MMS functionality with a new ROM, since the ROMs you'll use will probably be built for Sprint or Verizon.
You'll need RootExplorer on your phone to go to the above directory -> copy -> paste to your sdcard. Restore it to the same directory once you're new ROM is installed OR download and setup AndroidSDK (google it) and use adb to pull the file;
Code:
adb remount
adb pull /data/data/com.android.providers.telephony/databases/telephony.db
The file will end up in your /tools/ directory of the AndroidSDK.
Once you're new ROM is installed, you can use the SDK to push it back as well;
Code:
adb remount
adb push telephony.db /data/data/com.android.providers.telephony/databases/
adb reboot
That should restore MMS to your phone once you have the new ROM installed
-mak
Click to expand...
Click to collapse
Actually, APN Backup & Restore already does this job.
If you use mak's way, you won't be needing APN Backup & Restore.
Both methods will work perfectly well.
pkopalek said:
Actually, APN Backup & Restore already does this job.
If you use mak's way, you won't be needing APN Backup & Restore.
Both methods will work perfectly well.
Click to expand...
Click to collapse
Was APN Backup suggested previously? I didn't notice if it had been, sorry.
I also can't speak to the validity of a program I've never used, but I suppose it would be much easier for the OP to use that than adb.
-mak
you can follow the guide here
http://forum.xda-developers.com/showthread.php?t=675652
Use the zip to flash from recovery that i created, there are 2 zips, one for just internet, and one for internet + MMS, some say the internet + MMS doesnt work, which is why i provided just an internet one as well.
As always make a nandroid backup first and have fun.
Since your phone is already flashed, disregard all the QPST stuff and simply look at the setting up web/mms portion of the guide.
The zip for MMS + Web works great for me, but your mileage may vary
Good luck and have fun
token419 said:
you can follow the guide here
http://forum.xda-developers.com/showthread.php?t=675652
Use the zip to flash from recovery that i created, there are 2 zips, one for just internet, and one for internet + MMS, some say the internet + MMS doesnt work, which is why i provided just an internet one as well.
As always make a nandroid backup first and have fun.
Since your phone is already flashed, disregard all the QPST stuff and simply look at the setting up web/mms portion of the guide.
The zip for MMS + Web works great for me, but your mileage may vary
Good luck and have fun
Click to expand...
Click to collapse
The MMS flashes the APNs, but the APN has to be specific for your phone number on your device (in my experience), so I wouldn't expect MMS to work for anyone but you, Token!
I'd stick with editing the APNs to get MMS working, but thanks for the internet patch!
THanks for all the info guys but I'm stuck on how to add a new recovery image using either the EMA it keeps saying it can't find my device state?
Why?
init.d allows to run scripts at system startup (reboot) of Linux and Android devices. On the Sony Tablet S it is not supported on "stock" ROM. Therefore it is not possible to execute shell scripts at the boot process.
For what?
As mentioned above, primarily for startup scripts. It can be used for 'mounting ext.sdcard to int. sdcard' for example or it is also possible to integrate kernel modules or system tweaks boot time.
How?
This requires copying the files in the enclosed zip archive to the corresponding points and to change the permissions right. Firstyou must create the folder 'init.d' at '/system/etc'.
But now "Step-by-Step":
Requirements:
You need to use Root Explorer, adb or something else. I do not want to explain each step in detail. If you have not the necessary basic knowledge you should not do this because it is deeper system change, which could end with a brick or boot loop. That would not 'the end of the world', if you have previously prepared you system for this before and know what to do this case. I am not responsibility for damage or other any problems.
Everything is done at your own risk.
Step-by-Step Instructions:
1. Create in '/system/etc' a 'init.d' folder
2. Change the access rights to '777'
3. Copy the file 'sysinit' into folder '/system/bin'
4. Change the access rights to '755'
5. Copy file 'install-recovery.sh' into folder / system / etc '
6. Change the access rights to '777'
7. Copy file 'run-parts' into folder '/system/xbin'
(If 'run-parts' already existing, you can skip Step 7 and 8. In my case it was already on the Tablet S)
8. Change the access rights to '777'
9. Copy file '99test file' into folder '/system/etc/init.d'
10. Change the access rights to '777'
Now finished .... it should work !
After next reboot take a look into the folder 'data/local/tmp'. You should find a file 'init.d_log_test.txt', created by the test script. If so, everything works fine and now you can put there your own scripts under 'init.d'. Now you can delete the test script or if you like adjust it for your own tests.
Have fun with the new 'init.d' support and apologize for my weak English !!
Special thanks to DooMLord for the idea and first implementation.
Source: http://forum.xda-developers.com/show....php?t=1431134
am I missing something here, or where is the zip-file?
the link doesn't work at the bottom.
Thanx for a nice "how-to"
Seems simple and straightforward enough
Sorry for that and thank you for the hint. I was 100% sure that I enclosed the zip ... but it looks like I am getting old. ;-)
Now you should find the zip on the end of first post.
Sorry - how do you gve the 777 file permissions?
SWFlyerUK said:
Sorry - how do you gve the 777 file permissions?
Click to expand...
Click to collapse
Via the chmod unix command, or if you are using root explorer just enable read/write/execute permissions for owner, group, and others. For 755 give owner all permissions and only read/execute to group and others.
Whoops, my device is in a bootloop lol
I hope you are joking ...
@Rumball
Sorry, but you are wrong ...
755 give owner all permissions and only read/execute to group and others.
4=read
2=write
1=execute
I'm not joking, the permissions error is obviously the reason its in a bootloop then, fantastic.
What does it mean? Did you set wrong file permissions and reboots system? On all files or only on one specific? Did you changed build.prob and downloaded system update for boot loop prevention before?
obicom said:
I hope you are joking ...
@Rumball
Sorry, but you are wrong ...
755 give owner all permissions and only read/execute to group and others.
4=read
2=write
1=execute
Click to expand...
Click to collapse
Doh! Thanks
SWFlyerUK said:
I'm not joking, the permissions error is obviously the reason its in a bootloop then, fantastic.
Click to expand...
Click to collapse
Not permissions fault. Mine didn't bootloop
obicom said:
Special thanks to DooMLord for the idea and first implementation.
Click to expand...
Click to collapse
yep, DooMLord's great work.
got finished autoinstall tool for init.d as I said to you on thursday.
That sounds great ...
let us share your file ...
it makes it much easier for the other members ..
if you allow I could add it to the first post ...
with a special thx for Condi ;-)
obicom said:
That sounds great ...
let us share your file ...
it makes it much easier for the other members ..
if you allow I could add it to the first post ...
with a special thx for Condi ;-)
Click to expand...
Click to collapse
hah not important, just good to see that there are some people who are working on making our devices better and better the more of us = more of cool tab stuff
auto-install up, try it, tested so far only on one device.
I changed nothing in the build.prop.
All I did was follow the instructions to your post and change the permissions as said by the chap above.
I'm now in a boot loop. My own fault for doing it but you don't expect posted information on permissions to be incorrect...
Can't follow your comment ...
Nothing is wrong with the information regarding permissions.
I did exactly the same on my Tab and one hour ago via Teamviewer on a second one.
I am not responsible if you did something wrong. Specially if you did not follow my hint to do first all regarding "boot loop prevention"
If you have not the necessary basic knowledge you should not do this because it is deeper system change, which could end with a brick or boot loop. That would not 'the end of the world', if you have previously prepared you system for this before and know what to do this case. I am not responsibility for damage or other any problems. Everything is done at your own risk.
Click to expand...
Click to collapse
SWFlyerUK said:
I changed nothing in the build.prop.
All I did was follow the instructions to your post and change the permissions as said by the chap above.
I'm now in a boot loop. My own fault for doing it but you don't expect posted information on permissions to be incorrect...
Click to expand...
Click to collapse
I wrote in many threads about 'rescue-backdoor', why havent you made it?
I did condi ie got my ota firmware. Rolled the build.prop increment value back. But I get a verification cation error so everything was prepared.
That was the background regarding 'did you changed build.prob' and not as a reproach. I can not understand why someone try something out, without a backup or rescue strategy. Oh damn !!
-- Edit --
Rolled the build.prop increment value back
Click to expand...
Click to collapse
Does it mean now you have the original value or the lower value?
If first case , that was a fault.
SWFlyerUK said:
I did condi ie got my ota firmware. Rolled the build.prop increment value back. But I get a verification cation error so everything was prepared.
Click to expand...
Click to collapse
The key to 'rescue' is to leave modified build.prop. It fakes that you've got older firmware than zip (zip=device the same versions). Then you get in recovery, and got opportunity to reflash the same version!
Wanted to share this with fellow amaze users. It's a collection of scripts/binaries that will seamlessly reodex your /system/app and /system/framework folders. This will give you a noticeable increased in overall speed/fluidity, boot times, ram usage... I generally prefer to re-odex anything I use. Major downside to re-odexing is that you can't easily modify the APK. But honestly, it's not that difficult to simply deodex the APK in question, mod/theme it, then reodex it. I find the benefits are well worth it.
The original script was created by tommytomatoe. All credit goes to him for the actual creation of this script. I simply made a windows batch file to ease the setup and execution of said script.
Please PLEASE PLEASE make a NANDROID backup before you run this. I've never had it mess anything up, but who knows... just back up and be safe!..
ZIP is attached below. Unzip into any directory (make sure the files stay together) and run Dexo.bat - You MUST HAVE BUSYBOX, WORKING ADB (Wireless ADB support is built into the batch file), and ROOT!
I originally had a quick batch file made for just myself.. but I changed things around and made it a bit more user friendly and other things.... I've only tested it ONCE on my own device once (the modified one).. so just be warned.. and make a backup first!
The batch file will not close on its own, when it's done the device will reboot on its own. You can simply just close the window.
Hope this helps some people! Good luck.
--------------------
[What is Odex?]
During the build process, Android can be built with the flag “WITH_DEXPREOPT=true”. This means that the dex files are preoptimized in the build environment using a dalvikVM on the host, as opposed to optimized during boot on the device. The dex-preopt process results in two files per apk or jar – the jar/apk file and its accompanying .odex file.
----------------------
[What is so tricky about reodexing?]
Due to the nature of the dalvik VM (according to documentation in AOSP), the VM expects the optimization process to follow the strict BOOTCLASSPATH.
/* There are some fragile aspects around bootclasspath entries, owing
* largely to the VM's history of working on whenever it thought it needed
* instead of strictly doing what it was told. If optimizing bootclasspath
* entries, always do them in the order in which they appear in the path.
*/
So that is the dex-preopt during the build time. All the vendors ship devices with Odex, ie, stock ROMs are odex. What about ROMs that have been deodexed? Or how do you go about editing the smali code from the odex files? Thank goodness for JesusFreke, we have baksmali and smali. Using the two in sequence, one can successfully convert the optimized dalvik executable (odex) and dissemble it into a human readable (sorta) language called “smali”, created by JesusFreke and resembles the Jasmin language. Anyways, carrying on. Using the dexopt-wrapper binary, you can re-odex your ROM after it has been deodexed. This sounds pretty simple but as stated above, the VM expects the optimization to follow the BOOTCLASSPATH. You cannot silly nilly deodex android.policy.jar and then re-odex it. Your device will not boot. You must transfer the original “signature” from the original odex file to the newly created (Hint, dd if=original.odex of=new.odex bs=1 count=20 skip=52 seek=52 conv=notrunc). This can be done on a Linux machine or with the busybox binary.
OK. So what is this tool? I just wanted to give a brief (or not so brief) overview of the process. This tool doesn’t deal with partially odexed ROMs. This tool is for odexing a ROM that is completely DEODEX.
The benefits? Faster boot, smaller imprint on /data/ partition, overall faster feeling. The phone will generally just run a little bit faster, system apps will launch quicker..
The myths? I can’t theme ODEX! WRONG! You can theme odex just fine! Just use baksmali and smali.
This requires BUSYBOX.
This requires ADB.
Again HUGE THANKS to tommytomatoe for the original script and his original efforts.
THIS ZIP FILE IS NOT FLASHED IN RECOVERY! You simply extract it to a folder on your hard drive. Then run Dexo.bat, follow on screen instructions. Make sure to nandroid as well as having phone plugged in VIA USB with debugging enabled, or have wireless ADB ready to go.. batch file supports wireless. Just have to follow prompts and enter IP.
ericdjobs said:
Wanted to share this with fellow amaze users. It's a collection of scripts/binaries that will seamlessly reodex your /system/app and /system/framework folders. This will give you a noticeable increased in overall speed/fluidity, boot times, ram usage... I generally prefer to re-odex anything I use. [/B][/SIZE]
Click to expand...
Click to collapse
Tried this on my ICS ROM and it works fine.
Thanks!
Doesn't work for me :/
Sent from my HTC Ruby using xda app-developers app
avenged_sevenfold27 said:
Doesn't work for me :/
Sent from my HTC Ruby using xda app-developers app
Click to expand...
Click to collapse
Oh! It's not supposed to be flashed in recovery!
Sorry if I wasn't clear on that.
It's a script and a batch file. The batch file will make uploading the script, changing permissions, etc etc etc, a lot more intuitive and easier.
You simply need to extract the ZIP anywhere on your harddrive (Have to be using windows for the batch file to work.. if you're running Linux i'm sure you can figure out how to do it manually anyways) Make sure to keep all the files in the same folder.
Then simply execure dexo.bat and follow the prompts. Make sure you have the phone plugged in via USB and USB debugging enabled.. or have Wireless ADB running (batch has built in support for wireless ADB)
You can run it while the phone is on. The phone will reboot itself when the script is finished.
ericdjobs said:
Oh! It's not supposed to be flashed in recovery!
Sorry if I wasn't clear on that.
It's a script and a batch file. The batch file will make uploading the script, changing permissions, etc etc etc, a lot more intuitive and easier.
You simply need to extract the ZIP anywhere on your harddrive (Have to be using windows for the batch file to work.. if you're running Linux i'm sure you can figure out how to do it manually anyways) Make sure to keep all the files in the same folder.
Then simply execure dexo.bat and follow the prompts. Make sure you have the phone plugged in via USB and USB debugging enabled.. or have Wireless ADB running (batch has built in support for wireless ADB)
You can run it while the phone is on. The phone will reboot itself when the script is finished.
Click to expand...
Click to collapse
It goes through all the prompts for me, but then on the final "Press any key to continue" when I press any key, the batch file just closes with nothing being done to my phone.
Guess I should add, I'm using windows xp, and yes, usb debugging is enabled
masondoctorjt said:
It goes through all the prompts for me, but then on the final "Press any key to continue" when I press any key, the batch file just closes with nothing being done to my phone.
Guess I should add, I'm using windows xp, and yes, usb debugging is enabled
Click to expand...
Click to collapse
Hmm strange. I guess I should add instructions to do it manually, just in case something like this happens
Basically just open a command prompt, navigate to wherever you unzipped everything...
adb root
adb remount
(adb connect again here if using wireless)
adb push dexo /system/bin
adb push dexopt-wrapper /system/bin
adb push zip /system/xbin
adb push zipalign /system/xbin
adb shell chmod 755 /system/bin/dexo /system/bin/dexopt-wrapper /system/xbin/zip /system/xbin/zipalign
then the final command
adb shell dexo
let me know where at in this process it's getting snagged if that doesn't work.
ericdjobs said:
Hmm strange. I guess I should add instructions to do it manually, just in case something like this happens
Basically just open a command prompt, navigate to wherever you unzipped everything...
adb root
adb remount
(adb connect again here if using wireless)
adb push dexo /system/bin
adb push dexopt-wrapper /system/bin
adb push zip /system/xbin
adb push zipalign /system/xbin
adb shell chmod 755 /system/bin/dexo /system/bin/dexopt-wrapper /system/xbin/zip /system/xbin/zipalign
then the final command
adb shell dexo
let me know where at in this process it's getting snagged if that doesn't work.
Click to expand...
Click to collapse
Thanks... It might be a couple of days before I have a chance to try this again, but I'll let you know if this way works.
Sent from my HTC_Amaze_4G using xda app-developers app
Just ran the manual instructions since I had the same error noted above and all goes well until after the last adb shell dexo command; I get a message saying everything is installed but I also see this: Please install these binaries to continue: sed cp unzip. What does that mean?
Edit: I went ahead and rebooted anyway and nothing happened, still deodexed.
How can you tell if the custom rom you're on is dedoxed or redoxed? I'm on the ViperA
Sent from my HTC_Amaze_4G using xda app-developers app
kevinrubio1 said:
How can you tell if the custom rom you're on is dedoxed or redoxed? I'm on the ViperA
Sent from my HTC_Amaze_4G using xda app-developers app
Click to expand...
Click to collapse
Use root explorer or some similar app and go into system/apps and if you see any files right next to the app files that say .odex then you are not deodexed.
Also most custom ROM's state right in the OP if the are deodexed or not.
Sent from my HTC_Amaze_4G using Tapatalk 2
I don't have access to computer so can I run commands through terminal emulator?
Sent from my gt-1900 using xda premium
Doesn't work as of yet...
Followed the instructions
BusyBox Rooted S-off on ViperAmaze 1.7.1 ran the script as Admin and phone restarted after completion of script and stuck on bootscreen.
running fix permission and wiping dalvik+cache just in case if it works will report back EDIT: doesn't work had to recover nandroid
Can anyone dumb this thread down to what deodex/odex means to a person with no dev skills or
What can I do with deodex apks?
Is this a significant boost in speed etc?
Dumb and Dumber (remember the movie?)
blindskater39 said:
Can anyone dumb this thread down to what deodex/odex means to a person with no dev skills or
What can I do with deodex apks?
Is this a significant boost in speed etc?
Click to expand...
Click to collapse
When a Carrier releases a version of software it is ODEXED meaning you have an app like camera.apk, and you have a camera.odex
It's a file that contains the libraries and other things to support the apk.
When you DE-ODEX you build all of the stuff into the apk file so you don't need the .odex files.
it reduces the nuber of files in the rom. Meaning you now only have a camera.apk with no .odex file.
RE-ODEXING the apps and files makes it run faster.
That is taking the files back out of the apk file so you have two files again.
It seems easier to take DE-ODEXED files from one rom and use them in another rom, but you cannot just copy an apk that hasn't been DE-ODEXED into another rom without its' associated odex file.
How's that?! Hope it helps!
Looks like.... IT WORKS on Super Sense 3.2 (coming very soon)! This will speed it up big time!
chevycowboyusa said:
When a Carrier releases a version of software it is ODEXED meaning you have an app like camera.apk, and you have a camera.odex
It's a file that contains the libraries and other things to support the apk.
When you DE-ODEX you build all of the stuff into the apk file so you don't need the .odex files.
it reduces the nuber of files in the rom. Meaning you now only have a camera.apk with no .odex file.
RE-ODEXING the apps and files makes it run faster.
That is taking the files back out of the apk file so you have two files again.
It seems easier to take DE-ODEXED files from one rom and use them in another rom, but you cannot just copy an apk that hasn't been DE-ODEXED into another rom without its' associated odex file.
How's that?! Hope it helps!
Click to expand...
Click to collapse
For the most part its much easier to comprehend, thanks! But why can't you copy a de-odexed apk to another rom if it doesnt which doesnt need the .odex files anymore?
blindskater39 said:
For the most part its much easier to comprehend, thanks! But why can't you copy a de-odexed apk to another rom if it doesnt which doesnt need the .odex files anymore?
Click to expand...
Click to collapse
You can. I'm sorry if I complicated that part..
Sent from my HTC_Amaze_4G using xda app-developers app
this may be a stupid question but will this work on cm11?
dtr145r said:
this may be a stupid question but will this work on cm11?
Click to expand...
Click to collapse
No, CM11 is already deodexed.
SuperAfnan said:
No, CM11 is already deodexed.
Click to expand...
Click to collapse
well yea,
i know that.
thats the point, to 'RE-Odex' it....
Tried every method...but I'm unable you protect my backups in titanium backup
To protect*
How I solved this problem on my Moto G LTE
Shantanu Baviskar said:
Tried every method...but I'm unable you protect my backups in titanium backup
Click to expand...
Click to collapse
I carefully read this thread: [Help] Titanium Backup PRO - protected archive not working.
So I modified file /system/etc/permissions/platform.xml according http://jrummy-apps.com/fix-sdcard-on-kitkat/ and make new file /data/local/userinit.sh with this content:
Code:
#!/system/bin/sh
busybox mount -o remount,rw /
chmod 770 /mnt/media_rw
See the attached archive root.zip which I made for you it is pretty straightforward.
You should have move your TiB backup folder on this path: /mnt/media_rw/sdcard1/TitaniumBackup
You will be able to protect backup archives in Titanium Backup Pro then.
PS: If /data/local/userinit.sh doesn't start automatically in your ROM you can use for example Scripter feature in ROM Toolbox Pro and import userinit.sh script and set it as Start at boot.
_jis_ said:
I carefully read this thread: [Help] Titanium Backup PRO - protected archive not working.
So I modified file /system/etc/permissions/platform.xml according http://jrummy-apps.com/fix-sdcard-on-kitkat/ and make new file /data/local/userinit.sh with this content:
Code:
#!/system/bin/sh
busybox mount -o remount,rw /
chmod 770 /mnt/media_rw
See the attached archive root.zip which I made for you it is pretty straightforward.
You should have move your TiB backup folder on this path: /mnt/media_rw/sdcard1/TitaniumBackup
You will be able to protect backup archives in Titanium Backup Pro then.
PS: If /data/local/userinit.sh doesn't start automatically in your ROM you can use for example Scripter feature in ROM Toolbox Pro and import userinit.sh script and set it as Start at boot.
Click to expand...
Click to collapse
Although in the case of Note 4 it didn't work right off the bat, I made it work a little different thanks to your idea. For some weird reason the script just doesn't get executed at boot (neither the *.sh file, nor as a script, through ROM Toolbox) but I was able to use the 2 lines in the script and made a task (in Tasker) which executes the shell command at boot. Everything else is straight forward and TiBu can now protect backups.
As a mention for those interested in replicating all these: the suggested SD card fix made by rummy applies EXACTLY the same changes as the SDFix so you can use either of them. Again, thanks for your reply and the great idea! :good:
nacos said:
I was able to use the 2 lines in the script and made a task (in Tasker) which executes the shell command at boot. Everything else is straight forward and TiBu can now protect backups.
Click to expand...
Click to collapse
Great, this is another example how to execute script at boot
I solved this problem on all my phones (Moto G LTE and Samsung Galaxy Note 2 and Samsung Galaxy W) but not on my tablet Nexus 7 2013 nor on internal emulated SD card nor on attached OTG USB flash disk. This is example where pure Stock Google Android ROM sucks
_jis_ said:
Great, this is another example how to execute script at boot
I solved this problem on all my phones (Moto G LTE and Samsung Galaxy Note 2 and Samsung Galaxy W) but not on my tablet Nexus 7 2013 nor on internal emulated SD card nor on attached OTG USB flash disk. This is example where pure Stock Google Android ROM sucks
Click to expand...
Click to collapse
This update addresses the issue mentioned before about init'd scripts not executing at boot. OK, here is the issue (specific to Qualcomm's Snapdragon) and the working solution - thanks to alexndr. I've tested it and it's working, however it doesn't work directly with <X.sh> text files, instead the script must be packaged in a flashable zip and flashed from recovery. Once I did that, it worked like a charm! The 98mediarw file in the screenshot uses the same script as previously mentioned; The 98 before the file name assigns a higher execution priority - I used 98 for testing purposes, it clearly doesn't need that. :good:
nacos said:
OK, here is the issue (specific to Qualcomm's Snapdragon) and the working solution - thanks to alexndr.
Click to expand...
Click to collapse
Oh, at first I thought that you post something what helps me with my tablet:
_jis_ said:
I solved this problem on all my phones but not on my tablet Nexus 7 2013 nor on internal emulated SD card nor on attached OTG USB flash disk.
Click to expand...
Click to collapse
But this is just another example how to execute script at boot
none of these methods are working. Is it because I'm using a Custom ROM?
What are you trying to achieve? What exactly is your environment?
nacos said:
What are you trying to achieve? What exactly is your environment?
Click to expand...
Click to collapse
I have Motorola Moto E (CM11 Stable build by percy_g2) and I'm trying to protect my backups in TiB but I'm getting error "Sorry, the operation failed." It used to be the same in stock ROM. And one more question, is this bug fixed in Lollipop versions of Android?
To answer you questions, no, this is not a bug, it's by design, also it's not happening because you're using a custom ROM, but rather because all OEM's (Google being probably the worst of all) are pushing towards more and more restrictive software & hardware environments, also supported by laws meant to discourage the users from modifying original configurations. Why? Dirty politics, I won't get into that but if you keep your eyes wide open you'll see and understand A LOT! Oh, by the way...to expect for Lollipop to be less restrictive and more fun (to customize) would be naive! Nuff said, let's have some fun!
There are multiple parts to this fix/diagnostic. Don't skip any point and follow these instructions rigorously, otherwise it won't work!!! Let's take them one by one:
Is you platform.xml file (under system/etc) modified to allow read/write access to media_rw (mnt/media_rw)? If not, apply the patch using SDFix from Google Store.
TiBu backup folder must be set to mnt/media_rw/externalSD/Titaniumxxx (if you don't have externalSD than use your internal storage instead, pointing to TiBu folder) - but, for right now, you won't be able to set this path because currently TiBu doesn't have access to media_rw, due to media_rw not being given the right permissions by the system. That's exactly what mediarw script does.
In order for init.d to execute the mediarw script at every boot, you need to insure that you do have init.d support AND it's working. This is how you verify:
(3a) Do you see the folder system/etc/init.d? If yes, go to (3b), if no, you don't have init.d support! That's another fix entirely.
(3b) If you see the 00test file in the init.d folder navigate to /data and open up the file called Test.log - that tells you that init.d is installed and working. If you have a Qualcomm's Snapdragon and you do have the init.d folder but it doesn't execute any script at boot, see the fix in post #6.
(3c) If you don't care about setting up init.d support, you can still run the script at boot, as a shell command using Tasker - see post #4
Once you're sure that all the above are set correctly, flash the attached file from recovery. Reboot, navigate to system/etc/init.d and confirm the presence of the mediarw script in the init.d folder
Reboot again, then navigate to mnt/media_rw and check that permissions for media_rw have been set to 770 - :fingers-crossed: mission accomplished, my friend! :fingers-crossed: If, on the other hand, the permissions for media_rw are still set at 700, then something went wrong. Go back and check every step again, otherwise...
Open up TiBu, set the backup folder path as instructed in #2 and verify that your backups can be protected. Voila!!
nacos said:
To answer you questions, no, this is not a bug, it's by design, also it's not happening because you're using a custom ROM, but rather because all OEM's (Google being probably the worst of all) are pushing towards more and more restrictive software & hardware environments, also supported by laws meant to discourage the users from modifying original configurations. Why? Dirty politics, I won't get into that but if you keep your eyes wide open you'll see and understand A LOT! Oh, by the way...to expect for Lollipop to be less restrictive and more fun (to customize) would be naive! Nuff said, let's have some fun!
There are multiple parts to this fix/diagnostic. Don't skip any point and follow these instructions rigorously, otherwise it won't work!!! Let's take them one by one:
Is you platform.xml file (under system/etc) modified to allow read/write access to media_rw (mnt/media_rw)? If not, apply the patch using SDFix from Google Store.
TiBu backup folder must be set to mnt/media_rw/externalSD/Titaniumxxx (if you don't have externalSD than use your internal storage instead, pointing to TiBu folder) - but, for right now, you won't be able to set this path because currently TiBu doesn't have access to media_rw, due to media_rw not being given the right permissions by the system. That's exactly what mediarw script does.
In order for init.d to execute the mediarw script at every boot, you need to insure that you do have init.d support AND it's working. This is how you verify:
(3a) Do you see the folder system/etc/init.d? If yes, go to (3b), if no, you don't have init.d support! That's another fix entirely.
(3b) If you see the 00test file in the init.d folder navigate to /data and open up the file called Test.log - that tells you that init.d is installed and working. If you have a Qualcomm's Snapdragon and you do have the init.d folder but it doesn't execute any script at boot, see the fix in post #6.
(3c) If you don't care about setting up init.d support, you can still run the script at boot, as a shell command using Tasker - see post #4
Once you're sure that all the above are set correctly, flash the attached file from recovery. Reboot, navigate to system/etc/init.d and confirm the presence of the mediarw script in the init.d folder
Reboot again, then navigate to mnt/media_rw and check that permissions for media_rw have been set to 770 - :fingers-crossed: mission accomplished, my friend! :fingers-crossed: If, on the other hand, the permissions for media_rw are still set at 700, then something went wrong. Go back and check every step again, otherwise...
Open up TiBu, set the backup folder path as instructed in #2 and verify that your backups can be protected. Voila!!
Click to expand...
Click to collapse
(Please ignore that screenshot. I didn't properly read your msg in blue text)
I couldn't understand post #4 so can you please describe it more deeply? :crying: btw I don't have 00test but a file named 00banner. And can you tell me how to use tasker properly?
Sorry for butting in on this thread. I found it by searching because I too can no longer protect a backup in my tibu Pro. I used to be able to but not anymore and I'm not sure why.
I'm on a rooted nexus 5 running stock 4.4.4.
Reading your instructions I went looking for platform.xml and found it. When I checked its properties I got, see screenshot. Don't know what to modify to mount it as you say. I'm in ES Explorer.
Can you help?
Thanks.
And here is a screenshot in root Explorer
Update your tb to 7.0.1 and now you can protect backups ? this thread should get closed now
Closed? Why? Just because a shortcut is available doesn't mean there is nothing to learn from wondering around, my friend!
After all, this is exactly what XDA is: a huge data base available to those who are willing to learn and dare to wonder around, wouldn't you agree?
Hello,
let's assume I have a super-secure Android phone that's known for not being rootable. Let's also assume, I've successfully tried the Janus vulnerability and was able to replace the classes.dex of a system app with a slightly modified one.
As far as I understand it, using the Janus vulnerability, you can only replace the classes.dex but no resources. So whatever is in the classes.dex can only work with the resources already there.
Now the big question: Is there any classes.dex that doesn't depend on specific resources and that I could use to get e.g. a root shell?
I'll try to change a System app to gain higher rights, but i doubt this will be enough to write to system.
github.com/wegeneredv-de/CVE-2017-13156
Use Janus vulnerability to get root access ?
No, I think you can't really. It is maybe possible to root using this exploit by editing a system app because system apps have more rights than "normal" apps which are installed in /data partition. If you really want to use janus exploit to root your phone, try to find a privilege escalation exploit and edit an app to make it execute the exploit. But I think "normal" rooting methods are more efficients. You can install any app on your phone or update any apps, so you don't need Janus. Executing privilege escalation exploit is the only way to root your phone with no (not at 100% true, you can root your phone using recovery, but it is not the subject)
I hope I have helped you,
Have a n1ce day,
Luca
PS : Don't hesitate to thanks me
Yes, you can. You can edit the system upgrade app to make it install a special package (that should be signed by recovery) to root your phone I think.
lucahack said:
Yes, you can. You can edit the system upgrade app to make it install a special package (that should be signed by recovery) to root your phone I think.
Click to expand...
Click to collapse
There's no easier way? Something like copying a "su" binary to somewhere and setting a few filesystem permissions?
mbirth said:
There's no easier way? Something like copying a "su" binary to somewhere and setting a few filesystem permissions?
Click to expand...
Click to collapse
The easiest way is to flash supersu in a custom recovery to root. (link to supersu flashable : https://s3-us-west-2.amazonaws.com/supersu/download/zip/SuperSU-v2.82-201705271822.zip )
lucahack said:
Yes, you can. You can edit the system upgrade app to make it install a special package (that should be signed by recovery) to root your phone I think.
Click to expand...
Click to collapse
I've been looking into that for awhile. I thought it was possible using dirtycow also maybe.
How would a special package still be usable and signed by the recovery?
Wouldn't modification break the recovery signing?
Delgoth said:
I've been looking into that for awhile. I thought it was possible using dirtycow also maybe.
How would a special package still be usable and signed by the recovery?
Wouldn't modification break the recovery signing?
Click to expand...
Click to collapse
If you extract your ota certs from a valid OTA and sign the injected update.zip with those valid signatures it may be possible. That's the latest I've been looking into but the updater binaries are so complicated I don't know how it will work. I think the best option is smali edit within an app like testmode.apk on the K1 that can manipulate system properties and shared preferences. Once you can allow the properties to allow insecure adb or debuggable = true or secure = false you can do the rest of the work in adb. But BB probably has protections that will nullify on reboot.
jcrutchvt10 said:
If you extract your ota certs from a valid OTA and sign the injected update.zip with those valid signatures it may be possible. That's the latest I've been looking into but the updater binaries are so complicated I don't know how it will work. I think the best option is smali edit within an app like testmode.apk on the K1 that can manipulate system properties and shared preferences. Once you can allow the properties to allow insecure adb or debuggable = true or secure = false you can do the rest of the work in adb. But BB probably has protections that will nullify on reboot.
Click to expand...
Click to collapse
I have the Verizon test keys for the G925V 4CPI2 6.0.1, but my s6 edge is currently out of commission until I can find the signed bootloader binaries to upload to the device over the serial port. SDB and SDC are completely gone. I need to inject the data, but don't know the map of the sboot.bin
I had the same idea though. I'm glad I wasn't the only one. It got lost in the cracks because of other projects going on. I saw some malware one time that would install itself by piggybacking on the ota system update process, when you scheduled the update to occur five minutes from the current time. And that process I do believe relied on using a modified CSC or Cache once the process started.