Related
Hi just asking if anyone knows any links or archives or anything i can read through, im looking to build my own ROM. any help would be much appreciated and dont mind donating to someone that can help me start to learn.
Thanks
Well, first of all you need to be able to compile Android. This is pretty easy and it's explained directly in the developers google website. If you're not running a Nexus One or a Nexus S, you can't actually compile a working android copy for your own phone "as is" from AOSP. Because of this, you firstly need to change / create some dirs and files in order to add the support for your particular device. I'd start searching on CM repositories for this (I've got the Nexus One and thus I don't have such problems).
After you've compiled Android for your device and your changes (for example root), you'll have some disk images (you can find them all under out/target/product/PHONE_MODEL/, they are the .img files). You can directly flash them via fastboot ("fastboot flash boot boot.img" etc.). You can though create an update.zip file, and this can be made extracting the system.img file in a folder. Remember that you'll have to recreate the symlinks (to toolbox and/or busybox if you want to include it in your build) and set permissions, as zip doesn't save the permissions of the files once compressed.
Thus so far, if you succeed making every single step you should have your ROM on your phone
Since going on a little adventure with this, and successfully changing my boot Splash screen, (The ASUS + Nvidia logo before the standard boot animation) I decided to post a guide on how I accomplished this myself.
Thanks: This would not have been possible without the wonderful work of rayman86 for his blobtools, whirleyes for his splash patcher, and gee one for putting up with my total noob questions while I stumbled through this :3
The usual Disclaimer applies here, I'm not responsible for bricks, and if you're trying this with Sbkv2 (Like I did) and mess up, quite frankly you are FOUBAR SOL OCSA!! Be.. Careful. May the force be with you.
This guide was run on a Windows 7 (x64) machine, I was going to use linux, but I couldn't get Blobtools source to compile into something working (since I'm functionally retarted), the commands are pretty much exactly the same though, if you can get blobtools working.
Required files:
1. The latest ASUS update firmware from their site for your region: (I used US .24 firmware) link
2. Rayman84's (Give him thanks!) Blobtools (don't need boottools for just a splash screen change) [Attached] Original thread: link
3. A hex editor, I used xvi32 (you just need to be able to read and compare blobs) link
4. Three Images that you want to patch the splash screen with, the sizes need to be exactly 300x100 (asus logo) 300x90 (below) and 300x30 (Nvidia logo)
Note: Due to the nature of how the image is stored (In the freaking bootloader I might add -_-) these sizes need to be Correct, the bootsplash patcher should help you with this.
5. whirleye's (Give him thanks!) Boot Splash Patcher windows app. (Complete with shiny GUI) link
6. 3 pinches of ground unicorn horn, eye of newt, and hog's blood (extremely important ! ) Link
7. ???
8. Profit
*Make yourself a mental note of the disorganized location of these files as you scatter them throughout your documents/desktop/downloads folders.*
The Process:
1. Unzip the asus update, inside it is another zip, which you unzip. (Okay ASUS, you likes your zips) Inside there is a blob file, don't be alarmed, it will not attempt to absorb you into it's blobbiness, it stands for a Binary Large OBject file.
2. Put blobunpack into the same directory as the blob. (for easy cmd command)
3. MOD4+R (Windows key+R) to open run box, type 'cmd' This doesn't stand for central machine decimator.
4. Navigate to the directory with your blob, it was getting pretty lonely without you anyway. Ex: cd C:/users/username/downloads/blob
5. type blobunpack blob, your blob will now split itself into a multitude of blobs each with its own suffix. You now have to say Blob sr. and blob jr. when addressing them, it's only proper.
5a. You will (should) get:
blob.header (Oddly, I didn't actually get this, but we don't need it so don't worry about it.)
blob.app (huge file, the actual update system.img) [Don't Need]
blob.ebt (bootloader) [Need this blob]
blob.lnx (boot.img) [Don't Need]
blob.sos (recovery) [Avoid like the plague, unless you like losing cwm :3]
Note: The file extentions are 'false', they're just a way of separating the blob into manageable sections, they're all just blobs topped with a fancy-schmancy file extension.
6. Now that the blob has lost some extra poundage, it's time to patch it, Backup the blob.ebt and open the blob.ebt with whirleye's patcher!
7. Use your keyboard (This be old school) to load the images into the blob.ebt, shortcuts are at bottom and the tool is easy to use.
8. Save as patched_bl.bin, this should enable save as blob. (I had to do this for whatever reason, just don't question the gods)
At this point, you *Should* have a ready to patch bootloader with your new fancy image! If you like having a device that doesn't double as a very fancy paperweight, you'll keep going and check with a Hex editor.
9. Open your blob with the hex editor, the first line should be MSM-Radio-Update, followed by some 0s, then it should say EBT at the beginning. This marks which partitions are contained in the blob and will be flashed. Make sure none of the other (.SOS.LNX..etc) are in the blob, as then it would overwrite you. (shouldn't be there if you unpacked properly, and the filesize should be around 1.4KB)
9a. Search for whirleye's watermark, this shows the patcher worked, says "splash patcher by whirleyes"
9b. 9b is a terrorist and was deported by the TSA, move on to 9c. (bad hex joke)
9c. Open the backed up Asus blob.ebt you unblobbed, and compare the two files a tad, they should be nearly identical in length and code, except for the patched image section. If everything checks out you should be ready to flash your shiny new boot splash!
10. Now take your blob.ebt and De-knight it, stripping it of it's file extension. It is now just a 'blob' again.
11. Connect your tf and put it somewhere on your internal or external SD using adb or mass storage or whichever (I used /Removable/MicroSD/blob9000/blob)
12. --
gee one said:
to flash using the staging partition- you need either terminal or adb access.
the commands are:
su
dd if=/your/blob/here of=/dev/block/mmcblk0p4 # the last chars are zero pee four
reboot
Use adb or file manager or magic to save your blob somewhere on your transformer.
As it reboots, you should see a blue progress bar to indicate that it is flashing. It will reboot again and hopefully you will see your new splash screen.
Click to expand...
Click to collapse
13. ???
14. Profit!
Attached files:
Blobunpack.exe (zipped)
The Blob.ebt (zipped) finished product I made. For the US .24 update ONLY RAHHHHHH!!!!(Portal gun, aperture logo, mizore-kun. LD)
The blob.ebt.asus (zipped) original unblobbed .ebt part From the US .24 update (For all dem 'muricans)
Chuck Morris.png (A picture of a trollface, yes.) [Zipped]
Any questions? Let me know if this works out for you, worked wonderfully for me!
Link to my Q&A thread, may help with a little understanding, also has pic of my patched screen: link
If I helped, hit yo' self some thanks button. :3
Looks like you're fully explained how to do it and where to get the tools (which can often be harder than finding the how to info) but I've got to ask. Isn't that tons of work just to change something that shows for like a minute once a month whenever you reboot your tablet? I guess I don't understand why to do this but am trying to.
Sent from my PG41200 using Xparent Purple Tapatalk 2
Well, it's more of a, BAHAHAHAHAHAH I DID IT IN YO FACE! Sort of thing, and a neat challenge if you want to mod your tab a bit more. I did it more for the challenge of doing it than anything else. I also hated having everything EXCEPT splash completely customized. Just a proof of concept, and like a 30-40 min thing, not terrible. Let me know if you give it a shot
This is the complete open source evolution- ask some questions, do some research, flash something cool, and then write the guide. All you need now is the t-shirt. Congrats! We need more people willing to explore and ask questions.
sent while running with scissors
It's been a while since I made the discoveries.
Back then, I even made an android app to change the splash easily, but I never upload it to public.
Bump this thread if anyone interested.
I think I still have the source code buried deep inside my pc.
That'd be neat, the current method works but may be a tad confusing for some. I'll test out if you'd like
Has anyone done this successfully?
Flawless!
Works perfectly for me on:
TF101-A1 (16GB) B70
Android 4.0.4
Megatron ROM 1.1.6 (ricardopvz)
I don't think those last two matter, since this is a bootloader, but I thought I'd include it just in case.
I cannot express my thanks enough. If I had any skill, I'd create a CWM flashable template for this mod to make the flashing process a little easier.
I could do that, but that would encourage laziness, and noone would learn the Process behind it all. Which is the real whole point of this experiment :]
WHAT'S IN THE RAMDISK
So anyone who has compiled a kernel (for the X8) or is about to step into the world of developing android awesomeness through kernel building, should know that there are 2 (two) parts to the kernel:
The kernel image compiled from source code, and
The ramdisk
Both are equally important and are inter-dependent; without the kernel, the ramdisk is nothing (unless of course the devs come up with any other use) and without the ramdisk, the kernel is incomplete (again, this may change in the near future).
You (XDA-ians as I like to call you guys), especially those in the X8 sub-forums must have read viper001's kernel building guide. If you haven't, and do not want to read just 4 posts because of your laziness, it tells you how to compile your kernel image. Hah, now you are almost dying to read it. Well go ahead, read it.
Done reading. Well if you followed that guide to the letter (which I am sure many of you haven't), you'll have compiled your kernel with the FXP ramdisk. Now you want to build it from another source. It's pretty much the same process. However the FXP ramdisk won't work with this kernel. Not a chance (maybe a little). You need the ramdisk so you unpack the kernel using DooMLorD's tool (and forget to thank him; go thank him right now) and see a folder named kernel.sin-unpacked. You open it and see a bunch of files that you've never even heard of. You drop the kernel-building project.
This guide will hopefully eradicate that fear, or ignorance (maybe), and cover up what's in the ramdisk.
The parent (or root) directory of the ramdisk folder itself contains a bunch of files and folsers, which also contain more files.
Let's look at the contents in the root directory:
1 “modules” folder – This one is pretty easy. It contains the kernel specific modules that are loaded up at boot.
2 “res” folder – This folder contains another folder named “images” which contains images to be used in the recovery (more on that later).
3 “sbin” folder – Inside this folder are about 200 files (may vary), most of which are responsible for basic functioning of the phone.
4 default.prop – This file contains only a few lines of code that allow adb to run (line 4) and also makes the kernel insecure to give us permanent root.
5 init – This program initializes elements of the android OS and looks at the two following files:
6 init.rc – This file contains generic initialization code
7 init.<machine_name>.rc – This file contains device-specific initialization code.
8 initlogo.rle – This is the bootlogo (not the bootanimation which comes with the ROM).
9 pre_hw_config.sh – This file is executed at boot to get settings like cpu freq and governors just right.
10 recovery.fstab – This file specifies how the different partitions and file systems are to be mounted.
11 ueventd.rc – This file sets user or group (or root?) permissions on /dev nodes. (I got this line from the Internet and have no idea myself what the hell this means o_0).
12 ueventd.goldfish.rc – This file is empty in our kernels. Dunno why, though.
Now for the files in the /res/images directory:
1 icon_clockwork.png – This is the background seen in CWM.
2 icon_error.png and icon_firmware_error.png – These images are displayed on the screen when there is an error. Not sure though as I have never encountered any such error before in my life.
3 icon_firmware_install.png and icon_installing.png – These images are displayed when installing anything via CWM.
4 indeterminateX.png (where X is a number from 1 to 6, both inclusive) – This is basically the animation of the progress bar (the grey stripes moving forwards, or backwards, or both).
5 progress_empty.png – This is the progress bar during the initial stages of flashing anything in CWM.
6 progress_fill.png – This is the progress bar fill.
These are the files in the /modules folder:
1 sdio.ko – This is a file related to WiFi.
2 tiwlan_drv.ko – This is the tiwlan WiFi driver module.
3 tiap_drv.ko – This is the tiap WiFi driver module.
4 x8uv.ko – This is the undervolting module.
5 synaptics_i2c_rmi4_no_dt.ko – This disables dual touch in Synaptics.
6 synaptics_i2c_rmi4_dt.ko – This enables dual touch in Synaptics.
NOTE: I am not an expert.
More to come soon. See you and I hope sincerely that I do not get banned for this.
THE DREADED SBIN DIRECTORY
Going into the /sbin directory, we see a lot of files, the names of each sending shivers down your spine. But fear not, for sgt. meow will help you understand the functions of some important ones:
1. adbd – The file that allows you to use the adb shell. “adbd” stands for “Android Debugging Bridge Daemon”.
2. bootlogo – This file starts the kernel bootlogo (according to some user on the androidcentral forum; just saw a snippet on google search, opened the page and there was no thread).
3. bootrec – This file basically tells a kernel how to boot up a recovery
4. busybox – It lets you run LINUX / UNIX based commands (ls, gzip, uname etc.) that are required for root-level tasks.
5. dmesg – It is the Linux kernel's own logging system and is similar to logcat.
6. fix_permissions – This file applies and fixes permissions on the Android data folders.
7. insmod – This file is basically what is executed when you type insmod /..../../../../ xxx.ko (or similar) to load up the modules. An alternative way to do this is to write the line in hw_config.sh of /system folder (I guess) to load up modules at every boot. Or you could place the modules in the /modules directory of the kernel.
8. killrecovery.sh – This file, as the name suggests, kills the recovery when you exit it and boots into Android.
9. nandroid – The file responsible for nandroid backups.
10. nandroid-md5.sh – This file generates MD5 checksums for nandroid backups to verify its integrity.
11. reboot – This file reboots the phone when prompted to.
12. recovery – This is the recovery binary. For our devices, it is CWM recovery. This file can be changed easily (what I did with oxydo ICS) to other recoveries for this device for that version of Android.
Most of the other files are LINUX / UNIX based commands and some are files the functions of which cannot be explained by me.
More to come soon. Hope you enjoyed it so far.
FILES YOU CAN EASILY EDIT IN THE RAMDISK
There are some files in the ramdisk that can be edited pretty easily. There are also other files editing which means you gotta be RD or gotta have similar talent. Let's not go into that for now. The easy ones are:
1. initlogo.rle - The file that is easiest to edit. Basically you can convert any image to .rle format and replace it. make sure it is the right resolution.
2. /sbin/recovery - You can use recovery from another kernel (for the same Android version)and replace it in yours. You can also compile your own recovery binary by issuing the make recovery command after a successful CM build.
3./sbin/bootrec - You may have to change this when you change the recovery. Just a simple copy paste, that's all.
4. /sbin/rec_input - This file may need changing too when you change recovery.
5. /res/images/.. - Every .png file in this directory can be easily changed to any other .png file. Just make sure the resolutions are right, or else you will not be able to navigate properly in recovery.
6. init.rc - This file is easily changeable but you need to know what you are doing, otherwise you may mess up the boot sequence.
You can have a shot at changing other files, too. Lemme know how it goes.
CREDITS:
1. Allah Almighty (yes I'm a Muslim)
2. All XDA-ians, especially those in the X8 sub-forum for help (and for pressing thanks)
3. The Internet (Google, Wikipedia and Github mostly) for info
4. Me, for spending hours behind this guide.
5. My family, for not disturbing me while I was doing this. LOL
thank you
that is what i'm trying to understand :good:
This is for sure a valuable thread. Thanks for this!!
Sent With My Brains To Yours. Duh.
Nice thread , Captain Meow Meow
Sent from my X8 using xda app-developers app
sbin will take some time to cover but i will try my best.
sgt. meow said:
sbin will take some time to cover but i will try my best.
Click to expand...
Click to collapse
Its good to see that you are working hard...
Keep it up
great thread.thanks
sent from my x8™ using gingerzaraki®
THREAD UPDATED WITH SBIN CONTENTS. OMG. :wink:
Dude, you should make an *updated* Kernel Building Guide with new sources (i.e. alfs kernel or nAa kernel). Old one still uses FXP kernel source and outdated toolchain instead of Linaro.
RohinZaraki said:
Dude, you should make an *updated* Kernel Building Guide with new sources (i.e. alfs kernel or nAa kernel). Old one still uses FXP kernel source and outdated toolchain instead of Linaro.
Click to expand...
Click to collapse
And link to your sources as an example for others..
Banned? And why? This is usefull =))
Sent from my E15i using xda premium
@Rohin
yeah I might
@Elmir
that was a joke
@all
THREAD UPDATED WITH FILES THAT CAN BE EDITED AND CREDITS. :BIG GRIN:
MyMinds_Kernel_Swap
===================
Based on AnyKernel, but pretty much rebuilt in every way so that it will actually work. So, many thanks to Koush for the idea.
The Idea and What It Does...
=======================
Some but not all of this script has been snippets here and there from ArchiKitchen and DSIXDA Kitchen.
This has allowed me to formulate a zip as such without the need to technically build from scratch saving me LOADS OF HOURS.
It currently uses my static compiled mkbootimg, unmkbootimg, and mkbootfs binaries to allow editing, and rebuilding of the boot.img.
Some serious modifications were made to get this to work successfully with MUCH DEBUGGING. If you change something and it breaks another function then that is on you!
# IT IS CURRENTLY STABLE!
1. It will pull your current boot.img using dd.
2. It will search for the Android! header in the boot.img and remove the unnecessary junk before it if needed to.
3. It will split the boot.img in to the kernel and ramdisk.
4. It will unpack the contents inside the ramdisk.
5. It will modify the default.prop file giving you insecure ADB. If you already have it then this will not affect you.
6. It will modify the init.rc file to give support for init.d. If you already have it then this will not affect you.
7. It will write to sysinit and install-recovery.sh for the completion of init.d support. If already done, then this will not affect you.
8. It will make the init.d folder under /system/etc on your device with required permissions.
9. It will place an init.d script to test to see if init.d is fully working. If it works, you will find a file called, HAS_INIT, located in the /dev directory of your device.
10. It will swap out the original kernel with a new prebuilt kernel upon rebuilding the new boot.img
11. It will repack you a new ramdisk using mkbootfs to be applied to your new boot.img upon rebuilding it.
12. It will remove your old modules and push your new modules that came with your new prebuilt kernel.
13. It will write your new boot.img to your boot partition using dd.
14. Hopefully, more to come!
MAKE SURE YOU CHANGE...
=======================
"$BOOT_PARTITION" ACCORDING TO YOUR DEVICE BEFORE USING THIS SCRIPT!!!!!!
How to use it...
==============
1. Place your prebuilt kernel in the prebuilt folder and insure it is named, zImage.
2. Place kernel modules in the modules folder.
3. Zip, and flash in TWRP recovery.
If you have any suggestions then let me know. My ears are open to them.
https://github.com/ModdingMyMind/MyMinds_Kernel_Swap
Sent from my C525c using Tapatalk
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