Related
Thanks to anomalous3 over on the vibrant forum he was nice enough to port over his rom to our side based off of the new source code released by samsung
"If you feel like being a guinea pig, or know anyone who does, the deodexed build is here:
http://getyourboneon.com/CaptivateDeodexed.zip
Since I don't have a captivate I can't really test it, but it should work fine. It's based off that UCJH2 build. I didn't include any lag fixes since they've proliferated out of control, but I did include ext manipulation libraries and e2fsck to make life easier for people who want to use one of the lag fixes."
Please note I have NOT tested this rom yet, I don't have my captivate. Please somebody could test this and let us know if there's any problem so we can let him help us fix it.
Again, not responsible for whatever happens to your phone.
Here is the original thread I posted for reference.
http://forum.xda-developers.com/showthread.php?t=746466
EDIT: I'm going to assume you would install this like any other rom via update
EDIT2: anomalous3 has updated the link with corrections. Let us know how it works
Well... since I can't seem to get enough of abusing my phone, guess I'll give this a whirl =P
And I have JH2, So I suppose that makes me a good candidate
Zilch25 said:
Well... since I can't seem to get enough of abusing my phone, guess I'll give this a whirl =P
And I have JH2, So I suppose that makes me a good candidate
Click to expand...
Click to collapse
let us know how it goes
Do I just rename this to update.zip and go recovery and reinstall packages?
And when I try it and my phone crashes I'll blame Zilch because it's convenient.
Sent from my SAMSUNG-SGH-I897 using XDA App
Will do, flashing back to a stock JH2 while I download! I've been waiting for something like this
Clienterror said:
And when I try it and my phone crashes I'll blame Zilch because it's convenient.
Sent from my SAMSUNG-SGH-I897 using XDA App
Click to expand...
Click to collapse
It probably was my fault anyway =P
Wait a sec, what does deodexed mean? I looked it up and it means no oxded files, but i don't know what those files are...
damn it, wish this was around 2 hours ago when i was bored! its too late now to ruin my phone haha.. tomo sometime maybe i'll try..
Question...Do I have to install the stock Captivate ROM first as it states in the linked post? I have the stock ROM that is rooted with the AT&T bloatware removed. The only other mod is the lagfix version 2.3...Can I just flash this over that?
you should be able to, according to his original thread on the vibrant forums, the directions were to put on internal sd card and load via clockwork best method. or via recovery mode works too
nammyczc said:
you should be able to, according to his original thread on the vibrant forums, the directions were to put on internal sd card and load via clockwork best method. or via recovery mode works too
Click to expand...
Click to collapse
That's what's taking me so long... seems like JH2 is having some issues with update.zips... namely it's getting to the "Opening installer" then "Install Aborted". The(not new) update.zip for root still works, so I'm tossing on clockwork to see if I can get this thing crammed on here with that.
Installing from Clockwork:
Hoses up during the copying files stage
E:Can't symlink /system/bin/bugreport
E:Failure at line 5:
symlink dumpstate SYSTEM:bin/bugreport
Then install aborts
Zilch25 said:
Installing from Clockwork:
Hoses up during the copying files stage
E:Can't symlink /system/bin/bugreport
E:Failure at line 5:
symlink dumpstate SYSTEM:bin/bugreport
Then install aborts
Click to expand...
Click to collapse
That's because the capitvate uses a different independent bugreport that is not a symlink of dumpstate.
Simply edit the update script in the meta folder and remove that line.
I deodexed the actual captivate files the other day, just havnt tested/posted them, way too busy with school
BuglessPete said:
That's because the capitvate uses a different independent bugreport that is not a symlink of dumpstate.
Simply edit the update script in the meta folder and remove that line.
I deodexed the actual captivate files the other day, just havnt tested/posted them, way too busy with school
Click to expand...
Click to collapse
I'll pm him about this
nammyczc said:
I'll pm him about this
Click to expand...
Click to collapse
Also ask him why superuser.apk is in the xbin folder.
vietphunguyen said:
Wait a sec, what does deodexed mean? I looked it up and it means no oxded files, but i don't know what those files are...
Click to expand...
Click to collapse
-From googling, found on XDA:
Deodexed ROMs have their .apk's (which are basically the application packages) repackaged in a certain way. An "odex" can be thought of as a collection of parts of applications that have been pulled out and optimized before booting. This speeds up the boot process - in a way, it preloads part of the applications - but it also makes hacking those apps difficult because part of the original code is already extracted somewhere else.
Deodexing is just a process of putting those pieces back into the original applications. It takes a while to extract those parts and build the .dex cache (aka Dalvik cache), but only because the relevant parts aren't in an easy-to-access place for the system. The advantage of this is that an app can be modified effectively and the developer doesn't have to worry about conflicts from the separate odex part of the code.
So, short version: "Deodexed" ROMs have all their apps put back together. If an app can be themed, for example, a deodexed version of that app will not get messed up when the modified .apk tries to mesh with the odex of the original un-modified .apk. Because it's not there.
If you want an aftermarket theme, you need a deodexed ROM. I'm not sure if deodexing can be done to individual apps within a non-deodexed ROM.
golemaw said:
-From googling, found on XDA:
Deodexed ROMs have their .apk's (which are basically the application packages) repackaged in a certain way. An "odex" can be thought of as a collection of parts of applications that have been pulled out and optimized before booting. This speeds up the boot process - in a way, it preloads part of the applications - but it also makes hacking those apps difficult because part of the original code is already extracted somewhere else.
Deodexing is just a process of putting those pieces back into the original applications. It takes a while to extract those parts and build the .dex cache (aka Dalvik cache), but only because the relevant parts aren't in an easy-to-access place for the system. The advantage of this is that an app can be modified effectively and the developer doesn't have to worry about conflicts from the separate odex part of the code.
So, short version: "Deodexed" ROMs have all their apps put back together. If an app can be themed, for example, a deodexed version of that app will not get messed up when the modified .apk tries to mesh with the odex of the original un-modified .apk. Because it's not there.
If you want an aftermarket theme, you need a deodexed ROM. I'm not sure if deodexing can be done to individual apps within a non-deodexed ROM.
Click to expand...
Click to collapse
This is correct. Deodexed ROMs can be themed...
BuglessPete said:
Also ask him why superuser.apk is in the xbin folder.
Click to expand...
Click to collapse
Good catch on that one Yeah, it surprised me that a lot of the stuff in the captivate doesn't rely on toolbox either. I might even port that over to the Vibrant since I think that toolbox is a stupid vestigial substitute for busybox anyways. Link updated, let me know if it works.
anomalous3 said:
Good catch on that one Yeah, it surprised me that a lot of the stuff in the captivate doesn't rely on toolbox either. I might even port that over to the Vibrant since I think that toolbox is a stupid vestigial substitute for busybox anyways. Link updated, let me know if it works.
Click to expand...
Click to collapse
updated original post with info
DISCLAIMER: These scripts have worked for me without issue. It would behoove you to ensure you have a solid back up to recover from in the event that something goes horribly wrong. These scripts should be considered a WIP. I will edit them and provide information as needed if something does not work as it should. Please feel free to post here or PM me if you have issues and bear with me if they do not work properly for you. END DISCLAIMER
To be honest, I am lazy. I flash CM nightlies and sometimes themes, and I didn't like having to navigate through recovery over and over again to wipe cache and dalvik-cache. So, I decided to write a script that would just do it for me. Then I got even lazier. I found that I had written several scripts and now I was tired of having to flash them all in a certain order. Which is why I wrote one all inclusive script.
Here I will provide you with two separate scripts. The first does just enough and the second does that much and a few more personal tweaks.
The first script is a rather simple one. It formats your /cache partition and deletes /data/dalvik-cache.
Wipe_Cache_Dalvik.zip
Edify version to work with Clockword Mod Recovery
1. Back up your current rom
2. Flash Wipe_Cache_Dalvik.zip
3. Flash your nightly/theme of choice
4. Reboot
The second script is where my personal preferences come into play. This script is meant to be flashed after you install your nightly rom. This script will format /cache, delete /data/davlik-cache, delete certain system apps that I do not personally use, and then copy an edited build.prop into /system so that the DPI is set to 190 immediately after you reboot from installing the nightly rom. This script will more than likely have to be changed to suit your needs. I understand that people will want different DPI settings and would like to retain the use of apps that I do not use.
Wipe_Delete_Copy.zip
1. Edit the script if you so choose. (Directions will be given in the second post)
2. Back up your current rom
3. Flash your nightly
4. Flash Wipe_Delete_Copy.zip
5. Reboot
Many thanks to Omegasun and his BareBone App and Sense Removal Plus Community Tools Thread.
This was the thread that got me started writing scripts. I learned a lot from him. My script would not have been possibl without his.
Many thanks to unCoRrUpTeD and his unCoRrUpTeD Dual Boot V1 Thread. I did a lot of testing for unCoRrUpTeD on his dualboot setup. I learned a lot from him in regard to using updater-scripts and updater-binaries. Without him I would not have been able to write the second script.
A thank you also to Calkulin for his format_all.zip which was another source of inspiration for the first wipe script.
As always a giant thanks to Cyanogen, Team Douche, TeamWin, and the Snap Team. The information and aid that they have provided to me is second to none. Without them I wouldn't know half of what I do now. Their contributions are what make this community great.
Any gratitude that you may feel towards me for these scripts should be directed towards those mentioned above. I wrote these to benefit myself and now feel that I should give them back to you all. I hope they work as described and make flashing a little bit easier on you.
These are rudimentary directions for the time being. I will edit and make them more precise later tonight. Also included a few things for reference. Like I said, it is basic info for now and it will become more detailed and informative.
You will need a text editor to edit any of these scripts. I primarily use Notepad++ on Windows. If you are on a *nix box then I am sure you are more than able to find a text editor that suits your needs.
1. Unzip Wipe_Delete_Copy.zip
2. Navigate to *\META-INF\com\google\android\
3. You will see two files: updater-script and update-binary
4. Open updater-script with your favorite text editor. (In my case, I right click and choose "Edit with Notepad++")
5. Edit Away
6. Save
7. Rezip
For reference, these are the files deleted from /system/app:
ADW Launcher
Browser
Car Home Google
CM Wallpapers
Development
DSP Manager
Email
FM
File Manager
Google Quick Search Box
Genie Widget (News and Weather)
Live Wallpapers
Live Wallpaper Picker
Pro Tips (The CM Widget that appears after a clean install)
Sound Recorder
VoiceDialer
Notice "ADW Launcher." This means you will need Launcher Pro/ADW EX/etc before you flash this. Or you will need to remove this line from the script.
If you don't want to change your DPI settings:
1. Open up the script in your text editor
2. Delete
Code:
ui_print("");
ui_print("");
ui_print("");
ui_print("Copying build.prop to retain proper dpi");
show_progress(0.200000, 5);
package_extract_dir("system", "/system");
3. Save
4. Delete the "system" folder found in the original zip
5. Rezip
This will be very handy. Thank you, sir.
+1 for this when I get to mess around with it after work tomorrow. Great job
swyped from my cyanogenized and gingerbreaded EVO
i have been thinking about making a cache/dalvik wipe script forever, but never got the will. thanks for making my life easier karadore.
I appreciate the thanks. I know the basic script will work just fine. It is very straight forward. The second one is kind of tricky because it uses an updater/binary. I just recently started working with them and had a few issues to begin with. The more feedback you all give me on this the better. Hope they help.
i dont know how to write in edify, but i would like to. if you dont mind whipping up a little tutorial, that would be fantastic so all the peoplez can stop complaining that they get an error after flashing my zips on cwm 3+. it would help me and a lot of others as well.
dkdude36 said:
i dont know how to write in edify, but i would like to. if you dont mind whipping up a little tutorial, that would be fantastic so all the peoplez can stop complaining that they get an error after flashing my zips on cwm 3+. it would help me and a lot of others as well.
Click to expand...
Click to collapse
I may just do that. Would give me a nice little project in the next few days to help me procrastinate from school and work a little more
Anyway to update these to work on CW 3+ recoveries?
sminker said:
Anyway to update these to work on CW 3+ recoveries?
Click to expand...
Click to collapse
The second script should work because it is written in edify. I will update the first one so that it works. Leaving for work now but I should be able to do it all from my phone. Will post up the new version in a few.
sminker said:
Anyway to update these to work on CW 3+ recoveries?
Click to expand...
Click to collapse
Just did a quick edit from my phone. This new zip should work on all CW Recoveries. Let me know if there are more issues. Will update the op once I am off work.
http://db.tt/sBi95OV
Karadorde said:
Just did a quick edit from my phone. This new zip should work on all CW Recoveries. Let me know if there are more issues. Will update the op once I am off work.
http://db.tt/sBi95OV
Click to expand...
Click to collapse
Awesome. Haven't tested yet but thanks for updating.
All I ask is that you let me know if it works or not. No reason why it shouldn't, but the more R&D the better.
are you still planning on giving an edify tutorial? and if not do you have any helpful pages or just all-telling .zips i can look at? thanks a bunch karadorde
Wait you flash first and then wipe caches? I've always done it the other way around. Does it even matter? Guess not...
Sent from my PC36100 using XDA App
matt2053 said:
Wait you flash first and then wipe caches? I've always done it the other way around. Does it even matter? Guess not...
Sent from my PC36100 using XDA App
Click to expand...
Click to collapse
You can do it either way. I always used to wipe and then flash.
The reason I am wiping after flashing the nightly is because of the other code in the second script. The second script deletes all of those system apps that I don't use and copies my edited build.prop back into /system. If I flashed the script before the nightly, then those system apps would be reinstalled and I would lose my edited build.prop.
dkdude36 said:
are you still planning on giving an edify tutorial? and if not do you have any helpful pages or just all-telling .zips i can look at? thanks a bunch karadorde
Click to expand...
Click to collapse
I have started putting together the thread. I will be adding to it today. I will dig up some other threads for you as well. Here is a link to the one I just started in Evo General.
http://forum.xda-developers.com/showthread.php?t=994940
nice work.. definitely helps me with flashing nightlies.. i would always have to go and remove most of that stuff.. the only thing i wanted to keep was DSP so i went and simply edited script..
works.
I'd appreciate it if someone could give me some assistance. Basically the situation is that I wanted to get VPN working on the A7 which required tun.ko. I cross compiled the kernel and managed to get a tun.ko file and I added it to my device. Installing the module did not work, so I left it.
At some point my A7 shut off, and now it will not boot, it hangs at the ANDROID screen, before getting to the HC animation (dexmod 1.42). I am assuming at this point that my tun.ko is the issue so I created a patch update to remove the modules I had added to see if that would work.
Note: This patch is exactly the same as the ElocityMod 1.4.2 ad-hoc patch, I just changed the script actions and re-bundled.
The script only does this:
delete_recursive SYSTEM:lib/modules
delete SYSTEM:lib/tun.ko
I created the /system/lib/modules dir, so I know it exists, as does the /system/lib/tun.ko. When I try to run the update script I get the following error:
Installing Update
close from_child
E:Error in /sdcard/update.zip
(Status 6[1536])
Installation aborted.
I am trying not to flash back to the 1.4.2 as I have some investment and stupidly did not back-up before I started this venture. Any help would be appreciated.
Brad
As a side note, according to the /proc/config.gz on the tablet (kernel config) the TUN/TAP is compiled into the kernel, but not compiled as a module. For this reason I doubt VPN will work unless the apps can recognize the TUN device instead of failing because the module does not exist.
with specifics to an update script, the script desired should be as follows
Code:
run_program("/sbin/busybox", "mount", "-orw,remount","/system");
delete("/system/lib/tun.ko");
run_program("/sbin/busybox", "mount", "-oro,remount","/system");
you will need to remember to sign your update.zip after creation if you're not familiar with the process. searching on xda should turn up results for 'sign update.zip'.
i'd list the specific files and not do recursive deleting. though if introducing a kernel module caused you problems, i don't think it was merely copying/removing that had an effect, but wouldn't you have had to either issue an 'insmod' command manually or you added a call to that module using insmod added to the init.rc or a bash script. you need to remove that reference too if you did.
if your 'investment' is related to your /data folder (with your stored apps and app settings), you can use my cwm fakeflash recovery to backup and restore your /data contents (installed apps, and system settings) after a factory reset and reloading dexter's rom (using factory recovery).
alternative solutions; maybe if you were doing these kind of experiments you MIGHT have left the usb device setting on (for adb connectivity). if so, try to adb shell into the device to correct your problem by hand; type adb devices from a command prompt for fun to see if the device still lists (it did for me when softbricked once).
domito said:
I'd appreciate it if someone could give me some assistance. Basically the situation is that I wanted to get VPN working on the A7 which required tun.ko. I cross compiled the kernel and managed to get a tun.ko file and I added it to my device. Installing the module did not work, so I left it.
At some point my A7 shut off, and now it will not boot, it hangs at the ANDROID screen, before getting to the HC animation (dexmod 1.42). I am assuming at this point that my tun.ko is the issue so I created a patch update to remove the modules I had added to see if that would work.
Note: This patch is exactly the same as the ElocityMod 1.4.2 ad-hoc patch, I just changed the script actions and re-bundled.
The script only does this:
delete_recursive SYSTEM:lib/modules
delete SYSTEM:lib/tun.ko
I created the /system/lib/modules dir, so I know it exists, as does the /system/lib/tun.ko. When I try to run the update script I get the following error:
Installing Update
close from_child
E:Error in /sdcard/update.zip
(Status 6[1536])
Installation aborted.
I am trying not to flash back to the 1.4.2 as I have some investment and stupidly did not back-up before I started this venture. Any help would be appreciated.
Brad
As a side note, according to the /proc/config.gz on the tablet (kernel config) the TUN/TAP is compiled into the kernel, but not compiled as a module. For this reason I doubt VPN will work unless the apps can recognize the TUN device instead of failing because the module does not exist.
Click to expand...
Click to collapse
..alternatively alternatively i also did a update.zip of the latest factory rom that may assist with your issue, if the above solutions do not work. assuming your 'investment' isn't in the /system folder, it can format your /system folder and reinstall the /system files from the factory firmware with all correct permissions. a little examination of my update.zip could be used as a template for creating a similar one for dexter's rom, for these particular times when you'd like to re-do your /system folder and leave the rest of your partitions and data intact.
locatable, roundabout, from my twitter. same name as here.
oh. you could just write a script to execute a bash script (file.sh) thats got simple copy commands to copy your 'investment' to sdcard (/sdcard in recovery). that might be the simplest non creative approach that would allow you to continue on with a normal factory reset and reload of dexter's rom.
using bash scripts might also aid you in doing what you want without having to know or experiment with proper scripting syntax.
..oh, AND you could just edit dexter's rom update.zip to only install the system.img, and remove the rest of the files for installation, and DON"T do a factory reset..
that could help with restoring your system filesystem while leaving the rest of your data intact. didn't occur until this morning, that might be you EASIEST of the multiple suggestions listed.
Thanks for the response!
bestialbub said:
with specifics to an update script, the script desired should be as follows
Code:
run_program("/sbin/busybox", "mount", "-orw,remount","/system");
delete("/system/lib/tun.ko");
run_program("/sbin/busybox", "mount", "-oro,remount","/system");
Click to expand...
Click to collapse
This was actually what I did for my first try, with the same result.
bestialbub said:
you will need to remember to sign your update.zip after creation if you're not familiar with the process. searching on xda should turn up results for 'sign update.zip'.
Click to expand...
Click to collapse
I did not do this, I was not sure I had to.
bestialbub said:
i'd list the specific files and not do recursive deleting. though if introducing a kernel module caused you problems, i don't think it was merely copying/removing that had an effect, but wouldn't you have had to either issue an 'insmod' command manually or you added a call to that module using insmod added to the init.rc or a bash script. you need to remove that reference too if you did.
Click to expand...
Click to collapse
I did insmod it as well as modprobe, it gave me an error which was likely because (as I found later) the TUN is compiled into the kernel, which means a module could not possibly load.
bestialbub said:
if your 'investment' is related to your /data folder (with your stored apps and app settings), you can use my cwm fakeflash recovery to backup and restore your /data contents (installed apps, and system settings) after a factory reset and reloading dexter's rom (using factory recovery).
Click to expand...
Click to collapse
I'll have to take a look at that, I was no aware it existed.
bestialbub said:
alternative solutions; maybe if you were doing these kind of experiments you MIGHT have left the usb device setting on (for adb connectivity). if so, try to adb shell into the device to correct your problem by hand; type adb devices from a command prompt for fun to see if the device still lists (it did for me when softbricked once).
Click to expand...
Click to collapse
The issue with the A7 is that it's got USB host only which means I cannot connect it to my PC and adb it. This was a known issue before I bought the A7.
bestialbub said:
..alternatively alternatively i also did a update.zip of the latest factory rom that may assist with your issue, if the above solutions do not work. assuming your 'investment' isn't in the /system folder, it can format your /system folder and reinstall the /system files from the factory firmware with all correct permissions. a little examination of my update.zip could be used as a template for creating a similar one for dexter's rom, for these particular times when you'd like to re-do your /system folder and leave the rest of your partitions and data intact.
locatable, roundabout, from my twitter. same name as here.
oh. you could just write a script to execute a bash script (file.sh) thats got simple copy commands to copy your 'investment' to sdcard (/sdcard in recovery). that might be the simplest non creative approach that would allow you to continue on with a normal factory reset and reload of dexter's rom.
using bash scripts might also aid you in doing what you want without having to know or experiment with proper scripting syntax.
..oh, AND you could just edit dexter's rom update.zip to only install the system.img, and remove the rest of the files for installation, and DON"T do a factory reset..
that could help with restoring your system filesystem while leaving the rest of your data intact. didn't occur until this morning, that might be you EASIEST of the multiple suggestions listed.
Click to expand...
Click to collapse
In the end I went more heavy handed than all that and it worked out fine. I did this before I saw your response otherwise I would have tried to finesse it some more just for the fun of it.
I re-flashed with dexmod 1.41 but I did not reset or wipe anything first. Applying this over top got me booted again with all my apps. 1 quick 1.42 update (and annoying root FB upgrade) and I am back to pre-fail conditions. I backed up my stuff too.
Thanks again for all the useful tips. This type of event has happened a few times and my gut says I am getting some corruption on the NVRAM or something. Only time will tell.
adb connectivity works fine, the solution is buried in one of 5stronginos threads, maybe the cwm recovery one. google for USB_OTG.APK i think, its posted on xda w a download link.
..i also prepackage it in my firmware repack.. findable from my twitter.
Sent from my X10i using Tapatalk
bestialbub said:
adb connectivity works fine, the solution is buried in one of 5stronginos threads, maybe the cwm recovery one. google for USB_OTG.APK i think, its posted on xda w a download link.
..i also prepackage it in my firmware repack.. findable from my twitter.
Sent from my X10i using Tapatalk
Click to expand...
Click to collapse
I found this one, which looks right.
http://forum.xda-developers.com/showpost.php?p=12813894&postcount=36
I'll give it a shot. Thanks for the info.
See: http://forum.xda-developers.com/showthread.php?t=1402440
Sorry - don't have enough posts to reply directly in the dev tree, but it would seem to me that if all the updates are just zip files, couldn't they be modified to include root? Then the normal update system would handle the installation? You wouldn't need root then.. Just dump it into the "kindleupdates" folder and let it do its thing. It would just install it.
It looks like the install is just running a script.. one of the first things it does is wipe the system folder.. doesn't mean you can't include additional files and copy them in afterwards with the script does it?
AndrewTL said:
See: http://forum.xda-developers.com/showthread.php?t=1402440
Sorry - don't have enough posts to reply directly in the dev tree, but it would seem to me that if all the updates are just zip files, couldn't they be modified to include root? Then the normal update system would handle the installation? You wouldn't need root then.. Just dump it into the "kindleupdates" folder and let it do its thing. It would just install it.
It looks like the install is just running a script.. one of the first things it does is wipe the system folder.. doesn't mean you can't include additional files and copy them in afterwards with the script does it?
Click to expand...
Click to collapse
You need to go through all the lines of code for that and I believe some of them are binary files as well. Possible but will take much time. For now we must wait until someone finds a better solution.
Sent from my Kindle Fire using Tapatalk
signature issues.
6.2.1 experiment?
transfuntioner said:
signature issues.
Click to expand...
Click to collapse
Maybe I don't follow the process.. but I'm guessing no signatures..
not a signed bootloader.. no signatures required...
Get beyond compare and look at the differences between the OTA updates and the zip that Eldarerathis put together.
The ".bin" files are just ".zip" files renamed.
Look at
META-INF/com/google/android/updater-script in the bin files they release.
It is just a script.
And to do the things that it is doing, it has to be getting root permissions while it is running.
I don't know how to recover if it doesn't work, but I half wonder if you were to take the zip that fellow created, change the extension to ".bin" and just dump it into the update folder if the fire would install it for you?
He took out the image files from the script. He's just updating the system tree directly. He doesn't update the bootloader, recovery or backup trees.
For that matter if those contained something nasty, they could probably be pulled from an earlier update.
== cut ===
package_extract_file("recovery.img", "/dev/block/platform/mmci-omap-hs.1/by-name/recovery");
show_progress(0.100000, 10);
package_extract_file("u-boot.bin", "/dev/block/platform/mmci-omap-hs.1/by-name/bootloader");
format("ext4", "EMMC", "/dev/block/platform/mmci-omap-hs.1/by-name/backup");
mount("ext4", "EMMC", "/dev/block/platform/mmci-omap-hs.1/by-name/backup", "/backup");
package_extract_file("backup_userdata.zip", "/backup/backup_userdata.zip");
== cut ===
Please nobody try this idea that doesn't know enough to recover if it doesn't work, because I've not a clue how.
But could someone explain why wouldn't it work?
Worst case the rev might need to be manually edited to bump it one for the script.
Seems like it might be an easy way to get around headaches with OTA updates.
Andrew,
Are you having issues with getting into recovery so that you can test this? The Devolopers have a copy of TWRP 2 working perfectly on the device so you can get a clean backup of the OS before you test.
You sound like you may know what to do to fix the issue and I just want to help you get a good recovery in case it doesn't pan out or for testing.
~enjoy.
Actually I'm just afraid of messing up what I have working now.
I've got TWRP 2 running with the 6.2.1 image.
I'm setting these up as gifts. I spent a good 12 hours yesterday fighting the darn things. Guess I'm getting gun shy. Had a lot of issues with adb. Kudos to the new utility and setting the second ports up. I'm learning.
The OTA install wipes the system directory. It's in the script.
I was tempted to just comment that line out and see if it would leave the rest alone.
If I brick the thing its going to be painful for me to sort out.
I also didn't want to risk losing root. I also haven't tried loading an older OTA version.
At the time, I couldn't ask the fellow that developed the rooted 6.2.1 zip the question in his thread as I didn't have enough posts.
I'm going to be out of pocket for quite some time. I'm not going to have time to spend like this again for at least a few days.
But I was checking the zip he made versus the .bin/.zip files that the OTA releases using beyond compare. I wanted to see what files had actually changed.
That's when I found that script. It is manipulating permissions directly. It has to be running at a root level. I don't see anything like a signature on it, so why couldn't their own update system be used to tweak their own updates to allow for root?
Hey, I noticed while looking through the Stock Firmware AP file, that in meta-data/fota.zip there are .jar files that have to do with package signing. Only issue is that the zip is password protected. If someone has the Compute power and skills to decrypt a zip and look at the jar files and ****, maybe we could find a way to sign our own TWRP recoveries and roms. Just a thought, i'll post a link to the fota.zip file i was talking about in a bit if anyone wants to take a crack at it. (Google drive is taking forever to upload cause of AT&T's ****ty DSL speeds, sorry)
Download Link: htt*ps:/*/drive.*google*.com/file/*d/0B9tb-svjqaVD*b3Y0V0tXR3drSzA/vie*w?usp=sharing (Remove all *'s from link, stupid 10 post until you can post links limitation)
Thanks,
Lavavex
Did you saw this Thread?
https://forum.xda-developers.com/an...signing-boot-images-android-verified-t3600606
About fota.zip...
Did you heard about plain text attack?
In few Seconds... minutes done... no password required but you can unpack.
Best Regards
Yesterday I have download this fota.zip... and yes... same password as for instance from my prior test with:
SM-J330F and 1 more...
Here are the 3 keys to decrypt if somebody want try...
Code:
2b4d493c
6142b289
1b7024aa
Code:
Key0
Key1
Key2
I have used Advanced Archive Password Recovery from elcomsoft...
Best Regards
adfree said:
Yesterday I have download this fota.zip... and yes... same password as for instance from my prior test with:
SM-J330F and 1 more...
Here are the 3 keys to decrypt if somebody want try...
Code:
2b4d493c
6142b289
1b7024aa
Code:
Key0
Key1
Key2
I have used Advanced Archive Password Recovery from elcomsoft...
Best Regards
Click to expand...
Click to collapse
Which will allow unpacking of the above zip? I thought it needed a zip password.
osm0sis said:
Which will allow unpacking of the above zip? I thought it needed a zip password.
Click to expand...
Click to collapse
We never found the Password... but for Decryption you need only these 3 Keys...
They can be easily found in few Minutes... with the right Tool...
Code:
2b4d493c
6142b289
1b7024aa
Here Key0 Key1 Key2 for Samsungs fota.zip...
This is really no rocket science...
Simple read about plain-text attack...
You can see all filenames...
You can see all filesizes etc...
Many files are floating around the Internet... to create ZIP for attack...
Then result is in few Minutes possible... :angel:
Use these 3 Keys in Tool:
Code:
Advanced Archive Password Recovery
And try self to unpack...
Best Regards
Edit 1.
Screenshot added...
Then maybe more clear...
Trial Version have mabye limtations... but to see it work... it is enough to play with trial.
@adfree or to anyone who can answer.
Quick question, what are the legal limitations to what is going on here? I may or not have a file from inside the fota.zip, but will sharing it put me in the legal wrong? If it is within the legal boundaries, I'd be happy to upload it for anyone to take a look at, but I don't want to land on the wrong side of the law by doing so. Please do let me know, as this is the most exciting development we've had when it comes to bootloader unlocking in a while. Also, it seems as though we can't view the entirety of the contents of the fota.zip with the trial version of the zip extraction tool mentioned in this thread, so if someone with more knowledge about this can confirm we could unlock our bootloaders with the contents of the zip (based on what is currently known about this), I'd be happy to bite the bullet of paying for the premium version given we can do this within the boundaries of the law.
Thanks.
1.
Maybe you can answer your question self...
Samsung PROTECTED this ZIP with password.
2.
IMHO it is Kernel related...
Yeah I know... Boot is every irritating...
But it is not sboot.bin related...
3.
About decrypting all files...
There are floating around Command Line Tool...
Code:
pkcrack
Try to Google it...
I have not tried...
I am 1 click Button user...
Best Regards
zipdecrypt from the pkcrack package plus those 3 keys worked flawlessly. :good:
Edit: Crazy number of utilities in this zip, but no script to run them all, and a lot of references to external files. No smoking gun like a "sbootimg_signer" binary or anything to make their proprietary footer signature, and no Samsung signature files.
the password for that zip is fotatest1234
Correct. All fota zips passwords are fotatest1234
Drdra3 said:
Correct. All fota zips passwords are fotatest1234
Click to expand...
Click to collapse
@lavavex , @osm0sis
Yes it is, but now the question still to be answered is, do the tools within the fota.zip file, actually work for legitimately repacking the boot/recovery image? Because in the fota.zip I checked from Android Pie's release it mentioned the "user/test-keys" and very much so had all of the compiled tools to actually patch a system and create and ADB flashable zip for stock recovery.
Could we technically make a signed sideloadable update.zip if the the update package was created on the device itself? The scripts included, along with the updated compiled binary tools, really do seem to be the Toolkit we've been looking for but have overlooked. I haven't tested it out fully, but I'm still reading about how to proceed. It isn't just the S7 either. So are the tools customized to the device, the android branch, or the bootloader?
Delgoth said:
@lavavex , @osm0sis
Yes it is, but now the question still to be answered is, do the tools within the fota.zip file, actually work for legitimately repacking the boot/recovery image? Because in the fota.zip I checked from Android Pie's release it mentioned the "user/test-keys" and very much so had all of the compiled tools to actually patch a system and create and ADB flashable zip for stock recovery.
Could we technically make a signed sideloadable update.zip if the the update package was created on the device itself? The scripts included, along with the updated compiled binary tools, really do seem to be the Toolkit we've been looking for but have overlooked. I haven't tested it out fully, but I'm still reading about how to proceed. It isn't just the S7 either. So are the tools customized to the device, the android branch, or the bootloader?
Click to expand...
Click to collapse
Presumably what I previously said still stands:
osm0sis said:
Crazy number of utilities in this zip, but no script to run them all, and a lot of references to external files. No smoking gun like a "sbootimg_signer" binary or anything to make their proprietary footer signature, and no Samsung signature files.
Click to expand...
Click to collapse