XIP Visual Kitchen WP 6.5 GENE - P3400 ROM Development
i m trying to build Ervius Visual Kitchen to our gene i got information that Hermes Mobile is same rom structure as gene so i go to harmes forum and done necessary changes to Ervius Visual Kitchen but i m not able to flash
vaibhav,sumit,ramersonw,jyot,helgee,BesFen wakeup buddy
give some time to do different man, you all r doing same thing sine long time, i know we can do it
here is what i done till now
i got info that NBH file format used in gene is same as in the Hermes so why hermes kitchen is not working with gene (with gene XIP,hdr.etc )?
what is OS.nb.playload ?
what is ULDR ?
what is IMGSTART ?
hi guys i have tried this kitchen u need to modify xml file to get the gene settings
but after that it ask for some block size which it takes as defualt 4 and then when u cook the rom with this setting rom get build properly with a single warning erivius called it as time bomb.
but when u put the rom on the device it wont boot i tried many roms but non work with erivius visual kitchen v.9 latest verison might be working
i had put in the thread for this problem but erivius didnt respond...
will definately wake up ..lemme me bak frm vacation...
Pank789 said:
hi guys i have tried this kitchen u need to modify xml file to get the gene settings
but after that it ask for some block size which it takes as defualt 4 and then when u cook the rom with this setting rom get build properly with a single warning erivius called it as time bomb.
but when u put the rom on the device it wont boot i tried many roms but non work with erivius visual kitchen v.9 latest verison might be working
i had put in the thread for this problem but erivius didnt respond...
Click to expand...
Click to collapse
good start here my Solution + Question for this
you r talking about NBHUtil.xml
to all who don't know about NBHUtil.xml
its database file for NBHUtil, so u ask me what is NBHUtil.exe ?, NBHUtil is same like htcrt, htcrt use htcrt_devices.ini file as database and NBHUtil use NBHUtil.xml as database
new NBHUtil's database does not have gene device data base so you need add this entry
Code:
<device name="Gene" chunksize="1024">
<ModelID>GENE***</ModelID>
<CID>11111111</CID>
<Ver>1.00.000.0</Ver>
<Lang>WWE</Lang>
<Item value="0x100">IPL</Item>
<Item value="0x200">SPL</Item>
<Item value="0x600">Splash</Item>
<Item value="0x300">Radio</Item>
<Item value="0x400">OS</Item>
<Item value="0x700">ExtROM</Item>
</device>
i make this conflagration from htcrt_devices.ini
here is entry in htcrt_devices.ini
Code:
[Gene]
Experimental=0
ModelId=GENE10000
SignMaxChunkSize=1024
RomSections=6, "0x100,""IPL"",131072,TRUE", "0x200,SPL,524288,TRUE", "0x600,Splash,196608,FALSE", "0x300,Radio,2883584,FALSE", "0x900,""Ext. ROM"",10485760,FALSE", "0x400,OS,0,FALSE"
but this don't work
this is not big issue we can replace it with old htcrt but new stuff is always welcome
also if u see kitchen_build_rom.bat
there is entry for NBHUtil's
Code:
..\tools\nbhutil -model %deviceid% -ver %versionid% -lang %langid% -chunk %chunksize% -nogui -e -i %osidvalue% ..\temp\os-new.nb -b ruu_signed.nbh
but there no specification of ExtROM in this line
ankit360 said:
good start here my Solution + Question for this
you r talking about NBHUtil.xml
to all who don't know about NBHUtil.xml
its database file for NBHUtil, so u ask me what is NBHUtil.exe ?, NBHUtil is same like htcrt, htcrt use htcrt_devices.ini file as database and NBHUtil use NBHUtil.xml as database
new NBHUtil's database does not have gene device data base so you need add this entry
Code:
<device name="Gene" chunksize="1024">
<ModelID>GENE***</ModelID>
<CID>11111111</CID>
<Ver>1.00.000.0</Ver>
<Lang>WWE</Lang>
<Item value="0x100">IPL</Item>
<Item value="0x200">SPL</Item>
<Item value="0x600">Splash</Item>
<Item value="0x300">Radio</Item>
<Item value="0x400">OS</Item>
<Item value="0x700">ExtROM</Item>
</device>
i make this conflagration from htcrt_devices.ini
here is entry in htcrt_devices.ini
Code:
[Gene]
Experimental=0
ModelId=GENE10000
SignMaxChunkSize=1024
RomSections=6, "0x100,""IPL"",131072,TRUE", "0x200,SPL,524288,TRUE", "0x600,Splash,196608,FALSE", "0x300,Radio,2883584,FALSE", "0x900,""Ext. ROM"",10485760,FALSE", "0x400,OS,0,FALSE"
but this don't work
this is not big issue we can replace it with old htcrt but new stuff is always welcome
also if u see kitchen_build_rom.bat
there is entry for NBHUtil's
Code:
..\tools\nbhutil -model %deviceid% -ver %versionid% -lang %langid% -chunk %chunksize% -nogui -e -i %osidvalue% ..\temp\os-new.nb -b ruu_signed.nbh
but there no specification of ExtROM in this line
Click to expand...
Click to collapse
I already try to add os-new.nb and extrom manually using NBHutil, but still un booable. i guess the problem is in the xip.
BesFen said:
I already try to add os-new.nb and extrom manually using NBHutil, but still un booable. i guess the problem is in the xip.
Click to expand...
Click to collapse
did you flash gene successfuly ?, did u get msg on RUU that rom flash successfuly ? not bootable means what ? did u see htc splash screen ? or stuck at tri screen ?
ankit360 said:
did you flash gene successfuly ?, did u get msg on RUU that rom flash successfuly ? not bootable means what ? did u see htc splash screen ? or stuck at tri screen ?
Click to expand...
Click to collapse
flash success and RUU message said "congratulation........", but my deavice directly go to bootloader, no HTC slash. I release the battery and reinsert it again, and the device automatically on and go to bootloader again, and again.
BesFen said:
flash success and RUU message said "congratulation........", but my deavice directly go to bootloader, no HTC slash. I release the battery and reinsert it again, and the device automatically on and go to bootloader again, and again.
Click to expand...
Click to collapse
this not happen due to bad xip if u have bad xip u stuck at htc splash screen this happen because rom is no build property means wrong things goes wrong place
while building rom there is lot's factors like chunks size address of os.nb,xip,exrom if that get wrong device show u tri screen
gene partition info
this is new gene partition information
{
"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"
}
Hi Ankit,
Here is how i cook with visual kitchen, hope this could help ....
1)dump->Customize->Create Rom, after create rom i dont touch the released nbh file instead..
2)in kitchen/temp folder there is built xip.bin, os-ew.nb and imgfs-new.bin copy these three files and do nb work with imgfs.bin and xip and then htcert or directly htcert with os-new.nb and extrom ... it works try it.
and i also analysed os-new.nb its same with the original new gene os.nb the only difference is imgfsstart, you can if you do nbinfo oon on both you willl se imgfsstart address is different you can put the imgfs start value off new gene in the other biutton of kitchen and build .its someething 0060000
ps:writing from phone pardon my english
I will inspect it step by step tonight........., must by some coffee for it.
coolaj said:
Hi Ankit,
Here is how i cook with visual kitchen, hope this could help ....
1)dump->Customize->Create Rom, after create rom i dont touch the released nbh file instead..
2)in kitchen/temp folder there is built xip.bin, os-ew.nb and imgfs-new.bin copy these three files and do nb work with imgfs.bin and xip and then htcert or directly htcert with os-new.nb and extrom ... it works try it.
and i also analysed os-new.nb its same with the original new gene os.nb the only difference is imgfsstart, you can if you do nbinfo oon on both you willl se imgfsstart address is different you can put the imgfs start value off new gene in the other biutton of kitchen and build .its someething 0060000
ps:writing from phone pardon my english
Click to expand...
Click to collapse
it mean you use imgfs and xip to build the new os-new.nb, not use the result of os-new.nb from visual kitchen.
I ever read at ervius thread that they cut some address of xip and imgfstart, and it can save some phone storage and RAM, maybe that step make the result of RUU_Signed.nbh and os-new.nb from that kitchen not work in my GENE.
It's more interesting and exsiting, I will try it tonight and report it here.........see you tonight
coolaj said:
Hi Ankit,
Here is how i cook with visual kitchen, hope this could help ....
Click to expand...
Click to collapse
that means you create ROM for gene with visual kitchen successfully ?
here is result
my cooked ROM with old working kitchen
Code:
'os-new.nb' has valid boot sector
Partition table:
Partition 0
-----------
File System: 0x20 (boot)
Start Sector: 0x00000002
Total Sectors: 0x000000fa
Boot indicator: 0x00
First Head: 0x02
First Sector: 0x01
First Track: 0x00
Last Head: 0xfb
Last Sector: 0x01
Last Track: 0x00
Partition 1
-----------
File System: 0x23 (XIP RAM)
Start Sector: 0x000000fc
Total Sectors: 0x000017a0
Boot indicator: 0x00
First Head: 0x00
First Sector: 0x01
First Track: 0x01
Last Head: 0xfb
Last Sector: 0x01
Last Track: 0x18
Partition 2
-----------
File System: 0x25 (imgfs)
Start Sector: 0x0000189c
Total Sectors: 0x0001c0e0
Boot indicator: 0x00
First Head: 0x00
First Sector: 0x01
First Track: 0x19
Last Head: 0xfb
Last Sector: 0x01
Last Track: 0x1e0
Partition 3
-----------
File System: 0x00 (unknown)
Start Sector: 0x00000000
Total Sectors: 0x00000000
Boot indicator: 0x00
First Head: 0x00
First Sector: 0x00
First Track: 0x00
Last Head: 0x00
Last Sector: 0x00
Last Track: 0x00
Geometry: flash has 252 virtual heads
MSFLSH50 header found at offset 0x200
(0 Reserved Entries, 2 Flash Region Entries)
Flash Region Entry 0:
---------------------
Region type: XIP
Start phys. block: 0x00000000
Size in phys. blocks: 0x00000000
Size in log. blocks: 0x00000019 -> Size in sectors: 0x0000189c
Sectors per block: 0x000000fc
Bytes per block: 0x0001f800
Compact blocks: 0x00000000
-> Bytes per sector: 0x00000200
Flash Region Entry 1:
---------------------
Region type: READONLY_FILESYS
Start phys. block: 0x00000000
Size in phys. blocks: 0x00000000
Size in log. blocks: 0x000001c8 -> Size in sectors: 0x0001c0e0
Sectors per block: 0x000000fc
Bytes per block: 0x0001f800
Compact blocks: 0x00000000
-> Bytes per sector: 0x00000200
Searching for IMGFS signature...
Found IMGFS at byte 0x00313800 (sector 0x0000189c).
dwFSVersion: 00000001
dwSectorsPerHeaderBlock: 00000001
dwRunsPerFileHeader: 00000001
dwBytesPerHeader: 00000034
dwChunksPerSector: 00000008
dwFirstHeaderBlockOffset: 00000200
dwDataBlockSize: 00001000
szCompressionType: XPR
dwFreeSectorCount: 0000490A
dwHiddenSectorCount: 00000100
dwUpdateModeFlag: 00000000
Original WM 6 Rom
Code:
'01_OS.nb' has valid boot sector
Partition table:
Partition 0
-----------
File System: 0x20 (boot)
Start Sector: 0x00000002
Total Sectors: 0x0000189a
Boot indicator: 0x00
First Head: 0x02
First Sector: 0x01
First Track: 0x00
Last Head: 0xfb
Last Sector: 0x01
Last Track: 0x18
Partition 1
-----------
File System: 0x23 (XIP RAM)
Start Sector: 0x0000189c
Total Sectors: 0x00001a94
Boot indicator: 0x00
First Head: 0x00
First Sector: 0x01
First Track: 0x19
Last Head: 0xfb
Last Sector: 0x01
Last Track: 0x33
Partition 2
-----------
File System: 0x25 (imgfs)
Start Sector: 0x00003330
Total Sectors: 0x0001e258
Boot indicator: 0x00
First Head: 0x00
First Sector: 0x01
First Track: 0x34
Last Head: 0xfb
Last Sector: 0x01
Last Track: 0x21d
Partition 3
-----------
File System: 0x00 (unknown)
Start Sector: 0x00000000
Total Sectors: 0x00000000
Boot indicator: 0x00
First Head: 0x00
First Sector: 0x00
First Track: 0x00
Last Head: 0x00
Last Sector: 0x00
Last Track: 0x00
Geometry: flash has 252 virtual heads
MSFLSH50 header found at offset 0x200
(0 Reserved Entries, 2 Flash Region Entries)
Flash Region Entry 0:
---------------------
Region type: XIP
Start phys. block: 0x00000000
Size in phys. blocks: 0x00000000
Size in log. blocks: 0x00000034 -> Size in sectors: 0x00003330
Sectors per block: 0x000000fc
Bytes per block: 0x0001f800
Compact blocks: 0x00000000
-> Bytes per sector: 0x00000200
Flash Region Entry 1:
---------------------
Region type: READONLY_FILESYS
Start phys. block: 0x00000000
Size in phys. blocks: 0x00000000
Size in log. blocks: 0x000001ea -> Size in sectors: 0x0001e258
Sectors per block: 0x000000fc
Bytes per block: 0x0001f800
Compact blocks: 0x00000000
-> Bytes per sector: 0x00000200
Searching for IMGFS signature...
Found IMGFS at byte 0x00666000 (sector 0x00003330).
dwFSVersion: 00000001
dwSectorsPerHeaderBlock: 00000001
dwRunsPerFileHeader: 00000001
dwBytesPerHeader: 00000034
dwChunksPerSector: 00000008
dwFirstHeaderBlockOffset: 00000200
dwDataBlockSize: 00001000
szCompressionType: XPR
dwFreeSectorCount: 00003425
dwHiddenSectorCount: 00000100
dwUpdateModeFlag: 00000000
BesFen said:
it mean you use imgfs and xip to build the new os-new.nb, not use the result of os-new.nb from visual kitchen.
I ever read at ervius thread that they cut some address of xip and imgfstart, and it can save some phone storage and RAM, maybe that step make the result of RUU_Signed.nbh and os-new.nb from that kitchen not work in my GENE.
Click to expand...
Click to collapse
its called ULDR but don't know what is that ?
@Ankit, sorry replying late was testing rom built by ervius kitchen because icant test and be online at the same time b'cus i use internet from phone.
Okay yes i have created working roms from visual kitchen as said earlier used imgfs-new bin and xip and did nbwork and htcert. if you buil with os-new.nb and extrom gene will stuck at tricolour mode..have some more tricks will be posting..
All this done with Original 6.0 new gene rom
ULDR Info -http://forum.xda-developers.com/showpost.php?p=2916649&postcount=7 by ameet
coolaj said:
@Ankit, sorry replying late was testing rom built by ervius kitchen because icant test and be online at the same time b'cus i use internet from phone.
Okay yes i have created working roms from visual kitchen as said earlier used imgfs-new bin and xip and did nbwork and htcert. if you buil with os-new.nb and extrom gene will stuck at tricolour mode..have some more tricks will be posting..
All this done with Original 6.0 new gene rom
ULDR Info -http://forum.xda-developers.com/showpost.php?p=2916649&postcount=7 by ameet
Click to expand...
Click to collapse
can u give me you kitchen plz ? only tool folder
also tell me what changes u done in my temp folder i get only OS-new.nb romhdr.bin and xip.bin
if u have msn or yahoo mail id we can chat online
ankit360 said:
can u give me you kitchen plz ? only tool folder
also tell me what changes u done in my temp folder i get only OS-new.nb romhdr.bin and xip.bin
if u have msn or yahoo mail id we can chat online
Click to expand...
Click to collapse
In Tools/kitchen_build_rom.bat delete these lines
del imgfs-new.bin
del OS-new.nb.payload
and build you will see in temp folder.
and i think uldr part is causing the problem....
coolaj said:
In Tools/kitchen_build_rom.bat delete these lines
del imgfs-new.bin
del OS-new.nb.payload
and build you will see in temp folder.
and i think uldr part is causing the problem....
Click to expand...
Click to collapse
what is IMGSTART value ?
Related
Dead HTC TyTN - Help !!
I have big problem! I kill my TyTN, I go to multi port........... --------------------------------------------- USB>task 32 Level = 0 USB>task 28 Storage format start Write Nand Success dwBlockToWrite = 13 Storage start block: 473 Storage Total block: 463 Total Bad Block in CE: 0 NeedToEraseBlockStart: 486 Storage format success USB>lnb RUU_SIGNED.nbh :F=RUU_SIGNED.nbh :A=501A0000 :O=00000000 :L=FFFFFFFF start NB image downloadSH Load ADDR: 501A0000 Length: 5544382 *************************************** **************************************** ******************************* **************************************** **************************************** **************************************** ****LAST BLOCK, dwBytesCollected=0x10000 Code entry point at 0x556E0000 Write Nand Success USB>task 28 Storage format start Write Nand Success dwBlockToWrite = 17 Can't find OS in flash!!! Storage format success USB>task 8 ----------------------------------------------------------- can you halp me? please!
ouch.... you tried to flash the entire nbh. This file contains os, extrom, radio and splash screens. You need to take that apart first with nbhextract to get os.nb then flash that instead. Hopefully you'll be able to....
ROM Cooking 101
Are there any step for step instructions, either on a web site or in a downloadable PDF that detail how one can cook their own athena ROMs? Such a thing would be a big help to all those that would like to try cooking their own ROMS.. I have found some instructions but they are old and are for other devices mostly running WM2003se or WM5. It would be goo to have an updated one for WM6 and the Athena.
Madhadder said: Are there any step for step instructions, either on a web site or in a downloadable PDF that detail how one can cook their own athena ROMs? Such a thing would be a big help to all those that would like to try cooking their own ROMS.. I have found some instructions but they are old and are for other devices mostly running WM2003se or WM5. It would be goo to have an updated one for WM6 and the Athena. Click to expand... Click to collapse How about over in the Hermes forum? (Not trying to me a [email protected]$$..)
toyfreak said: How about over in the Hermes forum? (Not trying to me a [email protected]$$..) Click to expand... Click to collapse search for "rom donalds", its a guide for hermes written by myself and Bennec83 that aims to teach you the basics of cooking and give you and understanding of why and how you do things, not just do it
Nice explanation and good instructions. Is there a version that works for the Athena? I only got as far as dumping the os.nb. It must be a diifferent offset or addresses, or something with the imgfs.. it states NBSplit 2.0 RC 2 Done. ImgfsFromNb 2.0 RC 2 Searching for IMGFS start... Found IMGFS at 00666668. Dumping IMGFS at offset 00666668 (size 04666658) Done! ImgfsToDump 2.0 RC 2 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: XPR dwFreeSectorCount: 00006494 dwHiddenSectorCount: 00000100 dwUpdateModeFlag: 00000000 Address: 00000200, dwBlockSignature: FFFFFEFE dwNextHeaderBlock: 00000000 (size: FFFFFE00) Header type: 00000270, Addr: 00000208 Unknown header type, FS_DATA_TABLE?? Header type: 004C006C, Addr: 0000023C Unknown header type, FS_DATA_TABLE?? Header type: 000002A4, Addr: 00000270 Unknown header type, FS_DATA_TABLE?? Header type: 000002D8, Addr: 000002A4 Unknown header type, FS_DATA_TABLE?? Header type: 0000030C, Addr: 000002D8 Unknown header type, FS_DATA_TABLE?? Header type: 00000340, Addr: 0000030C Unknown header type, FS_DATA_TABLE?? Header type: 00000000, Addr: 00000340 Unknown header type, FS_DATA_TABLE?? Header type: 00003608, Addr: 00000374 Unknown header type, FS_DATA_TABLE?? Header type: 00630061, Addr: 000003A8 Unknown header type, FS_DATA_TABLE?? it creates and Deletes the following files OS.nb.payload OS.nb.extra imgfs.bin it creates an empty dump_MemoryMap.txt and no dump folder. Am i doing something wrong
ATHENA.. Not HERMES, guys.. while there maybe many simularities between the devices when cooking ROMS, some important steps are not correct for the Athena, thus the guides need to be updated.
basically the differences are: dont use nbsplit at all and use the '-nosplit' option on all imgfs programs
Midget_1990 said: basically the differences are: dont use nbsplit at all and use the '-nosplit' option on all imgfs programs Click to expand... Click to collapse thanks Midget_1990..That works great.. I knew you would know the answer!
guys the trinity tools dont work on athena. the tools we use for wizard and uni do. now to those that do wanna cook get ready for late nights and lots of anger. the athena's rom is partioned so the os.nb is a fixed size. if u dont overload it the rom will boot and everything will be ok. if u do then the rom wont work and ur device will not turn on. with the athena adding stuff is hit or miss. some stuff wont go in bc theres a real big file. it aint easy i can tell u that but if u want to try it go ahead.
Pawel062 said: guys the trinity tools dont work on athena. the tools we use for wizard and uni do. now to those that do wanna cook get ready for late nights and lots of anger. the athena's rom is partioned so the os.nb is a fixed size. if u dont overload it the rom will boot and everything will be ok. if u do then the rom wont work and ur device will not turn on. with the athena adding stuff is hit or miss. some stuff wont go in bc theres a real big file. it aint easy i can tell u that but if u want to try it go ahead. Click to expand... Click to collapse Yes be careful people and good luck. This one was a surprise to us...but then again, no one knows it all and it's fun to learn new things.
How abou just edit ext ROM.. can I do the same way as universal?? Or still unsolved? Thanks
Another way to reconstruct providers ROMS
The current form of rebuilding ROM for Niki, using the kitchen Kaiser, this very well but I think that this method is more simple and the ROM is identical to the source. I rebuilt two well ROM Spanish, tested by makoky. I don´t have this model. The structure of ROM is the AsianWWE identities. You need attached file and tree first parts extracted from your machine. Code: E:\Extract\niki.es>COPY /B inicio.bin+Part00.raw+Part01.raw os.nb.base inicio.bin Part00.raw Part01.raw 1 archivos copiados. E:\Extract\niki.es>COPY /B relleno.bin+Part02.raw imgfs.bin relleno.bin Part02.raw 1 archivos copiados. E:\Extract\niki.es>..\Tools\ImgfsToNb.exe imgfs.bin OS.NB.base os.nb.payload ImgfsToNb 2.1rc2 Using bigstorage mode Sector size is 0x800 bytes Writing imgfs to offset byte 0x6a0000, sector 0xd40 Padding ImgFs from 0x5060000 bytes (0xa0c0 sectors) to 0x5060000 bytes (0xa0c0 sectors) Not conservative mode. Changing imgfsEnd from 0x59c0000 to 0x5700000 Partition entry before: File System: 0x25 Start Sector: 0x00000d40 Total Sectors: 0x0000a640 Boot indicator: 0x00 First Head: 0x00 First Sector: 0x01 First Track: 0x35 Last Head: 0x3f Last Sector: 0x01 Last Track: 0x2cd Partition entry after: File System: 0x25 Start Sector: 0x00000d40 Total Sectors: 0x0000a0c0 Boot indicator: 0x00 First Head: 0x00 First Sector: 0x01 First Track: 0x35 Last Head: 0x3f Last Sector: 0x01 Last Track: 0x2b7 Partition entry before: File System: 0x04 Start Sector: 0x0000b380 Total Sectors: 0x0000ff40 Boot indicator: 0x00 First Head: 0x00 First Sector: 0x01 First Track: 0x2ce Last Head: 0x3f Last Sector: 0x01 Last Track: 0x2ca Partition entry after: File System: 0x04 Start Sector: 0x0000ae00 Total Sectors: 0x000104c0 Boot indicator: 0x00 First Head: 0x00 First Sector: 0x01 First Track: 0x2b8 Last Head: 0x3f Last Sector: 0x01 Last Track: 0x2ca ImgFs Flash Region log blocks was 0x299, now is 0x283 Storage Flash Region log block was 0xffffffff, now is 0xffffffff, Done! E:\Extract\niki.es>..\Tools\NBMerge.exe -kaiser OS.NB NBMerge 2.1rc2 Executing ..\Tools\NBMerge.exe with data chunk size = 0x800 and extra chunk size = 0x8 on file OS.NB Partition 0: start sector: 0x00000002, total: 0x0000063e first used: 0x00000002, used: 0x00000600 Partition 1: start sector: 0x00000640, total: 0x00000700 first used: 0x00000640, used: 0x000005df Partition 2: start sector: 0x00000d40, total: 0x0000a0c0 first used: 0x00000dc0, used: 0x0000a040 Checking OS.NB for bad NAND block marker Checked 0xae00 sectors successfully! Done. E:\Extract\niki.es> In attached file, you have two files extracted from AsianWEE, Ones is the header of ROM and another are some free bytes at start of imgfs. If someone finds any error, please say so. PD. Sorry for my bad english
Can someone confirm this methode of working? Or should we still hang on to the Kaiser methode?
mastogo the best! Eres el mejor mastogo Un Saludo.
FatalZero said: Can someone confirm this methode of working? Or should we still hang on to the Kaiser methode? Click to expand... Click to collapse I am waiting for several friends selected for testing, but still have not received their niki. But I can say that the structure of the ROM seems perfect and teory must operate.
Work And I can say that this method works correctly, the two ROMs have been tested by makoky in his Niki work and perfect. This method is much simpler and faster than the one currently used on the basis of the cuisine of the Kaiser and the ROM is identical to the original. It is necessary to use uSPL or HardSPL only by the signature tool. If you need these spanish roms, you can get here.
is this method intended only for Spanish Niki phones/users or anyone can follow this method to reconstruct his rom? thx
So afterward i get a complete Rom ready to flash? Still need a way to backup my german rom. Don't wanna switch to niki projct rom without a chance to get back.
Hallo Thyraz, ich habe das Verfahren erfolgreich getestet. Ich hatte einen Dump mit itsutils gemacht, mit dem Verfahren von mastsogo ein rebuild gemacht, mit kaiserkitchen_01-20-08 erfolgreich geflashed. Aber daran denken: Hard-SPL installieren.
Danke Werd mich die Tage dann auch mal ransetzen.
eroG said: is this method intended only for Spanish Niki phones/users or anyone can follow this method to reconstruct his rom? thx Click to expand... Click to collapse This method is valid for roms of other languages as well. Thyraz said: So afterward i get a complete Rom ready to flash? Still need a way to backup my german rom. Don't wanna switch to niki projct rom without a chance to get back. Click to expand... Click to collapse Once rebuilt only in the ROM required to sign HTC Rom Tool to be able to flash. { "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" } This utility can be found in this thread: http://forum.xda-developers.com/showthread.php?t=311909&highlight=htcrt
[Q] Hacking preloader.bin
I figured out how to hack the EBR1 on mediatek MTK6572 to increase userdata by merging the fat and userdata partitions. Unfortunatly, this mod does not change the blocks maps, even when editing the scatter text to match the EBR1 hack mod. Here is the post on how it is done. http://elizabethswikis.blogspot.com/2014/09/tutorial-how-to-increase-partition-on.html After much searching, finally found out that the blocks maps are probably setup via preloader.bin, which tells /proc/dumchar_info what the blocks are and sizes. Well now I would like to figure out how to hack the preloader, either the bin or preloader_and_dsp, to edit that sections that it matches up with the modded EBR1. Just can't find any information, looked at the preloader.bin and preloader_and_dsp in hex editor and emacs, but that doesn't help me much, am able to see the section where it tells EBR1, preloader, userdata, android, etc... but can't make out how to change those hex values.
Nobody knows Well, after much searching as to what could possibly be in the preloader.bin and lk.bin for emmc mtk devices, figure that what it probably is are all the .c files that were put into a .bin using the makefile. Well okay, that is great, even better, everybody knows how to make one, yet, nobody knows how to extract it? Terminal shell command, strings lk.bin, lets me read what exactly the preloader/bootloader is supposed to do, and where the files are pointed to. So for example, know that there is a meta.c and UART.c inside, to name a few, now I would like to get them out. That seems a bit hard to believe, why would one want to know how to make something they can't take apart later on for bug fixing?
Refer this tutorial http://forum.xda-developers.com/showthread.php?t=2596030&page=8 Regards, Karthick
read the post Karthickgandhi said: Refer this tutorial http://forum.xda-developers.com/showthread.php?t=2596030&page=8 Regards, Karthick Click to expand... Click to collapse I don't think you entirely read my post or looked at my blog. ANyways,, for anybody who wants to look at the preloader.bin and lk.bin, this can be done in IDA PRO using the arm little endian option. I've been looking at it myself, figured out that if you use the correct rom/ram size and start address, IDA PRO disembles the files. Only thing is, can't figure out what the start address for a ram file would be. Now that I have figured out how to read those "BIN" files, how can I get them to load so that I can modify the "/proc/dumchar/" to match my "ALREADY HACKED EBR1".
Research and continue your development and make a tutorial for hacking preloader.bin I have a very basic level knowledge in partitioning etc. Noted now only that the command --->cat /proc/dumchar_info doesn't change even after changing the ebr and i have increased the internal app storage memory. Regards, Karthick
Preloader.bin Karthickgandhi said: Research and continue your development and make a tutorial for hacking preloader.bin I have a very basic level knowledge in partitioning etc. Noted now only that the command --->cat /proc/dumchar_info doesn't change even after changing the ebr and i have increased the internal app storage memory. Regards, Karthick Click to expand... Click to collapse The post tells how to repartition the EBR1, as for the preloader.bin, well you can disemble it in IDA pro. Thing is, I got as far as finding where the partitions are, even figured out how to change the values. After exporting it as a raw binary, well that is where I'm stuck. Ida exports it with a .txt extension, needs to be .bin. How would in linux could I convert that using the dd command for a successful flash, aka: dd if=preloader.txt of=preloader.bin bs=1 skip=????
If that's a complete one you can use this command dd if=/path_of_edited_preloader.txt of=/path_for_new_preloader.bin Dont need to specify bs,skip,etc Regards, Karthick
Hacking mtk6572 bootloader Karthickgandhi said: If that's a complete one you can use this command dd if=/path_of_edited_preloader.txt of=/path_for_new_preloader.bin Dont need to specify bs,skip,etc Regards, Karthick Click to expand... Click to collapse I tried that, but it didn't boot when I loaded the modified preloader.bin. Was wondering if it was because: A. was it because I named it preloader-modified.bin? B. Is there another place that needs to be modified besided the userdata partition? The original size is 0x2000000, the full size using the fat and userdata combinded is 0xA7040000. Is there another place that it should be changed? Could not find the fat partition in the preloader.bin, everything except for the FAT size, which is 0x87040000 and the BMPOOL, have to look at that size. When comparing with the dumchar_info & Scatter file, shows all the partition sizes from preloader down to userdata. Also have a preloader.bin from the manufacturer whree I purchased my phone, that preloader, scatter and EBR1 uses the full userdata no fat size, but the scatter for the other tablet/phone has a fat section with a 0x0 partition size, uses the full userdata and no fat partition. Also, when comparting that preloader with my preloader, same thing, everything right down to the userdata, missing fat and BMPOOL. Well tomorrow I'll try again, this time doing dd if=preloader.txt of=preloader.bin. The name, preloader-modified.bin may not have worked, since reading through the entire preloader.bin and lk.bin, it directs to flash preloader, uboot, lk < know both are the same, userdata, fat, etc...
bethnesbitt said: I tried that, but it didn't boot when I loaded the modified preloader.bin. Was wondering if it was because: A. was it because I named it preloader-modified.bin? B. Is there another place that needs to be modified besided the userdata partition? The original size is 0x2000000, the full size using the fat and userdata combinded is 0xA7040000. Is there another place that it should be changed? Could not find the fat partition in the preloader.bin, everything except for the FAT size, which is 0x87040000 and the BMPOOL, have to look at that size. When comparing with the dumchar_info & Scatter file, shows all the partition sizes from preloader down to userdata. Also have a preloader.bin from the manufacturer whree I purchased my phone, that preloader, scatter and EBR1 uses the full userdata no fat size, but the scatter for the other tablet/phone has a fat section with a 0x0 partition size, uses the full userdata and no fat partition. Also, when comparting that preloader with my preloader, same thing, everything right down to the userdata, missing fat and BMPOOL. Well tomorrow I'll try again, this time doing dd if=preloader.txt of=preloader.bin. The name, preloader-modified.bin may not have worked, since reading through the entire preloader.bin and lk.bin, it directs to flash preloader, uboot, lk < know both are the same, userdata, fat, etc... Click to expand... Click to collapse Got that working???
decompile bootloader Karthickgandhi said: Got that working??? Click to expand... Click to collapse No, I have been picking it apart for a few hours a day since trying that method. The dd if=preloader.txt > preloader.bin didnn't work. Then found out there was a way to just apply the patch to the file, thought cool, tried that didn't work either . So now I'm thinking it's how I am trying to load it in IDA PRO. If what some reasearch says, it is an arm-eabbi-gcc, not sure if ida is actually supporting that correctly. There are plenty of TUT on how to compile, but nothing about decompiling.
bethnesbitt said: No, I have been picking it apart for a few hours a day since trying that method. The dd if=preloader.txt > preloader.bin didnn't work. Then found out there was a way to just apply the patch to the file, thought cool, tried that didn't work either . So now I'm thinking it's how I am trying to load it in IDA PRO. If what some reasearch says, it is an arm-eabbi-gcc, not sure if ida is actually supporting that correctly. There are plenty of TUT on how to compile, but nothing about decompiling. Click to expand... Click to collapse Nice.... but are you sure that the dumchar_info is associated with preloader? I doubt the pmt(partition management table) Part_Name Size StartAddr Type MapTo preloader 0x0000000000600000 0x0000000000000000 2 /dev/misc-sd mbr 0x0000000000080000 0x0000000000000000 2 /dev/block/mmcblk0 ebr1 0x0000000000080000 0x0000000000080000 2 /dev/block/mmcblk0p1 pmt 0x0000000000400000 0x0000000000100000 2 /dev/block/mmcblk0 pro_info 0x0000000000300000 0x0000000000500000 2 /dev/block/mmcblk0 nvram 0x0000000000500000 0x0000000000800000 2 /dev/block/mmcblk0 protect_f 0x0000000000a00000 0x0000000000d00000 2 /dev/block/mmcblk0p2 protect_s 0x0000000000a00000 0x0000000001700000 2 /dev/block/mmcblk0p3 seccfg 0x0000000000020000 0x0000000002100000 2 /dev/block/mmcblk0 uboot 0x0000000000060000 0x0000000002120000 2 /dev/block/mmcblk0 bootimg 0x0000000000600000 0x0000000002180000 2 /dev/block/mmcblk0 recovery 0x0000000000600000 0x0000000002780000 2 /dev/block/mmcblk0 sec_ro 0x0000000000600000 0x0000000002d80000 2 /dev/block/mmcblk0p4 misc 0x0000000000080000 0x0000000003380000 2 /dev/block/mmcblk0 logo 0x0000000000300000 0x0000000003400000 2 /dev/block/mmcblk0 ebr2 0x0000000000080000 0x0000000003700000 2 /dev/block/mmcblk0 expdb 0x0000000000a00000 0x0000000003780000 2 /dev/block/mmcblk0 android 0x000000002bc00000 0x0000000004180000 2 /dev/block/mmcblk0p5 cache 0x0000000007e00000 0x000000002fd80000 2 /dev/block/mmcblk0p6 usrdata 0x0000000040000000 0x0000000037b80000 2 /dev/block/mmcblk0p7 fat 0x000000006fba0000 0x0000000077b80000 2 /dev/block/mmcblk0p8 bmtpool 0x0000000001500000 0x00000000ff9f00a8 2 /dev/block/mmcblk0 Regards, Karthick
dumchar Right now I'm not in linux, so I can't copy and paste so will give a quick summary of what I see when I decompile the preloader.bin. At the bottom of the preloader in IDA PRO is a list of the partition sizes, everything except for the FAT and BMTPOOL. It shows, as ascii string, the partition sizes, just giving a bit of what i remember off the top of my head: 0x600000 < preloader 0X600000 < Rom 0x800000 < EBR1 0xA00000 0x1780000 < this is my cache size 0x2000000 < this is my userdata size ALso the ascii string has FAT USERDATA UBOOT PRELOADER BOOT ANDROIDSYS Ida isn't disembling it correctly because all the strings should point to an operand, the partition sizes aren't. Today went through though, am trying differant library types using the METAPC option. It took me 2 monts to hack the EBR1, may take my just as long.
Good luck. Don't forget to share if you hit that jackpot. I am trying to increase my recovery partition but facing some problems. Unlike /system or /data partition it cannot be altered by hacking mbr/ebr. U have any idea?
Hey, I have HTC Desire 310 it uses MTK6582 and it has locked bootloader. I think the bootloader has something to do with the preloader, so if you can help me in some way, pls PM me!
Take a look here, it may help http://forum.xda-developers.com/showthread.php?t=1959691 This WILL help with how the partitions and security may be working http://www.uefi.org/specifications Sent from my B1-730HD using XDA Free mobile app
f*ck Antagonist42 said: Take a look here, it may help http://forum.xda-developers.com/showthread.php?t=1959691 This WILL help with how the partitions and security may be working http://www.uefi.org/specifications Sent from my B1-730HD using XDA Free mobile app Click to expand... Click to collapse doesn't work brother.. idk what is the problem.. This is MTK phone, with locked bootloader by htc.. idk i tried everything and nothing works
boka18 said: doesn't work brother.. idk what is the problem.. This is MTK phone, with locked bootloader by htc.. idk i tried everything and nothing works Click to expand... Click to collapse What do you mean 'doesn't work'? What was it you're looking for? I'm posting info that may help the thread as to partitions, how they work and what different formats can be used. Sent from my B1-730HD using XDA Free mobile app
Dissemble preloader.bin - unlock bootloader? The preloader is the bootloader. After dissembling the preloader.bin, somewhat successfully, in IDA PRO, here is what I see for partitions: In ida, open the preloader.bin, change the dropdown to ARM little endian, unsure about size for rom and the loading address, tried many different sizes and start address, each time give me a somewhat of a different outcome. { "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" } Select Arm Little Endian Not sure about the Rom Size, did try size for RAM but would not encode. Have tried different sizes for ROM, getting different outputs. Using the loading address as 0x0, which is the linear start address in the scatter for preloader seems to make sense, could be wrong. Beware though, the larger size you try, the laggier your PC will get Now when the preloader.bin is done loading, go to Edit menu and select all. Now press the letter C on your keyboard for code, choose Analyse and say yes. When done analyzing, you can scroll through the code, it doesn't analyze everything you will see some code that was not analyzed, those are in gold, if you select all that unanalyzed code by pressing shift+arrowdown, then press C it will analyze that code, you may want to go through and do that little cleanup. Towards the bottom, you will see ASCII text that was decoded, here is what shows for my partitions. ROM:00017518 dword_17518 DCD 0x201A626, 0 ; DATA XREF: sub_11CC+2o ROM:00017518 ; ROMff_11D4o ROM:00017520 DCD dword_600000 <- PRELOADER ROM:00017524 ALIGN 0x10 ROM:00017530 DCD 0x201A630, 0 ROM:00017538 DCD dword_80000 <-- MBR ROM:0001753C DCD 0, 0, 0 ROM:00017548 DCD 0x201A634, 0 ROM:00017550 DCD dword_80000 <-- EBR1 ROM:00017554 ALIGN 0x10 ROM:00017560 DCD 0x201A639, 0 ROM:00017568 DCD dword_300000 <-- PRO_INFO ROM:0001756C DCD 0, 0, 0 ROM:00017578 DCD 0x201A642, 0 ROM:00017580 DCD dword_500000 < -- NVRAM ROM:00017584 ALIGN 0x10 ROM:00017590 DCD 0x201A648, 0 ROM:00017598 DCD dword_A00000 <-- PROTECT_F ROM:0001759C DCD 0, 0, 0 ROM:000175A8 DCD 0x201A652, 0 ROM:000175B0 DCD dword_A00000 <-- PROTECT_S ROM:000175B4 ALIGN 0x10 ROM:000175C0 DCD 0x201A65C, 0 ROM:000175C8 DCD dword_20000 <-- SEFCG ROM:000175CC DCD 0, 0, 0 ROM:000175D8 DCD 0x201A663, 0 ROM:000175E0 DCD dword_60000 <- UBOOT/LK.BIN ROM:000175E4 ALIGN 0x10 ROM:000175F0 DCD 0x201A669, 0 ROM:000175F8 DCD dword_600000 < -- BOOTIMG ROM:000175FC DCD 0, 0, 0 ROM:00017608 DCD 0x201A671, 0 ROM:00017610 DCD dword_600000 <-- RECOVERY ROM:00017614 ALIGN 0x10 ROM:00017620 DCD 0x201A67A, 0 ROM:00017628 DCD dword_40000 <-- SEC_RO ROM:0001762C DCD 0, 0, 0 ROM:00017638 DCD 0x201A684, 0 ROM:00017640 DCD dword_80000 < -- MISC ROM:00017644 ALIGN 0x10 ROM:00017650 DCD 0x201A689, 0 ROM:00017658 DCD dword_300000 <-- LOGO ROM:0001765C DCD 0, 0, 0 ROM:00017668 DCD 0x201A68E, 0 ROM:00017670 DCD dword_A00000 <-- EXPDB ROM:00017674 ALIGN 0x10 ROM:00017680 DCD 0x201A694, 0 ROM:00017688 DCD 0x28A00000, 0, 0, 0 < -- ANDROID SYSTEM ROM:00017698 DCD 0x201A69E, 0 ROM:000176A0 DCD 0x17800000, 0, 0, 0 < -- CACHE ROM:000176B0 DCD 0x201A6A4, 0 ROM:000176B8 DCD 0x20000000, 0, 0, 0 <-- USERDATA If you compare that to your scatter, you will see that they match up, right in order per the scatter as well as when you go into: Code: adb shell cat /proc/dumchar_info > /sdcard/dumchar.txt Katherick, for your question, yes the recovery can be modified, now another option is using a hexdump. Maybe somebody can point us to using hexdump to modify and saving it back to the binary format. First you would have to figure out how to change the value in the preloader.bin of your recovery, not sure if just that ascii value has to be changed, or is there another place. Once you decompile the preloader.bin in IDA, you can see where those ASCII values point to identifiers throughout the code in various spots, except for the partition sizes. Now, for the ascii, here is a little bit from mine: Code: ROM:00013426 aPreloader DCB "PRELOADER",0 ; DATA XREF: sub_DB84+B0o ROM:00013426 ; ROM:off_DCD0o ... ROM:00013430 aMbr DCB "MBR",0 ROM:00013434 aEbr1 DCB "EBR1",0 ROM:00013439 aPro_info DCB "PRO_INFO",0 ROM:00013442 aNvram DCB "NVRAM",0 ROM:00013448 aProtect_f DCB "PROTECT_F",0 ROM:00013452 aProtect_s DCB "PROTECT_S",0 ROM:0001345C aSecure DCB "SECURE",0 ; DATA XREF: sub_D7F8+5Co ROM:0001345C ; ROM:off_D8E8o ... ROM:00013463 aUboot DCB "UBOOT",0 ; DATA XREF: ROM:000027C8o ROM:00013463 ; ROM:off_2848o ... ROM:00013469 aBootimg DCB "BOOTIMG",0 ; DATA XREF: sub_DB84+38o ROM:00013469 ; ROM:off_DCBCo ... ROM:00013471 aRecovery DCB "RECOVERY",0 ; DATA XREF: sub_DB84+68o ROM:00013471 ; ROM:off_DCC4o ... ROM:0001347A aSecstatic DCB "SECSTATIC",0 ; DATA XREF: sub_DB84+118o ROM:0001347A ; ROM:off_DCF0o ROM:00013484 aMisc DCB "MISC",0 ROM:00013489 aLogo_0 DCB "LOGO",0 ; DATA XREF: sub_D544+6Ao ROM:00013489 ; ROM:off_D61Co ... ROM:0001348E aExpdb DCB "EXPDB",0 ROM:00013494 aAndsysimg DCB "ANDSYSIMG",0 ; DATA XREF: sub_DB84+112o ROM:00013494 ; ROM:off_DCECo ROM:0001349E aCache DCB "CACHE",0 ; DATA XREF: sub_DB84+DEo ROM:0001349E ; sub_DB84+12Ao ... ROM:000134A4 aUser DCB "USER",0 ; DATA XREF: sub_DB84+124o ROM:000134A4 ; ROM:off_DCF8o ROM:000134A9 aFat DCB "FAT",0 ROM:000134AD aDeviceApcDomai DCB 0xA ; DATA XREF: sub_1208+8o ROM:000134AD ; ROM:off_130Co and here is the identifier: Code: ROM:0000DCB4 off_DCB4 DCD aUboot - 0xDB8E ; DATA XREF: sub_DB84+4r ROM:0000DCB4 ; "UBOOT" ROM:0000DCB8 off_DCB8 DCD aLogo_0 - 0xDBA8 ; DATA XREF: sub_DB84+1Er ROM:0000DCB8 ; "LOGO" ROM:0000DCBC off_DCBC DCD aBootimg - 0xDBC0 ; DATA XREF: sub_DB84+36r ROM:0000DCBC ; "BOOTIMG" ROM:0000DCC0 off_DCC0 DCD aAndroid - 0xDBD8 ; DATA XREF: sub_DB84+4Er ROM:0000DCC0 ; "ANDROID" ROM:0000DCC4 off_DCC4 DCD aRecovery - 0xDBF0 ; DATA XREF: sub_DB84+66r ROM:0000DCC4 ; "RECOVERY" ROM:0000DCC8 off_DCC8 DCD aSec_ro - 0xDC08 ; DATA XREF: sub_DB84+7Er ROM:0000DCC8 ; "SEC_RO" ROM:0000DCCC off_DCCC DCD aSeccnfg - 0xDC20 ; DATA XREF: sub_DB84+96r ROM:0000DCCC ; "SECCNFG" ROM:0000DCD0 off_DCD0 DCD aPreloader - 0xDC38 ; DATA XREF: sub_DB84+AEr ROM:0000DCD0 ; "PRELOADER" ROM:0000DCD4 off_DCD4 DCD aUsrdata - 0xDC50 ; DATA XREF: sub_DB84+C6r ROM:0000DCD4 ; "USRDATA" ROM:0000DCD8 off_DCD8 DCD aCache - 0xDC66 ; DATA XREF: sub_DB84+DCr ROM:0000DCD8 ; "CACHE" ROM:0000DCDC off_DCDC DCD aSPartNameSNotF - 0xDC80 ; DATA XREF: sub_DB84+F2r ROM:0000DCDC ; "[%s] part name '%s' not found\n" ROM:0000DCE0 off_DCE0 DCD aLib - 0xDC82 ; DATA XREF: sub_DB84+F6r ROM:0000DCE0 ; "LIB" ROM:0000DCE4 off_DCE4 DCD aSec_util_c - 0xDC8E ; DATA XREF: sub_DB84+100r ROM:0000DCE4 ; "sec_util.c" ROM:0000DCE8 off_DCE8 DCD a0 - 0xDC90 ; DATA XREF: sub_DB84+102r ROM:0000DCE8 ; "0" ROM:0000DCEC off_DCEC DCD aAndsysimg - 0xDC9A ; DATA XREF: sub_DB84:loc_DC94r ROM:0000DCEC ; "ANDSYSIMG" ROM:0000DCF0 off_DCF0 DCD aSecstatic - 0xDCA0 ; DATA XREF: sub_DB84:loc_DC9Ar ROM:0000DCF0 ; "SECSTATIC" ROM:0000DCF4 off_DCF4 DCD aSecure - 0xDCA6 ; DATA XREF: sub_DB84:loc_DCA0r ROM:0000DCF4 ; "SECURE" ROM:0000DCF8 off_DCF8 DCD aUser - 0xDCAC ; DATA XREF: sub_DB84:loc_DCA6r ROM:0000DCF8 ; "USER" ROM:0000DCFC off_DCFC DCD aCache - 0xDCB2 ; DATA XREF: sub_DB84:loc_DCACr ROM:0000DCFC ; "CACHE" Issue is though, I cannot find the partition sizes the way I can when looking at the ASCII and Identifiers. Now to change the cache size or any other size, in the ascii where, for example, the cache size of mine is: ROM:000176A0 DCD 0x17800000, 0, 0, 0 1. Make sure to mouse click on the partition size before going into the hex, this will bring you right to it in hex, where it can be changed. 2. Click on the tab that says HEX View-A and lets say you want to decrease it cut it in half for example: 17800000/2 = BC00000 or 394264576/2= 197132288 which is a hex value of BC00000. So in the HEx View-A, make sure the size is selected, you want to change 80 17 to 00 BC, it has to be entered from right to left so that the IDA View-A can read it from left to right. Thing is, I tried a few things: In on the menu, selecting Edit > export data, and exporting it as raw binary then in terminal Code: dd if=preloader.txt > preoader.bin Did not work Also tried: Edit > apply patch > apply patch to input program did not work either, both just caused my tablet to get stuck at the boot logo. Now this, as mentioned could be possibly because, I am doing the conversion correctly when making the changes, but: Where is that identifier for the partition sizes, or is there one? Is IDA decompiling it correctly? Where is the identifier for FAT? Where is the partition size for FAT? Does the reason the EBR1 hack work, per my blog instructions, because there is no partition size for FAT in the bootloader? Once, just to see what would happen, and it worked, I decreased my cache, this was hard to get the phone to like, but it worked. Next I increased the cache, the phone seemed okay with that hack. Here are those instructions to modify the EBR1 and increase/decrease cache
Something to bear in mind is CRC32 once you edit something within partition data, I only stumbled on this looking for something else explained a lot and cleared a few things up for me as to why some editing doesn't seem to work. Try this on Partition info http://www.jonrajewski.com/data/PartitionScheme/Partition_Table_Documentation_Compressed.pdf really useful Sent from my B1-730HD using XDA Free mobile app
This is going to be a bit incoherent, because I'm just starting out with this stuff, and my issue is not exactly the same as yours. But I **think** that the overlap is so close that perhaps we can help each other. I admit up front that I am going to have to read this entire thread another 5-10 times before I really understand what you know, what you don't know,and what you need/want to know. In the meantime, here is my problem and the bits I think i know: 1. What I have: i have an MT6735M-based phone [it is the "rook" by EE]. I have managed to root this phone by SP-Flash-Tool to manually download TWRP over the stock recovery partition; then I used TWRP to install superuser.apk for this device. In order to do this and not brick anything, I spent a fair amount of time getting a correct scatter file, and I think i have a very accurate one for my phone. 2. My problem: The phone is rooted all right, but the bootloader is still locked. The above rooting with SP Flash Tools was unconcerned with the bootloader lock state. But my understanding is that the bootloader being locked or not is simply a bootloader variable, just as S-on or s-Off is a bootloader variable . My understanding is that the bootloader code is just the partition lk.bin -- but that the variables themselves are stored in nvram.bin. From various threads about other phones, I believe that "all" that the bootloader unlocking and locking recipes just in the end change the stored value of the single toggle variable bootloader:locked. If i can find out where tha variable is stored, I should be able to read-back the nvram parition, change the single long int corresponding to the value of "lock", and download the new nvram.bin to the phone. DO I have a hope of finding these bytes? 3. I can say with some certainty that if you read-back the preloader partition from a MT6735M, you get a file whose first 2048 bytes needs to be discarded to get an imagine you can flash back to the phone. How to unpack the stripped prleloader bin file is proving very difficult. any clever ideas?
Wierd ELF files used by QPST
Hi all, For some reason I want to modify the bootloader on my device(Lenovo Zuk Z2 plus, which has SnapDragon 820, MSM8996). I have research a little bit and got a snippet of assembly code that I believe appears in the bootloader, and I hope to replace. So I believe the xbl.elf file in the stock ROM, which is to be flashed by QPST, is the bootloader I hope to hack. My plan: 1. Interpret the file xbl.elf 2. find the snippet of code I hope to replace 3. replace the snippet of binary with some cooler binary. So here is the result of `readelf -a xbl.elf`: Code: ELF Header: Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: AArch64 Version: 0x1 Entry point address: 0x6213f10 Start of program headers: 64 (bytes into file) Start of section headers: 0 (bytes into file) Flags: 0x0 Size of this header: 64 (bytes) Size of program headers: 56 (bytes) Number of program headers: 17 Size of section headers: 0 (bytes) Number of section headers: 0 Section header string table index: 0 There are no sections in this file. There are no sections to group in this file. Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align NULL 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x00000000000003f8 0x0000000000000000 0 NULL 0x0000000000001000 0x0000000085eec000 0x0000000085eec000 0x0000000000001b48 0x0000000000002000 1000 LOAD 0x0000000000003000 0x0000000006208000 0x0000000006208000 0x00000000000567b4 0x00000000000567b4 R E 10000 LOAD 0x00000000000597c0 0x000000000625f000 0x000000000625f000 0x0000000000009a58 0x0000000000009a58 RW 10000 LOAD 0x0000000000063220 0x000000000626a000 0x000000000626a000 0x0000000000000000 0x00000000000052a8 RW 10000 LOAD 0x0000000000063220 0x0000000085e00000 0x0000000085e00000 0x0000000000000000 0x0000000000024da0 RW 10000 LOAD 0x0000000000063220 0x0000000006680000 0x0000000006680000 0x00000000000029d0 0x00000000000029d0 R E 10000 LOAD 0x0000000000065bf0 0x0000000006683000 0x0000000006683000 0x0000000000000694 0x0000000000000694 RW 10000 LOAD 0x0000000000066290 0x000000000021e000 0x000000000021e000 0x0000000000005e54 0x0000000000005e54 R E 10000 LOAD 0x000000000006c0f0 0x00000000066a2000 0x00000000066a2000 0x0000000000000000 0x0000000000012400 RW 10000 LOAD 0x000000000006c0f0 0x0000000085e80000 0x0000000085e80000 0x00000000000282ee 0x00000000000282ee R E 10000 LOAD 0x00000000000943e0 0x0000000085ec0000 0x0000000085ec0000 0x000000000002b9a0 0x000000000002b9a0 RW 10000 LOAD 0x00000000000bfd80 0x0000000085eb0000 0x0000000085eb0000 0x0000000000000000 0x00000000000099e8 RW 10000 LOAD 0x00000000000bfd80 0x0000000080200000 0x0000000080200000 0x00000000000f0000 0x00000000000f0000 RWE 1000 LOAD 0x00000000001afd80 0x0000000000207000 0x0000000000207000 0x000000000000ebe1 0x000000000000ebe1 R E 10000 LOAD 0x00000000001be970 0x0000000000217800 0x0000000000217800 0x00000000000004c8 0x00000000000004c8 RW 10000 LOAD 0x00000000001bee40 0x0000000000219800 0x0000000000219800 0x0000000000000000 0x00000000000001d0 RW 10000 There is no dynamic section in this file. There are no relocations in this file. The decoding of unwind sections for machine type AArch64 is not currently supported. Dynamic symbol information is not available for displaying symbols. No version information found in this file. So as you can see, this elf file is quite uncommon. Anyone has any idea how to interpret this file? Thanks!
Solved Nevermind, I simply regard this file as binary and disemble it: aarch64-linux-gnu-objdump -b binary -D xbl.elf -maarch64 And the assembly is crystally clear!