Related
You NO larger need GParted or a Linux/Unix distro in order to make your own data.img! You NO longer need a command prompt either. However, you can use the command prompt still as an alternative option since this supports the commands in Windows. But this is an application.
With this Application you can create a brand NEW data.img or Add/Subtract space from an existing data.img. Example: You can take a 256MB data.img & make it convert to a 1GB data.img or take a 1GB data.img & make it 256MB data.img. Maximum space possible shown is based on the HDD or SD space left. So you could create a 150GB data.img if the drive had 150GB free space. It is completely safe & wont do anything to damage an existing data.img.
You will need WinRar or 7zip to extract the .RAR for this download.
WARNING!: DO NOT MAKE YOUR DATA.IMG Larger than 2GB because Android will not recognize the SD Card after. I will test this later.
1024 = 1GB
2048 = 2GB
4096 = 4GB
8192 = 8GB
Just double the #!
Screenshot:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
How to make a NEW(Fresh) Data.img:
NOTE: In order to start NEW you must have wiped your SD card or removed every file or folder such as: .REC, Cache, Android, OLD Data.img & any apps that took a folder on the card.
1. Open TopoResize
2. Select "Create New"
3. Select Save destination such as the SD Card & name it data
4. Select "Create File"
5. Select ext2 or ext3
6. Hit Ok & it will autorun.
DONE!
How to add space to an existing Data.img:
1. Open TopoResize
2. Select "Find File"
3. Locate file & select it
4. Use the size slider to select the extra space
5. Select "Resize File"
6. It will autorun
DONE!
How to subtract space to an existing Data.img:
Same instructions apply to add space just use the slider to go down & select resize file.
How to read the system.ext2 & transfer it over to the desktop:
1. Open Ext2explore
2. Select File & Open Image
3. Goto the system.ext2 & select it
4. Select Save
5. Select a destination to save it to. (Save it to a folder is preferred, so make one.)
INSTRUCTIONS TO CREATE A NEW or MODIFY EXISTING DATA.IMG via Command Prompt:
1. Open Command Prompt
2. Goto the directory of Data.img Maker
3. Enter dd if=/dev/zero bs=1M count=XXX >> data.img (XXX = Amount of Space for NEW such as 256MB is 256. Also if file is 256 already add 256 to make modified data.img = 512MB)
Alternative method! Instead of dd. You can use the following (only for new data.img):
Enter tfile data.img XXX (XXX = Size of MB ex. 1024 = 1GB. For new data.img only)
Alternative method! Instead of dd. You can use the following (only for modify data.img):
Enter Resize2fs -p data.img XXXXXX (1024*512MB=524288, always use 1024 times amount of space like 1024MB=1GB, so 1024*1024MB=1048576 for modify data.img only, can skip dd & just run this command for modify!)
4. Enter Mke2fs data.img (This will actually partition it so it doesnt come out as a bad read, MODIFY DATA IMAGE DOES NOT APPLY TO THIS STEP!)
5. Enter Resize2fs -f data.img (This will resize it for MODIFY ONLY! NOTE: can skip if you did the alternative method for existing!)
6. Enter E2fsck -f data.img (This checks to make everything is correct)
DONE!
Creating NEW Example:
d:\Software\DATA.IMG Maker\DATA.IMG Maker>dd if=/dev/zero bs=1M count=512 >> dat
a.img
rawwrite dd for windows version 0.6beta3.
Written by John Newbigin <[email protected]>
This program is covered by terms of the GPL Version 2.
512+0 records in
512+0 records out
d:\Software\DATA.IMG Maker\DATA.IMG Maker>mke2fs data.img
mke2fs 1.40.6 (09-Feb-2008)
data.img is not a block special device.
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
131072 inodes, 524288 blocks
26214 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=67633152
64 block groups
8192 blocks per group, 8192 fragments per group
2048 inodes per group
Superblock backups stored on blocks:
8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 25 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
d:\Software\DATA.IMG Maker\DATA.IMG Maker>e2fsck -f data.img
e2fsck 1.40.6 (09-Feb-2008)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
data.img: 11/131072 files (9.1% non-contiguous), 18858/524288 blocks
Alternative examples:
Using tfile to create fresh data.img instead:
D:\Software\DATA.IMG Maker\DATA.IMG Maker>tfile data.img 512
data.img
sizeMB= 512
Using resize2fs only to resize w/o anything else:
D:\Software\DATA.IMG Maker\DATA.IMG Maker>resize2fs -p data.img 524288
resize2fs 1.40.6 (09-Feb-2008)
Resizing the filesystem on data.img to 524288 (1k) blocks.
Begin pass 1 (max = 30)
Extending the inode table XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
The filesystem on data.img is now 524288 blocks long.
Download HERE! (Alternate)
NEED HELP? Comment here.
FINALLY! Thanks. I'm sure this will definitely come in useful. Downloading now... Testing later.
Yeah, really appreciated! Downloaded and will try out and report back (expanding standard 256MB data .img months old to 512MB or 1GB).
Nice App
I tried this out a few days ago to see how easy it was to use and how well. It was surprisingly simple. Good app. Worked like a charm.
OK. First of all a big thanks Viper.
But -yes it IS a stupid question but i don't get it - what does this application do beside from making a data.img with various sizes. I use android now for -i think it is- a long(er) time and just want to know what i can do to explore the System .
Cheers Bieka
Bieka said:
But -yes it IS a stupid question but i don't get it - what does this application do beside from making a data.img with various sizes. I use android now for -i think it is- a long(er) time and just want to know what i can do to explore the System .
Click to expand...
Click to collapse
That's all it does... Other questions?
arrrghhh said:
That's all it does... Other questions?
Click to expand...
Click to collapse
Uhm am i kickin' myself out if i ask what this (making various sizes of a data.img file) means?! Is this the storage size android gets?
That's all it does... Other questions?
Click to expand...
Click to collapse
Uhm am i kickin' myself out if i ask what this (making various sizes of a data.img file) means?! Is this the storage size android get?
Click to expand...
Click to collapse
You kno the way if you had an android device you would have sd storage and phone storage? and phone storage would be used for apps? well this data.img is lik a virtual phone memory, When you install apps they are stored on the data.img. And for alot of of ppl 256mb isnt enough, but unlike physical harware phone memory the data.img can be made bigger. understand?
Also a big tanks viper matrix, i was looking for a way to do this a couple weeks ago, i got it sorted by using someones modified rootfs to create a new data.img but this application will probly still come in handy
Aaaaah. Thanks a lot. Now i get it Simple and obvious .
Now i can say Thanks Viper for this aplication ^^ Great Job
Worked GREAT expanding trusty months-old data.img from nearly filled up 256MB to glorious 1GB. Now Android reports memory is over 990MB!
Dead simple: run the .bat, point to data.img on SD, move slider to expand size and go. Recognized errors, corrected them, then set to it's task which took a few minutes. Done.
Superb tool, waaay too unknown to group.
Open ext2explore & goto your system.ext2 & open it & then youll be able to save it to your desktop.
Use it on the desktop & make sure its extracted into a folder.
hi!
i linked my thread to your tool if you don't mind.
posting this app in the hd2 forums would bring it a LOT of attention.
@Viper
Excellent work on these apps! I was easily able to resize my data.img. I also tried ext2explore, which works well extract items from a system.ext2. A few questions:
- Would it be possible to have the data.img resizer use standard sizes, like 524288 for 512MB, 786432 for 768MB, 1048576 for 1GB (I think you get the idea). It seems like the resizing sizes are a bit arbitrary - or is there some sort of correlation between the standard sizes and the ones selectable in the app? Or, is there a way to put these values in manually?
- In the ext2explore app, will the possibly to Copy/Cut/Paste ever be added (or drag & drop from Explorer)?
I would love to see these apps developed further .
Again, great work!
P.S. I was hoping to be able to use ext2explore to add the BLAZN theme to the FRX03 build (see this thread) - that's when I realized I couldn't copy/paste.
Viper Matrix Wireless said:
You NO larger need GParted or a Linux/Unix distro in order to make your own data.img! You NO longer need a command prompt either. However, you can use the command prompt still as an alternative option since this supports the commands in Windows. But this is an application.
With this Application you can create a brand NEW data.img or Add/Subtract space from an existing data.img. Example: You can take a 256MB data.img & make it convert to a 1GB data.img or take a 1GB data.img & make it 256MB data.img. Maximum space possible shown is based on the HDD or SD space left. So you could create a 150GB data.img if the drive had 150GB free space. It is completely safe & wont do anything to damage an existing data.img.
You will need WinRar or 7zip to extract the .RAR for this download.
WARNING!: THIS HAS NOT BEEN TESTED, DO NOT MAKE YOUR DATA.IMG Larger than 2GB because Android may not recognize the SD Card after. I will test this later.
1024 = 1GB
2048 = 2GB
4096 = 4GB
8192 = 8GB
Just double the #!
Screenshot:
How to make a NEW(Fresh) Data.img:
NOTE: In order to start NEW you must have wiped your SD card or removed every file or folder such as: .REC, Cache, Android, OLD Data.img & any apps that took a folder on the card.
1. Open TopoResize
2. Select "Create New"
3. Select Save destination such as the SD Card & name it data
4. Select "Create File"
5. Select ext2 or ext3
6. Hit Ok & it will autorun.
DONE!
How to add space to an existing Data.img:
1. Open TopoResize
2. Select "Find File"
3. Locate file & select it
4. Use the size slider to select the extra space
5. Select "Resize File"
6. It will autorun
DONE!
How to subtract space to an existing Data.img:
Same instructions apply to add space just use the slider to go down & select resize file.
How to read the system.ext2 & transfer it over to the desktop:
1. Open Ext2explore
2. Select File & Open Image
3. Goto the system.ext2 & select it
4. Select Save
5. Select a destination to save it to. (Save it to a folder is preferred, so make one.)
Download HERE!
NEED HELP? Comment here.
Click to expand...
Click to collapse
Or you just install linux and make that all with one or two mouse clicks by your self
d0nate110 said:
Or you just install linux and make that all with one or two mouse clicks by your self
Click to expand...
Click to collapse
That's not an option for everyone , so Viper's tool is very useful for those people (like me) .
Captain_Throwback said:
That's not an option for everyone , so Viper's tool is very useful for those people (like me) .
Click to expand...
Click to collapse
For me it is ONLY option, cuz with linux I can apply my lovely BLAZN theme to any Froyo etc. Release what I want
Jandyman said:
You kno the way if you had an android device you would have sd storage and phone storage? and phone storage would be used for apps? well this data.img is lik a virtual phone memory, When you install apps they are stored on the data.img. And for alot of of ppl 256mb isnt enough, but unlike physical harware phone memory the data.img can be made bigger. understand?
Also a big tanks viper matrix, i was looking for a way to do this a couple weeks ago, i got it sorted by using someones modified rootfs to create a new data.img but this application will probly still come in handy
Click to expand...
Click to collapse
making sure I understand, under sd card in settings....phone free space, this is what it does...makes that free space bigger? more storage.?
Resized the img file from 512MB to 2 gigs, but I'm using the HD2 Nexus ROM, and it doesn't report the correct disk space usage. It still shows like 65MB free as it did before resizing. The file resized properly, but the phone doesn't report that.
Normal? If not, did I do something wrong? I followed the directions...
Hi devs,
Are you aware of any work (for other Android phones, for instance), where an altered mtd kernel driver was used to allow (raw) root access anyplace within flash memory? (For example, maybe a raw pseudo-partition which overlaps all the other partitions?) The stock mtd driver creates devices in the kernel device tree only for specific partition slices (boot, system, recovery, data, cache) - for obvious safety and security reasons.
After all these months, I stumbled across this tonight
Code:
C:\foo>fastboot oem listpartition
...
INFO[radio]:(OTHER) block start=0, size=332 (42496 KB)
INFO[hboot]:(RAW) block start=333, size=6 (768 KB)
INFO[misc3]:(RAW) block start=339, size=2 (256 KB)
INFO[mfg]:(RAW) block start=341, size=2 (256 KB)
INFO[sp1]:(RAW) block start=343, size=6 (768 KB)
INFO[misc2]:(RAW) block start=349, size=3 (384 KB)
INFO[mfg2]:(RAW) block start=352, size=3 (384 KB)
INFO[recovery]:(RAW) block start=355, size=40 (5120 KB)
INFO[boot]:(RAW) block start=395, size=20 (2560 KB)
INFO[system]:(YAFFS) block start=415, size=1360 (179520 KB)
INFO[cache]:(YAFFS) block start=1775, size=1040 (137280 KB)
INFO[userdata]:(YAFFS) block start=2815, size=1276 (168432 KB)
INFO[misc]:(RAW) block start=4091, size=5 (640 KB)
INFO[microp]:(OTHER) block start=0, size=0 (0 KB)
INFO[nv]:(OTHER) block start=0, size=0 (0 KB)
INFO[tp-melfas]:(OTHER) block start=0, size=0 (0 KB)
OKAY [ 0.071s]
finished. total time: 0.071s
I had never seen references in the Eris forums to the misc3, mfg, sp1, misc2, or mfg2 partitions - I suppose one or more are for boot images. Maybe interesting to boot a kernel image that had access to them, and have a peek at them?
bftb0
You are venturing into an area that is slightly beyond my current level of understanding. (Although we can all learn more.)
Is this even close to what you are looking for?
http://forum.xda-developers.com/showthread.php?t=754805
I'm thinking not, since they appear to be resizing the existing partitions, which doesn't seem to be quite what you are looking for.
I was asking about this a while back to see if anyone was able to get read access to the splash1 (i'm guessing sp1) partition so we could dump the REAL original splash screen for people that needed to go back to full stock. This was basically the only thing that is left out of going to stock since the "original" boot image that I had used for the android skateboards in my post about changing the boot logo was just a resized version I found online somewhere which is slightly bigger than the original if you look closely. I had some info laying around somewhere but it was definitely something about people modifying the mtd drivers in the kernel to get this done.
Without the modified drivers there is no way to do a FULL nand dump at this point.
gnarlyc said:
You are venturing into an area that is slightly beyond my current level of understanding. (Although we can all learn more.)
Is this even close to what you are looking for?
http://forum.xda-developers.com/showthread.php?t=754805
I'm thinking not, since they appear to be resizing the existing partitions, which doesn't seem to be quite what you are looking for.
Click to expand...
Click to collapse
Well, I'd seen that before - but THANK YOU - your post encouraged me to do a better job of searching, and I came up with this:
http://forum.xda-developers.com/showthread.php?t=542688
[SIZE=+2]Awesome![/SIZE] It appears that no mtd kernel hack is needed - as long the Eris kernels we are using accept those parameters (obviously, a little additional work is needed to get the offsets correct for the Eris).
I knew that partitions could be resized - but I wasn't aware that you could add new partition definitions. If it works for the Eris, then cool. (I have to say - the G1/G2/Hero devs surely have turned over a lot of stones that have helped us.)
bftb0
Mohahahhahahahaaha (rubbing hands together deviously). I smell either some interesting development or at least some interesting information coming out of this.
It's working.
More details later.
Flash Memory Map for the Eris:
Code:
PARTITION START END SIZE(1KB) SIZE(128KB) NOTES
radio 0x00000000 - 0x02980000 42,496 332 (3)
- gap! - 0x02980000 - 0x029a0000 128 1 (3)
hboot 0x029a0000 - 0x02a60000 768 6 (2)
misc3 0x02a60000 - 0x02aa0000 256 2 (5)
mfg 0x02aa0000 - 0x02ae0000 256 2 (6)
sp1 0x02ae0000 - 0x02ba0000 768 6 (4)
misc2 0x02ba0000 - 0x02c00000 384 3 (4)
mfg2 0x02c00000 - 0x02c60000 384 3 (4)
recovery 0x02c60000 - 0x03160000 5,120 40
boot 0x03160000 - 0x033e0000 2,560 20
system 0x033e0000 - 0x0dde0000 174,080 1360
cache 0x0dde0000 - 0x15fe0000 133,120 1040
userdata 0x15fe0000 - 0x1ff60000 163,328 1276
misc 0x1ff60000 - 0x20000000 640 5
( You can verify the above on your own phone with a combination of examining /proc/mtd, "dmesg" output immediately after the boot, and output of "fastboot oem listpartition" )
(1) Note all partitions are aligned to a 128-KB boundary (0x20000 - 18 bits)
Presumably this is why "fastboot oem listpartition" reports sizes in this unit
(2) Hboot images from HTC for the Eris have always been exactly 512 KB. Slack space is here,
but I found nothing but 0xFF's in the slack area.
(3) Attempting to dump the from this partition produces many, many error messages of the form:
mtd: MEMGETBADBLOCK returned -1 at 0x02940000 (errno=5)
mtd: MEMGETBADBLOCK returned -1 at 0x02960000 (errno=5)
(4) On my phone, dumps of partitions "sp1", "mfg2" and "misc2" produced un-interesting data blobs: all 0xFF's
Note that I have never flashed a custom boot splashscreen.
(5) Nearly "empty" - bytes not 0x00 or 0xFF are all string data (including CID)
(6) Contains "interesting" string data (including handset ID, manufacturing date, etc) and other binary data. Performing interesting handset operations and then recapturing a partition dump (before/after) and performing a binary diff could reveal strategic locations.
[SIZE=+1]HOW-TO[/SIZE]
Most people have absolutely no business doing this - you have been warned.
Under no circumstances should you hand-type any of these addresses; a simple typo could lead to disaster.
Code:
fastboot -c " mtdparts=msm_nand:[email protected](misc),[email protected](recovery),[email protected](boot),[email protected](system),[email protected](cache),[email protected](userdata) " boot recovery-RA-Eris-v1.6.2.img
will produce the standard kernel partition mappings. Note the leading and trailing spaces in the quoted string - and that the order of appearance is critically important
You may append one or more** of the following, separated with commas as shown in the above (standard mapping) command.
[email protected](radio)
[email protected](hboot)
[email protected](misc3)
[email protected](mfg)
[email protected](sp1)
[email protected](misc2)
[email protected](mfg2)
** I performed individual boots adding only one non-standard partition, and can not guarantee that a disaster will not result if you try to append more than one - or all of them - in one boot.
You can verify the additional partitions have been kanged into the kernel's device tree with
adb shell cat /proc/mtd
and may dump individual partitions via the command "dump_image" (provided by Amon_RA in /sbin), as in the following example:
mount /sdcard
dump_image mfg /sdcard/part.mfg.img
bftb0
If you just want to dump a specific Eris flash memory partition(s) off your phone, there is an even easier method. (Doh!)
Prerequisites:
- 1.49.2000 S-OFF bootloader is installed on your Eris.
- working device drivers on PC and fastboot utility
Steps:
1) Connect via USB to your PC and put phone in FASTBOOT mode (Power up with Send+End)
2) Get the partition names listing using
Code:
fastboot oem listpartition
3) Using the following fastboot syntax, plug in the desired partition name (PNAME):
Code:
fastboot oem saveprt2sd PNAME -n PNAME.bin -a
for example, the "sp1" partition:
Code:
$ fastboot oem saveprt2sd sp1 -n sp1.bin -a
... INFOSaveImageToSD partition file name:sp1
INFOSaveImageToSD output file name:sp1.bin
INFOCmd5 CMD_TIMEOUT
INFOsdcc_poll_status(): i=21
INFOCmd5 polling status timed out
INFOSD: CMD5 fail, rc=2 ..
INFOSD 2.0
INFOHC card
INFO Searching free data sectors....
INFO [SAVE2SD] 131072 bytes saved.
INFO [SAVE2SD] 262144 bytes saved.
INFO [SAVE2SD] 393216 bytes saved.
INFO [SAVE2SD] 524288 bytes saved.
INFO [SAVE2SD] 655360 bytes saved.
INFO [SAVE2SD] 786432 bytes saved.
INFO [SAVE2SD] Done.
OKAY [ 1.728s]
finished. total time: 1.728s
Yep, it really is that simple.
bftb0
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.
Hello ... so i have an Radio.img and i know inside there are this files
(bootloader) Validating 'radio.default.xml'
(bootloader) Committing 'radio.default.xml'
(bootloader) - flashing 'NON-HLOS.bin' to 'modem'
(bootloader) - flashing 'fsg.mbn' to 'fsg'
(bootloader) - erasing 'modemst1'
(bootloader) - erasing 'modemst2'.
How can i extract NON-HLOS and fsg ? thanks in advance ...
I know this is an ancient thread, but it's still the first search result, so I figured a solution could help anyone else that stumbles upon this..
I made a quick and dirty extractor that works at least for motorola edge 2021 xt2141 radio images. These files seem to start with magic "SINGLE_N_LONELY" and end with "LONELY_N_SINGLE". Filenames are provided, followed by the length of the contents (in little endian), then the contents.
This script will try to open radio.img in the current dir if a filename is not provided. Dumped files will go right in the working dir, so be careful. File content reading isn't done in chunks here, so be mindful of memory usage. Likely not an issue, but you can code in some chunking if needed.
Code:
#!/usr/bin/env python
import io
import sys
# supply filename as argument or default to 'radio.img'
try:
filename = sys.argv[1]
except IndexError:
filename = 'radio.img'
with open(filename, 'rb') as f:
magic = f.read(0x100).strip(b'\0').decode()
print(magic)
assert magic == 'SINGLE_N_LONELY'
while True:
# filename
fn = f.read(0xF0).strip(b'\0').decode()
print(fn)
if fn == 'LONELY_N_SINGLE':
break
# size of file in little endian
f.seek(0x08, io.SEEK_CUR)
l = int.from_bytes(f.read(0x08), 'little')
print(l)
# warning: not reading in chunks...
# warning: outputs to working dir
with open(fn, 'wb') as o:
o.write(f.read(l))
# seek remainder
rem = 0x10 - (l % 0x10)
if rem < 0x10:
f.seek(rem, io.SEEK_CUR)
# seek until next filename
while not f.read(0x10).strip(b'\0'):
continue
# rewind back to start of filename
f.seek(-0x10, io.SEEK_CUR)
Note the resulting images will likely be in sparse format. You'll need simg2img to convert to raw images if you're trying to mount or otherwise manhandle the images.
If interested in dumping carrier profiles (from inside the fsg image), EfsTools has an extractMbn function. Not sure how to reassemble though. https://github.com/JohnBel/EfsTools
ziddey said:
I know this is an ancient thread, but it's still the first search result, so I figured a solution could help anyone else that stumbles upon this..
I made a quick and dirty extractor that works at least for motorola edge 2021 xt2141 radio images. These files seem to start with magic "SINGLE_N_LONELY" and end with "LONELY_N_SINGLE". Filenames are provided, followed by the length of the contents (in little endian), then the contents.
This script will try to open radio.img in the current dir if a filename is not provided. Dumped files will go right in the working dir, so be careful. File content reading isn't done in chunks here, so be mindful of memory usage. Likely not an issue, but you can code in some chunking if needed.
Code:
#!/usr/bin/env python
import io
import sys
# supply filename as argument or default to 'radio.img'
try:
filename = sys.argv[1]
except IndexError:
filename = 'radio.img'
with open(filename, 'rb') as f:
magic = f.read(0x100).strip(b'\0').decode()
print(magic)
assert magic == 'SINGLE_N_LONELY'
while True:
# filename
fn = f.read(0xF0).strip(b'\0').decode()
print(fn)
if fn == 'LONELY_N_SINGLE':
break
# size of file in little endian
f.seek(0x08, io.SEEK_CUR)
l = int.from_bytes(f.read(0x08), 'little')
print(l)
# warning: not reading in chunks...
# warning: outputs to working dir
with open(fn, 'wb') as o:
o.write(f.read(l))
# seek remainder
rem = 0x10 - (l % 0x10)
if rem < 0x10:
f.seek(rem, io.SEEK_CUR)
# seek until next filename
while not f.read(0x10).strip(b'\0'):
continue
# rewind back to start of filename
f.seek(-0x10, io.SEEK_CUR)
Note the resulting images will likely be in sparse format. You'll need simg2img to convert to raw images if you're trying to mount or otherwise manhandle the images.
If interested in dumping carrier profiles (from inside the fsg image), EfsTools has an extractMbn function. Not sure how to reassemble though. https://github.com/JohnBel/EfsTools
Click to expand...
Click to collapse
Thanks for making python script to unpack these SINGLE_N_LONELY header files(bootloader.img, radio.img, singleimage.bin, gpt.bin) from Moto Stock ROM zips.
But why reading filename only 240 bytes and skipping 8 bytes instead of reading whole 248 bytes?
This guy wrote to read 248 bytes instead https://forum.xda-developers.com/t/...t-of-the-moto-g-5g-plus.4371213/post-87807175
I also made quick and dirty unpacked using Lua 5.3 at https://forum.xda-developers.com/t/...t-of-the-moto-g-5g-plus.4371213/post-87931915
I guess one of us has to post this to github, since I can't find any Open Source tool to unpack this simple format image files.
Currently, only star tool that we can find from some of blankflash files(eg. this) and imjtool can unpack these SINGLE_N_LONELY header files as far as I know. But I guess these are not Open Source.
Thanks
HemanthJabalpuri said:
But why reading filename only 240 bytes and skipping 8 bytes instead of reading whole 248 bytes?
This guy wrote to read 248 bytes instead https://forum.xda-developers.com/t/...t-of-the-moto-g-5g-plus.4371213/post-87807175
Click to expand...
Click to collapse
Ah neat. I only used xt2141 radio images as reference for approximating the file format. It's been a while, but I think based on the actual positioning of the filenames in the images I was testing, I wasn't sure if the final 8 bytes were part of the filename or padding.
Likewise, I wasn't sure of how padding works after the file data, so I just did a dumb seek and rewind.
Hi guys, I am asking you some help due to an emergency.
I had to downgrade an Android 10 rom where I had encryption turnen on (rom).
All I did was flashing a previous (minor) version of the rom via TWRP with just a "wipe cache/dalvik".
After rebooting my pin was not recognized anymore by both Android and TWRP.
I did many tentatives and at some point I typed "default_password" as pin, when asked by Android during the boot, and there was a important change:
1. After rebooting I typed my old pin, and now Android always tells me: "The password you entered is correct, but unfortunately your data is corrupt".
2. Now when TWRP asks for the password, it accepts the old pin too. But it is "unable to mount storage".
3. The system partition's contents are now visible: before they were not showing at all. The data partition is not accessible (error decrypting…).
I have done a lot of studying and tentatives to get the phone working without formatting and losing the data, but I could not solve the issue. I don't think the data is actually corrupted, because the rom downgrade was a minor version and it did not modify anything about encryption.
Could you please point me to the right direction? I am trying to understand what could have gone wrong, and find some possible solution.
EDIT: more details and list of the attempted solutions in this post: https://forum.xda-developers.com/t/...sue-after-rom-downgrade.4168821/post-85210619
JackSlaterIV said:
After rebooting I typed my old pin, and now Android always tells me: "The password you entered is correct, but unfortunately your data is corrupt".
Click to expand...
Click to collapse
Look inside here.
jwoegerbauer said:
Look inside here.
Click to expand...
Click to collapse
Both methods cause /data to be erased, which is what I don't want. Thanks anyway.
guess if something has changed since your dirty flash, it must be something in last 16384 bytes where the crypto footer is
there are some bytes which are most likely one or eight flag(s)
Flags : 0x00000000
you can locate and copy the crypto footer like this
- check fstab for location if it says encryptable=footer (or see recovery.log)
- get partition size and calculate the offset -16384
- extract the footer to /sdcard with dd (any file name)
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
on PC open that file with Hex Editor
- the crypto footer will start with magic 0xD0B5B1C* (little endian). in my case it's C5 B1 B5 D0 as it's a samsung device.
- you should also see a string aes-cbc-essiv:sha256 (in my case aes-xts)
inspect the crypto footer with python script. you can't decrypt since android uses scrypt+keymaster but it will give you a nice layout
- install python 2.7
- run that script bruteforce_stdcrypto.py
Code:
Android FDE crypto footer
-------------------------
Magic : 0xD0B5B1C4
Major Version : 1
Minor Version : 3
Footer Size : 2352 bytes
Flags : 0x00001008
Key Size : 128 bits
Failed Decrypts : 36
Crypto Type : aes-xts
Encrypted Key : 0xCCE7D93B501B400D3D81726806F92936
Salt : 0x51B68B017C2A181E3ABD0B041FBFAA14
KDF : scrypt+keymaster
N_factor : 15 (N=32768)
r_factor : 3 (r=8)
p_factor : 1 (p=2)
crypt type : PIN
FS size : 52453304
encrypted upto : 52453304
-------------------------
as you can see in your case the flags are 0x00001008 so you can easier locate that in your Hex Editor
- convert the string little endian 0x00 00 10 08 -> 08 10 00 00
- you will find that four bytes at offset 13 in the first line
- reset the flags to 00 00 00 00 and save the file
if you prefer linux you can also use that shell script for doing that. fde_crypto.sh
Before messing up your data partition do a full dump for backup purposes (because we don't know what we are doing here, encryption is complicated stuff). In case you broke something you can just adb push it later
Code:
adb pull /dev/block/bootdevice/by-name/userdata
Now, write the new crypto footer back to end of userdata partition
- copy the file back to the device (another file name)
- get partition size and calculate the offset -16384
- write the footer to offset with dd (seek)
Code:
adb push data-footer.bin /sdcard
adb shell
cd /sdcard
blockdev --getsize /dev/block/bootdevice/by-name/userdata
dd bs=512 seek=$((52453336-32)) count=32 if=data-footer.bin of=/dev/block/bootdevice/by-name/userdata
Note: i don't know if that works. indeed, that's all guesswork based on your input in pm. good luck!
Hi and thanks again. As you wrote we spoke a lot via PM before your post.
I reset the footer flags to 00 00 00 00. Then used dd as you suggested to overwrite the userdata footer.
During the first Android boot, it asked me to enter the pin, but then it failed to decrypt, and now is always showing the old message "The password you entered is correct, but unfortunately your data is corrupt" .
So looks like the flag at least reset the default mode.
And TWRP still can't decrypt the partition.
It's no surprise because, as you showed me, the userdata partition may be corrupted.
I wanted to get the updated footer back from the phone to my PC. I used this:
dd bs=512 seek=$((52453336-32)) count=32 if=/dev/block/bootdevice/by-name/userdata of=/tmp/data-footer-new.bin
32+0 records in
32+0 records out
16384 bytes (16.0KB) copied, 0.009945 seconds, 1.6MB/s
Then Adb pull tmp/data-footer-new.bin
But it started downloading a few GB of data. I checked the size via ls -l:
-rw-rw-rw- 1 root root 26856108032 Dec 20 14:04 data-footer-new.bin
What I did wrong? Is it a bug?
usage problem - this is expected behavior for dd seek. when the output file is too small or doesn't exist, a zero padding is filled to create a big file before the offset starts, where it finally starts to write the real data (32 x 512 bytes)
you have mixed up parameters skip/seek, in your case copied first 16384 bytes from userdata into the end of a big file data.footer.bin
btw the userdata partition is not corrupt per se (or at least there is no proof i could show ever) you will never find ext4 file system magic 0xEF53 on encrypted userdata, only on dm-0 (if decrypted successfully). but true, mounting is a different case, indeed mount may fail even for successfully decrypted file system (like for Redmi 5). so the safest way to know if decrypted successfully is looking for zero paddings, first 1024 bytes will have enough of it...
you can try lot of other values for this flag (0x00001000 like for LG?) or try other (undiscovered) flags. you need a lot patient and time as you are the first one trying this. also reset the failed decrypts counter as this may important for gatekeeper timeout
i recommend to decrypt straight from twrp command line, should "work" without reboot
edit: i could even imagine automatizing that with script (10 sec/attempt - min timeout)
edit 2: interesting too would be binary (or checksum) compare of userdata before/after failed attempt (without footer) to figure out if changes happen elsewhere (other than footer)
even more interesting, you could factory reset and reproduce the mistake, make a snapshot before/after and bitwise compare where the changes happen
if the key itself has changed, there is no possible way to revert as the old key is lost
but decryption should still be possible on the newer android version, all you need is working twrp that fits
edit: factory reset is maybe not the best idea! turns out for FBE file-based-encryption the KEK is stored in TEE and depending on rollback resistance (not related to version binding) master key may deleted on factory reset. FBE is introduced with Android 7.1 - your device is still running good old FDE full-disk-encryption - but who knows what additional protections Android 10 enforces? can't guarantee that KEK is encrypted by hardware-backed RSA-2048 private key and screenlock credentials only and everything is stored in crypto footer only, although the documentation doesn't indicate contradictory
aIecxs said:
usage problem - this is expected behavior for dd seek. when the output file is too small or doesn't exist, a zero padding is filled to create a big file before the offset starts, where it finally starts to write the real data (32 x 512 bytes)
you have mixed up parameters skip/seek, in your case copied first 16384 bytes from userdata into the end of a big file data.footer.bin
Click to expand...
Click to collapse
Can you confirm this is the correct command to get the new footer?
dd bs=512 skip=$((52453336-32)) count=32 if=/dev/block/bootdevice/by-name/userdata of=/tmp/data-footer-new.bin
I think that this new big file may have caused some corruption.
I want to restore the userdata partition backup, but I read it's not easy as a simple adb push: https://android.stackexchange.com/q...n-image-of-android-partition-from-my-linux-pc
Can you tell me any reliable way to do this, apart using busybox as in the above replies?
btw the userdata partition is not corrupt per se (or at least there is no proof i could show ever) you will never find ext4 file system magic 0xEF53 on encrypted userdata, only on dm-0 (if decrypted successfully). but true, mounting is a different case, indeed mount may fail even for successfully decrypted file system (like for Redmi 5). so the safest way to know if decrypted successfully is looking for zero paddings, first 1024 bytes will have enough of it...
Click to expand...
Click to collapse
Thanks for clarifying this.
you can try lot of other values for this flag (0x00001000 like for LG?) or try other (undiscovered) flags. you need a lot patient and time as you are the first one trying this. also reset the failed decrypts counter as this may important for gatekeeper timeout
i recommend to decrypt straight from twrp command line, should "work" without reboot
edit: i could even imagine automatizing that with script (10 sec/attempt - min timeout)
edit 2: interesting too would be binary (or checksum) compare of userdata before/after failed attempt (without footer) to figure out if changes happen elsewhere (other than footer)
Click to expand...
Click to collapse
Indeed I had already tried 0x00001000 and resetting the counter, before the mess up with my dd command.
Do you know any other combination I could try?
Something I could try is see what happens to /userdata if I type default_password at the first boot.
yes, that is the right command
no, you didn't mess up with big file because of= is the only thing written (and /tmp is only in RAM)
yes, simple adb push is fine and works quite well for single partition. the link is talking about something different (whole eMMC including gpt and bootloader)
no, i have no clue about the flags. the source code might help but it's above my knowledge (yet)
found some explanation for flags
https://www.0xf8.org/2019/01/analyz...axy-s7-data-partition-with-samsung-encryption
have implemented the above link, not sure if i am doing it right but have a look into script fde_crypto.sh
Hello alecxs, thanks for your last messages. Sorry for this long delay.
I did not write any update because I couldn't find anything useful in the footer and the full data images. The phone is still not in use, in a drawer.
I had tried different flags, but after each tentative I had the same result. The "system" tells that data may be corrupted and updates the flag accordingly.
I had compared before vs after data images and did not find any difference. There is only one field in the footer that is modified after each tentative: the sha256 of the footer (offset 90c).
Without further information I cannot tell what causes this issue, if the data is corrupt or not. It would be useful having a more verbose mode in the mount command, so that it shows the reason of the failed mount. I guess it's not possible.
i think it is caused by rollback resistance and you should try higher android version (that one that messed up everything) with compatible TWRP. besides recovery.log you can check dmesg and logcat for additional information
Hi again,
I am attaching dmesg and recovery log, taken from TWRP after a failed mount of the data partition, using my pin, with the crypto footer flags reset to zero.
I could not find anything, so I hope someone reading this could give me a hint.
From what I can see, anti rollback and verified boot are disabled in Mi5 and in LineageOS based roms (see here).
Regarding TWRP I always used the same version recommended by the rom developer.
EDIT: file attachment not working for me...
See them here:
dmesg.log
Shared with Dropbox
www.dropbox.com
recovery.log
Shared with Dropbox
www.dropbox.com
looks like double encryption bug. try to dump content of dm-0 and restore it to userdata, that should at least eliminate the FDE encryption. second encryption is FBE? let binwalk analyze usually there is unencrypted area
aIecxs said:
... you should try higher android version [...]
Click to expand...
Click to collapse
just as a reference: for this you would find errors like
E vold : upgrade_key failed, code -38
E Cryptfs : Failed to upgrade key
which is not the case here.
(note: yes it says "upgrade" but in my example the installed key is from a higher version so actually a downgrade would be needed - which is not possible at all.)
(see a full example and details here and google details here)
JackSlaterIV said:
Hi again,
I am attaching dmesg and recovery log, taken from TWRP after a failed mount of the data partition, using my pin, with the crypto footer flags reset to zero.
I could not find anything, so I hope someone reading this could give me a hint.
From what I can see, anti rollback and verified boot are disabled in Mi5 and in LineageOS based roms (see here).
Regarding TWRP I always used the same version recommended by the rom developer.
EDIT: file attachment not working for me...
See them here:
dmesg.log
Shared with Dropbox
www.dropbox.com
recovery.log
Shared with Dropbox
www.dropbox.com
Click to expand...
Click to collapse
the interesting part is here:
Code:
<3>[ 5.880909] QSEECOM: __qseecom_process_incomplete_cmd: fail:resp res= -65,app_id = 0,lstr = 12288
<3>[ 6.007678] QSEECOM: __qseecom_process_incomplete_cmd: fail:resp res= -71,app_id = 0,lstr = 12288
<3>[ 6.007697] QSEECOM: __qseecom_set_clear_ce_key: process_incomplete_cmd FAILED, resp.result -71
<3>[ 6.007716] QSEECOM: qseecom_create_key: Failed to create key: pipe 2, ce 0: -22
<3>[ 6.007726] QSEECOM: qseecom_ioctl: failed to create encryption key: -22
<3>[ 6.098357] scm_call failed: func id 0x72000501, ret: -2, syscall returns: 0xffffffffffffffbf, 0x0, 0x0
<3>[ 6.225071] QSEECOM: __qseecom_process_incomplete_cmd: fail:resp res= -71,app_id = 0,lstr = 12288
<3>[ 6.225082] QSEECOM: __qseecom_set_clear_ce_key: process_incomplete_cmd FAILED, resp.result -71
<3>[ 6.225096] QSEECOM: qseecom_create_key: Failed to create key: pipe 2, ce 0: -22
<3>[ 6.225104] QSEECOM: qseecom_ioctl: failed to create encryption key: -22
the main error is likely:
Code:
<3>[ 5.880909] QSEECOM: __qseecom_process_incomplete_cmd: fail:resp res= -65,app_id = 0,lstr = 12288
[..]
<3>[ 6.007716] QSEECOM: qseecom_create_key: Failed to create key: pipe 2, ce 0: -22
<3>[ 6.007726] QSEECOM: qseecom_ioctl: failed to create encryption key: -22
-65 means: ATTESTATION_APPLICATION_ID_MISSING whatever that means actually.
aIecxs said:
looks like double encryption bug. try to dump content of dm-0 and restore it to userdata, that should at least eliminate the FDE encryption. second encryption is FBE? let binwalk analyze usually there is unencrypted area
Click to expand...
Click to collapse
interesting idea especially as it actually can decrypt /dev/dm0 according to the recovery.log but then failing to mount it.
I would +1 here and try if you can dump the content of /dev/dm0 after trying the decryption ( e.g. when you have an ext sdcard: `dd if=/dev/dm0 of=/external_sd/dump.img bs=4096` )
Other then that it might be an issue with your blobs - either in TWRP, or the device
i think your issue is bit different and the links provided are about FBE. afaik FDE does not hold keys in TEE (except for hardware-backed RSA-2048 private key which is not flushable) so i am not sure if upgradeKey affects crypto-footer but deleteKey is clearly some keystore thing
to eliminate issues with TWRP i would do decryption test on working block encryption (and maybe try OrangeFox) only then you can determine issues with faulty crypto-footer
Hello guys, thanks for your help.
I dumped both sda14 and dm-0 partitions (using adb dump).
The dm-0 ("decrypted" partition) is a smaller binary file (26.856.091.648 bytes) vs sda14 (26.856.108.032 bytes).
I compared these binary files using HxD and they look different. dm-0 does not contain the crypto footer section (the 16384 bytes difference).
I just installed binwalk for the suggested purpose, and started analyzing dm-0 (binwalk dm-0). It is outputting something and I don't have any idea of how much time it would take to complete the task.
Let's see if I can attach a screenshot..
okay not sure binwalk may just false detect random data or it may real files. anyway you can concatenate dm-0 with crypto-footer from userdata and check what TWRP says about this garbage then
aIecxs said:
okay not sure binwalk may just false detect random data or it may real files. anyway you can concatenate dm-0 with crypto-footer from userdata and check what TWRP says about this garbage then
Click to expand...
Click to collapse
Yes indeed.
I did not find any text in the dm-0 binary.
Can you suggest me how I concatenate these files? I have dm-0 and crypto-footer in separate files. EDIT: just by using HxD.
To overwrite the partition can I use "adb push dm-0-new /dev/block/sda14"?