Please I want a full ROM for HTC Desire 310 dual sim and contains the following files - HTC Desire 310 Questions & Answers

Please, I want a full ROM for HTC Desire 310 and contains the following files : EBR1 - EBR2 - MBR - blinkfeed - expdb - misc - pro_info - protect_f - protect_s - resv - seccfg .ยก Or have a full ROM format * .bin * please help

Related

[TUT] SRPX compressed XIP section workout (like Asus, HP or Etens)

As I've heard some people have problems with working with XIP sections of some ROMs... as for example Asus P525 or other devices, here's a little tiny tutorial about this issue. What's the problem with them? It's their XIP sections are compressed with SRPX algorithm.
In some Asus kitchens in the ROM directory you have a ROM.TPL file. How to use it?
1. Get the OSNBTool from the attachement (it's a fantastic tool from Weisun of PDAclan.com).
2. Do:
Code:
>osnbtool -d rom.tpl 1 xip.bin
OS ROM Partition Tool V1.48 By Weisun :> PDAclan.com
Sector size : 0x00000200
OS IMAGE found.
Partitions infomation:
**************************************
Part-0 type: BOOT SECTION image
Part-1 type: XIP RAM Image
Part-2 type: IMGFS file system
**************************************
Signature: SRPX
CompressVersion: 5
Uncompressed size: 2E0000
Deompress processing...
Successfully decompressed to xip.bin
3. Run XIPPort and click "dump xip.bin".
4. Do your work with a XIP section.
5. After you're finished, issue "realloc P" and "build xip_out.bin" in XIPPort.
6. Do:
Code:
>osnbtool -c rom.tpl 1 xip_out.bin
OS ROM Partition Tool V1.48 By Weisun :> PDAclan.com
Sector size : 0x00000200
OS IMAGE found.
Partitions infomation:
**************************************
Part-0 type: BOOT SECTION image
Part-1 type: XIP RAM Image
Part-2 type: IMGFS file system
**************************************
Source OS image:
Signature: SRPX
CompressVersion: 5
Uncompressed size: 2E0000
Source Part-1 Size: 1AC400
--------------------------------------
Compress processing...
NEW Uncompressed size: 2D5000
NEW Compressed size: 1A6BF6
New Part Size: 1A71E6
Successfully compressed xip_out.bin into rom.tpl.NEW
7. You're done!
It turns out that a dumprom.exe and buildxip.exe tools handle those XIPs really well, too - and even better, as they do better reallocation of modules.
So, it can go as this:
Code:
>dumprom rom.tpl
IMGFS guidBootSignature: F8 AC 2C 9D E3 D4 2B 4D BD 30 91 6E D8 4F 31 DC
dwFSVersion: 00000001
dwSectorsPerHeaderBlock: 00000001
dwRunsPerFileHeader: 00000001
dwBytesPerHeader: 00000034
dwChunksPerSector: 00000008
dwFirstHeaderBlockOffset: 00000200
dwDataBlockSize: 00001000
szCompressionType: LZX
dwFreeSectorCount: 0000001E
dwHiddenSectorCount: 00000100
dwUpdateModeFlag: 00000000
Address: 00000200, dwBlockSignature: 2F5314CE
dwNextHeaderBlock: 00000000 (size: FFFFFE00)
Header type: FFFFFFFF, Addr: 00000208
Empty header
Header type: FFFFFFFF, Addr: 0000023C
Empty header
Header type: FFFFFFFF, Addr: 00000270
Empty header
Header type: FFFFFFFF, Addr: 000002A4
Empty header
Header type: FFFFFFFF, Addr: 000002D8
Empty header
Header type: FFFFFFFF, Addr: 0000030C
Empty header
Header type: FFFFFFFF, Addr: 00000340
Empty header
Header type: FFFFFFFF, Addr: 00000374
Empty header
Header type: FFFFFFFF, Addr: 000003A8
Empty header
Now you have new files: boot.bin, msflsh.bin and romhdr.bin, and a new folder XIP. Edit your XIP folder as you want.
Now, in ..\temp\dump folder put your .VM and .ROM folders and issue:
Code:
>buildxip
BUILDXIP 0.54 Copyright (c) 2007-2008 bepe 30 Jan 2008
Slot 0 Boundary: 0x01fa0000
Slot 1 Boundary: 0x03e18000
RAMStart: 0x88868000
RAMFree: 0x888c6000 - 0x8c000000 L0373a000
KernelFlags: 0x00000000
FSRamPercent: 0x00000004
Done!
In the end put your new created out.bin file into your tpl file:
Code:
>osnbtool -c rom.tpl 1 out.bin
OS ROM Partition Tool V1.48 By Weisun :> PDAclan.com
Sector size : 0x00000200
Extra data bytes : 0x00000000
OS IMAGE found.
Partitions infomation:
**************************************
Part-0 type: BOOT SECTION image
Part-1 type: XIP RAM Image
Part-2 type: IMGFS file system
**************************************
Source OS image:
Signature: SRPX
CompressVersion: 5
Uncompressed size: 2E0000
Source Part-1 Size: 1AC400
--------------------------------------
Compress processing...
New part size larger than old part in source OS image!
Rebuilding partition structure...
NEW Uncompressed size: 2E7000
NEW Compressed size: 1B1664
New Part Size: 1B1C78
Successfully compressed out.bin into rom.tpl.NEW
and you're done!
Hello utak3r.
This info is really important for me as I have an Eten device. Although, I've tried several times to build a XIP using "buildxip" (with or without -b flag - I don't know exactly what it does) but my rom doesn't boot.
I didn't even tried to change anything in XIP folder. Only dumped the XIP using "dumprom" and then build again to test it. Was I supposed to do something in the middle? Any idea?
bgcngm said:
with or without -b flag - I don't know exactly what it does
Click to expand...
Click to collapse
This flag tells if it should take another, external boot.rgu file, or the included one. So, you should do it without this flag.
bgcngm said:
but my rom doesn't boot.
Click to expand...
Click to collapse
The problem may be not in the building it, but in inserting it back. Some devices don't like changing the partition's size, for instance...
Check, what was the original xip.bin size and try to fill your new one with 0xFFs to this size - maybe it will help...
Another thing: give here full outputs from all the steps.
utak3r said:
The problem may be not in the building it, but in inserting it back. Some devices don't like changing the partition's size, for instance...
Click to expand...
Click to collapse
I already thought that the problem was XIP insertion, but then I found XIPKitchen.
With a XIP created by XIPKitchen, I can successfully create a bootable rom, even with a different XIP partition size. I'm happy because those XIP's are working, however XIPKitchen doesn't integrates nicely in a rom kitchen. The user has to manually input the files and select some options in the program and I wanted to build the new XIP silently which is what buildxip does.
Do you know what could be the problem? I might be missing something... like rellocating the modules... But as I said before, I tried to build the XIP without touching it, simply by dumping and then rebuilding it. In that case there was no need to rellocate the modules, right?
utak3r, don't you know what could be the problem?
Hi bro
In some Asus kitchens in the ROM directory you have a ROM.TPL file
Click to expand...
Click to collapse
use tool NB0 KITCHEN mrtoto which extracting&inserting partition xip in file out.bin in to NewROM.tpl
extracting out.bin use XipKitchen or buildrom bepe,ren xip_out_new.bin to out.bin ,move to directory Rom.tpl end push button "Build Template" in NB0 KITCHEN mrtoto
THANKS A LOT !!
Awesome tool, had troubles extracting one of the xip files since a LONG time, this just did the trick and it's nifty features like putting romhdr, o32, e32 headers nicely were also helpful.

Is it possbale to unlock EXTROM space?

It seems that there is about 100 MB Missing... I just guess is EXTROM
It could very easy to test that - different EXTROM but same Flash.bin.
The total free ROM space unchanged, even your EXTROM just used a few MB
If the EXTROM could be used, then it could be great help for cooking
The files may relate to FLASH.Header and partition.mbn. could anyone have a good try?
But...
pdocread.exe -l
411.25M (0x19b40000) DSK1:
| 1.87M (0x1df000) Part00 BOOT SECTION image
| 5.00M (0x500000) Part01 XIP RAM Image
| 84.25M (0x5440000) Part02 IMGFS file system
| 320.13M (0x14020000) Part03 legit DOS partition
handle#1 ef638fc6 320.13M (0x14020000)
handle#2 ef6adea6 84.25M (0x5440000)
handle#3 2f6ade82 5.00M (0x500000)
handle#4 4f6ade3a 1.87M (0x1df000)
Total is just 411.25, about 100MB (0x064C0000) seems missing....
For Part02, I could know is imgfs, and Part00 seems EXTROM, but where is disappear 100M?
partition table:
Code:
Partition-Info :
------------------
MIBIB
---------------------------------------------------------
Page: 0x6
Size: 0x4
Address: 0x000C0000 - 0x00140000
Block: 0x00000180 - 0x00000280
Flash: 0xFEFFFFFF
SIM_SECURE
---------------------------------------------------------
Page: 0x4
Size: 0x2
Address: 0x00080000 - 0x000C0000
Block: 0x00000100 - 0x00000180
Flash: 0xFEFFFFFF
FSBL
---------------------------------------------------------
Page: 0x180
Size: 0x1E
Address: 0x03000000 - 0x033C0000
Block: 0x00006000 - 0x00006780
Flash: 0xFFFFFFFF
OSBL
---------------------------------------------------------
Page: 0x180
Size: 0x1E
Address: 0x03000000 - 0x033C0000
Block: 0x00006000 - 0x00006780
Flash: 0xFFFFFFFF
AMSS
---------------------------------------------------------
Page: 0x4650
Size: 0x708
Address: 0x8CA00000 - 0x9AB00000
Block: 0x00119400 - 0x00135600
Flash: 0xFFFFFFFF
EFS2
---------------------------------------------------------
Page: 0x1F40
Size: 0xC8
Address: 0x3E800000 - 0x40100000
Block: 0x0007D000 - 0x00080200
Flash: 0xFFFFFF01
DSP1
---------------------------------------------------------
Page: 0x3E80
Size: 0x258
Address: 0x7D000000 - 0x81B00000
Block: 0x000FA000 - 0x00103600
Flash: 0xFFFFFFFF
FOTA
---------------------------------------------------------
Page: 0x80
Size: 0x64
Address: 0x01000000 - 0x01C80000
Block: 0x00002000 - 0x00003900
Flash: 0xFFFFFFFF
EXTROM
---------------------------------------------------------
Page: 0xC350
Size: 0x7D0
Address: 0x86A00000 - 0x96400000
Block: 0x0010D400 - 0x0012C800
Flash: 0xFFFFFFFF
APPSBL
---------------------------------------------------------
Page: 0x300
Size: 0x32
Address: 0x06000000 - 0x06640000
Block: 0x0000C000 - 0x0000CC80
Flash: 0xFFFFFFFF
APPS
---------------------------------------------------------
Page: 0x80
Size: 0xC
Address: 0x01000000 - 0x01180000
Block: 0x00002000 - 0x00002300
Flash: 0xFFFFFFFF
EFS2APPS
---------------------------------------------------------
Page: 0xFFFFFFFF
Size: 0xFFFF
Address: 0xFFFE0000 - 0xFFFC0000
Block: 0x001FFFC0 - 0x001FFF80
Flash: 0xFFFF02FF
good investigation ! I hope you can find a Way to reduce the allocated space, sadly I can't help you with this...keep the research !
Arto said:
good investigation ! I hope you can find a Way to reduce the allocated space, sadly I can't help you with this...keep the research !
Click to expand...
Click to collapse
Thank you also
The difficult problem is that, I'm not much understanding NAND Flash...
But, it seems that, after flashing ROM with new partition.mbn, the size of ExtRom could be changed.
At this moment, I'm not sure that the Hex files should be also changed or not ...
Code:
EXTROM
---------------------------------------------------------
[COLOR="Red"] Page: 0xC350
Size: 0x7D0[/COLOR]
Address: 0x86A00000 - 0x96400000
Block: 0x0010D400 - 0x0012C800
[COLOR="Red"] Flash: 0xFFFFFFFF[/COLOR]
Form Page (seems like format pagepool), the maximum ExtROM could be 50MB, that's the limit for a cook to modify ExtROM.
Of cause, if we could modify ExtROM size, then we could include more module in to Image
Moreover, including ExtROM, the boot system could used up to 93.674MB
my extrom take 7mb...so if the extrom allocated space can be changed it would be reallocated to application space? Qazer found a way to change page pool size, maybe it can help you on this !
edit, what is NAND flash?
Arto said:
my extrom take 7mb...so if the extrom allocated space can be changed it would be reallocated to application space? Qazer found a way to change page pool size, maybe it can help you on this !
edit, what is NAND flash?
Click to expand...
Click to collapse
After rearranged the partition table, it could be like this:
Code:
offset size
SIM_SECURE 0x4 0x2
MIBIB 0x6 0x4
FOTA 0x80 0x64
APPS 0x80 0xC
FSBL 0x180 0x1E
OSBL 0x180 0x1E
APPSBL 0x300 0x32
EFS2 0x1F40 0xC8
DSP1 0x3E80 0x258
AMSS 0x4650 0x708
EXTROM 0xC350 0x7D0
EFS2APPS 0xFFFFFFFF 0xFFFF
It could be much strange that some 'partitions' are overlapping!
Emmm, I forgot the order flashing these programs (.mbn), however, the ExtROM could be the last one to flash in the phone...
If somebody could tell me the order, then it could be much clear the process
Seems changed size could be OK, but I just wonder that what about ImageFS...
BTW, for term 'NAND flash', just wikipedia it
the best thing we can do is to reallocate this space in a virtual ram driver, and dont use the extrom space anymore. I noticed that the extrom files (cabs,tsk..) are in the windows folder of the device when you explore the windows folder.
So Is there a virtual ram driver or is there a way to do that, we don't need space, we need ram alternative.
anyway, don't know if it is possible to do such a thing on winmo devices...
( a kind of swap space....)
ocman said:
the best thing we can do is to reallocate this space in a virtual ram driver, and dont use the extrom space anymore. I noticed that the extrom files (cabs,tsk..) are in the windows folder of the device when you explore the windows folder.
So Is there a virtual ram driver or is there a way to do that, we don't need space, we need ram alternative.
anyway, don't know if it is possible to do such a thing on winmo devices...
( a kind of swap space....)
Click to expand...
Click to collapse
I think we should hardmod to add more RAM instead of using NAND flash, to avoid damaging it faster
Emmm, at this time I could not be sooooooo brave to flash my only phone
I just only change 0x7D0 (D0 07 00 00) to 0x3E8 (E8 03 00 00)....
If I try to flash with new partition.mbn,the phone turn into FTM Mode
But I just put partition.mbn, extrom.bin and two hex files only to the flash tool...
It sounds like I should put all files in that...
Then, finally these two hex files ENPRG8650.hex and NPRG8650.hex should be also modified.

Copy binary by odin (Samsung SM-G531M android 5.1)

Greetings to all.
I have a Samsung SM-G531M Galaxy Grand Prime. Android 5.1
By mistake delete a system binary (linker) and now the phone does not start. And every time I try to start it in recovery (loop) mode but I have the FRP lock. Only the downlad mode works for me.
Can you copy the binary linker by odin? Ie edit the stock rom and put only the linker (delete all, just leave / system / bin / linker).
If so, I have tried modifying the stock rom, but I can not extract a file from boot.img (file_contexts from the boot.img \ ramdisk) that it is essential to package the new modified system(using program Auto Tool v3.0 x64).
-My system is windows 7.
-CarlivImageKitchen_x64
Your image: boot.img
Create the boot folder.
*Printing information for "boot.img"
*Unpack image utility by carliv @ xda
*Header:
**Magic: ANDROID!
**Magic offset: 0
**Page size: 50331648 (0x03000000)
**Base address: 0x10000000
**Kernel address: 0x10008000
**Kernel size: 6294484 (0x00600bd4)
**Kernel offset: 0x00008000
*>> kernel written to 'boot / boot.img-kernel' (6294484 bytes)
**Ramdisk address: 0x11000000
**Ramdisk size: 1532010 (0x0017606a)
**Ramdisk offset: 0x01000000
*>> ramdisk written to 'boot / boot.img-ramdisk.unknown' (1532010 bytes)
**Second address: 0x10f00000
**Tags address: 0x0001f800
**Tags offset: 0xf001f800
**Dt size: 268435712 (0x10000100)
*>> device_tree written to 'boot / boot.img-dt' (268435712 bytes)
Compression used: unknown
Unpacking the ramdisk ....
The system can not find the specified batch label: unknown
And the ramdisk folder appears empty.
Thanks in advance.

Full RAW flash dump

I have replaced new empty eMMC flash memory in change of previous dead one.
Reason: bootloop, google logo, no boot, no fastboot (no LED blinking), device detected only in Intel DNX fastboot (MOOREFIELD):
Code:
New USB device found, idVendor=8086, idProduct=0a2c, bcdDevice= 0.a0
New USB device strings: Mfr=2, Product=1, SerialNumber=3
Product: MOOREFIELD
Manufacturer: INTEL
Instead of android fastboot mode:
Code:
New USB device found, idVendor=18d1, idProduct=4ee0, bcdDevice=ff.ff
New USB device strings: Mfr=2, Product=3, SerialNumber=4
Product: fugu
Manufacturer: Android
xFSTK Downloader (used files from ZenFone) doesn't work. Player disconnecting during flashing.
Actually I need partitions dumps or full RAW dump.
Code:
Setting interface to EasyJtag2/E-Socket
Setting bus width to 8 Bit
Setting frequence to 42 MHz
EMMC Device Information :
EMMC CID: 110100303038474530006625C95B71F1
EMMC CSD: D05E00320F5903FFFFFFFFEF924000D3
EMMC Manufacture : TOSHIBA , EMMC NAME: 008GE0 , HEX: 303038474530 , S/N: 6625C95B , rev. 0x00
EMMC Manufacture ID: 0x11 , OEM ID: 0x00 , Device Type: BGA (Discrete embedded) , Date: 7/2014
EMMC ROM 1 (Main User Data) Capacity: 7456 MB (0001D2000000)
EMMC ROM 2/3 (Boot Partition 1/2) Capacity: 4096 KB (000000400000)
EMMC RPMB (Replay Protected Memory Block) Capacity: 4096 KB (000000400000) Counter: 716 , Response: Not Clean
EMMC Permanent Write Protection: No
EMMC Temporary Write Protection: No
Extended CSD Information :
Extended CSD rev: 1.7 (MMC 5.0, MMC 5.01)
Boot configuration [PARTITION_CONFIG]: 0x00 , Boot from: no boot
Boot Bus Config: 0x00 , width 1bit
H/W Reset Function [RST_N_FUNCTION]: 0x00, RST_n signal is temporarily disabled
Supported partition features [PARTITIONING_SUPPORT]: 0x07
Device supports partitioning features
Device can have enhanced technological features in partitions and user data area
Device can have extended partitions attribute
Partition Settings [PARTITION_SETTING_COMPLETED]: 0x00
Backup saved: 008GE0_6625C95B_20191117_171608.extcsd
EMMC Init completed.
Warning: Health report is very BAD
Device Life Time Estimation (MLC) [269]: 0x00 Not defined
Device Life Time Estimation (SLC) [268]: 0x0B Exceeded its maximum estimated device life time
Pre EOL information [267]: 0x01 Normal
Scanning soft partitions
GPT header is found and is valid
Partition: boot, [000000005000 - 000001005000], size: 000001000000 (16,0 MB)
Partition: recovery, [000001005000 - 000002005000], size: 000001000000 (16,0 MB)
Partition: fastboot, [000002005000 - 000003005000], size: 000001000000 (16,0 MB)
Partition: factory, [000003005000 - 000003605000], size: 000000600000 (6,00 MB)
Partition: splashscreen, [000003605000 - 000003A05000], size: 000000400000 (4,00 MB)
Partition: panic, [000003A05000 - 000003E05000], size: 000000400000 (4,00 MB)
Partition: misc, [000003E05000 - 000003F05000], size: 000000100000 (1,00 MB)
Partition: temp, [000003F05000 - 000004F05000], size: 000001000000 (16,0 MB)
Partition: cache, [000004F05000 - 000014F05000], size: 000010000000 (256 MB)
Partition: system, [000014F05000 - 000054F05000], size: 000040000000 (1,00 GB)
Partition: userdata, [000054F05000 - 0001D1FFBE00], size: 00017D0F6E00 (5,95 GB)
GPT header successfully parsed
Dump status:
ROM1 - failed !
ROM2/3 (bootloader = ifwi - 164 bytes ?) - ok
RPMB - ok
Partially I can get boot, recovery, fastboot (droidboot), splashscreen, system from official google firmwares.
But more important is factory partition.
Anyway it would be nice to have full RAW dump.
Thanks.

[TOOL][NOT TESTED] BOOT partition repartitioner

I am not responsible for bricked devices, dead SD cards, thermonuclear war, or you getting fired because the alarm app failed. Please do some research if you have any concerns about features included in this ROM before flashing it! YOU are choosing to make these modifications, and if you point the finger at me for messing up your device, I will laugh at you.
FLASHING THIS WILL DELETE /BOOT AND /RECOVERY PARTITION!!
VERY IMPORTANT: YOU WON'T BE ABLE TO FLASH TWRP OR ANY OTHER RECOVERY, AS /RECOVERY WILL BE SHRINKED TO 23 MiB AND TWRP SIZE IS AT LEAST 28 MiB.
this is a repartitioner for /boot partition (to 47 MiB instead of 32 MiB), to make it to work i had to shrink /recovery partition (as it's the nearest partition; /boot is /dev/block/mmcblk0p10 and /recovery is /dev/block/mmcblk0p11), it works in this way:
/tmp/sgdisk $DK --delete 10 -> deletes /boot
/tmp/sgdisk $DK --delete 11 -> deletes /recovery
/tmp/sgdisk $DK --new=10:124928:221184 -> creates /boot again, with Block Size: 124.928 and with Block Count: 96.256
/tmp/sgdisk $DK --new=11:221184:268288 -> creates /recovery again with Block Size: 268.288 and with Block Count: 47.104
to get some infos from stock j6 PIT file i used Pit Magic (https://forum.xda-developers.com/t/...-samsung-pit-creator-editor-analyzer.1916936/)
Stock BOOT Partition:
Code:
----------------------------------------------------------
Entry Memory Address: 0x754
----------------------------------------------------------
Binary Type: 0 (UNKNOWN)
Device Type: 2 (MMC)
Identifier: 10
Attribute: 5 (READ / WRITE)
Update Attribute: 1 (FOTA)
Block Size: 124.928
Block Count: 65.536
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: BOOT
Flash FileName: boot.img
FOTA FileName:
Stock RECOVERY Partition:
Code:
----------------------------------------------------------
Entry Memory Address: 0x7D8
----------------------------------------------------------
Binary Type: 0 (UNKNOWN)
Device Type: 2 (MMC)
Identifier: 11
Attribute: 5 (READ / WRITE)
Update Attribute: 1 (FOTA)
Block Size: 190.464
Block Count: 77.824
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: RECOVERY
Flash FileName: recovery.img
FOTA FileName:
To get these numbers i just did some mathematical proportions:
using a unix blocks to megabytes converter (http://www.unitconversion.org/data-storage/blocks-to-megabytes-conversion.html) i found that 65.536 blocks correspond to 32 MiB.
so i did:
Code:
65.536 : 32 = x : 47
where 65.536 is the block count, 32 are the corrisponding MiB, x is the block count to find to get 47 MiB and 47 are the MiB i wanted to have.
so i just did: (65.536 * 47) / 32 = 96.265 -> corresponding to 47 MiB.
CREDITS: @ProtoDeVNan0 for his EPR

Categories

Resources