yashsingh1/xdaforums huggingface dataset:
[Android Software/Hacking General [Developers Only]] FriendlyNeighborhoodShane:
Ooookay... thanks for the help guys... will definitely check those out...
[Android Software/Hacking General [Developers Only]] osm0sis:
1) the snippet as a whole chooses between /system and /su, not sure you wanted that?

2) you've got /su/xbin as a target, but you'd want /su/su.d, same goes for /system/xbin -> /system/su.d

3) package_extract_dir requires a destination, you'll probably want it to be $target

You should also be aware that /su doesn't exist anymore with Oreo, a link to the updated snippet with supersu_is_here detection is in the 2nd post.
[Android Software/Hacking General [Developers Only]] Beakhole:
Thank you so much. I really appreciate it. I'll give that a try.
[Android Software/Hacking General [Developers Only]] jcmm11:
No need to apologise, we were all there once upon a time. Let's look at this piece

test -d /su/su.d && target=/su/su.d || target=/su/su.d;
else
mount -o rw,remount /su;
target=/su/su.d;
fi;

ui_print " Flashing kernel gestures... ";
package_extract_dir $target;

Start with the test statement. You're setting target to the same string whether the test passes or fails. If that's really what you want you don't even have to bother with a test statement, just use "target=/su/su.d". I suspect what you really want is

test -d /su/su.d && target=/su/su.d || target=/system/su.d

We'll come back to the else clause in a minute. Let's go to "package_extract_dir $target". package_extract_dir requires both a source and a destination. That's point one. Point two - all you're doing is extracting one script file. Right? You should probably use package_extract_file instead. Format is the same, needs both a source and a destination. $target is fine for a destination, source depends on how your zip is structured. So this should be

package_extract_file(source, $target)

Now for the else clause. This clause is triggered if su.img doesn't exist so I don't think you want to remount su at that point, nor do you want to set target to /su/su.d

You probably want to either abort or check to see if SuperSU is installed in sbin mode and, if so, proceed accordingly. At this stage I'd recommend just aborting, you can always extend the script later.
[Android Software/Hacking General [Developers Only]] Beakhole:
So how does this look?

ui_print " Flashing kernel gestures... ";
package_extract_file(ZZZ-Kernel-Gestures, $target);
set_perm 0 0 0755 /su/su.d/ZZZ-Kernel-Gestures;
ui_print " --- DONE!!! --- ";

And can you help me out with the else statement? You suggested that I just abort.

else
mount -o rw,remount /su;
target=/su/su.d;
fi;

If that's what it looks like right now, what would I put in to abort at the else statement?
[Android Software/Hacking General [Developers Only]] jcmm11:
ui_print " Flashing kernel gestures... ";
package_extract_file(ZZZ-Kernel-Gestures, $target);
set_perm 0 0 0755 /su/su.d/ZZZ-Kernel-Gestures;
ui_print " --- DONE!!! --- ";

As long as ZZZ-Kernel-Gestures is a file in the root of your zip file it looks fine. I would change the set_perm target to ${target}/ZZZ-Kernel-Gestures

else
mount -o rw,remount /su;
target=/su/su.d;
fi;

Simple enough

else
abort "Couldn't find su.img"
fi

The attached PDF may be helpful. Just know that it's based on an actual update-binary. The script doesn't have, for example, an ifelse statement. You can always look at the script to see what is there and what parameters it needs
[Android Software/Hacking General [Developers Only]] osm0sis:
That else was meant to be the fallback for /system and to mount that if you look at the original snippets again. If he only cares about /su then an abort is all that should be in there.
[Android Software/Hacking General [Developers Only]] osm0sis:
package_extract_file(ZZZ-Kernel-Gestures, $target);

should be

package_extract_file ZZZ-Kernel-Gestures $target/ZZZ-Kernel-Gestures;

And

test -d /su/su.d && target=/su/su.d || target=/system/su.d;

should be

test -d /su/su.d && target=/su/su.d;

As long as the su.d script file is in the root of the zip then everything else looks fine. :good:
[Android Software/Hacking General [Developers Only]] FriendlyNeighborhoodShane:
Hi,

I actually need some shell scripting help here. I realise this might seem somewhat unusual, but I'm stripping some special characters from a file (in-place) using sed, and in all my attempts the file ends up empty.

I'm using the commands:

sed -i 's/(/ /g' $file

sed -i 's/,/ /g' $file

sed -i 's/)/ /g' $file

I even tried escaping the characters, but still the same.

sed -i 's/\(/\ /g' $file

sed -i 's/\,/\ /g' $file

sed -i 's/\)/\ /g' $file

No problems in the recovery logs though. Am i doing something wrong? Or is it because of the whitespace? I don't think there is some problem with the file before sedding as i also make the script backup it and it seems fine.

Thanks for your help in advance.
[Android Software/Hacking General [Developers Only]] osm0sis:
Try without -i so you can see the output of the command and try to figure it out. I'm guessing some escaping will be required since () and , in sed usually refer to saved substrings and address ranges.
[Android Software/Hacking General [Developers Only]] jcmm11:
In a terminal emulator the first, non-escaped, versions all work for me. I did have a hardcoded filename rather than using a variable.

Make sure that the variable is properly initialized, you may not be passing the filename you think you are.

Also note that the way you have it setup you're not stripping the characters, you're replacing them with spaces.

Test this by using the actual filename rather than a variable, and make sure the file has the contents you think it has before you start.
[Android Software/Hacking General [Developers Only]] jcmm11:
For the record the following also works

sed -i 's/[),(]/ /g' <filename>

I suspect that there's another part of the script that's causing the problem. Make copies of the file immediately before and after the sed commands and see what that shows.
[Android Software/Hacking General [Developers Only]] FriendlyNeighborhoodShane:
Yeah, i did try with the escapes... Still the same.

Hmm... Sed behavious should not be different across busyboxes, right? And yes, sorry for poorly wording the question, I'm replacing the characters with spaces.

Next thing I'll try, for sure

And the revovery log is the stdout, right? And so errors from sed should show up there, probably?

Thanks guys... Will report results.
[Android Software/Hacking General [Developers Only]] jcmm11:
sed should behave the same. It's possible that some options [may/may not] be supported depending on version - but what we're discussing here is very basic functionality. If this didn't work then sed would be considered totally broken and non-functional.

You can always use the terminal in TWRP for testing.

I did try both toybox and busybox versions, just in case.

As far as the log goes just grab TWRP's log and it should show errors.

As far as escapes in sed - read up on the -r option (extended regular expressions). If you were using that option then some escapes would be necessary for what you're trying to do.
[Android Software/Hacking General [Developers Only]] osm0sis:
sed is totally broken in toybox in Marshmallow, but should be fine in any recent ROM or recovery.
[Android Software/Hacking General [Developers Only]] jcmm11:
Doesn't surprise me. In Nougat it seems to work, at least for this scenario.
[Android Software/Hacking General [Developers Only]] osm0sis:
Yup should be fine now. Google just shipped a half-baked toybox build with all their official stock Marshmallow ROMs (and refused to fix it until Nougat when I reported it, since it wasn't a "security concern").
[Android Software/Hacking General [Developers Only]] jcmm11:
Lol. While I got you a quick question. Did /sys/fs/pstore/console-ramoops replace /proc/last_kmsg? Or what is the relationship?

I've been accused of spreading misinformation, and want to know if I really am or not

Thanks

PS - do you know if they fixed the mount command for Oreo? (Just curious)
[Android Software/Hacking General [Developers Only]] osm0sis:
I'm not sure honestly.

There's this:

https://sites.google.com/site/zhuow...onandroid60andabovesysfspstoreconsole-ramoops

I feel like that definitely wasn't the case on my older Nexus devices, even though they're running Nougat now. So maybe it's devices that launched with Marshmallow and above, or more accurately, whatever Linux kernel revision those launched with.

My Nexus 5X has ramoops. Not sure about mount, my only Oreo device is my 5X and it's all systemless and passing SafetyNet with SBIN SuperSU and suhide so I don't want mess around with mounting /system. ;)
[Android Software/Hacking General [Developers Only]] jcmm11:
Yeah I found, and posted, that link and was accused of spamming outdated information. (Mixplorer thread) I still have Nougat, via Pure Nexus, also have ramoops. (Also passing Safetynet with suhide, but my system is most definitely modified)

Wonder if it might be ROM dependent. Lineage?

Maybe I'll post it in [MENTION=3292224]franciscofranco[/MENTION] thread (or maybe I'll get lucky and he responds here ? ).

In any case thanks for the response. We now return you to your regularly scheduled broadcast ?

In any case thanks for the response.
[Android Software/Hacking General [Developers Only]] osm0sis:
Gathering the quoted zipadjust issues in one post for [MENTION=631273]Chainfire[/MENTION] to hopefully take a look at. :good:
[Android Software/Hacking General [Developers Only]] Chainfire:
So... why not use the standard 'zip' command the tool was created to be used with? :)

Otherwise, you even link to the source in your OP...
[Android Software/Hacking General [Developers Only]] ale5000:
Because zip, the one from infozip, is probably no longer developed (I'm not 100% sure but last version is from 2008) instead 7-zip is constantly developed, suport both compression and decompression, support a lot of formats and I can easily get it on all OS where I need it (Windows, Linux, macOS, Android, etc.).
[Android Software/Hacking General [Developers Only]] osm0sis:
Haha I do, and I've found even WinRAR works, but if 7zip doesn't work, and a ^M or #!/ in the updater-script can break it, there's something wrong.. and yes, I have access to your source but I have a funny feeling you know it a bit better than I and could fix it in minutes rather than the days it might take me researching zip and poking around in it. ;)
[Android Software/Hacking General [Developers Only]] _that:
I've never needed to use zipadjust, and I've built all my flashable zips with 7-zip. What am I doing wrong? ;)
[Android Software/Hacking General [Developers Only]] ale5000:
The procedure is needed to create a zip flashable with signature verification enabled in the recovery.

If you disable it every zip will work.
[Android Software/Hacking General [Developers Only]] _that:
I sign the zip, then I unpack it again, repack with 7-zip and then run only the whole-file signing process:

https://xdaforums.com/showpost.php?p=52684360&postcount=20

This is from 2014, I don't know if it still works but it's maybe worth a try.
[Android Software/Hacking General [Developers Only]] osm0sis:
Yeah your method is similar, rezipping it would be what likely avoids the issue, since that's the step where zipadjust is usually used. Then either your whole file signing jar or Chainfire's will probably work equally for the last step.
[Android Software/Hacking General [Developers Only]] osm0sis:
I'll be adding this to the OP under signing methods; makes things super simple for Windows users! :)

[MENTION=2777334]TKruzze[/MENTION] of PA GApps and TK GApps fame (basically the daddy of modern GApps) has come back to release a fantastic "Zip Builder" Windows tool that all Android mod makers should find helpful!

https://xdaforums.com/android/software-hacking/tool-zip-builder-v4-2-1-build-sign-t3739556

It makes creating and signing a zip from a Magisk module or AnyKernel2 (or any otherwise complete zip contents) git repo a two-click experience, and allows unpacking and easy repacking of any downloaded flashable zip by automatically using the correct different signing processes for both shell-based and edify-based zips. Super cool.

Don't thank me, go thank his thread! :silly:
[Android Software/Hacking General [Developers Only]] ale5000:
Hi,

are you sure it works correctly with old recovery that have the "1 and 8 issue with unzip"?

I need it since I support also phones with Android 2.3, very old recoveries and picturesque recoveries (Ding Dong Recovery).

It would be nice if you release the sources.

PS: I have automated my procedure for all OS here but if I find a better method I will change it.

If I could also automate the compilation of used tools it would be the best.

---------- Post added at 10:18 ---------- Previous post was at 10:15 ----------

[MENTION=4544860]osm0sis[/MENTION]

Hi,

I need to store some info (in a single file) on the phone from a flashable zip.

Do you know a place where I can store it?

I need a place that doesn't cause any problem to Android, apps or recovery.
[Android Software/Hacking General [Developers Only]] osm0sis:
/data/local is where I install everything
[Android Software/Hacking General [Developers Only]] ale5000:
I'm not talking about apps, I just want to place a text file (with my textual data) mainly to know if it is the first installation of the flashable zip or just an upgrade and the file should survive a factory reset.
[Android Software/Hacking General [Developers Only]] osm0sis:
Oh wow, should probably be in /system then, only place that doesn't get wiped on factory reset which is also easily accessible.
[Android Software/Hacking General [Developers Only]] ale5000:
Yes, but where can I place a file in the /system partition that isn't parsed by Android and doesn't cause errors / problems?
[Android Software/Hacking General [Developers Only]] _that:
Yes it does, because that was the reason why I invested the time to research and develop this script.

I think I found the source: View attachment SignWholeFile.java.txt

The jar was built with this shell script:

javac SignWholeFile.java
jar cfe SignWholeFile.jar SignWholeFile SignWholeFile.class SignWholeFile\$SignatureOutputStream.class
[Android Software/Hacking General [Developers Only]] osm0sis:
Pretty much anywhere. Any PA GApps-based GApps use /system/etc/g.prop, so you could certainly stash something in etc. Android doesn't care about stuff like that, SafetyNet might on an unrooted device, but that's about it.
[Android Software/Hacking General [Developers Only]] partcyborg:
Well almost everyone, Android mod makers who don't use Windows won't find this that helpful yet ?
[Android Software/Hacking General [Developers Only]] osm0sis:
True! For Linux my ZipScriptSign tool from the OPs will still do the trick nicely once the zip is packaged. :good:
[Android Software/Hacking General [Developers Only]] kamilmirza:
greetings [MENTION=4544860]osm0sis[/MENTION]

i have some noob questions regarding updater-script and update-binary, advance apologies for being a complete noob :D

i have seen some zips containing the update-binary file with complete gibberish(Notepad++) or hex (Sublime Text) and the updater-script file contains the actual shell script

and sometimes the update-binary contains the shell script and the updater-script is a dummy file

even sometimes i have seen update-binary (hex) files with different sizes - from few KBs to 1.5 MBs

what does these update-binary (hex) files contain?

recently, i have started creating flashable firmwares for my device, using official OTAs update-binary (hex) with modified update-script (actual script) - is this method alright? any flaws using this method? though, i have not seen any issues yet

OR

should i switch to update-binary (containing actual shell script) with dummy updater-script method?

i.e by copy paste my updater-script into update-binary (blank file) and making updater-script the dummy file, right?

waiting for your wise counsel :)

thanks again for your great contributions to the Android community :good::highfive:
[Android Software/Hacking General [Developers Only]] osm0sis:
Well sir, I must refer you to read the "References" list (bottom of second OP) and XDA wiki link (in the OP) for EDIFY scripts since it'll answer all these questions.

I think the shell methods I explain here to replace the EDIFY are generally superior in all cases, of course. ;)
[Android Software/Hacking General [Developers Only]] Yuvch122:
Hello! I'm really interested in this keycheck function but I'm a bit confused about command1 and command2.

Let's say, I want to do multiple things when command1 is chosen, such as mkdir, extract and then run program. How would I fit all that into command1?

Command 1:
mkdir /tmp/rooting-zip
unzip $zip META-INF/com/google/android/* -d /tmp/rooting-zip
sh /tmp/rooting-zip/META-INF/com/google/android/update-binary dummy 1 $zip
Command 2:
just skip it

Sorry, I'm just a bit confused on how to properly use this.
[Android Software/Hacking General [Developers Only]] partcyborg:
Just checking: you are not responsible for the GitHub repo that was shared a ways back in the thread that contains these scripts correct? I only ask because there are some syntax errors. Maybe they are allowed in mksh but they surely aren't posix compliant because of them.

Anyway thanks for putting so much work into these. It really shows. Xda members getting their shell script on makes me happy ?
[Android Software/Hacking General [Developers Only]] osm0sis:
Nope, not mine. But yeah, things aren't always posix 'round here. :p
[Android Software/Hacking General [Developers Only]] Zappo:
To execute multiple commands, create a function.

Then call that function with "choose()":

Command1() {
mkdir /tmp/rooting-zip
unzip $zip META-INF/com/google/android/* -d /tmp/rooting-zip
sh /tmp/rooting-zip/META-INF/com/google/android/update-binary dummy 1 $zip
}
choose 30 "Command1" "Command2"
[Android Software/Hacking General [Developers Only]] osm0sis:
I just updated the signing documentation in the 2nd OP with the quite possibly revolutionary zipsigner-2.1.jar from [MENTION=4470081]topjohnwu[/MENTION]. :highfive:

It's legit amazing. I can sign Open GApps ARM 7.1 AROMA zips (1069mb) on my old PC now, which was completely impossible before due to memory constraints. Enjoy! :D

ZipScriptSign is no longer necessary at all since zipsigner is an all-in-one self-contained solution, but I've left it and the documentation for the old method up for posterity behind a Hide tag.

Edit: [MENTION=2777334]TKruzze[/MENTION] just released an update to his awesome Zip Builder package for Windows using zipsigner as well! :good:
[Android Software/Hacking General [Developers Only]] osm0sis:
Just uploaded a Proguarded build of zipsigner-2.1 courtesy of [MENTION=4470081]topjohnwu[/MENTION]. It's about 1/10 the filesize. :cool:
[Android Software/Hacking General [Developers Only]] partcyborg:
Any chance of putting all this stuff up on GitHub or somewhere downloadable? If much rather use your exact versions here but it's basically impossible up to accurately copy them on either the mobile xda app or the website in chrome, and copying them in my laptop in Linux renders them unusable as well as all the spaces get replaced with some Unicode non ASCII space or something that isn't a space. Not to mention copy pasting several huge blocks of text is cumbersome and error prone. ?
[Android Software/Hacking General [Developers Only]] osm0sis:
My goal here is to only have to update these in one place. Someone was mirroring it to GitHub for awhile, you can search the thread for it.

Also, if you hit reply on the script post you can copy them from the quoted text and whitespace is properly preserved.
[Android Software/Hacking General [Developers Only]] Nikhil:
Hi [MENTION=4544860]osm0sis[/MENTION],

I've been working on bringing Android Oreo Support to this tool, I've observed few changes being implemented with Android Oreo with the way apps are installed so I am facing issues while installing data apps (basically pushing files to /data/app)

while using the same shell script function "mount /data", I am getting below error with latest twrp version (3.2.1-0)

mount: mounting /dev/block/mmcblk0p29 on /data failed: Device or resource busy

any idea why this would be happening?

when i check if the partition is mounted using "if is_mounted /data;" it returns true.
[Android Software/Hacking General [Developers Only]] osm0sis:
That just means it's already mounted. It's good to leave those in there though, since some recoveries might not have them mounted by default (e.g. CM/Lineage recovery).
[Android Software/Hacking General [Developers Only]] Ibuprophen:
I'm just wondering if the following might help out...

run_program("/system/xbin/busybox", "mount", "/dev/block/mmcblk0p29");

I may be wrong about this but, it just looks to me like there's something wrong with the mounting script.

Just a friendly Suggestion/Recommendation... :)

~~~~~~~~~~~~~~~

I DO NOT provide support via PM unless asked/requested by myself. PLEASE keep it in the threads where everyone can share.
[Android Software/Hacking General [Developers Only]] osm0sis:
Nah, you're talking about EDIFY, and we're talking about shell. There's nothing wrong with it - my post above explains. :)
[Android Software/Hacking General [Developers Only]] Ibuprophen:
Ahhh I see! :eek:

I knew that I might have been off a bit regarding the correct script.

I'm still a "Noob-Novice" and am still trying to learn.

Thanks a bunch [MENTION=1143630]osmosis[/MENTION]! :)

~~~~~~~~~~~~~~~

I DO NOT provide support via PM unless asked/requested by myself. PLEASE keep it in the threads where everyone can share.
[Android Software/Hacking General [Developers Only]] Nikhil:
But then after I do the following

mkdir -p "/data/app/org.adaway-YB74E9vzSSpRfezAbtk3AA=="
set_perm 1000 1000 0755 "/data/app/org.adaway-YB74E9vzSSpRfezAbtk3AA=="
ui_print "Copying base.apk"
package_extract_file "customize/aroma_0/Project_My Device/Type_data_app/Group_Data Apps/Folder_org.adaway-YB74E9vzSSpRfezAbtk3AA==/base.apk" "/data/app/org.adaway-YB74E9vzSSpRfezAbtk3AA==/base.apk"
set_perm 0 0 0644 "/data/app/org.adaway-YB74E9vzSSpRfezAbtk3AA==/base.apk"

Below log comes in.

Installing org.adaway-YB74E9vzSSpRfezAbtk3AA==
Copying base.apk
chown: /data/app/org.adaway-YB74E9vzSSpRfezAbtk3AA==/base.apk: No such file or directory

When it says No such file or directory, I believe mkdir didn't work (probably because /data did not get mount?)

Also, what is "-YB74E9vzSSpRfezAbtk3AA==" anyway after package name of the app? I have tried modifying the name and when I rebooted, I lost the app as well as folder (may be thats the behavior with Android Oreo roms)

I was wondering if the same is happening with recovery too? If the name is not appropriate, the folder just gets deleted/cleaned up on boot and app never gets installed.

Is it even possible to push files to /data/app like that in Android Oreo?
[Android Software/Hacking General [Developers Only]] Nikhil:
Yeah, it was related to shell script but I will surely try this out too with edify script. I'll see if that's a general behavior of android oreo roms or if is not working with shell script in my case. Thanks for the suggestion!
[Android Software/Hacking General [Developers Only]] osm0sis:
It's just a new naming convention to avoid conflicts, replacing the old -1 -2 -3 etc. one. Since your chown error only occurred with base.apk the directory must exist, so the problem is with the extraction. Maybe try a less complex source directory within your zip?
[Android Software/Hacking General [Developers Only]] Nikhil:
I tried a less complex source directory, the folder got pushed (check first screenshot where titaniumbackup is there (-1 one)) but the same folder disappeared after boot (check second screenshot)

Is something wrong? Am I missing permissions or something?

Even if I manually go ahead and rename the folder's random alphabets part, on reboot, the folder just gets deleted.

Is this how Android Oreo behaves and there is no way we can push files to /data/app and have the apps installed on boot?