Related
Hi there, guys. I don't know if I should ask this here or in the general forum, so... here I go.
I use cerberus in my nexus one since several months ago, and after watching the SassiBoB review of this program, I started to think how could I get it permanently configured into my system, just in case the thief knows how to restore the system configuration of the phone.
She says something about installing it as a system app with... ¿Rom manager?
I can't understand it perfectly, english isn't my mother tongue.
Anyway, I used titanium backup and I was able to get it installed as a system app (I could also add it to the rom zip, but... I know, I'm such a lazy ), so this step is done. Next problem: the configuration. When you do the factory reset, the configuration of the cerberus app is deleted, so it doesn't matter if it's installed or not. It won't work.
Is there any way to keep the configuration in the system, even if you do a system reset?
I know there are several other problems, like the root apps to flash the phone, or even the recovery menu, but I would like to solve all the problems step by step, and I think this is the first one.
Thank you, guys.
Pretty sure this belongs in the question section.
I don't have it cerb but, my friend told me you go to there website https://www.cerberusapp.com/ and there's a flashable zip you download and install with Rom manger.
Yes, you are right. In the cerberus web page there is a zip file which contains the cerberus app, so you can flash it as a rom, and it keeps it installed as a system app, but unfortunately there isn't any difference with the other methods. It keeps the app after a factory reset, but the configuration is deleted, so it's like the app isn't installed. I have already sent an email to them asking if there is a way to keep the configuration, but I haven't received any answer yet (and it's new year, it's weekend...).
OK, step done. They will release another version (2.0) that keeps a copy of the configuration in /etc/system, so if we add the apk and this file to the ROM, it will be safe.
Next step: the app is installed and configured BUT it has to be added to the list of devices administration in the security and privacy option (it has to manage the device). To add it, you must open the app and set the "activate" option, so we have the same problem that we had, so now it's not an app problem, but a ROM problem.
Is there any way to change the apps aded to the devices administrator option? I supose it should be, as the configuration has to be stored somewhere...
A little step more. I think I found the file where the administration params are stored. It's in /data/system/device_policies.xml
New problem: this file is in the installed system, but I can't find it in the ROM.
¿Any idea? Thanks
Another hint: I found this:
http://hi-android.info/src/com/android/server/DevicePolicyManagerService.java.html
It seems this is the class who creates the file. It should be easy to modify it so it adds the required data to the file. New problem: I can't find this class in the ROM file. I'll keep searching...
FOUND!
It's in services.jar, inside the framework directory.
It's necessary to extract the classes.dex, convert it into .jar, extract the DevicePolicyManagerService class and decompile it as java code, and here it is:
Code:
private static JournaledFile makeJournaledFile()
{
File localFile1 = new File("/data/system/device_policies.xml");
File localFile2 = new File("/data/system/device_policies.xml.tmp");
return new JournaledFile(localFile1, localFile2);
}
I think I should be able to modify it. I can't right now, but I'll post it when I try it.
I was trying to change that java file, but it's a real pain in the ass to recompile it and avoid all the errors. Then I realized that I can just modify the update script to copy the file (yes, I'm such an idiot lol).
I was trying to get it done with the update-script in META-INF/com/google/andriod/updater-script, but I can't get it working. A little help would be appreciated
Another update (Were you missing me?). I decided to modify the flasheable zip of the cerberus, so it has all the configuration files. I added the data/system/device_policies.xml and also de etc/cerberus_conf.xml files to this zip. Then, I changed the updater:
Code:
show_progress(1.000000, 0);
ui_print("Mounting /system");
run_program("/sbin/busybox", "mount", "/system");
set_progress(0.125000);
ui_print("Mounting /data");
run_program("/sbin/busybox", "mount", "/data");
set_progress(0.250000);
ui_print("Deleting old APK from /system");
delete("/system/app/Cerberus.apk");
set_progress(0.375000);
ui_print("Deleting old APK from /data");
delete("/data/app/com.lsdroid.cerberus.apk");
delete("/data/app/com.lsdroid.cerberus-1.apk");
delete("/data/app/com.lsdroid.cerberus-2.apk");
set_progress(0.500000);
ui_print("Extracting files to /system");
package_extract_dir("system", "/system");
set_progress(0.625000);
--------------ADDED-------------------
ui_print("Extracting files to /data");
package_extract_dir("data", "/data");
set_progress(0.680000);
---------------------------------------
ui_print("Unmounting /data");
unmount("/data");
set_progress(0.750000);
ui_print("Unmounting /system");
unmount("/system");
set_progress(0.875000);
ui_print("Installation complete!");
set_progress(1.000000);
It's a standalone zip file, so you need to flash your ROM and flash this zip file after it. Anyway,
WARNING
This doesn't work. After flashing the second zip file, the ROM won't boot (It keeps booting, with the boot animation in loop). I suppose I break the data directory or something like that. I'll keep trying.
Yep, I tried several things and the problem is with this line:
package_extract_dir("data", "/data");
It seems it breaks the data directory or something like that. The other files are copied perfectly.
OK, problem found with adb. With this command, it deletes completely the /data/system directory, so it keeps only the new file. Time to fix it...
EDIT: my fault. /data/system is empty until we start the system for first time. We must flash the rom, boot it, restart and flash the patch with cerberus. This is starting to be kinda stupid... If we do this, we can select cerberus in the administrators menu, instead of flashing anything...
Last post for the moment with partial conclussions.
When we do a factory reset, it deletes ALL the content of the data directory. So it's impossible to solve this problem just flashing anything after the ROM. Is the ROM who HAS TO COPY the device_priorities.xml into /data/system/. There isn't any other way, it would be erased after a factory reset.
Now, time to find out how to get it done by the ROM. I'll let you know as soon as I get it.
Work!
I did a full wipe (Wipe Data / Factory Reset + Wipe Cache Partition Wipe Dalvik Cache) and installed the official samsung rom (Android 4.1.2). I installed the flashable ZIP from the site on my galaxy s2 and did not have to reconfigure anything. Everything worked as it should. I believe that the application connects to the user's account based on the information of the device recorded previously.
Avast anti-theft has a Function to protect the configuration after a wipe. Just discover how avast achieves this.
(Translated via google translator)
That's the one thing is that even Avast and Cerberus won't escape if /system is formatted, but Avast did make it through a full SBF followed by factory reset on my phone.
Would this be a possible solution to our kernel flashing problems, I know it works for the evo
Sent from my HTC Amaze 4G using XDA App
DEFINITIONOFREAL said:
Would this be a possible solution to our kernel flashing problems, I know it works for the evo
Sent from my HTC Amaze 4G using XDA App
Click to expand...
Click to collapse
It's possible. In fact I mentioned this about a month ago to a developer.
I would like to see one that has a couple of options such as flashing recovery and flashing boot.img files.
You can easy push the flash_image binary to /system/bin and set the permission to 755. In fact my CWMFaux kernel does just that. Faux stopped using it because it doesn't always work.
In fact I made it so easy that all you need to do is push the boot.img to /system and reboot. Yet... no one uses it. In fact I suggested to a couple of rom developers to simply add the binary file to /system/bin so that you can at least run the command from terminal but they don't even want to do that. I like being able to update my recovery at anytime by entering "flash_image recovery /sdcard/recovery.img" and then just rebooting to recovery. You can easily do that for kernels too. But I suppose it's so much easier to carry a computer around.
Binary100100 said:
It's possible. In fact I mentioned this about a month ago to a developer.
I would like to see one that has a couple of options such as flashing recovery and flashing boot.img files.
You can easy push the flash_image binary to /system/bin and set the permission to 755. In fact my CWMFaux kernel does just that. Faux stopped using it because it doesn't always work.
In fact I made it so easy that all you need to do is push the boot.img to /system and reboot. Yet... no one uses it. In fact I suggested to a couple of rom developers to simply add the binary file to /system/bin so that you can at least run the command from terminal but they don't even want to do that. I like being able to update my recovery at anytime by entering "flash_image recovery /sdcard/recovery.img" and then just rebooting to recovery. You can easily do that for kernels too. But I suppose it's so much easier to carry a computer around.
Click to expand...
Click to collapse
Im going to contact joeykrim and see if I can get him to add support in his app, and Ive been using your method since I got the phone (2 days ago) and started reading, but still a little hassle, and a big htc fail
Sent from my HTC Amaze 4G using XDA App
DEFINITIONOFREAL said:
Im going to contact joeykrim and see if I can get him to add support in his app, and Ive been using your method since I got the phone (2 days ago) and started reading, but still a little hassle, and a big htc fail
Sent from my HTC Amaze 4G using XDA App
Click to expand...
Click to collapse
Keep me posted will ya?
I believe that Faux and other developers would have to use the zImage kernel flashing technique to get it to work with his existing app but I'm sure he can simplify it to accept .img files and the .ko files in the /system/lib directory of a zip file. It actually should be very easy. It took me about ten mintues with testing included to create the script for my method. I just can't code for apps else it would be done by now.
DEFINITIONOFREAL said:
Im going to contact joeykrim and see if I can get him to add support in his app, and Ive been using your method since I got the phone (2 days ago) and started reading, but still a little hassle, and a big htc fail
Sent from my HTC Amaze 4G using XDA App
Click to expand...
Click to collapse
I contacted pershoot, no answer lol!!!
Joeykrim is willing to support the Amaze, he just needs testers, this would be a great backup incase the new script failed to push the kernel. I'll keep everyone posted with updates
Sent from my HTC Amaze 4G using XDA App
I've been working with joeykrim getting his app setup for our device, it looks like it should work, hopefully, within the next couple of days we can get this working and released
Sent from my HTC Amaze 4G using XDA App
DEFINITIONOFREAL said:
I've been working with joeykrim getting his app setup for our device, it looks like it should work, hopefully, within the next couple of days we can get this working and released
Sent from my HTC Amaze 4G using XDA App
Click to expand...
Click to collapse
That would be wonderful!
I'm tired of having to repeat myself.
flash_image boot /sdcard/boot.img
flash_image recovery /sdcard/recovery.img
Binary100100 said:
That would be wonderful!
I'm tired of having to repeat myself.
flash_image boot /sdcard/boot.img
flash_image recovery /sdcard/recovery.img
Click to expand...
Click to collapse
I just wish the devs would use your script, it would make things so much easier
Sent from my HTC Amaze 4G using XDA App
DEFINITIONOFREAL said:
I just wish the devs would use your script, it would make things so much easier
Sent from my HTC Amaze 4G using XDA App
Click to expand...
Click to collapse
Once I see that they do I can work out something else like:
kernelupdate
recoveryupdate
kernelupdate would be
flash_image boot /sdcard/kernel/*boot*.img
recoveryupdate would be
flash_image recovery /sdcard/recovery/*recovery*.img
So that if you place ANY of the appropriate img file in the perspective folders on the sdcard partition it would flash the .img by just entering either of the two commands from adb shell or terminal.
But I'm not going to waste my time if the devs don't want to use it.
Binary100100 said:
Once I see that they do I can work out something else like:
kernelupdate
recoveryupdate
kernelupdate would be
flash_image boot /sdcard/kernel/*boot*.img
recoveryupdate would be
flash_image recovery /sdcard/recovery/*recovery*.img
So that if you place ANY of the appropriate img file in the perspective folders on the sdcard partition it would flash the .img by just entering either of the two commands from adb shell or terminal.
But I'm not going to waste my time if the devs don't want to use it.
Click to expand...
Click to collapse
could a script be written to automatically flash these while installing/flashing the custom rom? This would cut down atleast the step for flashing kernels for a lot of noobs!!
seansk said:
could a script be written to automatically flash these while installing/flashing the custom rom? This would cut down atleast the step for flashing kernels for a lot of noobs!!
Click to expand...
Click to collapse
Actually, yes! I did add it to the init.d script but since xboarder had removed the init.d scripts from his rom it doesn't work anymore. But you sure could. It was basically how I was setting up my CWMFaux kernels. However it didn't seem to work 100% of the time. Couldn't figure out why.
It basically worked like this...
Flashing the CWM custom kernel .zip via recovery.
copies boot.img to /system
copies init.d 06tweaks script to init.d folder.
copies and set permissions for flash_image binary and kernelupdate script to /system/bin directory.
You then boot your phone up which triggers the init.d script which commands the kernelupdate script to initiate. The kernel update script is simply using the flash_image binary command "flash_image boot /system/boot.img" and it automatically updates the kernel. Then the init.d script removes the boot.img file from the /system directory to keep it from flashing upon every boot.
I would like to change it to /sdcard directory but there's the problem that the sdcard doesn't get mounted until the very end. WAY after the system. Which is why I stored it there. The system gets mounted even before the data partition so I couldn't even store the file in data because the script would run even before the data partition could mount. Basically the script is initiated while your still looking at the boot animation. Pretty much when your softkey backlights and led light comes on it flashes the new kernel. It's a pretty neat workaround if I must say but unfortunately nowhere near perfect and not even close to having an s-off workaround.
Now if you don't mind the fact that it won't be initiated upon boot I could make it so that it will flash any file in a perspective folder on the sdcard.
example:
kernelupdate would update the kernel with any *boot*.img file located in a certain directory... say /sdcard/kernel
recoveryupdate would update the recovery with any *recovery*.img file located in a certain directory... say /sdcard/recovery
The problem:
Some people would want to collect their kernels and recoveries and store them in those directories. That would NOT be possible since using the command "flash_image recovery /sdcard/*recovery*.img would flash any img file with the word "recovery" in it. So if there's more than one it would error out and not flash anything because of the conflict. Same principal with the kernel only MOST kernels are simply named "boot.img" where-as almost all recovery files have a unique name since they are all already custom.
Binary100100 said:
Actually, yes! I did add it to the init.d script but since xboarder had removed the init.d scripts from his rom it doesn't work anymore. But you sure could. It was basically how I was setting up my CWMFaux kernels. However it didn't seem to work 100% of the time. Couldn't figure out why.
It basically worked like this...
Flashing the CWM custom kernel .zip via recovery.
copies boot.img to /system
copies init.d 06tweaks script to init.d folder.
copies and set permissions for flash_image binary and kernelupdate script to /system/bin directory.
You then boot your phone up which triggers the init.d script which commands the kernelupdate script to initiate. The kernel update script is simply using the flash_image binary command "flash_image boot /system/boot.img" and it automatically updates the kernel. Then the init.d script removes the boot.img file from the /system directory to keep it from flashing upon every boot.
I would like to change it to /sdcard directory but there's the problem that the sdcard doesn't get mounted until the very end. WAY after the system. Which is why I stored it there. The system gets mounted even before the data partition so I couldn't even store the file in data because the script would run even before the data partition could mount. Basically the script is initiated while your still looking at the boot animation. Pretty much when your softkey backlights and led light comes on it flashes the new kernel. It's a pretty neat workaround if I must say but unfortunately nowhere near perfect and not even close to having an s-off workaround.
Now if you don't mind the fact that it won't be initiated upon boot I could make it so that it will flash any file in a perspective folder on the sdcard.
example:
kernelupdate would update the kernel with any *boot*.img file located in a certain directory... say /sdcard/kernel
recoveryupdate would update the recovery with any *recovery*.img file located in a certain directory... say /sdcard/recovery
The problem:
Some people would want to collect their kernels and recoveries and store them in those directories. That would NOT be possible since using the command "flash_image recovery /sdcard/*recovery*.img would flash any img file with the word "recovery" in it. So if there's more than one it would error out and not flash anything because of the conflict. Same principal with the kernel only MOST kernels are simply named "boot.img" where-as almost all recovery files have a unique name since they are all already custom.
Click to expand...
Click to collapse
quite a dilemma, I wonder if we could add pause to the script until everything is loaded on the first boot then after the pause the script flahes the recovery and more importantly the kernel!!! if this was possible we could keep the files in a separate place on the SD card.
Still nothing like S-off!!! Thanks HTC for being so dev friendly
seansk said:
quite a dilemma, I wonder if we could add pause to the script until everything is loaded on the first boot then after the pause the script flahes the recovery and more importantly the kernel!!! if this was possible we could keep the files in a separate place on the SD card.
Still nothing like S-off!!! Thanks HTC for being so dev friendly
Click to expand...
Click to collapse
I'm sure there's a way to add a delay timer of some sort. I'm just not that savvy. Easiest way would be through an app like Tasker.
DEFINITIONOFREAL said:
Would this be a possible solution to our kernel flashing problems, I know it works for the evo
Sent from my HTC Amaze 4G using XDA App
Click to expand...
Click to collapse
The short answer is yes!
I've setup the application to support the HTC Amaze 4G, but before I release it publically and officially, I want to have a few testers confirm everything is working properly for them.
Posted all the information in a new thread as this one seems to be covering a few different topics so I didn't want to "hijack".
http://forum.xda-developers.com/showthread.php?p=21574722
Thanks for the request and for reaching out to me DEFINITIONOFREAL.
Binary100100 said:
Once I see that they do I can work out something else like:
kernelupdate
recoveryupdate
kernelupdate would be
flash_image boot /sdcard/kernel/*boot*.img
recoveryupdate would be
flash_image recovery /sdcard/recovery/*recovery*.img
So that if you place ANY of the appropriate img file in the perspective folders on the sdcard partition it would flash the .img by just entering either of the two commands from adb shell or terminal.
But I'm not going to waste my time if the devs don't want to use it.
Click to expand...
Click to collapse
I think my application, Flash Image GUI, will be the best alternative, but of course I have a biased opinion!
Regarding alternatives, I think a simple sh script which takes an argument would make a nice wrapper. The argument would be location to the image file to flash. The script could either bundle the flash_image binary or take the location of it as another argument.
All depends on how the developers want to create some type of standard. Which is another great reason Flash Image GUI will work well as it contains everything required and doesn't rely on developers providing support in their ROM, only relys on developers following the standards for ROMs and kernel .zip files.
Also, in looking through some of the custom ROMs and kernel .zip files for this device, I notice one of the custom kernels does something similar to the suggestions above, it executes a file located in /system/etc/init.d on every boot which automatically flashes /system/boot.img file.
At first glance I was horrified to see this as this is a *major* security issue. If anybody were to place any type of file in /system/boot.img, either a rogue kernel or just a blank file, the script automatically flashed it on boot w/o any type of file verification or user notification!
Wanted to get that off my chest and discourage the use of *automatic* loading of any type of major file, such as kernel or recovery image, especially without at least file verification or user approval/notification.
I'll try and keep up with the thread and help contribute ideas to alternatives for anybody who wants to develop/implement! Great ideas in the thread and always enjoy reading community collaboration efforts, especially in resolution to manufacturer "adjustments" of standards.
ugh, sorry about the double post (too excited for being too early in the morning). if a moderator wants to combine my last two posts, please do. i dont have access to delete a post.
joeykrim said:
I think my application, Flash Image GUI, will be the best alternative, but of course I have a biased opinion!
Regarding alternatives, I think a simple sh script which takes an argument would make a nice wrapper. The argument would be location to the image file to flash. The script could either bundle the flash_image binary or take the location of it as another argument.
All depends on how the developers want to create some type of standard. Which is another great reason Flash Image GUI will work well as it contains everything required and doesn't rely on developers providing support in their ROM, only relys on developers following the standards for ROMs and kernel .zip files.
Also, in looking through some of the custom ROMs and kernel .zip files for this device, I notice one of the custom kernels does something similar to the suggestions above, it executes a file located in /system/etc/init.d on every boot which automatically flashes /system/boot.img file.
At first glance I was horrified to see this as this is a *major* security issue. If anybody were to place any type of file in /system/boot.img, either a rogue kernel or just a blank file, the script automatically flashed it on boot w/o any type of file verification or user notification!
Wanted to get that off my chest and discourage the use of *automatic* loading of any type of major file, such as kernel or recovery image, especially without at least file verification or user approval/notification.
I'll try and keep up with the thread and help contribute ideas to alternatives for anybody who wants to develop/implement! Great ideas in the thread and always enjoy reading community collaboration efforts, especially in resolution to manufacturer "adjustments" of standards.
ugh, sorry about the double post (too excited for being too early in the morning). if a moderator wants to combine my last two posts, please do. i dont have access to delete a post.
Click to expand...
Click to collapse
I look forward to tryin out your app.
It was basically what this thread was all about in the first place.
The clockwork method that you mentioned is the only workaround that I was able to come up with for custom kernels (like Faux123) because a kernel cannot be flashed through recovery without s-off. Really stupid. So I started thinking "How can we flash a boot.img file from recovery without the typical means?" Then came up with the solution to flash_image the boot.img file automatically IF the file is detected. But how to start a script automatically upon boot? init.d is the only way I could think of. Okay... so where to put the boot? I tried the sdcard but it failed to mount until it was way too late. So... data. Nope... still didn't mount in time. Cache? Well... how many developers will include a cache file into their roms? So the only other option was /system and it seemed convenient since /system mounts BEFORE the script can run (obviously) so that's why it is as it is. I also figured "If someone wants to flash a new kernel all they need to do is push the boot.img to /system and reboot." Must easier than using the EKF method (requiring PC access) and I don't know about you but I'm not around a computer 24/7.
hello there! i think this is my first post here but ive been lurking since my evo 4g days. But my question is, is there anyway to remove the full wipe that comes with some roms? sometimes ill flash a kernel that hates my rom or my phone or more likely me. Or some other error happens and i would like to just flash the same rom over top to repair and be on my way. ive been running meanrom gb and it works no problem. but i tried running mikrunny 1.13 and i tried flashing rcmix kernel on it and apparently it wasnt for gingerbread i guess. but since it had full wipe built in i lost all my stuff and had to start fresh. sorry for the drawn out post but just trying to explain what my reasonings are. thanks everyone for being awesome here!
You can always do a advance backup of your data in 4ext recovery, cwm recovery I believe also has that option
(Don't ask me for help as I couldn't care if your phone explodes, eh!
It's a command in the install script. Now where and how to remove, I'm not sure.
jump454 said:
hello there! i think this is my first post here but ive been lurking since my evo 4g days. But my question is, is there anyway to remove the full wipe that comes with some roms? sometimes ill flash a kernel that hates my rom or my phone or more likely me. Or some other error happens and i would like to just flash the same rom over top to repair and be on my way. ive been running meanrom gb and it works no problem. but i tried running mikrunny 1.13 and i tried flashing rcmix kernel on it and apparently it wasnt for gingerbread i guess. but since it had full wipe built in i lost all my stuff and had to start fresh. sorry for the drawn out post but just trying to explain what my reasonings are. thanks everyone for being awesome here!
Click to expand...
Click to collapse
Look at the updater-script in the meta-inf folder you will see something that looks like this at the top of the script
Code:
format("ext4", "EMMC", "/dev/block/mmcblk0p24");
Remove any line that references formatting a partition. I wanna say that's all you'd need to do. If that doesn't work PM me a link to the ROM and I'll play with it and get it how you want it.
Editing the updater-script file
This might be more than you are interested in trying, but maybe not if you've been lurking since Evo 4G days.
All Android ROM and kernel installation scripts ultimately perform the installation using a scripting language called Edify, but some of them also have an Aroma script included as a preprocessor. Here's a good description of the relationship between Edify and Aroma explained by the Aroma developer.
To do what you are asking requires editing the /META-INF/com/google/android/updater-script file within the zip file you are going to flash. I use WinZip and UltraEdit on my PC but there are a number of editors and archiving programs that will work. You have to use an editor that will leave the Unix/Linux end-of-line characters and Notepad++ is a free editor that can do that.
Once you have the updater-script file open, look for lines like this:
Code:
ui_print("Formatting DATA Partition...");
unmount("/data");
run_program("/sbin/erase_image", "userdata");
format("ext4", "EMMC", "/dev/block/mmcblk0p24");
and change them to this:
Code:
# ui_print("Formatting DATA Partition...");
# unmount("/data");
# run_program("/sbin/erase_image", "userdata");
# format("ext4", "EMMC", "/dev/block/mmcblk0p24");
The lines above are from the updater-script file in the MikVirgin 1.01 zip file.
That will prevent your data partition from being formatted, although flashallthetime's suggestion to do an advanced backup of the data partition before flashing and advanced restore afterwards is effectively the same as the above script change. However, you may find other things you want to change in updater-script files if you become more familiar with them.
For more help with editing scripts just do a Google search for "edify script". If it's more than you want to tackle, PM ItzCrooK2UxD and ask him to make the changes for you.
ramjet73
thanks guys for the fast reply. i dont wanna do a backup everytime because the backup alone takes up more time then flashing the rom over itself plus then youd have to reflash the backup after the fact. i will try some suggestions and see if they work.
Not a full back up, just an advance data back up which takes no time at all
(Don't ask me for help as I couldn't care if your phone explodes, eh!
advance databackup? ive never heard of that. im gonna see if i can locate it in 4ext right now!
When you go into recovery you'll see backup/restore and you'll see advance restore
Sent from my PG86100 using Tapatalk 2
This should be applicable to any ROM on devices which share internal storage for applications and the internal "sdcard" (Note II, SGS3, probably others). Symptoms may include inability to take screenshots and other failures, and will usually show a "Permission denied" in logcat for files under /data/media/. The underlying problem is that permission is denied to the filesystem, even by the root user when the ROM is booted (this is strange and I still don't understand why). Running "Fix permissions" did not fix this issue for me (that script doesn't change any permissions on the sdcard).
When booted into recovery (ClockworkMod was tested in my case), root has the ability to reset the permissions properly. To fix the problem, connect with adb while booted in recovery and run the following commands to correct the permissions:
Code:
chown -R media_rw:media_rw /data/media/
find /data/media/ -type d -exec chmod 775 {} ';'
find /data/media/ -type f -exec chmod 664 {} ';'
UPDATE (Credit to @Quinny899) If that does not work, you may also want to reset the SELinux contexts for the media partition with this command:
Code:
restorecon -FR /data/media/
Hope this helps! :victory:
I recently restored a Nandroid backup of my old Nexus 7 on a replacement Nexus 7. Most everything worked okay, but screenshots, deleting certain files and directories, and other basic operations weren't really working, and "Fix permissions" didn't help.
Running the commands here worked like a charm! I used TWRP and I have JellyBeer 4 on my Nexus 7. Thanks!
skoshy,
I'm glad this helped you. JellyBeer is a fantastic ROM. Cheers!
xak944 said:
skoshy,
I'm glad this helped you. JellyBeer is a fantastic ROM. Cheers!
Click to expand...
Click to collapse
Well, I created a ZIP of this for people to flash in Recovery, ADB sideload or in an App like Fashify... Only to realize that XDA superstar @osm0sis had already done pretty much the same thing with his sdcard Fix Permissions Script Found here. His script uses pure edify whereas mine uses linux commands.. Both work but his Was First so I will only leave the link for his.
Cheers!
Yeah it's kinda funny. I had that script posted up in the ADBsync thread back in February because I noticed things could start acting funny when I restored an entire sdcard backup to one of my devices. But hey, great minds think alike! Good work all around!
Thanks @TheByteSmasher for bringing another use for the zip to my attention! I didn't know those things had a tendency to go awry on their own as well!
Edit:
Here's the edify script equivalent of the above, plus the proper original perms for /data/media itself, and the special perms that CWM likes its subfolder to have (root + all). TWRP keeps its backups under the primary user subfolder (/data/media/0) and doesn't seem to care as much.
cwm-sdcard.Fix.Permissions.zip/META-INF/com/google/android/updater-script:
Code:
ui_print("");
ui_print("sdcard Fix Permissions Script");
ui_print("by osm0sis @ xda-developers");
show_progress(1.34, 0);
ui_print("");
ui_print("Mounting...");
run_program("/sbin/busybox", "mount", "/data");
set_progress(0.2);
ui_print("");
ui_print("Setting /data/media to media_rw and fixing...");
set_perm_recursive(1023, 1023, 0775, 0664, "/data/media");
set_perm(1023, 1023, 0770, "/data/media");
set_progress(0.8);
ui_print("");
ui_print("Setting /data/media/clockworkmod perms...");
set_perm_recursive(0, 0, 0775, 0777, "/data/media/clockworkmod");
set_progress(1.0);
ui_print("");
ui_print("Unmounting...");
unmount("/data");
set_progress(1.2);
ui_print("");
ui_print("Done!");
set_progress(1.34);
Available over in my Odds and Ends thread as TheByteSmasher mentioned before.
Nice. Good to know this is a well known issue, I thought I was nearly alone (and it drove me up the wall for a while until I figured it out).
Does anyone know what is technically causing even the root user not to be able to write? I'm curious.
Probably because even root apps only run root commands when they need to, so for simple stuff could run into the same issue. Just a guess, but makes sense.
I'm not talking about root apps. When I had the issue I couldn't modify any files with a shell over adb as the root user. Write operations always resulted in 'permission denied' errors. Generally in Linux, the only way this can occur is with filesystem permissions (root user bypasses this), the immutable bit (not set), or if it's a read-only filesystem (didn't appear to be based on the output of 'mount').
xak944 said:
I'm not talking about root apps. When I had the issue I couldn't modify any files with a shell over adb as the root user. Write operations always resulted in 'permission denied' errors. Generally in Linux, the only way this can occur is with filesystem permissions (root user bypasses this), the immutable bit (not set), or if it's a read-only filesystem (didn't appear to be based on the output of 'mount').
Click to expand...
Click to collapse
Osm0sis actually states in the description of his zip, that when you use ADB push to put some stuff on the SD it can mess with the permissions... that's what did it for me.. but I guess a nandroid restore can cause it too depending on how it performs the action.
Sent from my Nexus 4 using Tapatalk 4 Beta
I'm ditching the idea of editing fix_permissions. The way they do all the system files is extremely intelligent and done on-the-fly based on the contents of certain system files to trace through. Adding something specifically for internal sdcards, even with the appropriate checks, would be a hack compared to all the really great work they've done to make the script device-nonspecific.
Deleted
1990mustafa said:
Deleted
Click to expand...
Click to collapse
Could somebody point me in the direction of how to do this for the Note 3 SM-9005 please?
I have an internal SD permissions issue and the flashable zip doesn't work, I presume because the directories are located slightly differently.
Many thanks
i m also stuck in same boat as none of scripts work for note 3... need some help / guidance here ..
You saved me, i was playing with ubuntu touch and i forgot that symbolic links and chown always modify the original directory and twrp could not fix the permissions!
Thank you! Works like a charm! :highfive:
Following using this, I found that the internal SD wouldn't be mounted
Googling the logcat output's lines, I found this, specifically:
[email protected] said:
use for fixing access
su
restorecon -FR /data/media/0
Click to expand...
Click to collapse
Worked a dream, might be useful for anyone else
Quinny899 said:
Following using this, I found that the internal SD wouldn't be mounted
Googling the logcat output's lines, I found this, specifically:
Worked a dream, might be useful for anyone else
Click to expand...
Click to collapse
worked perfectly!
Hey, big THANKS to everyone who contributed to this thread. I restored by SD a different way than I used to do it and had this issue. I figured it was a permissions issue but couldn't get the 'Fix Permissions' function in TWRP or ROM Manager to fix it (now I know why). This saved me, much appreciated!
Quinny899 said:
Code:
su
restorecon -FR /data/media/0
Click to expand...
Click to collapse
Oh man, so it was SELinux causing these issues all along!? I wonder why my original fix worked then since it didn't reset the SELinux context... Oh well, good to know.
Thanks @TheByteSmasher for leading me to the right solution
TheByteSmasher said:
Well, I created a ZIP of this for people to flash in Recovery, ADB sideload or in an App like Fashify... Only to realize that XDA superstar @osm0sis had already done pretty much the same thing with his sdcard Fix Permissions Script Found here. His script uses pure edify whereas mine uses linux commands.. Both work but his Was First so I will only leave the link for his.
Cheers!
Click to expand...
Click to collapse
Thanks again
osm0sis said:
osm0sis' Odds and Ends -- Misc./Batch Tools, Flashable Zips, Scripts, etc.
General Information
In a nutshell, I just wanted a single thread to gather links to some of my other, larger projects, but also serve as a spot I could put some smaller scripts and zips I've created that I don't think merrit their own separate threads. This is partially for my own sanity and will hopefully make it easier for others to find some things as well. A lot of the stuff here was developed with the GN or N7 (my devices) and Windows in mind, but could generally be applicable to most devices either out-of-the-box or with some slight modification. If you see something that inspires you, go ahead and mod it, just let me know and give me some credit somewhere. If anyone would like to know the specifics of what's in a particular script that I haven't already linked to more information on, just let me know and I'll post that in here as well. Thanks!
Misc./Batch Tools
AnyKernel 2.0 (many devices) - link
AnyKernel was a simple template for an update.zip that could apply any kernel to any ROM, regardless of ramdisk to reduce the chance of any issues arising from the custom kernel pairing. The drawback to this is that some kernels require modifications to the ramdisk to enable/set up kernel features, and in the old AnyKernel format there was no way to do this. AnyKernel 2.0 pushes the format even further by allowing kernel developers to modify the underlying ramdisk for kernel feature support easily using a number of included command methods along with properties and variables to customize the install experience.
Android Image Kitchen (many devices) - link
A collection of Windows/Android ports of the necessary Linux utilities for Android image (kernel+recovery) mod work, and my own automation script to unpack, edit and repack the ramdisk. Other guides/scripts exist but none of them are universal for target device, compression and/or developed for Windows/Android. Now also Linux builds to bring my improved featureset back to where it came from. Has been extremely useful for me in my messing around with kernel ramdisks.
ADB Screenshot (all devices) - attached
Take screenshots while in recovery. Useful for development of recovery apps or error reporting. Original method had lots of different threads around with the general method for various devices but I figured out a couple tricks required for getting it working on the Galaxy Nexus and then automated the process. Tested and confirmed working with both pixel formats of CWM and TWRP. More information in this GN Q&A FFmpeg thread. New method uses fb2png and should work on all devices.
ADBsync sdcard Backup (many devices) - attached
Backs up the entire sdcard so that you can have a complete snapshot of your device when you make periodic backups, and be able to restore things exactly as they were. Automates the sync process of Renate NST's great ADBsync utility which makes only newer files get pulled, significantly decreasing backup time for the sdcard compared to "adb pull". Original version posted in the old ADBsync thread. Defaults for devices with /data/media/ internal sdcards (Nexus devices, etc.), but is easily customizable to backup other mountpoints.
Flashable Zips
Nexus BootUnlocker script (GN, N4, N5, N7 '13, N10) - attached
I don't know about everyone else but sometimes I find I've rebooted into the bootloader only to realize I've forgotten to unlock it in segv11's excellent BootUnlocker App beforehand. Well, I decided to make a BootUnlocker Script for my Galaxy Nexus so I could just boot to recovery quickly, unlock, then adb reboot-bootloader (or use my Reboot To Bootloader script below) to get back without having to fully boot the OS to make the change. Also extremely useful in the case you aren't able to boot. As with the app there is no data loss like there would be with fastboot, allowing you to relock for safety. Originally posted in the GN EDIFY Scripting thread. Modified for the newer Nexus devices and combined into a single Nexus BootUnlocker zip with tamperbit reset support added using information from the BootUnlocker App Dev thread.
N7 BootUnlocker script (N7 '12) [creation guide] - link
The Nexus 7 2012 is a special case. Per-device encryption of an entire partition makes it impossible to support the N7 '12 in a simple root app, or flashable zip as above, however using my guide and included script you can now create a working BootUnlocker Script Zip for your specific device. As with the above scripts there is no data loss like there would be with fastboot, allowing you to relock for safety.
Flashify script (many devices) - attached
This script zip makes flashing boot.img (kernel), recovery.img, and radio.img/modem.img (baseband) files via recovery simple. Inspired by cgollner's powerful and visually stunning Flashify App, it aims to save the average user the hassle of repacking their own image zip, or using the command-line or fastboot to flash it. Place an appropriately named file in the same directory as the zip and flash away! Should work on all emmc devices with normal partition naming ("boot", "recovery" and "radio" or "modem") which accept Android standards-compliant images. Extremely handy when used with amarullz' brilliant AROMA Filemanager, and/or my Android Image Kitchen: Mobile Edition (linked above).
Kernel Emergency Reset script (many devices) - link
Basically a go-to cure-all for custom kernel users experiencing issues after an upgrade due to old settings left over in a kernel control app (eg. franco.Kernel updater, Trickster, etc.), or problematic init.d/userinit.d scripts. It's also useful if you just want to make sure you're running clean defaults without conflicts.
Reboot To Bootloader script (all devices) - attached
Those who prefer using CWM may have noticed a couple of things missing that the other popular custom recovery, TWRP, has built-in. One of these is a file explorer/manager, which is answered by amarullz' brilliant AROMA Filemanager. Another thing I found myself wanting is a way to reboot back to the bootloader once I'm in recovery, so I created this very very simple flashable zip script. (No longer required on CWM >=6.0.3.5). Note: Once in the bootloader, "Start" will boot you back to recovery. Not sure why, but it's not a big deal, just reboot normally from recovery at that point.
sdcard Fix Permissions script (many devices) - attached
A little flashable zip script to fix ownership and permissions of files and directories on the sdcard to what they would be if Android OS had put them there itself, since some apps can't access pushed files that have root.root as owner/group. This is useful when restoring to your sdcard backup, as with my ADBsync sdcard Backup batch script above, since generally, pushed files get root.root from adb shell and higher permissions than usual. Also a solution for a bug where sdcard files get lower permissions somehow, resulting in similar access problems. Currently written for devices with /data/media/ internal sdcards (Nexus devices, etc.), but could easily be modified for other mountpoints.
nano Terminal Editor v2.2.6 Installer (all devices) - attached
A simple installer to push bgcngm's great Android port of the nano editor binary to /system/xbin/ along with the required files in /system/etc/terminfo/. It can then be used from Terminal while booted from that point on. Each time you flash it also temporarily enables use in recovery by pushing a script to /sbin/nano with the required environment variables, so you can then trigger it from recovery shell or the console in amarullz' brilliant AROMA Filemanager. Makes it extremely easy and worry-free to tweak and mod on the go, knowing you can edit the faulty build.prop or init.d script if something goes wrong. This script could also be added to recovery to make the functionality permanent.
odex Script Installer (all devices) - attached
Based on the great work and binaries from this thread, a simple installer to push my odex script along with the required dexopt-wrapper and zip binaries to /system/xbin and set the appropriate permissions. Automates the procedure to odex any apk or jar from the commandline to potentially improve performance. Dalvik runtime only. Also uses cut from busybox.
Kernel init.d Support Injector (many devices) - attached
Following from great ideas by Captain_Throwback in my AnyKernel2 thread and using script from my Flashify script above, this AK2 zip will inject basic init.d bootscript support into any kernel ramdisk on any emmc device with normal partition naming and using the Android bootable image standard, without having to bloat a ramdisk using a busybox binary. This zip is also signed, so could potentially be used with stock recovery on a locked bootloader, but that depends on the stock recovery supporting grep, etc. for the zip script to perform the required file changes.
Dev Team init.d Pack Installer (all devices) [see "950iosettings, etc." below] - link
A simple installer I wrote to create the /system/etc/init.d/ directory, extract the latest init.d scripts as published by the "Franco's Dev Team" tuning collective (of which I'm a member), then set correct owner, group and permissions to the entire init.d directory. Link points to my Dev-Host since these may still be subject to change from time to time. If you are a developer and would like to include these tunables/scripts in your kernel or ROM please provide credit. A lot of time and effort has gone into this project and that's all we ask.
Credits & Thanks: All authors of any included binaries and libraries for their amazing work. Anyone who's helped me with these projects along the way.
Disclaimer: Naturally, you take all the responsibility for what happens to your device when you start messing around with things.
XDA:DevDB Information
osm0sis' Odds and Ends -- Misc./Batch Tools, Flashable Zips, Scripts, etc., Tool/Utility for the Android General
Contributors
osm0sis
Version Information
Status: Stable
Created 2013-11-13
Last Updated 2015-03-30
Click to expand...
Click to collapse
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?