[Tutorial] Changing the XOOM Splash Screen - Android

Being new to XDA, I originally posted this information in the General Discussion forum under Changing the XOOM Splash Screen". Having had time to dig around more and read, I think this information is better suited here in the "Chef" area.
I have searched the web and many forums regarding this issue and found many many discussions on how to use utilities to do this and that to the Motorola XOOM Splash Screen. Most of which involved cropping the image to 256x320. This seemed a bit odd on 2 levels. First, no one ever seems to what to explain the process or the whys and wherefores, and second with a 1280x800 screen, having such a small splash screen just seemed odd.
So starting with the utility in :
http://forum.xda-developers.com/showthread.php?t=1410040
and found I was randomly able to change my splash screen. I say randomly as it did not always seem to succeed, even though it appeared it had. As there was no feed back to indicate success or failure, one must presume it worked. So I did a bit of digging on how it worked and found that the image is an RGBA image with a depth of 8 for the XOOM. Additionally the image is simple stored on the partition pointed to by :
/dev/block/platform/sdhci-tegra.3/by-name/logo
This is simply a link to /dev/block/mmcblkXp4 (where the 'X' is 0 or 1 depending on if and when the external SD card was mounted). I therefore INSIST that the long path to the logo name be used to reference this partition as it will always point to the proper partition as mounted.
Another note -- sdhci-tegra.3 is the internal SD card while sdhci-tegra.2 is the external SD card.
Also, I found that the link above and the utility are only partly accurate. The utility requires you to crop an image to 256x320 before applying it the splash. This is actually not accurate. You can use an image up to 1280x800. The full size of the XOOM sxcreen. As long as you know the secret, and the BIN file isn't over 4M (4,194,304 bytes), which I am going to show you. For some reason I can find a lot of information on special tools to do this, but no one seems to want to just give away the format details. If you're like me, tools are nice, but you like to know what they are doing.
The best tool I found for converting an image to the RGBA format needed is ImageMagicK. If you used the utility I mentioned before, then you already have it installed. I think it's best because of the many features and simplicity. Plus the price is right. To modify the splash as I describe or use the tools I have attached below, you need to have ImageMagicK installed. With it you can do a convert of any image to the proper RGBA format by using the following command:
convert -size <W>x<H> -depth 8 <FILE> <RGBA>
Where <W> is the width of the image. Up to 1280.
<H> is the image height. Up to 800.
<FILE> is the image file (jpg, png, tiff, etc)
<RGBA> the name of the output rgba file, MUST have rgba as the file extension
This will create the RGBA file of the image needed to create the BIN file. This is where the utility in the other post fails out. The RGBA file must be converted to a "BIN" file. Which is basically nothing but the RGBA file with 20 extra bytes at the front. These bytes are:
ID - "SOL:"
xOffset - Offset from the left side of the screen (Being in landscape mode), up to 1280
yOffset - Offset from the top of the screen, up to 800
Width - Image width
Height - Image height
All values are in big endian format. Meaning that the value for 256 would be x'00000100' as opposed to the PC storage mode of little endian which would produce x'00010000'. I am including a windows program as an attachment that will make the BIN file. It is a command line program, and if you run it with no options, you get :
USAGE: MakeBIN.exe <input> <output> <width> <height>
Where -- <input> is the rgba file to be converted to bin
<output> is the name of the bin file to create
Note that for flashing to XOOM logo, the output BIN file
cannot be more than 4 meg in size.
If the width and height of the image are not specified to the MakeBIN utility, it defaults to 256x320. Additionally, the offsets are dynamically calculated to center image on the XOOM.
With this header in the front of the image, you are ready to "flash" the new splash screen. All you have to do for this is use ADB. First push the new file over to the XOOM using something like:
adb push mysplash.bin /data/local/.tmp
Once the file is there, you flash it. Again turning to ADB:
adb shell
This will put you at the command line on the XOOM. From there perform the following:
cd /data/local/tmp
dd if=mysplash.bin of=/dev/block/platform/sdhci-tegra.3/by-name/logo
exit
When you return to the command line, you are ready to go. Just reboot the XOOM your preferred way and enjoy your new splash screen. I like to do :
adb reboot
I hope this information has been helpful to others looking to make a bigger splash with the XOOM.
Oh. Two other things to keep in mind. The default background is black. So unless you're going full screen, you want to be sure you're using a black background. Or the second thing comes in handy - Transparency works. As the image is an RGBA format image, the attribute information for the pixel is supplied allowing transparency.
Now. I usually like to back up things before I do changes like this. If you do as well, simply perform the following prior to writing the above image out. This will create a 4M copy of the splash partition. Not all of the partition contains the existing image, but it doesn't hurt to have it all.
adb shell
cd /data/local/tmp
dd if=/dev/block/platform/sdhci-tegra.3/by-name/logo of=backup_splash.bin
exit
adb pull /data/local/tmp/backup_splash.bin
You can always reimage it to the partition by following the steps above.
I have attached a Apple image I used as a test. As it is 1280x800, the full screen was presented with my image. It's really an awesome site to see your full screen splash for the first time.
Further, I decided to make things easy. I developed a simple batch script for the Windows command like that will perform all the steps addressed above. It first verifies that the tools it needs are available, the creates the image and will flash it. Each sequence of steps it reported to the command window and you are prompted to perform each block. A "N" or empty response to the continuation questions causes the script to exit. So you could generate the BIN file without flashing it.
This is a very basic script. I could have developed a Windows application, and hidden all these steps so only I knew how to do it. Or even developed a XOOM app that would do it so you'd never know what I was doing. But I think the best way for others to learn about their systems is to know where things are and how they are used.
With that in mind, I have included the batch file in the zip.
Lastly, some information about partition sizes. I mentioned above that the partition size for the XOOM logo partition is 4M. That is to say it is 4,194,304 bytes in length. Why is this important? Because it will hold a full size 1280x800 image. When converted, a 1280x800 image using a depth of 8-bits is calculated as follows:
Size = Width x Height x 4
Why '4'? Because this is an RGBA file. The type says it all. As there is a depth of 8 bits, each color representation is 1 byte in length. 1 for Red, 1 for Green, 1 for Blue, and 1 for the attribute. That makes 4 bytes per pixel on the screen.
We then have to add the 20 byte header that tells the loader where to place the image and how big it is.
In total, the most a full screen splash will EVER be is : 4,096,020 bytes
This leaves 98,284 bytes as a buffer in case someone makes a boo boo.
Following the steps and using the tools I have documented in this thread, you will never make a boo boo and you will have lots of fun putting any image you like as your splash screen. (I'm using a photo of my family).
Thanks for taking the time to read my ramblings.

Thanks for the info! Nice work my friend.

Related

[SEP 18][V0.3] Stable Customized BT5 for HD2 - Links updated

Zen's Backtrack 5 For HD2 (and other) Android Smartphones
V0.3
----------------------------------------------------------
New app for loading this (and other) Linux Systems! - https://play.google.com/store/apps/details?id=com.linux.autoloader
Image and app support can be found here --> http://www.zenfulapps.com/
Packed - 640mb
Unpacked - 2.6gig (fits on 3.3 img now.)
--GRAB THE UPDATED SCRIPTS ATTACHED TO THIS POST, THEY ARE NOT PACKAGED INTO THE ZIP--
--Scripts are set to load from EXT4 partition, when i modify them for the .img's ill add them to the script pack--
--if you have .img mounting scripts from previous versions, they will work, as long as file names and directories match--
V0.3 Download
http://www.zenfulapps.com/Android/backtrack5-0.3.7z
(MD5 is still the same
MD5sum (of .7z file) - 9a4796f0ed96e03579c2b4a684d026f5
--------------------
Script pack contains
--------------------
btgo - mounts BT5, and askes how you would like to start, CLI or VNC
bts - stops BT5, and unmounts everything for it.
btl - used to login to bt5 after it has been mounted, to avoid all those "resource busy" messages
mkcore - directory installation and swap file creation
-------------
What you need
-------------
Rooted Android Smartphone
Linux on PC
Busybox installed on your device
SDcard adapter or reader, if neccesary
----------
Lets begin
----------
There are 3 different ways you can do this:
1. Fresh install on EXT4 Sdcard partition ( I HIGHLY recommend this method if possible, much better, a bit faster (no double loops to write to)
2. Create Fresh .img
3. Replace old BT5 system .img
=========================================
1. Fresh install on EXT4 Sdcard Partition
=========================================
This portion of the guide is to install BT5 on a FRESH EXT4 partition on your SDcard. Throughout this porcess, you will:
Backup your current sdcard (EVERY PARTITION, this is why we use PC-linux and not windows)
Fully erase and repartition your SDcard
Replace Android system and user data
Install BT5 on third partition
prepare system for chroot and VNC connection
----------------------------------------
Boot into your Linux operating system. **I DO NOT recommend using virtualbox or vmware, as drivers for usb and SDcard connections arent direct, things can go wrong.**
Shutdown your phone, and remove your SDcard. Do not use adb, or any other tools to do this.
insert your SDcard into your computer (adapter or reader yada yada) and mount every partition.
Make careful note of what is on which partition. safest way to back everything up is through the command line with the command
Code:
sudo cp -Rfvp /media/your-sdcard-partition/* /where/your/backup/folder/is
Do this for each partition, whether you have 1, 2, 3, or more.
In my case, my backup directory looks like this:
Code:
[[email protected] sdcard-backup]$ ls -l
total 12
drwxrwxr-x. 2 hookup-cellular hookup-cellular 4096 Sep 13 18:48 ext2
drwxrwxr-x. 2 hookup-cellular hookup-cellular 4096 Sep 13 18:48 ext4
drwxrwxr-x. 2 hookup-cellular hookup-cellular 4096 Sep 13 18:48 fat32
(ignore the empty directory sizes, my TRUE backup folder is MUCH more vulgar and i wont display it publicly, people may tear thier eyes out )
After everything is backed up, open your partition manager (in Gnome it is gparted, cant remember the name in others)
Navigate to your SDcard, and DELETE every partition. every one.
afterwards, recreate them using this strategy:
partition 1 - FAT32 size = total sdcard size minus ext2 and ext4 partition sizes
partition 2 - EXT2 size = 256mb, 512mb, 1gb, depending on how you like your apps2sd
partition 3 - EXT4 size = size you want for linux, minimum should be 4gb (mines at 10gb, i like my linux and got 3 different ones on it at the same time.)
When you are done, copy back your fat32 and ext2 stuff using the SAME COMMAND AS ABOVE (sudo cp -Rfvp from/here to/here)
Now, unzip/tar the .tar.gz package. I recommend extracting it to your pc before trying to put it on your sdcard.
Using the copy command above, put the extracted files onto your sdcard's EXT4 partition.
Double check the partition (navigate to it in nautilus or whatever filemanager your using) and ensure that it has the system copied over properly. You should see /boot /etc /root /sys so on and so forth, NOT just one folder with all of those inside of it.
Insert your SDcard, power on your phone, go to terminal emulator, and enter this:
Code:
su
cd /sdcard/scripts
sh mkcore
Swap file is damn near neccessary if your planning on using any GUI tools (armitage, zenmap)
Your directory structure is now in place, swap file created, and you start BT5 by typing (from /sdcard/scripts OR /data/linux):
Code:
sh btgo
=================================
2. Fresh Image Creation
=================================
for this, we use the dd command and mkfs.ext4 command.
Code:
dd if=/dev/zero of=/path/to/where/you/want/the/img bs=1M count=3300
Change this command as needed, running it as is wont do anything good. Change the of= to where you want your img to be located.
next is mkfs.ext4
Code:
mkfs.ext4 /path/to/where/you/want/your/img
select yes when it cautions about "not a block device"
When this is finished, mount it using these commands:
Code:
su
-your password-
mkdir -p /mnt/bt5img
mount -t ext4 /path/to/your/img /mnt/bt5img
now, extract the BT5 package to a place on your Computer. When finished, run this command:
Code:
sudo cp -Rfvp /path/to/bt5/core/* /mnt/bt5img/
changing parameters accordingly.
After this, copy the .img to /sdcard/bt5 and run the start scripts from your terminal emulator.
================================
3. Replace Existing Image
================================
Mount your bt5 image, erase what is inside of it, and copy in the new system:
Code:
su
-your password-
mkdir -p /mnt/bt5img
mount -t (your ext type) -o loop /path/to/your/bt5/img /mnt/bt5img
rm -Rfv /mnt/bt5img/*
cp -Rfvp path/to/bt5/core/* /mnt/bt5img/
unmount your .img, place it on your sdcard, and your all set.
==============================
Changes in v0.3
==============================
- Trimmed alot of fat, fits inside of 3.3 image now, though space is SEVERLY limited (removed CUPS and sound stuff, who needs to print from within thier phone anyways?)
- various small changes for performace improvements.
- a few new tools installed, but not tested
- restored my personal version that i nuked. It works now.
NEW STUFF TO COME, STAY TUNED!!!
First off, My apologies for starting a second thread on this, I've made ALOT of changes and i feel the first thread is dead and useless. (Reprimand me if needed
-pics coming once I find my camera could be a small while-
---------------------------------------
Backtrack5 for HD2 - v0.2
Customized by z3n
My goal: the perfect stealth
tool in your pocket
just one tap away
---------------------------------------
========================
Codename
Squeaky Wheel
========================
Updated, check second post for changelog
========================
DOWNLOAD
========================
Please use the scripts attached at the bottom of this post instead of the packaged ones, and i havent had a change to update the full image zip with it (uploads take a while )
V 0.2
Part 1 - http://www.megaupload.com/?d=D0MQVAS4
Part 2 - http://www.megaupload.com/?d=M2MRYLAH
MD5 - 06225e18cdbfee6f88daf7e9ee3a1163
SHA1 - eeba19e53565a1643703cf8938be2f8cfc12db9a
V 0.1
Part 1 - http://www.megaupload.com/?d=83B22Y00
Part 2 - http://www.megaupload.com/?d=SB98AA19
mirror - (NOT interchangeable)
Part 1 - http://www.megaupload.com/?d=HU320Z81
Part 2 - http://www.megaupload.com/?d=QN9C560Z
Checksums of bt5.img
MD5 = 863e6db99e5207a81ad0df7d13998235
SHA1 = c84d8f27df8b9b51059e5a6b09e65853f11de970
7zip required to extract.
Just over 1gb packed, unpacked is 4.9gb.
========================
INFO
========================
This is my first release of a customized, working, mostly stable BT5.
Many things have been added, taken out, and configured to be used within the Android system. For a full list, please see the bottom of this post.
Mounting is different than most other linux .img installations, allowing for a full (and expandable) image.
V 0.2 Now has a swap file created when you run the mkdirectory script. This swap file is necessary, as with all my tests, When you run VNC with most of the major tools, there's a high chance of the phone running out of memory (im running no extra apps, completely stock Hyperdroid)
(if you have a swapfile already, you can say no to creating another, just make sure that the file is located at /data/bt and named btswap.)
**This image is in ext4, make sure your kernel supports it!**
**Everything tested on Hyperdroid-CM7 by pongster**
==============
INSTALLATION
==============
You need:
-Full Nandroid Backup in case something goes batty
-16gb HD2
-ext4 support on your ROM/kernel (lost my ext2 image due to my own stupidity, will create another matching one later)
-Linux on PC (to create the ext4 partition)
-Busybox (from market)
-VNC Viewer (from market) (optional)
FAT32/EXT4 Split card
---------------------
1.
Back up your HD2 and SDCard to safe places (off of the phone and sdcard)
2.
Boot your linux installation and open partition manager. erase all the partitions on yor SDcard. Then create them in this order.
1. FAT32 - size of this is total sdcard size minus 6.5g (for bt image) minus 100mb for aps2sd
2. ext2 - 100mb
3. ext4 - 6.5 gb
3.
Copy the bt5.img to the root of your third partition.
copy the bts folder to the root of your FAT32 partition.
4.
if this is your first time using this script/image, run the mkdirectory script first with
Code:
su
sh /pathtoscripts/mkdirectory
Load up your android terminal and type
Code:
su
cd /path/to/scripts
sh go
5.
Now it asks you if you want to log in to the console or start vnc automatically. (check log for port, usually 5901 or 5902)
DEFAULT VNC PASSWORD IS: toortoor
DEDICATED SDCARD
----------------
Same as everything above, minus the FAT32 partition.
"sh ded"
starts for dedicated SDcard instead of
"sh go"
Proper Shutdown Procedure
=====================
Stop script has been modified to shutdown backtrack and all of the (usual) programs that stop things from unmounting properly.
Exit any VNC connection you currently have.
1. Run sh stop (from your scripts location)
2. Reboot phone as a precaution.
One thing i did personally to make this easier was load the scripts onto /data/bt, so switching SDcards or locations doesnt matter.
(I also changed the terminal start directory to my scripts folder easy quick access)
=======================
Main Features I've gotten to work
=========================
-Clean mount/umount, as long as VNC and MySQL are killed BEFORE exiting the chroot - stop script kills these now
-Apps no longer disappear for good with sdcard removed, only disappear until SDcard is reinserted (apps2SD/loop device problem, any ideas?)
-MySQL for metasploit
-Metasploit working
-Armitage working, missing some "Attack" options (looking into it)
-Zenmap installed
-OpenVPN installed
-Traffic analysis possible with tcpdump (local only)
-Enables possibility for FakeAP attacks
-macchanger works (kinda, phone needs a reboot for original MAC to return)
-Armitage Launcher placed on Desktop (takes a while to load, be patient)
-Terminal Launchers in various places (updating may randomly remove your terminal, synaptic placed on desktop as standby to redownload terminals
-guake installed (drop down Terminal, makes commands easier to see while working) (not configured to a key yet)
This probably works with other Android phones too. If you change the scripts, and as long as it has a external SDcard you can partition.
if your using a different phone, this is untested unless specified otherwise.
-boot and shutdown scripts run clean as long as VNC and MySQL are shut off(in almost all cases)
@ XDA
http://forum.xda-developers.com/show....php?t=1152994
PASSWORDS
------------
MySQL - user: root pass: toor
VNC - User: root pass:toortoor
sys pass - user:root pass:toor
(I know, standard ones, but this should answer a few questions)
===============================
Thanks
===============================
anantshri - for the original scripts and BT5 img for android
BT dev team - (of course )
and all of you
===============================
Information, bugs, and oddities
===============================
One important thing, While performing heavy operations, its normal for your screen to not turn on for a while if it turns off. Dont panic, just give it some time to finish whatever you were running and your phone will be back to normal again. DO NOT PULL THE BATTERY UNLESS ABSOLUTELY NECESSARY.
To avoid this, get wakelock (known to cause problems) or set your screen timeout to some large number.
Swap file will help with alot of this.
These are the features I've tested out so far.
No major changes to anything, (except new packages) just configuring everything i see.
If you find anything you want added in or that is acting odd, please let me know. Same goes for if you fix something!!
Overall
-------
-Repo's activated, most things work (upstart processes fail, for now)
-startvnc and stopvnc no longer give that pesky USER error
-startvnc starts mysql database for metasploit
-stopvnc stops mysql (mostly, invoke ps -A and look for mysqld. Kill it with fire(-9) if need be)
-network traffic is capture-able with tcpdump, with wifi hotspot activated
-working on adding in a swap partition on sdcard (if possible)
-openoffice installed
-openVPN installed (the quieter you become...)
-Removed Zoho Web services
MySQL
-----
default user - root
default pass - toor
-Starts automatically with startvnc
-stops automatically with stopvnc
-start manually by invoking "mysqld"
-Only runs as root (for now)
-Console hangs when it is manually loaded or shutdown, service continues running though. killall --signal 9 mysqld if needed.
Metasploit
----------
-Loads up alright (45-90 seconds)
-MySQL already set as default DB
-Must manually connect to MySQL DB each instance of metasploit by invoking (from msf) db_connect root:[email protected]
-working on a possible way to limit cpu consumption to prevent system hangs(cpulimit does some nasty things)
-So far, this is the only connection string ive been able to get to work: root:[email protected]
Armitage
--------
-Takes forever to load (30 seconds for connect screen, 4 minutes or so for main client)
-Causes system hangs frequently (to minimize this, leave the vnc server on your screen, and set the display timeout to 10 minutes-switch it back when done to conserve battery life)
-So far, this is the only connection string ive been able to get to work: root:[email protected]
-Can Crash phone if running too big of an operation (Max Phone memory problem, fixed in v.2 with swapfile added)
Zenmap
------
-Slows phone down (incredibly bad with more complex scans, of course)
-Some Complex scanning options can crash phone (Nothing damaging has happened)
-will attempt to throttle cpu usage in the future
-Can Crash phone if running too big of an operation (Max Phone memory problem, fixed in v.2 with swapfile added)
Aircrack-ng suite
-----------------
-Aircrack-ng works
-Airodump-ng doesnt work (needs monitor)
-Airdecap-ng untested
-Airdecloak-ng untested
-Airbase-ng doesnt work (needs monitor)
-Airmon-ng doesnt work (needs monitor)
-Aireplay-ng doesnt work (needs monitor)
-Airdriver-ng doesnt work (yet)
-Airolib-ng works (doesnt do anything yet)
-Airserv-ng doesnt work (needs monitor)
-Airtun-ng doesnt work(needs monitor)
Plus lots of stuff for the future, stay tuned!!
http://forum.xda-developers.com/show....php?t=1152994
In the future
=========
-nessus
-Booting via HD2 Toolbox by d4n14l (sp?)
-Custom kernel (WAYYYY down the road, but working on it)
and more
--Copyrighted by z3n, 2011
(just kidding, but it looks good )
Looks good will give it a go.
Thanks for sahring
I we could get our wifi card into monitor mode --> awesome!!!!
Thanks to z3nful & everyone made this possible!
Enjoy everyone
The next release is going to be faster, stabler, and more useful
I'm also working on a round-about way for packet injection and monitor mode
Stay tuned
Sent from my Hyperdroid Pocket Laptop
cool.. good job man..
Are you trying to patch the wifi drivers ? =D
Holy crap.....this is a dream in the making Bring on monitor mode and packet injection
I've done some researches.. and found out that many devs have tried making the driver to work on the Monitor mode.. but they failed to do that.
It looks to me that Backtrack on HD2 is kinda useless.
Not useless, just last night I ganked my roommates computer with my phone
As far as monitor mode and injection go, sadly, they may be right that its not possible, but I got some ideas that may make it work, I just need to hammer out some kinks in BT first
And who needs monitor when you can fakeAP?
"Make them hand you the keys and you don't have to break their Window(s)™"
Sent from my Hyperdroid Pocket Laptop
A m a z i n g
Next release is going to be even better this 5gig image is almost full, so I'm going to expand it to 6gig, along with instructions on how to expand your own image if that's to large or want even more space.
Btw, Wine should be good to go in the next one
stay tuned!!
Sent from my HD2 "Pocket Laptop"
I would love to see some Sceenshots (or better: a video) here!
Lol will do, gotta go find my 10 year old Polaroid I've been using this phone or all my pics and videos, so this could be tricky
Sent from my HD2 "Pocket Laptop"
good to see development beyond just starting up the image... I would be taking some pointers from here for my device too....
hope you don't mind that....
Not at all, I've been trying to track down your name again so it can add you to the credits part, as the basis of the scripts was yours lol, I just changed the loops and mounting structures around a bit, and added some stability checks.
The scripts for this image are slightly out of date but I got new ones going up once I have time they should fix a few of the small eerrors people get while mounting
My next version is a little ways out (works gotten crazy busy lately) but it'll be out eventually
Sent from my HD2 Pocket Laptop
Not Booting!
Hi Thank you for sharings this up!!! this is like a dream for alot of people.
i have followed all your steps but i have a problem when i run the scripts, the folders dont get created because when i run go i get a bounch of folder not found.
my SD card had some differences is a 16GB
with
Fat32
Ext-sd/ EXT2 -->1GB
EXT3 --> 100MB
EXT4 --> 6.5GB
could this setup causing the script to look on the wrong partitions? i have alot of time with out playing with Shell scripting but i would like to know if that is the place i should start looking for a fix
-edit- just double checked (forgot scripts were on my phone... its been a long week lol) and you should just need to change the mount -t ext4 /dev/block/vold/179:3 to /dev/block/vold/179:4
Also, did you run the new mkdirectory script? If you have the one packaged with the image its out of date. The attachment on the fist post has the updated ones
Ignore all mmcblk's
For another "buffer" partition, you need t point the sdcard parts (mmcblk0p* and vold/179:*) to what yours are in /dev/block. In your case I think you just need to change any vold/179:3 to 179:4. If you go to /dev/block/vold it will have folders from each partition (they are numbered 0 and up, but 1 would be your fat32, 2 is ext2 so on and so forth)
When I'm near my computer ill figure out the full ones for you
Sent from my HD2 Pocket Laptop
can I get it for Htc desire..??
It should work, as long as you have a big enough sdcard, your phomes kernel suppers ext4, and you might have to change a few small variables
Sent from my HD2 Pocket Laptop

Get boot.img From Stock Samsung FW?

I'm working on my first ROM that is based on the "stock" Samsung firmware. I am used to messing around with AOSP and CM ROMs where there's a nice flashable ZIP with a boot.img in it. Working from the "stock" Samsung image has been less clean.
My device is a Samsung SGH-T869 (the T-Mobile version of the Galaxy Tab 7.0 Plus).
I began with the file T869TMBLG7_T869UVLG7_T869UVLG7_HOME.tar.md5, which is the newest firmware available for this device.
I am able to extract the image using 7-zip, which gives me the error "There is no correct record at the end of archive", but otherwise appears to extract perfectly.
Extracted files include:
-boot.bin
-cache.img
-factoryfs.img
-hidden.img
-modem.bin
-param.lfs
-recovery.img
-Sbl.bin
-zImage
These files are enough to give Android Kitchen something to start with, but AK is complaining about the lack of a boot.img, plus I want to do some ramdisk tweaking. I have been researching this for hours, and I get the impression that what I need is in there, just in a proprietary format. I have installed KernelKitchen, which I guess I can use to build boot.img from zImage and a ramdisk, I'm just not sure where to go from here.
I also tried dumping ADB (dd if=/dev/block/mmcblk0pX of=/sdcard/boot.img, tried all partitions one by one).
I also looked at a backup made via CWM 6 of the 'stock' untouched ROM running on my tab. My backup contains:
-boot.img
-cache.ext4.dup
-data.ext4.dup
-nandroid.md5
-recovery.img
-system.ext4.dup
So far, no success. The various imgs I have pulled are all treated as invalid by Android Kitchen and also split_bootimg.pl by William Enck. When running that nice Perl script I get the error "Android Magic not found".
My general first goal is a cleaned up stock ROM which has been deodexed, zipaligned, with insecure boot enabled, and of course, root.I would like to also do a sweet custom boot image and boot animation, but I believe its best to start with a solid foundation before jumping into the other stuff. Any suggestions, XDA gang? Somewhere in that mix did I get the actual boot.img but Samsung uses a weird header? Or something else?
Rename file.tar.md5 to file.tar and unzip
Find an updater-script of custom based stock rom and you get "name' of kernel partition
Sent from my X10i using xda app-developers app
xSkArx said:
Rename file.tar.md5 to file.tar and unzip
Find an updater-script of custom based stock rom and you get "name' of kernel partition
Sent from my X10i using xda app-developers app
Click to expand...
Click to collapse
Your first instruction (to "rename and unzip") makes no difference at all.
The second suggestion seems like it may be useful.
From the CM9 flash script I found that /dev/block/mmcblk0p5 is the boot partition.
I am not sure what's wrong with the boot.img I am pulling.
Here's my command session:
Code:
adb shell
su
dd if=dev/block/mmcblk0p5 of=/mnt/sdcard/boot.img
exit
adb pull /mnt/sdcard/boot.img
I attached the resulting file. I looked at it a bit in a hex editor but I'm not sure what I'm lookin for...
DivinityCycle said:
Your first instruction (to "rename and unzip") makes no difference at all.
The second suggestion seems like it may be useful.
From the CM9 flash script I found that /dev/block/mmcblk0p5 is the boot partition.
I am not sure what's wrong with the boot.img I am pulling.
Here's my command session:
Code:
adb shell
su
dd if=dev/block/mmcblk0p5 of=/mnt/sdcard/boot.img
exit
adb pull /mnt/sdcard/boot.img
I attached the resulting file. I looked at it a bit in a hex editor but I'm not sure what I'm lookin for...
Click to expand...
Click to collapse
It seems that you managed to extract a kernel image (zImage). What you are looking for is an image starting with the signature "ANDROID!".
What do you see if you enter the following command?
Code:
$ cat /proc/mtd
It should read something similar to:
Code:
dev: size erasesize name
mtd0: xxxxxxxx xxxxxxxx "system"
...
DivinityCycle said:
Your first instruction (to "rename and unzip") makes no difference at all.
The second suggestion seems like it may be useful.
From the CM9 flash script I found that /dev/block/mmcblk0p5 is the boot partition.
I am not sure what's wrong with the boot.img I am pulling.
Here's my command session:
Code:
adb shell
su
dd if=dev/block/mmcblk0p5 of=/mnt/sdcard/boot.img
exit
adb pull /mnt/sdcard/boot.img
I attached the resulting file. I looked at it a bit in a hex editor but I'm not sure what I'm lookin for...
Click to expand...
Click to collapse
My first instruction is to get boot.bin without error when unzip it.
With the boot.img that you attached try this http://forum.xda-developers.com/showthread.php?t=1849666
Sent from my X10i using xda app-developers app
You are probably going to have to trim some extra data off the front of your boot.img so that the tool finds the needed Hex address. If you haven't already I'd pull the applicable scripts out of dsixda's kitchen and see how he handles it.
k02a said:
It seems that you managed to extract a kernel image (zImage). What you are looking for is an image starting with the signature "ANDROID!".
What do you see if you enter the following command?
Code:
$ cat /proc/mtd
It should read something similar to:
Code:
dev: size erasesize name
mtd0: xxxxxxxx xxxxxxxx "system"
...
Click to expand...
Click to collapse
I'm pretty sure you're after the partitions. However, there's no /proc/mtd on the SGH-T869 running stock.
Code:
[email protected]:/proc # cat partitions
cat partitions
major minor #blocks name
179 0 15388672 mmcblk0
179 1 20480 mmcblk0p1
179 2 1280 mmcblk0p2
179 3 1280 mmcblk0p3
179 4 8192 mmcblk0p4
179 5 8192 mmcblk0p5
179 6 8192 mmcblk0p6
179 7 204800 mmcblk0p7
259 0 16384 mmcblk0p8
259 1 786432 mmcblk0p9
259 2 13791232 mmcblk0p10
259 3 524288 mmcblk0p11
259 4 8192 mmcblk0p12
179 8 30318592 mmcblk1
179 9 30317568 mmcblk1p1
When looking at /proc/mounts, I see that partitions 1, 4, 7, 9, and 10 are all mounted. I'm also relatively certain that mmcblk1 is the microSD card slot, based on its size (I've got a 32GB card installed at the moment).
So, ruling those out, we're left with:
Code:
major minor #blocks name
179 2 1280 mmcblk0p2
179 3 1280 mmcblk0p3
179 5 8192 mmcblk0p5
179 6 8192 mmcblk0p6
259 0 16384 mmcblk0p8
259 3 524288 mmcblk0p11
259 4 8192 mmcblk0p12
I have already extracted the first 8 partitions and tried running each through Android Kitchen's boot.img unpack tool without success. The script fails to locate the ANDROID header within any of the files. I'm guessing Samsung uses some sort of custom header, because if it works perfectly fine, why not mess with it?
I've searched through a few of the files with XVI32 for "ANDROID" but didn't get any hits.
As posted earlier, other ROMs flash boot.img to mmcblk0p5 so I'm pretty sure that's the right space.
Any hints on an application I can use to analyze the dump and locate the offsets where the header and ramdisk are inside it?
Update. In my research I have come across this article:
http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images
It wasn't directly helpful but it did give me a key idea: "Find the Magic Number for a GZ archive and you'll find the ramdisk inside the raw image"
As per http://www.garykessler.net/library/file_sigs.html, the "Magic Number" for a GZ archive is 1F 8B 08. The first article only mentions "look for a bunch of zeros and then 1F 8B." That never occurs in my dumped file, and the number 1F 8B occurs 65 times. However, "1F 8B 08" only occurs once in the entire file, indicating the spot where the header and kernel end and the ramdisk begins.
I deleted everything before 1F 8B 08 and saved the result as ramdisk.gz.
Then, I threw the resulting file onto one of my Linux boxes and used the following commands to extract:
Code:
mkdir ramdisk
cd ramdisk
gunzip < ../ramdisk.gz | cpio -i --make-directories
ls
(results of ls command here:)
data init.goldfish.rc lpm.rc ueventd.goldfish.rc
default.prop init.rc proc ueventd.rc
dev init.smdk4210.rc sbin ueventd.smdk4210.rc
fota.rc init.smdk4210.usb.rc sys vendor
init lib system
I did this stuff in a command terminal connected over Putty, and I got a ton of crazy output during extraction, mostly the line "cpio: Malformed number" over and over.
My next planned task is to take 3 boot.img dumps from my tablet and them compare MD5s on all 3 dumps, to ensure I got a "good" copy.
I imagine this is largely unnecessary, but I've learned from working on other embedded devices that you can't be too careful about raw reads / writes.
I'm pretty sure now that I have extracted the ramdisk I am OK. The factory firmware has zImage as a discrete file, so I'm pretty sure I can use either Android Kitchen or Kernel Kitchen to repack the stuff into a "normal" boot.img.
I'll post my results here, since there may be like one other person interested in doing ROMs for the T869
Just a little update, the md5sums on ALL of my various dumps matched.
By that I mean CWM's backup and all the various dumps I did via ADB (using the dd command) all match.
md5sum for this firmware's boot.img appears to be 1e4367954524901c7dfff14b02023163
Interesting and a great research!
I look forward to see more of your progressive work.
Sent from my Xperia Arc via Tapatalk 2
---------- Post added 11th October 2012 at 12:00 AM ---------- Previous post was 10th October 2012 at 11:39 PM ----------
DivinityCycle said:
As per http://www.garykessler.net/library/file_sigs.html, the "Magic Number" for a GZ archive is 1F 8B 08. The first article only mentions "look for a bunch of zeros and then 1F 8B." That never occurs in my dumped file, and the number 1F 8B occurs 65 times. However, "1F 8B 08" only occurs once in the entire file, indicating the spot where the header and kernel end and the ramdisk begins.
I deleted everything before 1F 8B 08 and saved the result as ramdisk.gz.
Then, I threw the resulting file onto one of my Linux boxes and used the following commands to extract:
Click to expand...
Click to collapse
According to RFC1952, the gzip header only contains two bytes (ID1, ID2), while the third byte (CM) normally seems to be set to 0x08 (deflate) - so you did the right thing to include the third byte.
http://tools.ietf.org/html/rfc1952
Sent from my Xperia Arc via Tapatalk 2
k02a said:
Interesting and a great research!
I look forward to see more of your progressive work.
Sent from my Xperia Arc via Tapatalk 2
Hell yeah, I'm surprised at how much I've achieved, since today has been pretty busy at work. I use Putty, WinSCP, and SplashTop to access my home machines from the office, and I've got an ADB command line connection to my tab on my workstation here, so I've been able to get a lot done.
My current task is reverse-engineering dsixda's scripts that do the task of taking apart the boot.img. I should have looked at them before, they're well-written and self-documented. It's looking like I'll have to figure out the weird offsets Samsung is using (already half done) and then I can tweak the scripts so they'll probably be able to unpack / repack the image.
If I'm building a stock ROM do the offsets and header have to all be the same on my modified boot.img? I would assume so, but I'm new to this
I only want to modify the ramdisk a bit, no kernel tweaks.
Click to expand...
Click to collapse
After much searching, it looks Samsung's boot.imgs sometimes simply have no header at all, so like the first chunk is the kernel, and the second is the ramdisk. I'm gonna test out unpacking ramdisk, making the changes I need, repacking it, and then combining the two chunks back together for flashing.
Will post results
DivinityCycle said:
After much searching, it looks Samsung's boot.imgs sometimes simply have no header at all, so like the first chunk is the kernel, and the second is the ramdisk. I'm gonna test out unpacking ramdisk, making the changes I need, repacking it, and then combining the two chunks back together for flashing.
Will post results
Click to expand...
Click to collapse
I took a new look at your boot.img today.
Besides the gzip header at address 0000:4634 (which you found), I also noticed that there are 256 (0x100) bytes at 007f:fc00.
Any clue about this?
DivinityCycle said:
I'm working on my first ROM that is based on the "stock" Samsung firmware. I am used to messing around with AOSP and CM ROMs where there's a nice flashable ZIP with a boot.img in it. Working from the "stock" Samsung image has been less clean.
My device is a Samsung SGH-T869 (the T-Mobile version of the Galaxy Tab 7.0 Plus).
I began with the file T869TMBLG7_T869UVLG7_T869UVLG7_HOME.tar.md5, which is the newest firmware available for this device.
I am able to extract the image using 7-zip, which gives me the error "There is no correct record at the end of archive", but otherwise appears to extract perfectly.
Extracted files include:
-boot.bin
-cache.img
-factoryfs.img
-hidden.img
-modem.bin
-param.lfs
-recovery.img
-Sbl.bin
-zImage
These files are enough to give Android Kitchen something to start with, but AK is complaining about the lack of a boot.img, plus I want to do some ramdisk tweaking. I have been researching this for hours, and I get the impression that what I need is in there, just in a proprietary format. I have installed KernelKitchen, which I guess I can use to build boot.img from zImage and a ramdisk, I'm just not sure where to go from here.
I also tried dumping ADB (dd if=/dev/block/mmcblk0pX of=/sdcard/boot.img, tried all partitions one by one).
I also looked at a backup made via CWM 6 of the 'stock' untouched ROM running on my tab. My backup contains:
-boot.img
-cache.ext4.dup
-data.ext4.dup
-nandroid.md5
-recovery.img
-system.ext4.dup
So far, no success. The various imgs I have pulled are all treated as invalid by Android Kitchen and also split_bootimg.pl by William Enck. When running that nice Perl script I get the error "Android Magic not found".
My general first goal is a cleaned up stock ROM which has been deodexed, zipaligned, with insecure boot enabled, and of course, root.I would like to also do a sweet custom boot image and boot animation, but I believe its best to start with a solid foundation before jumping into the other stuff. Any suggestions, XDA gang? Somewhere in that mix did I get the actual boot.img but Samsung uses a weird header? Or something else?
Click to expand...
Click to collapse
Feel free to use my updater-script in the scorched kernel thread. The updater works for ics boot images. just remove the parts about copying lib files and setting permissions ... and remove the lib files from the zip. they are specific to the kernel. a stock kernel will break if those lib files are copied to /system/lib/modules.
Oh, and you can get the boot image easily in CWM by doing a backup of the stock rom and grabbing it from the clockworkmod folder on the sdcard.
merwin said:
Feel free to use my updater-script in the scorched kernel thread. The updater works for ics boot images. just remove the parts about copying lib files and setting permissions ... and remove the lib files from the zip. they are specific to the kernel. a stock kernel will break if those lib files are copied to /system/lib/modules.
Oh, and you can get the boot image easily in CWM by doing a backup of the stock rom and grabbing it from the clockworkmod folder on the sdcard.
Click to expand...
Click to collapse
As posted earlier in this thread, I pulled a boot.img from a CWM backup, but that was back before I knew how to do anything useful with it yet.
The md5sum of the CWM-generated backup boot.img matches the dumps I did over ADB using the dd command, so they're different ways to get the same end result. I have a pretty good understanding of the syntax used in the CWM flashable ZIPs. My rough plan was to first build a "restore to stock boot.img" flashable zip (so I can fix it if I make my tab unbootable ), then experiment with building my own boot.img and flashing it using the same methods. The only thing that'll be different about the "flash modded boot.img" and "flash stock boot.img" is the actual boot.img file included in the zip. Didn't get a chance to do it while off work last night, but should be able to knock it out today.
k02a said:
I took a new look at your boot.img today.
Besides the gzip header at address 0000:4634 (which you found), I also noticed that there are 256 (0x100) bytes at 007f:fc00.
Any clue about this?
Click to expand...
Click to collapse
Your guess is probably better than mine, honestly. I would think that second address is actually within the 'ramdisk' part of things, so that seems pretty odd. I'm a relative noob when it comes to hex stuff, as that's a couple levels down from where I usually operate with computers
If I unpack, modify, and repack the ramdisk, any suggestions on the 'best' way to reattach the header/kernel to it?
k02a said:
I took a new look at your boot.img today.
Besides the gzip header at address 0000:4634 (which you found), I also noticed that there are 256 (0x100) bytes at 007f:fc00.
Any clue about this?
Click to expand...
Click to collapse
Following up on this earlier point, it looks like there are a few more regions within the 8 MB file than I initially saw.
I use XVI32, so the addresses I found are formatting as such.
it seems like the following is the layout of the file contents:
Part 1 - $000000 to $004633 = 17.5 KB header?
Part 2 - $004634 to $4768A6 = 4.44 MB ramdisk (?)
Part 3 - $4768A7 to $7FFBFF = 3.53 MB of zero padding
Part 4 - $7FFC00 to $7FFCFF = 241 bytes footer
Part 5 - $7FFD00 to $7FFFFF = 768 bytes of zero padding
My initial attempt to unpack / repack the image of course made the device unbootable. My "restore" flashable zip worked as expected, so I'm now able to mess around with this stuff with relative ease.
I'm still getting a bunch of weird crap in my terminal when extracting the ramdisk. The command I am running is gunzip -c ../ramdisk.gz | cpio -i run within the directory where I want the files to extract. Both under Cygwin in Windows and under Ubuntu Server, I get tons of "cpio: Malformed number" followed by garbage. Under Ubuntu Server, despite this weird output, the files actually DO appear to extract and I get 1.65 MB of unpacked files, all in the expected format and directory structure.
Under Cygwin it didn't extract at all.
I'll continue to mess around but for your hacky fun, I have attached the parts all split up and then packed into a single ZIP.
Post if you have any ideas. I'm gonna try and repack the ramdisk and then re-assemble the whole thing. The repacked ramdisk will be smaller, but I'll just fill in the empty spot with zero padding so that the footer still ends up at the same address. We'll see if that works
Quite interesting result so far...
I wonder if there are some documentation on the data structure of the footer information floating around in public, and secondly if the offset is static.
Speaking of padding zeros. Maybe the number of trailing zeroes depends on the payload size and the page size (evenly divided by given page size), which is the case for e. g. boot.img?
Sent from my Xperia Arc via Tapatalk 2
k02a said:
Quite interesting result so far...
I wonder if there are some documentation on the data structure of the footer information floating around in public, and secondly if the offset is static.
Speaking of padding zeros. Maybe the number of trailing zeroes depends on the payload size and the page size (evenly divided by given page size), which is the case for e. g. boot.img?
Sent from my Xperia Arc via Tapatalk 2
Click to expand...
Click to collapse
It will take some experimentation to see how picky the boot loader is. I have been sidetracked today by actual work (imagine that!) and also I have been working on exhaustively cataloging and documenting the contents of the stock ROM, particularly /system/app. Cutting the Samsung bloat has been challenging only in that there's so much stuff to remove
I just had a brainstorm: I'm going to examine the boot.img from the CM9 and CM10 ROMs for the T869. After all, both of them are accepted by the bootloader, so those two and the "stock" boot.img must share some common properties, which one would think would be the "key" stuff to make the boot.img work.
The boot.imgs from CM9 and CM10 both lack any useful "handles" to try and understand their contents.
I'm uncertain how else to proceed.
I have tried creating a modified ramdisk archive, then padding out the rest of the space with zeros so that the various pieces of boot.img fall at the same location, but no success.
I'm beginning to think everything about the Samsung boot.img is weird. I was able to locate the boot logo, but its located in the ramdisk at /sbin/fota.png.
I've been knocking away on this for like a week now, and I'm beginning to think maybe it ain't worth it. All this so I can get insecure boot and maybe a modified boot image? Freakin Samsung

SOLUTION CUSTOM ROM -Turbo X Hive 3 - rk3066 device tablet

After a long time search i think i can do a custom rom along with a CWM Recovery for TURBO X HIVE III tablet, but i need ORIGINAL boot.img, kernel.img, misc.img, recovery.img, system.img dump. I will do it myself, but in my Turbo X Hive III tablet i do not have original Andoid OS 4.1.1. I already put it on this nice tablet C.M.10.1 but with some other kernel from another tablet and i screw up the touchscreen drivers. From what i understand some of them are integrated in kernel, but i do not have the original kernel image! For those who wants to help to update this tablet (offcourse must have this device) i will upload a tool that can be easily dump .img for our needs! If more people want to develop something nice for this tablet i will provide more details on what we need to do or what i already did! But for now i will wait and see.....!!!
For the tool dump click HERE​
Understanding!
​Learning things first (optional).
All this is OPTIONAL for you to learn. If you don’t want to learn it then move on down to the instructions!
Understanding NAND layout:
Your NAND chips is broken into "partitions" or parts if you will call it that.
Each one of these servers a purpose. Here are all the partitions of a RockChip ROM.
Loader.bin - this is low in NAND and special. You can flash it but cannot dump it.
parameter - this file tells the loader how NAND memory is split up into partitions.
misc.img - this is a special area that tells the recovery system what to do on boot.
boot.img - this is the boot section and basically is the ram disk the kernel uses to boot.
kernel.img - this is of course the kernel.
cache.img - this is an area APPs store information like Google Play for instance.
kpanic.img - this is a special area for use by the kernel.
metadata.img - this is a NEW area for KitKat only. It does not exist in pre-kitkat ROMs. It's used for Encryption.
recovery.img - this is like boot.img but boots the recovery menu system.
system.img - this is the system OS.
backup.img - I am not sure what this is. It started showing up with Rockchip ROMs but does not appear to do anything.
But it might be work backing up anyway.
userdata.img - this is where APPs get installed, user accounts are stored, databases, etc. This area if erased losses all your user installed apps, settings, etc. A factory data reset erases this area.
user.img - This is the remaining NAND space and is set aside as the Internal SDcard.
Please note, many APPs like games, etc store stuff here! Erasing this you can lose data! This is also erased on a factory reset.
So based on the above what parts are a stock ROM?
Loader.bin
parameter
boot.img
kernel.img
misc.img
recovery.img
system.img
As you can see a stock ROM is just that! No user data!
Erasing NAND with the flash tool and flashing a stock ROM gives you a empty like new device as if you just bought it.
OK so some basics there. Now let’s look at the parameter file.
It's important because we will be using this to DUMP NAND memory.
I do not need to make you an expert on this but you need to know a few things.
If we look at this area of a parameter file, you will see the partitions I listed above!
Both the ones that hold a stock ROM images as well as ones that are created to be used by the system.
Here is an example of a parameter file for a kitkat ROM.
[email protected](misc),[email protected](kernel),[email protected](boot),[email protected](recovery),[email protected](backup),[email protected](cache),[email protected](userdata),[email protected](metadata),[email protected](kpanic),[email protected](system),[email protected](user)
So what do those number mean in from of each partition name like boot for instance?
First all these numbers are in hex. Second the numbers are blocks of 512 bytes!
let's look at boot..
[email protected](boot)
The first number 0x00006000 is the size of the partition.
The second number 0x0000a000 is the offset into the NAND chip from 0 location (start of the NAND chip).
But remember all these numbers are in 512 blocks.
If you wanted to know the size in bytes then do this math in your PC calculator.
REMEMBER to have the calculator set to HEX!!!
Enter 6000 and now multiply by 200 (fyi 200 hex is 512 decimal).
You will get C00000. Want to see that it decimal? In the calculator just click Dec and it will convert it!
So what we have is 12,582,912 bytes! Basically that is 12 megabytes.
Alright you can do that same math if you wanted to know the offset into NAND in decimal bytes.
Why is all this important? Well if gets you up to speed later when we calculate internal SDcard.
You don't need to know this but it might help you understand if you were to do things on your own.
___________________________________
Instructions for dumping....
Before we begin let’s get familiar with the tool.
In the download run the ROM_Dumper_Tool.exe.
When it opens you will notice 3 tabs at the top.
Download image - this is for flashing ROMs
Upgrade Firmware - this is for lashing single .img ROMs. I won’t be going into this area for as we don’t use it for dumping.
Advanced Function - This is for dumping and doing some NICE stuff! We will be in here all the time for this procedure.
Note: Anytime we dump a partition the tool always makes a file called ExportImage.img in a folder called Ouptut.
So every time we dump a different partition it will overwrite that file unless we rename them first!
Don't forget that please.
OK first lets dump the basic flashable ROM:
To do ANY dumping we need to dump the parameter file of the ROM from NAND.
Why? because we need the start (offset) and count (size) of the partition or we can’t dump anything.
1) Click the advance functions tab.
2) At the bottom is the "export image" button and to empty boxes, Start and Count.
3) To get the parameter file put a 0 in the start box and a 2 in the count.
4) Now press the export image button.
5) Now we need to make this a real parameter file! Rename the file to parameter.txt
6) We need to clean it up a bit. Open in Windows note pad ONLY!!! Do not open in MS word or anything else or it won’t work!
Also you may need to turn on word wrap to see everything (format menu, select word wrap checked).
7) The first line you will see something like this:
PARMi FIRMWARE_VER:4.1.1
Delete all the junk in front of the word FIRMWARE so it looks like this now:
FIRMWARE_VER:4.1.1
8) clean up ending junk. At the end you will see this word:
(user)
After it will be some junk. Delete everything after (user) including any blank space.
When done make sure to hit enter once so there is a new line after (user)
9) Save the cleaned up parameter file but leave it open as we need it to continue.
Now let’s start dumping!
We will do system.img to start with as an example.
1) Look at the parameter file and find (system) and the numbers before it. Example:
[email protected](system)
REMEMBER the number before @ is the COUNT and the number after the @ is the START!
2) Copy the number after the @ example: 0x00484000 into the start box of the advanced tab in the tool.
3) Copy the number before the @ example: 0x00180000 into the count box of the advanced tab in the tool.
4) Press the export image button and wait for it to complete.
5) Go into the Output folder and rename the file ExportImage.ing to system.img
Now we just repeat the steps 1-5 above for
misc.img
kernel.img
boot.img
recovery.img
backup.img (This can be optional but do it anyway especially if this is a first REAL stock ROM dump as we may need it).
Remember to always use the numbers in front of each name! Don't forget to change those or you won’t have a good dump.
Also remember after each dump, to rename ExportImage.img to the proper name of the image you dumped!
Each time you press Export Image, it will overwrite the existing ExportImage file unless you rename it!
When you’re done you should have the basic ROM dump.
misc.img, kernel.img, boot.img, recovery.img, system.img, and backup.img.
You can now use the flash tool 2.1 or the flash tool 1.37 to flash these.
_________________________________
Dumping userdata, cache, metadata, kpanic:
For a user backup the above 4 should be dumped.
We will start with userdata
This is basically the same as above except can take longer depending on how big your user data partition is.
This will be larger than any other partition so far as most devices have at least 1GB or more!
1) Again look at the parameter file and find (userdata) and the numbers before it. Example:
[email protected](userdata)
REMEMBER the number before @ is the COUNT and the number after the @ is the START!
2) Copy the number after the @ example: 0x00080000 into the start box of the advanced tab in the tool.
3) Copy the number before the @ example: 0x00400000 into the count box of the advanced tab in the tool.
4) Press the export image button and wait for it to complete.
5) Go into the Output folder and rename the file ExportImage.ing to userdata.img
Again repeat above for cache, kpanic, metadata.
if your parameter file does not have metadata then no need to dump this as it does not exist.
Remember only KitKat ROMs have this so do not worry if you don’t have it.
_________________________________
Finally to the hardest part but it is not really that hard. Dumping "user" which is internal SDcard.
Note: if you have a 32GB NAND or something large like that, this might not be worth your time!
Just back up internal SDcard another way (file copy) as it will probably be faster.
One way I like to do it is turn on MASS Storage in settings and enable USB to the PC.
Then I just copy the files to the PC.
For restore after flashing a ROM and userdata, I do the same thing and copy the files back to internal sd BEFORE running any apps that need that data on internal SDcard!
Dumping 32GB and flashing a large internal SDcard takes a LONG TIME! If most of your internal SDcard is empty,
dumping and flashing still writes ALL 32GB anyway so it's a waste of time to do this unless you have a LOT on internal SD.
So there is a trade-off... YOU decide which best works for you!
*********
So to back this area up we have to work some things out.
You will notice the parameter file for (user) has no SIZE number just the offset!
Example: [email protected](user)
the [email protected] simply says to use the remaining NAND as all of user (internal SDcard).
Thus to dump it we must calculate the size! To do this we must know how big our NAND chip is.
First put the number after the @ into the start box so we don't forget example: 0x00604000
This is just like the other parts we did above. We need the start point for user (internal SDcard).
Now let’s find out the size of the NAND chip.
In the advanced tab click the Read Flash Info button.
On the right it will display information but we are interested in this:
Flash Size: XXXXX MB
Where XXXXX is the size of your flash chip "page" size.
For instance my "other androidrk3066 device" says 8192 MB.
BUT WAIT! We also have to see how many pages of NAND we have.
Look at the line Flash CS:
If yours has a 0 then that is all you have 8GB
If CS says something like 0 1 2 3 (That’s 4 pages)
Then you have 4 pages of 8GB or 32GB NAND. If it says 0 1 then you have 2 pages or 16GB NAND and so on.
So whatever your size is multiple that by number of pages!
Example my "other rk3066 android device" stick says:
Flash Size 8528 MB
Flash CS: 0
Thus my full NAND size is 8528 as there is only 1 page
(yes the 0 is a page! The first page starts at 0 and a 1 is the 2nd page).
My "other rk3066 android device" says this:
Flash Size 8192 MB
Flash CS: 0 1 2 3
Thus I would take 8192 and multiply by 4 pages = 32768 MB NAND size.
So we now have our total NAND size!
Now a little more math but easy if you follow my instructions.
First we must make the size in MB a REAL GB number (not a MB number in 1000's).
I am going to use 8192 MB (8GB) NAND as an example. (It only had 1 page e.g. Flash CS: 0)
1) Open your PC calculator and again make sure it is set to programmer mode!
2) Make sure your set to Dec (decimal) not Hex mode!!!
2) Type in your NAND size you read or calculated with pages from the tool. My example 8192.
3) Multiply that by 1024. My example 8192 x 1024 = 8388608
4) Now do that one more time and multiply 8388608 by 1024. My example 8388608 x 1024 = 8589934592
5) Now divide this number by 512. My example 8589934592 / 512 = 16777216
So you know what all this math did was take the proper number of bytes and divide them into 512 blocks.
This is what is needed by the flash tool and parameter file!
6) Now press the Hex button on the left of the calculator to convert this to a hex number. My example came to 1000000 Hex.
7) OK now we know the total size of our NAND chip in 512 byte blocks in Hex format!
8) Now take this number and subtract the "start" that what was shown in the parameter file.
In my example parameter file I had [email protected](user) so my start is 604000 (we don’t use the beginning 0's).
So again my example 1000000 - 604000 = 9FC000
We now have our user (internal SDcard) size! It is 9FC000 in hex!!!
9) Enter this number into the count box of the tool. Again my example is 9FC000
BUT we need to enter it in the format the tool needs and that is hex!
Just add the 0x at beginning of the number so the tool knows it's hex. Again my example is now 0x9FC000
Just a note: 0's in front of any hex number are ignored. So 0x009fc000 is the same as 0x9fc000.
10) Make sure as I said above, you also entered the start number! Again in my example 0x00604000
11) Press the export image button and wait for it to finish. Depending on size this could be a long time!
12) Done forget to rename the ExpoertImage.img to user.img!
We are DONE! We now have a flashable FULL backup of the entire NAND chip!
What you should have in the output folder, if you did everything above dumping EVERYTHING is:
parameter.txt
backup.img
boot.img
cache.img
kernel.img
kpanic.img
metadata.img (optional if you had that and were on KitKat)
misc.img
recovery.img
system.img
user.img (internal SDcard)
userdata.img
__________________________________
Flashing your dump:
OK so now you have dumped the ROM and other items and you want to flash them back.
Well we can’t use the 2.1 RK tool! Why? Because it has 2 bugs in it.
1) Flashing userdata. It works but will error at 50% every time.
It actually does flash 100% but due to a math bug in the program it counts to 50% instead of 100%.
2) It won’t flash user (internal SD). If you try it says it did it but it doesn’t.
It returns success instantly so obviously it doesn’t flash anything.
If you did not backup user (Internal SD) then feel free to flash with the 2.1 tool and you will be OK even with the error at 50%.
However I setup the old 1.37 flash tool for you. All of the lines for each image is there.
I even have them checked by default for you.
In the download there is a flasher tool folder. Just run the flash tool from there.
Uncheck anything you didn’t backup or items you don’t want to flash.
Note: if you leave something checked you did not backup or the .img is not in the Output folder, you will get an error.
I left boot loader unchecked as there is no reason to flash that!
OK so that’s it!​
Specs!
In case somebody not know what device is about: Turbo-X, 10.1", 1280 x 800 pixels resolution, IPS panel, Front Camera 0.3 Mp, Back Camera 2.0, Android 4.1 Jelly Bean, CPU - Dual Core ARM Cortex A9 at 1.5 GHz, Internal Storage 16 GB, RAM -1 GB, WiFi, Bluetooth, Mini HDMI, Micro usb 2.0 host, microSD card slot, Li-Ion 6600 mah with Android 4.1.1, 3.0.8+ Kernel !
Battery
Also for those who have some problem with battery i found this one that is even better then original HERE​
Some other toolkit that i find!
Special thanks to Zeus and Faheem! With their tools you can Check Device, Wipe data, fastboot wipe, Reset user lock, Reset gmail, Reboot device, Fix camera, install usb driver and many other cool stuff!
HERE​
My dear friend Seby, i can help you without any problem and maybe we can open a new development thread for this old tablet because i already did a custom rom with a great help from a greek friend Panagiotis! So we will talk in PM about that!
Hello,can i have more information about this rom?
I must fix my brother's tablet ,stuck on bootloader.
It's exactly the same model as the author's of the current thread.
does anybody know how to enter fastboot mode in a turbox hive iii tablet it stuck in boot logo screen and i cannot do anything. If there is something I can do please tell me.
thanks

How To Change The Splash Screen or Boot Logo In Huawei Honor 7?

Hello Everyone!
After i managed to change the boot animation, i started researching some ways to change the boot logo or the splash screen that appears before the boot animation.
Boot animations and splash screens are two different things. The splash screen is the first static frame that you see the moment you turn on your phone. It is displayed before boot animation and it is usually much harder to change.
To change your boot animation, view my post at: http://forum.xda-developers.com/honor-7/help/how-to-change-boot-animation-huawei-t3247851
Back to the splash screen, so far I know the following:
1. The image file must be stored in RGB565 format. Photoshop and Paint.Net (with a plugin) are capable of saving in this format. In Photoshop, you can find it from the advanced options of .bmp.
2. There is a file called "oemlogo.mbn" which i think is responsive for the boot logo. After changing it though, it did not have any affect on the boot logo or splash screen.
If someone knows which file is responsive for the splash screen or he/she can point out a way to change that, it would be greatly appreciated.
Thanks in advance for your help!
Best Regards,
Ken
Here is the solution​
All the credits goes to Ziolek67 and Kostyan_nsk, I just made the zip to revert back to our stock logo, and made his guide compatible to our device. Thanks to @kenshiwara for helping me.
**TAKE NANDROID BACKUP VIA TWRP RECOVERY BEFORE DOING THIS**
1. Install adb and fastboot in your PC.
2. Dump your "oeminfo" partition by executing this command
Code:
adb shell su -c "dd if=/dev/block/platform/hi_mci.0/by-name/oeminfo of=/sdcard/oeminfo"
this will be saved in your internal storage as "oeminfo". Saving this to PC is recommended. To do that execute this command
Code:
adb pull /sdcard/oeminfo oeminfo
3. Now, Ziolek67 mentioned to edit the pulled "oeminfo" but in our case I tried and got error "resolution mismatch", so I pulled out his provided stock "oeminfo" of Huawei Ascend P7, which works fine, the sizes are also same of both the "oeminfo". Download this tool, extract and save it to the folder having adb and fastboot.
4. Make your own image with extension *.bmp. The resolution of the image should match your device resolution (1080x1920 pixels). Put it to adb folder.
5. Download OEMinfo.zip extract it and put "oeminfo" in adb folder.
6. Put your *.bmp image in "oeminfo" by executing this command.
Code:
OEM_logo.exe oeminfo *your_logo.bmp*
7. Push new "oeminfo" to your internal storage by executing this command
Code:
adb push oeminfo /sdcard/oeminfo
8. Put new "oeminfo" with new logo in your device by executing this command
Code:
adb shell su -c "dd bs=32768 if=/sdcard/oeminfo of=/dev/block/platform/hi_mci.0/by-name/oeminfo"
**UPDATED THE ABOVE COMMAND, THANKS TO @sminki
9. Now reboot your device to see your changed logo.
10. To revert back to stock Honor logo simply flash this file using TWRP recovery.
You can get more info here thanks to Kostyan_nsk.
How to make a compatible *.bmp image​
Create a new file in Adobe Photoshop with these parameters:
Width: 1080 pixels
Height: 1920 pixels
Resolution: 72 pixels/inch
Color Mode: RGB Color, 8-bit
Click to expand...
Click to collapse
After making your image save it with these parameters:
Extension: *.bmp
File Format: Windows
In "Advanced Options"
Select R5 G6 B5 from 16-bit depth options.
Click to expand...
Click to collapse
The Android Hero Of Today! ~ Amazing guide. Thank you very much!
Thank you @kenshiwara
it should be noted that in the wrong hands dd can brick your device, you are writing directly to the block device and dd does not care what you are doing.. especially if you do not add bs and/or count
I don't think adding bs would do any good, as dd automatically stops when the input of blocks runs out, in our case that is 32768, it can't go forever . Hope this was what you were pointing out, if no then please explain, I don't know much about other attribs and if the commands need any improvements then please suggest it so that I can add it.
Thank you
no it's fine, just giving general advice
when i said "you" i didn't mean you
you never know who is reading these things and what they might do, dd can be very dangerous, as you (DigiGoon) know... Man that was confusing
Oh, Okay
I have just written a clearer version of your solution, at my post here:
http://forum.xda-developers.com/honor-7/general/guide-beginners-how-to-root-update-fix-t3255452
Everything is the same, i just made it bit more organized for the absolute beginners to understand.
Thank you @DigiGoon and @sminki for writing and updating this guide.
Anytime buddy @kenshiwara

[WIP][MOD][SPLASH][OP6] Splash Screen Image Injector

Hey folks, thanks to @iElvis sharing his or her logo 'data' from the OP6. I have adapted my previous OnePlus programs that let you change the splash screen to work with the OP6. This means that the encoding of the data structure and the encoding of the image data are done. I do not have a OP6 and can not test certain things like where to put the modified file. In the past, flashing was always easy (and always has been especially with the OnePlus models).
My holdup and why I need the XDA/OP6 community support is to find out where to exactly put this modified file. In the past I haphazardly made a super fast in-memory program for altering the splash screen for the Nexus 6p that was (and is currently) at a roadblock for one reason. That reason was Google used ELFs to populate partitions (not short people with pointy ears and green clothing), and at that time utilized separate partitions that the ELFs populate. Not all were ELF generated, but that is outside of the scope of what I do because to a certain point the ones that I wanted to change were generated that way.
This concept of splitting partitions, back then, was just trying to grab a footing on seamless upgrades initially from what I have read up until this newer style. I have put some research into some things involving this, but Google is kind of bland in it's description of what this all means. This is different than the Nexus 6P that I mentioned previously, and if you read that last link, it may be just as easy as flashing it to both partitions logo_a & logo_b. One partition is always active and has two different statuses, which make the device 'ideally' always bootable after an OS update.
Most of my research was done through reading a lot of the open source code put out by the AOSP for "fastboot". You can learn more than you can ever derive from documentation in this realm. I hope to hear some feedback of attempts so that I can delete all of this up above
Please read below so you can better understand this type of encoding being used:
What Is A Raw Image?
A raw image, whether it be a file or an image in memory, is simply pixel data. There is no extra information like width, height, name, end of line... Absolutely nothing, just pixel data. If you have an image that is raw and the resolution is 1080x1920 and you are using a typical RGB24 or BGR24 (like the ones used here), then your exact filesize or size in memory will be 1080x1920x3! We use 3 here because there is one byte for the R or red component, one for the G (green), and one for the B(blue).
What Is A Run Length Encoded Image?
A run length image encoding uses a count ;usually a single byte (char), 2 bytes (short int), or 4 bytes (long int); and then the pixel components. So instead of writing out 300 bytes of '0's to make a line of 100 black pixels. Black is RGB(0,0,0). You could encode this as 100, 0, 0, 0. And only use 4 bytes of data to get the exact same image as the 300 byte raw image. All the run length encoding I've found, except the Motorola style which is a little different, use a run length encoding that is pixel-oriented like this.
Now I've found this new one and it is a byte-oriented run length encoding. This is for runs of bytes, not pixels. You may think, well whats the big deal? When you add a little area of color, you increase the run length encoded image in you logo.bin immensely! You use 6 bytes per pixel if there aren't any runs of color data. If you had an image that was a 1080x1920 black image with a 25 pixel horizontal line in the middle. The encoder would be doing runs of black data efficiently until it reached the red area.
.....0 255 0 255 0 255 0 255 0 255 0 133 /// we've reached the top left corner of the red line /// 13 1 30 1 255 1 // << that was just one red pixel!! in bgr color order (13, 30, 255) <<// And it keeps going through the rest of the red pixels on that line using 6 bytes per pixel, which is the opposite of compression. Before reaching the red line the encoding was decoding to 255 zeros over and over, until finally 133 zeros. 255 zeros is 85 black pixels stored in just 2 bytes!
This type of encoding is ONLY good for grey scale images. It is not good with color, but it still will handle color of course. In grey scale, the Red, Blue, and Green data components are always the same values. All the way from black (0,0,0) to white (255, 255, 255); including every shade of grey in between>>>(1,1,1) (2,2,2) (3,3,3)....(243, 243, 243) (254, 254, 254)<<<
One other difference in this method of run length encoding is that the color byte is before the count, which is backwards from all of the other methods.​
The attachment contains the executable that was compiled using mingw32 on a 64 bit Windows 10 PC. The awesome PNG library that I used for generating the pngs is LodePng, the source can be found here.
To use the OnePlus 6 Logo Injector:
Decode your logo.bin:
Code:
OP6Logo -i logo.bin -d
All the PNG 's will be extracted from logo.bin. Edit the PNG(s) that you want to change...
Note:
Your original "logo.bin" file is never changed, it is just read. If the file you try to load isn't a logo file, or a different style, then the program will tell you and exit.​
Inject the image(s) back in to the logo.bin:
Code:
OP6Logo -i logo.bin -j fhd_oppo fhd_at
To list whats in your logo file:
Code:
OP6Logo -i logo.bin -l
For a more detailed list:
Code:
OP6Logo -i logo.bin -L
If the colors are messed up use the "-s" switch while decoding.
Code:
OP6tLogo -i logo.bin -d -s
If you had to use the "-s" switch to decode properly, you'll have to use it to inject also:
Code:
OP6Logo -i logo.bin -j image_name -s
Note:
You can put as many names after "-j" as you want, and it's not case sensitive. You also don't have to put the whole name. If you just put "-j fhd" every image in the logo.bin that starts with "fhd" will be injected. There has to be a PNG with the name in the directory though​
The size of your modified.logo.bin will displayed along with the original size, if everything went good. The 'splash' partition is 16 MB on the OP6. If you use too much color on too many of the images you will easily go over 16 MB. The program will tell you and delete the "modified.logo.bin" that was created. If for some strange reason you would like to keep it, use the "-B" flag on the command.
The last step is to flash the modified logo file via fastboot with the command
Code:
fastboot flash LOGO modified.logo.bin
Use this at your own risk.
Always make backups.
Always.
Source
Source:
I haven't had a chance to work up a custom splash and flash it just yet, in part because I realized that on this phone, the splash screen only shows up for a split second before it's replaced by the "Your phone is unlocked and insecure, don't put sensitive files on it blah blah" warning. So I'm not sure this is going to do a whole lot for us. I'm going to try later tonight or this weekend and report back. Pretty sure "flash logo" should work fine, but it will flash only to the active partition. We may need to "flash logo_a" and "flash logo_b" to get it on both partitions.
Also, thanks for posting the source. I'm going to see if I can get this to compile in Xcode so we have an OSX version.
Edit 6/10: I can't get it to compile in Xcode, but I'm sure it's something I'm doing wrong.
Anyone tested it splash screen
Okay, welp, I'm throwing in the towel on this one. The bootloader warning is not in text like it was on the HTC phones I've modded to remove it. On those phones, the text showed up in the bootloader file in a hex editor, and could be replaced with empty spaces to remove it.
I pulled the boot file from /dev/block/bootdevice/by-name/ and searched through it. None of the text in the warning can be found with a simple search. As I suspected, that warning screen looks like it's a function coded into the boot process, which means removing it is probably impossible.
work Fine !
file :
lodepng.h
lodepng.c
OP6Logo.c
# gcc lodepng.c -c
# gcc OP6Logo.c -c
# gcc *.o -o OP6_prog OR # gcc lodepng.o OP6Logo.o -o OP6_prog
# ./adb shell
# su
# cd /dev/block/bootdevice/by-name
# ls --color --all
lrwxrwxrwx 1 root root 16 1970-01-06 04:29:20.549999999 +0100 LOGO_a -> /dev/block/sde20
# dd if=LOGO_a of=/sdcard/LOGO_a
exit
# ./adb pull /sdcar/LOGO_a ./
# OP6_prog -i LOGO_a -d
MODIFY YOUR PICTURE .....
# ./OP6logo -i LOGO_a -j fhd_
you have modified.logo.bin
Just dd if of and work fine !
And for the Real Splash :
./adb pull /system/media/bootanimation.zip ../
God bless
gao0309 said:
file :
lodepng.h
lodepng.c
OP6Logo.c
# gcc lodepng.c -c
# gcc OP6Logo.c -c
# gcc *.o -o OP6_prog OR # gcc lodepng.o OP6Logo.o -o OP6_prog
# ./adb shell
# su
# cd /dev/block/bootdevice/by-name
# ls --color --all
lrwxrwxrwx 1 root root 16 1970-01-06 04:29:20.549999999 +0100 LOGO_a -> /dev/block/sde20
# dd if=LOGO_a of=/sdcard/LOGO_a
exit
# ./adb pull /sdcar/LOGO_a ./
# OP6_prog -i LOGO_a -d
MODIFY YOUR PICTURE .....
# ./OP6logo -i LOGO_a -j fhd_
you have modified.logo.bin
Just dd if of and work fine !
And for the Real Splash :
./adb pull /system/media/bootanimation.zip ../
God bless
Click to expand...
Click to collapse
Way to remove bootloader unlocked warning?
NO
Please create flashable zip. Of splash screen
I'm trying this on linux on a 6T boot splash screen but I get a segmentation fault:
Code:
__________________________________________________________-_-
OP6 Logo Injector v1
Written By Makers_Mark @ XDA-DEVELOPERS.COM
_____________________________________________________________
FILE: logo.bin
_____________________________________________________________
RGB is the color order. Use "-s" switch to change it to BGR.
#01: Offset:0
Header=SPLASH!!
Width=1080
Height=1920
Data Length=81798
Special=1
Name=
Metadata=
Segmentation fault
Any idea why?
foobar66 said:
I'm trying this on linux on a 6T boot splash screen but I get a segmentation fault:
Any idea why?
Click to expand...
Click to collapse
For 6T, maybe you need look at this thread
https://forum.xda-developers.com/oneplus-6t/development/tool-splash-screen-modification-t3874158
Sent from my ONEPLUS A6000 using XDA Labs
I tried to report that the error memory could not be read under Windows 10 and wimdows7. Then I executed the following instructions under Linux and still reported the error. What can I do, oneplus 6, Android 9.0?
gcc lodepng.c -c
gcc OP6Logo.c -c
gcc *.o -o a.out
./a.out -i logo.bin -d
The following are the results of implementation:
__________________________________________________________-_-
OP6 Logo Injector v1
Written By Makers_Mark @ XDA-DEVELOPERS.COM _____________________________________________________________
FILE: logo.bin _____________________________________________________________
BGR is the color order. Use "-s" switch to change it to RGB.
#01: Offset:0
Header=SPLASH!!
Width=1080
Height=1920
Data Length=77716
Special=1
Name=
Metadata=
Segmentation fault
Code:
C:\Users\denie\Documents\logo>OP6Logo -i logo.bin -d
__________________________________________________________-_-
OP6 Logo Injector v1
Written By Makers_Mark @ XDA-DEVELOPERS.COM
_____________________________________________________________
FILE: logo.bin
_____________________________________________________________
BGR is the color order. Use "-s" switch to change it to RGB.
#01: Offset:0
Header=SPLASH!!
Width=1080
Height=1920
Data Length=81798
Special=1
Name=
Metadata=
C:\Users\denie\Documents\logo>
Any ideas?
Does this work?
Prakyy said:
Does this work?
Click to expand...
Click to collapse
There's no way to hide the Google warning about unlocked bootloaders, if that's what you mean.
iElvis said:
There's no way to hide the Google warning about unlocked bootloaders, if that's what you mean.
Click to expand...
Click to collapse
Really... This is what I've been searching all over for for my 6t... Get rid of the stupid bootloader unlock warning. On all my other devices we always used a custom made boot-logo.bin and installed it on slot a and slot b using fastboot.. I guess if it could be covered up it definitely would have by now. ?
Edit added: I just read the thread. From what I've gathered basically this device (6&6t) is designed different and that's why we can't tamper with/cover up the bootloader warning message.
flash713 said:
Really... This is what I've been searching all over for for my 6t... Get rid of the stupid bootloader unlock warning. On all my other devices we always used a custom made boot-logo.bin and installed it on slot a and slot b using fastboot.. I guess if it could be covered up it definitely would have by now. ?
Edit added: I just read the thread. From what I've gathered basically this device (6&6t) is designed different and that's why we can't tamper with/cover up the bootloader warning message.
Click to expand...
Click to collapse
I gave up after a lot of experimenting. I'm not aware of anyone managing it.
iElvis said:
I gave up after a lot of experimenting. I'm not aware of anyone managing it.
Click to expand...
Click to collapse
You should get an award for your XDA signature. ?? It's funny because it's real and oh so true! The way some people comment on things never ceases to blow me away. I see some posts and I think to myself, "what the hell?" "Who raised this person!?" There are definitely many different types of humans out there in the world that's a fact. I try and stay out of it as much as possible. ? lol.
It sucks we can't just make a ton of boot logos and cover that up. Oh well the 6 & 6t are awesome devices!! Usually whenever I end up on down the road selling my phone and purchasing another one from eBay or swappa things similar to this begin to be solved and then 15 custom roms all drop outa nowhere all at once. ? Happens every...single...time...haha!! Thanks for giving it a shot! :good:

Categories

Resources