[X]Assistant

[And_pda]

пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ (пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅ пїЅпїЅпїЅпїЅпїЅпїЅ) пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅ (*.img, *.bin) пїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅ download

WINDOWS

This topic was created to continue the discussion and help in the processing of various images under Windows, a start was made in another topic, but the authornegatively perceived discussion, not related to his means, offered to discuss in a personal or to start another topic. I am categorically opposed to communicating in person, because many people will not see the information under discussion, which can be very useful and will not be able to contribute to the discussion. Therefore, I came to the decision to create this topic. I want to offer my utilities for unpacking images of the EXT2 \ EXT3 \ EXT4 \ SPARSE \ YAFFS2 format, my own kitchen variant for unpacking \ packing full firmware for Rockchip, MTK (as * .img files or archives * .tar (rar)) and contained inside the firmware of individual images of the type system, kernel, recovery, boot. This is something that has already been done and is working,in the near future to make friends a unpacker with * .SIN images(format for Sony Xperia)

Useful (examples of processing different images)
Unpacker payload.bin
Work with system.new.dat1
UNIX attributes (rights, UID, GID) on files and folders in WINDOWS
Image formats, utilities and examples of their processing
Stock update RECOVERY for CWM do-it-yourself
Removing the ramdisk from recovery.img from Lenovo K900 (x86) through WinHex
Extracting kerenel from recovery.img from Lenovo K900 (x86) using WinHex
Adding a modified ramdisk to recovery.img from Lenovo K900 (x86) via WinHex
Analysis of the format of the SIN 3 version of the images from the firmware for Sony Xperia
Parse an IFWI image into blocks (used when flashing through MFT (xFSTK) for x86-based Android devices) using WinHex
Kernel extraction and recovery instructions from fwu_image.bin
Convert system.new.dat.br to system.new.dat and back
How to patch system.img on a PC without flashing OTA on a smart if system.patch.dat file> 0
Collection of scripts for working with images
Utilities

Script to build a zImage image containing a patched kernel.img
an automatic script for unpacking Android 5.x.x firmware, the format of which is "system.new.dat".

Updated: 07/30/2014reassembledmake_ext4fs - EXT4 and SPARSE EXT4 image build utility(added a way to build the system through 'dragging the mouse')

AndImgTool (Android Image Tool)- a utility for unpacking and reassembling boot images such as BOOT and RECOVERY for the ARM platform, no matter what percentage of the device (rockchip, media library, etc., etc.), it is important what standard the manufacturer followed! The following formats are currently supported: Android Boot Image (also with MTK wrapper for the internal kernel and ramdisk blocks and the new DTB block), KRNL Image, UBOOT Image (packing formats: none, LZMA, GZIP), unpacking / packing full firmware for RockChip (RKFW \ RKAF)
More about the utility,tested device list, instructions, screenshots and logs here.

AndImgTool version 1.3.0 Updated: 12/30/2014release and details here
- Added support for unpacking / packing x86 boot images (functionality transferred from xImgTool utility)

AndImgTool version 1.2.3 AndImgTool_1_2_3.rar(196.69 KB)
Updated: 11/13/2014- update functionality, details here

Older versions

AndImgTool version 1.2.2AndImgTool_1_2_2.rar(196.73 KB)
Updated: 10/22/2014- update functionality, details here
AndImgTool version 1.2.1 Updated: 08/13/2014- fixed bugs fixed
AndImgTool version 1.2.0AndImgTool_1_2_0.rar(196.16 KB)
Updated: 07/10/2014
- Added support for kernel support with XZ-compression
- Added functionality for unpacking ramdisk compressed LZMA for Android Boot Image format
- modified packing algorithm in LZMA (for greater similarity when repacking original data)
more about the changes in this version, the logs of the utility
AndImgTool version 1.1.2 Updated: 06/12/2014Intermediate version 1.1.2 with implemented processing of blocks with UBOOT-wrapper for Android Boot Image format and description of this wrapper for ramdisk and kernel blocks, examples and logs for unpacking such images here
AndImgTool version 1.1.1AndImgTool_1_1_1.rar(115.14 KB)
Updated: 05/20/2014more about the changes in this version, the logs of the utility
AndImgTool version 1.1.0AndImgTool_1_1_0.rar(115.38 KB)
Updated: 05/16/2014more about the changes in this version, the logs of the utility
AndImgTool version 1.0.0AndImgTool_1_0_0.rar(109.14 KB)
First version
04/24/2014 UPDATED In connection with testing, new versions are laid out in topic posts, while the current version of the utility is 1.0.8, the zImage reassembly is being tested (relevant for UBOOT-OMAP boot images)

Try and unsubscribe about the results, if everything was successfully unpacked and assembled into the working version write the manufacturer and model of the device (add to the list of tested devices), if the utility did not cope with the image, then attach the problem image to all of the above will be more than 20 megabytes).

Imgxtractor - the main utility for unpacking images of file systems such as system, userdata, cache, secro (the extension can be any, for example img or ext4).
The following file system formats are supported:EXT2 \ EXT3 \ EXT4 \ YAFFS2 \ CRAMFS , image structure formats (wrappers) SPARSE \ SIN (1, 2 and 3 versions) \ MOTO , it is possible to convert an image of the file system format EXT4 from a SIN or SPARSE wrapper directly to EXT4, output information about the superblock for images of file systems is implemented, this utility will continue to develop.

ImgExtractor version 1.3.7 Updated: 02/13/2015 release and details here
- added support for unpacking SPARSE-Marvell images for MOTO
- fixed utility crash when unpacking images containing files with "?"
- added identification of UBIFS format and MOTO wrappers inside SPARSE format
- Added image conversion from EXT3 \ EXT4 to SPARSE with splitting into smaller files

Older versions and usage example

ImgExtractor version 1.3.6release and details here
07.08.2014:
- Added image conversion from EXT4 to SPARSE EXT4
- added the -l option (displaying a list of files and folders with their attributes, similar to the output of the ls utility)
- when forming an attribute file, for symlinks it is written the name of the file to which the link is directed, this field is ignored when used in the assembly (-A mode<fix_stats_filename>)
- fixed error when converting SPARSE EXT to EXT with a block size of 1024 bytes (it is strange that no one came across this before or all SPARSE EXT have a block size of 4096 bytes)
ImgExtractor version 1.3.5ImgExtractor_1_3_5.rar(75.46 KB)
06.06.2014:
- added the formation of a file with UNIX-attributes when unpacking an image of file systems,more and an example here
- fixed unpacking and displaying information on the superblock for images of file systems of the EXT2 format
- fixed unpacking under Windows XP when dragging an image to the utility (previously, the unpacked folder was created on the path "C: \ Documents and Settings \<Username>")
ImgExtractor version 1.3.4ImgExtractor_1_3_4.rar(75.59 KB)
02/24/2014 - Added support for the format of the system.img image structure for Moto G motor scooter (initial MOTO signature)
- Fixed unpacking of the YAFFS2 format in terms of creating empty files (having a zero size), previously similar files were ignored
ImgExtractor version 1.3.2ImgExtractor_1_3_2.rar(75.32 KB)
02/17/2014 - Added support for the format of the system.img image structure for Moto X Motorola (initial MOTO signature), added support for unpacking the YAFFS2 format, whose images have a block size of 4096 bytes
ImgExtractor version 1.3.1ImgExtractor_1_3_1.rar(75.56 KB)
12/26/2013 - Added support for SIN version 2 format, added conversion of EXT4 file system images from SIN format (version 1 and 2) to EXT4, added output of information on the superblock of images of file systems inside SIN \ SPARSE \ EXT3 \ EXT4 formats (new key-s ) screenshots of innovations here [/ color]
ImgExtractor version 1.3.0ImgExtractor_1_3_0.rar(70.56 KB)
11/15/2013 - Added support for SIN version 1 and CRAMFS formats, added recognition of the EXT4 \ EXT3 format (the message is displayed when unpacking)
ImgExtractor version 1.2.1ImgExtractor_v1_2_1.rar(62.79 KB)
- Added support for processing large image sizes, optimized code and reduced utility size.
ImgExtractor version 1.2ImgExtractor_v1_2.rar(184.28 KB)
- Added support for SIN version 3 format
ImgExtractor version 1.1ImgExtractor_V1_1.rar(175.56 KB)
- Added support for YAFFS2 format

Usage example

This is a completely console application, use for unpacking is similar to the example of working with the Ext4Extractor utility given below. If you simply and briefly unpack the firmware archive (to test the format of the SIN version 3, use the C6603_10.3.A.0.423_1270-1410_Rus.FTF firmware), copy the unpacked ImgExtractor to the unpacked folder and drag the required images onto the unpacker like on screenshots, as a result, unpacked images will appear in this folder either as a file (* .ELF) or as a folder with the image name and the underscore symbol at the end.

Screen unpacking system.sin

Screen unpacking kernel.sin

Ext4Extractor version 1.5.2 Ext4Extractor_V1_5_2.rar (174.8 KB)
- the first version of the unpacker, useful for unpacking images of the type system, userdata, cache, secro (the extension can be any, for example img or ext4), unpacks the formatsEXT2 \ Instructions for unpacking system.img without using a computer, directly on your Android deviceEXT3 \ EXT4 \ SPARSE
A small description of use(wrote at the request of the owners of Samsung)

xImgTool - utility for unpacking / packing boot images (IMG, BIN) and containers (INB, SZB, QSB) for devices based on x86 Android Platform (Lenovo K900, Ramos i9, Asus ZenFone 4,5,6, ZTE Geek)

xImgTool version 1.3.32 xImgTool_1_3_32.rar (40.86 KB)
UPDATED: 11/06/2014
- support for new bootstub block size
- saving new attributes in a block of sizes
- when unpacking the QSB container, the parts involved in the merging into one file are saved in a separate folder in its original form (especially for system and userdata images)

Older versions

xImgTool version 1.3.31 17.10.2014 - added processing of new signature block, details here
xImgTool version 1.3.25 30.01.2014 test version 1.3.25, added support for QSB container
xImgTool version 1.2.18 xImgTool_1_2_18.rar (28.58 KB)
12.20.2013 - improved support for container images (INB, SZB), unpacking the container into a folder and reassembling the container from the contents of the folder, the assembly is based on the file container.cfg (more here)
xImgTool version 1.2.6 xImgTool_1_2_6.rar (28.06 KB)
12/10/2013 - added support for container images (INB, SZB), unpacking the container into a folder and assembling the container from the contents of the folder, the assembly is based on the file container.cfg (more here)
- Added additional processing of the second composite block IFWI, which contains inside two blocks with FIP Header (information about the versions of the firmware modules)
xImgTool version 1.1.1 xImgTool.rar (17.81 KB)
11/22/2013 - added support for unpacking LOGO and IFWI images into blocks used in the MFT flashing process (xFSTK)
xImgTool version 1.0.27 The first version of the utility (version 1.0.27)
Implemented unpacking / packing of images such as boot.bin, pos.bin, droidboot.img, recovery.img, fastboot.img, kboot.bin - Android x86 images may or may not have an OSIP header and signature block inside, as well There are options with several images (data areas) within a single file. Implemented accounting for new sizes of composite blocks (bzimage and initrd), recalculation of the OSIP header checksum and calculation of the SHA-256 hash for the signed data area.

sparse2img - The CYGWIN utility for converting SPARSE images into regular IMGs is based on simg2img, but the main difference from the original is the ability to roll SPARSE onto an already existing IMG image, this is relevant when converting MOTO G system images, which are divided into several parts. The archive includes the necessary for the GYGWIN DLL, and also added a ConvertMotoG.bat batch file - to facilitate the conversion of the system image from MOTO G, consisting of several parts of the system.img_sparsechunk type. *
Utility for unpacking boot.img tablets with ATM7029 processor (Ainol)(authoralexxxx82 )
Utility for unpacking and packing boot.img and recovery.img for tablets based on the Actions ATM7029 / 7025/7039 processor(authorlione999 )
Unpacker system.new.dat.br.

Kitchen

Due to the fact that the main functionality of the kitchen moved to a single utilityAndImgTool I do not require any additional CYGWIN DLL for my work, I strongly recommend using it for working with boot images AndImgTool (for images of file systems there is a single utility Imgxtractor ), since the kitchen reassembly is no longer planned.

My kitchen version for unpacking entire firmware under Rockchip, MTK and their contents. Initially I made this modification for myself - for the convenience of pulling out system files from different firmware, the original versionhere.

05/17/2014 UPDATEDReassembled version of genext2fs for small RAM
02.24.2014 UPDATED
- Updated ImgExtractor utility (current version 1.3.4), used for unpacking system.img in EXT2 \ EXT3 \ EXT4 \ SPARSE \ YAFFS2 \ CRAMFS formats
- Updated genext2fs CYGWIN utility used to build images in EXT2 \ EXT3 \ EXT4 format (main fix - the old version did not allow to collect images larger than 671087616 bytesmore here), also added a few more changes,about which I will unsubscribe here.
- Added CYGWIN-utility sparse2img for converting SPARSE images into regular IMGs, compiled on the basis of simg2img, but the main difference from the original is the ability of SPARSE to roll over an already existing IMG image, which is relevant when converting system images from MOTO G, which are broken down into several parts.More here.
- Added logging of image assembly EXT3 \ EXT4 (log.txt file is created for the active project)
- Added scripts (BAT files in the folder RKwinToolsMod_v2_8 \ Scripts \): ConvertMotoG.bat - to facilitate the conversion of the system from MOTO G and CreateFSimage.bat - to facilitate the assembly of any image in EXT3 \ EXT4 (was previously posted here)
RKwinToolsMod version 2.8 RKwinToolsMod_v2_8.rar (6.43 MB)

Older Versions and Kitchen Information

RKwinToolsMod version 2.7 RKwinToolsMod_v2_7.rar (6.38 MB)

02/13/2014 UPDATED
- Updated ImgExtractor utility (current version 1.3.1), used to unpack system.img in EXT2 \ EXT3 \ EXT4 \ SPARSE \ YAFFS2 \ CRAMFS formats
- Fixed a problem with the rights (owner and groups) when building images in the YAFFS2 format (you can read about the problems found and their solutionhereandhere)
RKwinToolsMod version 2.6 RKwinToolsMod_v2_6.rar (6.38 MB)

12/01/2013 UPDATED
- Added support for building system.img in EXT4 format (new menu item)
- Updated ImgExtractor utility (current version 1.3.0), used to decompress system.img in EXT2 \ EXT3 \ EXT4 \ SPARSE \ YAFFS2 formats
- Added the introduction of ROOT for Android 4.2.x (a new menu item, for Android 4.1.x, a separate menu item, based on previous data), the su binary is searched in the \ xbin and \ bin folders
- Added information about the system.img image (new menu item) - the system.info file is formed with information from the superblock, full information is still possible only for images in the EXT2 \ EXT3 \ EXT4 format, an error in the system.info will be recorded for the SPARSE format (in this case, if you still want to get information about the superblock, then you can convert SPARSE to EXT4 (menu item 7, the resulting system.img size will be noticeably larger), replace the original system.img in Unpack \ Firmware \ Image \ with the resulting and re-request information.
- The method of forming the system image has been slightly modified - now after creating, converting and checking the image, a request appears to confirm the procedure for reducing the image size (RESIZE), it is simply not always RESIZE that is appropriate - the image is collected with a minimum excess and spend time reassembling, winning about 10 megabytes frivolous. But the decision remains with the user.

Request for RESIZE

RKwinToolsMod version 2.5 RKwinToolsMod_v2_5.rar (6.38 MB)

RKwinToolsMod version 2.4 RKwinToolsMod_v2_4.rar (5.83 MB)

What can be useful for RKwinToolsMod

- to unpack the firmware file (RKFW format file (* .img) or archive of the form * .tar (rar), the latter is relevant for example for Samsung devices)
- for unpacking the contents of the firmware (system, kernel, recovery, boot images)
- to build images from unpacked content (system, kernel, recovery, boot images)
- to build a full firmware file format RKFW (* .img)

Appearance of the program

I warn you - the names of firmware and images should consist of Latin letters, numbers and underscores.
A small instruction for using the kitchen as an example of disassembling and assembling the firmware 3Q_RC9724C_20121102.img and its contents for the 3Q tablet (under Rockchip)RKwinToolsMod_readme.pdf(975.45 KB)

Try, unsubscribe about the results, if the unpacker did not cope with the system image, then do not be lazy to leave a link to this problematic system in this thread, pre-packed into the archive. If there is an error in the kitchen, then screenshots and a detailed description of the actions that caused the error or incorrect operation of the kitchen are welcome.

There is no curator in the subject. If there is a user in the subject who wants to become a Curator and the correspondingRequirements for candidates, he can apply in the topicI want to be curator(after having studied the topic header and all materials for curators).
Prior to the appointment of the curator, on filling caps, please contactmoderatorssection through a buttonunder the messages to which you want to add links.

Post has been editedvaalf - 27.09.18, 13:17

Reason for editing: Collection of scripts for working with images

[And_pda]

[email protected], 11:03

Your reassembled recovery was done without problems. I repent, I packed ramdisk in * .cpio.gz with scripts for OS prohibited in this topic. I don’t remember exactly what it’s called, I did it on a working computer, everything remained in it (on Monday I can say). Did you collect via cpio.exe from this topic?

In this thread, nothing is FORBIDDEN :-) On the contrary, sometimes it is useful to see how it should be on Linux or Android itself, so that I can understand what to achieve on Windows, I also use ubuntu and have nothing against Linux, but I want to do the processing strictly under WINDOWS .

Ramdisk utility mkbootfs.exe is going to, I advise you to immediately download the kitchen from the header, there in the RKwinToolsMod_v2_4 \ Cygwin \ folder there will be a lot of useful utilities for WINDOWS lying, cpio and gzip are also taken from there.

Now, about your ramdisk - if the reassembled version is loaded, then this is good - you can try to make changes to the unpacked data, add some files, change init.rc - Lenovo K900 users should have thoughts on this, but I’m worried about a significant increase in ramdisk size which will result in an increase in the file recovery.img.

[prog2]

Apparently I somehow collect not so. I inserted a modified ramdisk into the recovery, it was not possible to flash it. Attached ramdisk. Can you insert it in rekoveri? Thank you in advance.

Attached files

ramdisk.zip(3.25 MB)
recovery.img(8.27 MB)

[And_pda]

[email protected], 13:43

Attached ramdisk. Can you insert it in rekoveri?

Inserted, check - the most interesting result.
recovery.img(8.46 MB)

[prog2]

[email protected], 15:42

Inserted, check - the most interesting result.

Everything was done successfully (although it does not start, but it does not need to be cut there), it means that I have something with my hands. Please spend not a great educational program.

Post has been editedprog2 - 07.09.13, 17:22

[alexseyuh]

And more educational system.sin please.
All Sony Xperia branches will be grateful.

[prog2]

[email protected], 18:28

And more educational system.sin

I looked at the Sony branch on xda, there seems to be a sin2img program. And img is already standard means (from the header).

[alexseyuh]

prog2,
I do not need to disassemble, with this I perfectly cope myself.
I need to collect back in sin.
And this is already a problem, as I know as yet no one has gathered.

[And_pda]

[email protected], 18:28

And more educational system.sin please.
All Sony Xperia branches will be grateful.

Educational program on the format of the SIN 3 version will be required, he himself googled for a long time on this topic and generally no information, even surprisingly, found only crumbs about the SIN 1 and 2 versions, the new third as banned. And about the utility sin2img and others like it - they are all under the old SIN revisions - the system.sin that I threw offalexseyuhThey do not take it, only the flashlight unpacks it. But comparing WinHex with different * .SIN (besides the system, cache and userdata are also suitable), we managed to find patterns and understand the principle of proper decompression. So there will soon be an updated version of ImgExtractor with support for the SIN 3 format version. Regarding the reverse packing in the SIN - this is unrealistic - for correct packing, you need a Sony certificate, with which it seems to hash the data blocks so that you can check their validity.

[alexseyuh]

And_pda,
As for the certificate, this is for sure, there is a program for firmware under Windows.
It downloads the firmware in parts without permissions and designations, and then assembles it into tft.
Here you have to dig there.
Sony Xperia S / SL - Firmware (Android 2.3.7, Android 4.xx) (Post # 20154973)
If the problem is resolved, it will be a masterpiece, as the above said has no analogues anywhere !!

Post has been editedalexseyuh - 08.09.13, 13:23

[And_pda]

[email protected], 17:26

Everything was done successfully (although it does not start, but it does not need to be cut there), it means that I have something with my hands. Please spend not a great educational program.

1 step.
We collect from the unpacked ramdisk initrd.cpio.gz To do this, copy the mkbootfs and minigzip utilities to the folder at the ramdisk folder level (in principle, gzip should come up, in another case I pack it and there was no difference) and the necessary * .dll (see the screen ).
You need to run this code

mkbootfs ramdisk | minigzip> initrd.cpio.gz

After this, the file will appear in the folder initrd.cpio.gz - open it in WinHex

2 step.
Determine the size of the resulting initrd.cpio.gz - select the entire file as a block (you can immediately press Shift + Ctrl + End) and look at the bottom of the Size field for its size - I got 33A18F, remember it. Then copy the block by selecting the main menu item Edit \ Copy Block \ Hex Values

You open the recovery.img file and look for the GZIP 1F8B0800 signature from the bottom, it will still be at offset 0x53B1A3 (but we’ll see that the cursor is in the right place) and paste the Copy \ Clipboard data \ Paste menu item from the buffer (you can select and Write - in this case, the old data will be reset immediately, but here you need to understand with a larger block size, you will overwrite a smaller one or vice versa, then the remnants of the old block will need to be cleaned up)

We just inserted a new block - now we have two ramdisks and, accordingly, one more signature 1F8B0800 was added, so again we search our old block by the signature, select it to the end of the file and delete it by choosing the main menu Edit \ Cut or Ctrl + X (check screen)

3 step. Important and mathematical.
The size of the original recovery.img was a multiple of the block size of 512 bytes. This means that if you divide the file size in bytes by 512 and then multiply the resulting value by 512, you should again get the original file size and not a byte more and not a byte less, i.e. 8675328/512 = 16944 and 16944 * 512 = 8675328
Now let's check what we get (we can see where the file size is shown on the screenshot), the file size is 8868655 bytes, we check:
8868655/512 = 17321 and 17321 * 512 = 8868352 Problem ... So you need to add empty bytes 0xFF so that the size would be a multiple of 512
Calculate how many bytes are needed, 8868655>8868352, it means that in order for our file to fit in blocks, you need to add another block of 512 bytes, then we get the file size in (17321 + 1) * 512 = 8868864, now 8868864 - 8868655 = 209 - this is the number of bytes to insert. We get to the end of our file and select the Edit \ Paste Zero Bytes main menu item, enter 209 in the field and click Ok (see the screen)

All of our file size is correct and a multiple of 512. For even greater compatibility, do we replace zero bytes with 0xFF? To do this, select the menu item of the main menu Edit \ Fill Block, in the Fill with hex values ​​field, write FF and click Ok (check with the screenshot)

4 step.
Now it remains only to correct the areas in which the ramdisk size and the entire recovery.img file are stored. The first lies at offset 0x7E4 there is the old value 31AE30, our new ramdisk size is 33A18F (see step 1), we expand this value and we get 8FA133 and prescribe these bytes by offset 0x7E4

If I understood correctly, the size of the entire recovery.img file is indicated in blocks minus one and lies at offset 0x30, in the original file there is 0x2F42, after rotation we get 0x422F and if translated from hexadecimal to decimal, we get 16943, add 1 and get the value that was discussed in step 3 about the multiplicity of the file size block 512 bytes.
As a result, our modified recovery has 17322 blocks, subtracts 1, translates from decimal to hexadecimal, and we get 0x43A9, expand and prescribe A943 at offset 0x30

That's it, save the modified recovery.img and try to flash it.

Of course, I would like to check step 4 in practice, for example, do not perform it and check the firmware - whether it works or not, the second point is to change the size of the ramdisk at offset 0x7E4, and do not touch the size of the entire file at offset 0x30 and vice versa. This is the only way to calculate whether step 4 is needed or not with such a modification.

[prog2]

Fine! Thanks for the detailed instructions! Everything worked out! Now I'm experimenting, without a 3 step, it definitely does not work. Now I try to do without the 4th. Thanks again.

Tried it like that. Without the 4th step is not enough, but it is not difficult!

Post has been editedprog2 - 09.09.13, 21:14

[prog2]

I inserted CWM from donors into the ramdisk, the body is stitched without errors, but it does not enter the recovery mode. It seems to do everything according to the instructions.

[VEK_UA]

prog2 @ 09/06/2013, 17:56

I understand, this is not a stock boot.img, maybe cwm something namutil?

The firmware is just stock. Replaced only recovery on CWM using adb.

[VEK_UA]

[email protected], 11:12

and did not see any difference in comparison with the original.

There is a slight difference all the time - we look at the address 0077B8AD and further (on the first screenshot), and compare it with the address 0003BE39 and further (from the second screenshot). But in my case it is already important. Utility fromalexxxx82Successfully passed the pre-validation check - the image of the file after unpacking and back packing was matched to a bit, and when changing one letter in the file I need, the changes in the output image are minimal. Thank you all for your help and participation.

[And_pda]

[email protected], 10:21

Inserted CWM from donors into the ramdisk, the body is stitched without errors, but does not enter the recovery mode

If the body is loaded with the reassembled stock version of the ramdisk, then I would advise gradually to step on, first to add a few heavy files to the stock option - to increase the ramdisk size and the recovery.img image as a whole, BUT do not delete anything and do not change it in init.rc and * .fstab. If this option is loaded normally, then the modification method is appropriate and you can already specifically modify it under CWM. The archive that you attached to the assembly is somehow strange - the modules have been changed, the system \ has become empty, although in the original version there are bin, lib, xbin subfolders, and in init.rc at the on init stage it is written

# adb shell needs / system / bin / sh
symlink / system / bin / mksh / system / bin / sh

a symlink is created for mksh, but you don’t have it ...
then the service starts

service watchdogd / sbin / ia_watchdogd
user root
oneshot

ia_watchdogd doesn't either, but in the original it is all there ...
I didn’t write about 4 steps - it is needed for correct firmware or multiplicity is sufficient, although I admit that multiplicity is enough for firmware, but for the operability of the image, step 4 is probably needed.

[And_pda]

VEK_UA @ 09.09.2013, 14:18

There is a slight difference all the time - we look at the address 0077B8AD and further (on the first screenshot), and compare with the address 0003BE39 and further (from the second screenshot)

Everything is correct, I created dummies like dev \ acta myself, and I didn’t transfer attributes from the unpacked links, but I didn’t attach the screen to this, but to confirm that these links were lime - there should have been just dummies, except for the name and attributes nothing more They do not have any content.

I am glad that you did it all and the utility fromalexxxx82it helped - for this the topic was created - to collect as many useful utilities for image processing under Windows as possible.

[prog2]

And_pda @ 09/09/2013, 10:03

That archive that you attached to build some strange

Quite right, this was just an experiment for the sake of, you collected the recovery, my phone successfully swallowed this image. There in the ramdisk folder sbin from another device, and init.rc stock, that's the inconsistency.
Now the phone is flashing the recovery with any ramdisk inside and it does not depend on the size of the recovery itself. The fact is that there are CWM donors (the same architecture and almost also iron), I have already tried all the options, I’ve changed init.rc, ueventd.rc, default.prop, recovery.fstab, left unchanged. I'll try to add a couple of files to the stock ramdisk unchanged. But I am more than confident that such a recovery will be sewn up, but it will not enter the mode. Although ... need to check.

Post has been editedprog2 - 09.09.13, 21:47

[prog2]

Added to the ramdisk file in 1.5mb. Accordingly, nothing deleted and no rules. The body was sewn, it does not enter into the recovery mode. Everything is not so simple. Can there be any dependencies with a bootloader, kernel, or droidboot? Here's another thing that turned out, before that I did not check for some reason. So if you disassemble and assemble without changes, it is stitched into the body without errors, but it also does not enter into the recovery. File before disassembly and after bytes to bytes. That's it!

Post has been editedprog2 - 09.09.13, 22:49

[prog2]

In the folder with the firmware is the IFWI.bin file. It contains references to Image verifying and Hash verifying.

[And_pda]

[email protected], 23:40

So if you disassemble and assemble without changes, it is stitched into the body without errors, but it also does not enter into the recovery. File before disassembly and after bytes to bytes. That's it!

And does the stock version at least enter the recovery mode? How do you enter the recovery mode at all? buttons or "adb reboot recovery"? If the file is after rebuilding byte-by-byte, but there is no entry into the recovery mode, the problem is not in the image. I had a similar situation - the image that was modified under CWM was not stitched on the child’s tablet, or was stitched, but did not enter the recovery mode, but I do remember that there was some kind of rake - but with the flash_image utility from the body itself, everything turned out well. Are you flashing the recovery option in the same way as the modified version or completely filling the entire firmware for recovery?

[email protected], 00:32

In the folder with the firmware is the IFWI.bin file. It contains references to Image verifying and Hash verifying.

If the image is byte-by-byte with the original one, then the verification should go through any. The problem in the other means that either the image gets to the wrong place on the body or some other changes occur during the firmware and for example the file attributes have values ​​(creation date, modification, rights) - after all, the reassembled image will differ by these attributes from the original - maybe this Look at the side too - for example, change the modification date of a stock copy, fill it in and try to enter the recovery mode.

Post has been editedAnd_pda - 10.09.13, 12:09

Reason for editing: added