[TUT] How to make a custom ROM for Samsung ATIV S - Windows Phone 8 Development and Hacking

This tutorial is about making a custom ROM for ATIV S or any other Samsung WP8 phone.
Samsung ROM files:
.wp8 - main file with OS and boot
.csc - file with regional info
.smd - ROM for WP7 devices
All those files have (almost) the same format. I call it SMD. Old .smd file can be unpacked using this instruction, back in time smd-tool was made for it, but format changed slightly. This process was only tested on ATIV S.
CSC
.csc files aren't flashed to device, those are just containers for MBN files. And MBN files are copied to DPP during flashing process.
AS ALWAYS YOU ARE MAKING THIS ON YOUR OWN RISK! AND GOOD LUCK
Tutorial contents
Basic:
Making custom CSC (.mbn)
Extracting SMD
How to work with "packed" partitions
What to edit in ROM
Packing SMD
Advanced:
Making CSC from MBN
Making developer ROM

Making custom CSC (.mbn)
Software
sam-tools
Any tool for mounting drive images (OSFMount)
MBN Creator
MBN Creator is a kitchen itself. It has some limitations, but creating MBNs with MBN Creator is very easy. This method is described in the end.
Unpacking CSC files
Official CSCs come in .csc files. Use smd-tool to unpack file.csc to csc_dump folder:
Code:
smd-tool /u file.csc /d csc_dump
Now mount DPP.bin and copy CSC.mbn file from it. Unmount DPP then.
Code:
\Samsung\CSC\CSC.mbn
Now use mbn-tool to extract files from csc.mbn to mbn_dump folder:
Code:
mbn-tool /u csc.mbn /d mbn_dump
Every folder in mbn_dump is for one CSC code. There are 4 files inside every folder (AUT for ex.):
SS_AUT.ini - init values for welcome screen (first boot). Language, region, timezone and carrier.
SS_AUT.reg - registry file.
SS_AUT_AppInstall.provxml - PROVXML file with (and only) install app instructions.
SS_AUT_CSC.xml - PROVXML file.
Warning! There is a size limit for any file ~50KB. MBN itself is limited to DPP free space.
Packing MBN
Code:
mbn-tool /p mbn_dump /f my.mbn /ver I8750OXXCMK2 /subver OXX
CSC version (I8750OXXCMK2) should be greater or equal to your ROM version. Otherwise it will be ignored. DOC2 CSC will work on CMK2 ROM, but not vice versa!
Warning! Official DNI and DOC ROMs don't support custom MBNs.
Using MBN Creator
You can apply predefined tweaks from 1st tab or add your own directly into files. Last tab contains MBN file properties. MBN Creator is limited to only one CSC code.
You can check your work in
Code:
MBN Creator temp
folder. Output file is CSC.mbn.
Flashing MBN with MBN Creator
Reboot phone into Download Mode
Connect to PC and install drivers
Copy or create CSC.mbn file
Press Flash, Scan
Choose CSC code and press Flash
All done. Reset phone. Perform HR if MBN didn't apply.
Warning! MBN Creator can't flash files larger than 64KB.
Flashing MBN with stock Downloader
Open .wp8 and .mbn files
Check "Select" and uncheck everything but "CSC"
If flasher asks you about something click NO

Extracting SMD
Software
sam-tools
Any tool for mounting drive images (OSFMount)
Unpack
Unpack file.wp8 to dump folder
Code:
smd-tool /u file.wp8 /d dump
Output example:
Code:
Partition name NAND off N size ROM off R size Part. ID Type Status
GPT 00000000 00000800 00200C00 0000FC00 00000000 00000000 [ OK ]
SECURE 00000800 00000800 00210800 00000400 00000001 00000000 [ OK ]
DPP 00001000 00004000 00210C00 00800000 00000002 00000000 [ OK ]
SBL1 00008000 00000BB7 00A10C00 0016A400 00000003 00000000 [ OK ]
SBL2 P 00009000 00000BB7 00B7B000 0016A400 00000004 00000000 [ OK ]
SBL3 0000A000 00000FFF 00CE5400 001F8000 00000005 00000000 [ OK ]
UEFI S 0000B000 00001387 00EDD400 00207C00 00000006 00000000 [ OK ]
RPM 0000D000 000003E7 010E5000 0006E400 00000007 00000000 [ OK ]
TZ 0000E000 000003E7 01153400 0006E400 00000008 00000000 [ OK ]
WINSECAPP 0000F000 000003FF 011C1800 0007E000 00000009 00000000 [ OK ]
PLAT 0001A000 00003FFF 0123F800 00742800 0000000A 00000000 [ OK ]
EFIESP 00020000 0001FFFF 01982000 0094A400 0000000B 00000000 [ OK ]
MMOS 00046000 0002403F 022CC400 0440B800 0000000C 00000000 [ OK ]
MainOS 0006C000 004B295F 066D7C00 61F20000 0000000D EACCE221 [ OK ]
Data 00520000 01838FFF 685F7C00 02920000 0000000E EACCE221 [ OK ]
Output files:
header - header of SMD
GPT - partition table
PLAT, EFIESP, MMOS - partitions with FAT file system
MainOS and Data - NTFS partitions
other files - bootloader and other low level stuff
DPP partition isn't flashed to phone. In wp8 file it's empty.
EACCE221 means that partition is packed.

How to work with "packed" partitions
Software
sam-tools
Any tool for mounting drive images (OSFMount)
Unpack
Large zero areas are cut off from those partitions. image-rebase can restore such files.
Code:
image-rebase /u MainOS.bin /o MainOS.img
You can now mount and edit MainOS.img.
Warning! Data partition is very large and almost empty.
Pack
First of all slice image file:
Code:
image-rebase /s MainOS.img /z 2048
This command will cut off zero areas larger than 2048 sectors (1MB).
MainOS.img.xml is a template file.
Now you can glue files together using template:
Code:
image-rebase /p MainOS.bin /t MainOS.img.xml

What to edit in ROM
CSCMgr
This service applies MBN file. The idea is to downgrade it to CMK2 (GDR3) version. To do so replace those files:
system32\CSCMgr.dll
system32\CSCMgrSvc.dll
system32\drivers\CSCMgrSvc.dll (yes, it's a copy)
FCRouter
This service is used by Samsung system tools to perform actions with high privileges. Files:
system32\FCRouter.dll
system32\FCRouterProxy.dll
system32\drivers\FCRouter.dll
system32\drivers\FCDriver.dll
Registry hives
Code:
system32\config
You can edit those hive as you want. But HR will destroy all you work.
OSRepack
It a simple tool to work with packages on mounted partitions. Available here.
SDelete
There is a tool called SDelete which can fill all free space on a drive with zeros.
Code:
sdelete -z X:
Very useful for non-developer ROMs.

Packing SMD
Software
sam-tools
Hex editor (HxD)
Pack MainOS image
Code:
image-rebase /s MainOS.img /z 2048
image-rebase /p MainOS.bin /t MainOS.img.xml
Prepare SMD header
It's not really a header but a first part of file. This file can be used as template for your later work. It contains all partitions except MainOS.
Code:
smd-tool /info file.wp8
This command will give you some info about SMD file structure. Open it in hex editor and copy all data up to MainOS ROM offset to a new file. Add Data.bin to this new file.
There are some structures at the start of file. For example:
4D 61 69 6E 4F 53 00 00 00 00 00 00 00 00 00 00
00 C0 06 00 5F 29 4B 00 00 7C FF 08 00 0E AD 61
1F 1F 1F 1F 00 00 00 00 21 E2 CC EA 00 00 00 00
2B C2 5E C9 6A 2F 0B E1 6F 1C 95 FC 49 FF E9 FD
Start and length are colored.
Warning! Those numbers are little endian (12345678 = 78 56 34 12)
Replace Data Start with MainOS Start. You can use Ctrl+C & Ctrl+B (copy and paste with replace).
Replace MainOS Start with length of this (template) file.
Save file.
Adding MainOS
Add MainOS.img to your template.
Replace MainOS Length with length (in bytes) of MainOS.bin file.
Replace 16 bytes at offset 0x50 with zeros.
Count MD5 hash of the file (HxD can do it) and write it at 0x50 (^C & ^B).
Save this file as .wp8
You can check numbers you entered with following command:
Code:
smd-tool /info custom.wp8
Warning! This .wp8 file can only be flashed with Downloader v3.54

Making CSC from MBN
Software
Hex editor (HxD)
Pack
Open CSC file in HxD.
At 0x00A00C00 it has MBN file contents.
Replace it with your MBN and fill rest of the CSC with zeros.
Warning! This file can't be unpacked with this instruction because FAT is broken. You can unpack it manually.
Correct MD5 as you did for WP8 file.
Warning! This CSC can fool Downloader but not phone. New CSCMgr will still ignore custom MBN.

Making developer ROM
Such ROMs can be directly mounted with OSFMount.
This command will pseudo slice MainOS.img:
Code:
image-rebase /s MainOS.img /z 4000000
Entire partition will be in one piece.
If you pack SMD with this file you can mount it and edit without repacking SMD.
In OSFMount enter offset equal to MainOS ROM offset + 0x1000.
Don't forget to recalculate MD5 after edit.

OMG, WOLF! People tell me that my tutorials are too long. But you are a true match for me!! :highfive:
Congrats on this great achievement! :victory:

Wow! Huge thanks for rewriting these tutorials in English; I wasn't expecting you to do it so soon! Can't wait to play around and to see what others come up with.

I play around with the replacement of files FC Router + WP8 Diag on my GT-I8750 (from the SM-W750V, SPH-I800, SGH-I187, SGH-T899M), in the end everything works.
Powered mode Smart Download.

so I could be possible to use ATIV S version of CSCMgr on SE. And SE then will have custom MBN

Yea, that's what I gathered from the info as well. Unfortunately I won't have time to try this out for another 4-7 days but I'll let you know if I do. And if you (or anyone else) feels like whipping it up and you need someone to try it, shoot me a PM.

Added info about sdelete and OSRepack to "What to edit in ROM"

I have an idea to record full process of ROM making and upload it on Youtube. Will it be useful?
Added poll.

Related

Please help with extracting files from non-xda ROM CE 4.0

I did a dump of non-xda device running CE 4.0 .net and am trying to extract the individual files. Here is the first 3F bytes:
00000000 4230 3030 4646 0A00 0022 0068 F5F5 0100 B000FF...".h....
00000010 0022 0010 0000 0057 0700 0090 9090 90E9 .".....W........
00000020 0F2F 0000 9090 9090 9090 9040 0022 0008 ./[email protected]"..
00000030 0000 0087 0200 0045 4345 432C B217 8200 .......ECEC,....
I have tried to used splitrom.pl to put convert to a format that dumprom.exe would like.
"splitrom.pl dtr.bin -wo out.bin" creates empty binary file
and..
Webpad_CE4>splitrom.pl dtr.bin
B000FF image: 00220000-0217f568, entrypoint: 00222f18
!!! your rom is not known to me: md5: a520f0d1093b36f0a3cfd9323ea99155
this bootloader seems to be No bootloader present
no xipchain found
Microsoft's viewbin.exe yields plenty of good results, but I am not sure how to apply them to splitrom.pl and dumprom.exe. Knowing starting starting offsets and lengths of individual files in ROM, can I manually extract/decompress files from ROM. Do I need the XIP chain to do this?
Thanks!
Success using dumprom on B000FF file type (non-xda)
Had to convert the nk.bin to a file that dumprom recognized using the platform builder tool "cvrtbin.exe" This created a nk.nb0 file that was dumped with dumprom.
Image start and length parameters for cvrtbin was obtained using viewbin.exe
cvrtbin.exe -r -a 00220000 -l 01F5F568 -w 32 nk.bin
Then I could dump the files using dumprom:
dumprom -3 nk.nb0 -d c:\dump
Had to use -3 decompression option even though this is a win ce 4.0 .net rom.

[REQ] Need a little help for porting my WM6 ROM on my MIO P550 / Airis T620

hello everybody
I'm a user of a mio p550. I'ma développor, and i want to port à wm6 rom for this pda, because there are many users of this pda, and i want to flash my pda on wm6 !
The mio p550 have three clones : the mio p350, the Aris T620, ans the Yakumo Delat X, so there are many many users of these pda, but no wm6 rom.
SO i have begun, but, it stay a little problem !
The only available flashable image is the "famous" "MioP550 - Osc260A R05_P09.nb0" file.
The header of it looks like:
Code:
00000000: 50 6f 63 6b 65 74 50 43 5f 32 30 30 35 00 00 00 PocketPC_2005...
00000010: 10 01 00 00 00 00 02 00 5a fc 35 00 00 00 00 00 ........Z.5.....
00000020: 4d 53 5f 49 50 4c 00 00 00 00 00 00 00 00 00 00 MS_IPL..........
00000030: 10 01 02 00 00 88 e9 01 70 1f ae 1c 00 00 00 00 ........p.......
00000040: 4f 53 5f 49 4d 41 47 45 00 00 00 00 00 00 00 00 OS_IMAGE........
00000050: 10 89 eb 01 00 00 02 00 de 1e f8 00 00 00 00 00 ................
00000060: 55 42 4f 4f 54 00 00 00 00 00 00 00 00 00 00 00 UBOOT...........
The structure is somewhat easy to see:
Code:
00000000: "Pocket_PC_2005" // some sort of signature. In UBOOT section I could find the very same string, so I'd assume the update loader checks it.
00000010: 10 01 00 00 // 4 bytes : offset of the 1st section -> 0x110
00 00 02 00 // 4 bytes : length of the 1st section -> 0x20000
5a fc 35 00 // 4 bytes : checksum -> 0x35fc5a
00 00 00 00 ...
00000020: "MS_IPL" // name/id of the 1st section
00000030: 10 01 02 00 // 4 bytes : offset of the 2nd section -> 0x20110
00 88 e9 01 // 4 bytes : length of the 2nd section -> 0x1e98800
70 1f ae 1c // 4 bytes : checksum -> 0x1cae1f70
00 00 00 00 ...
00000040: "OS_IMAGE" // name/id of the 2nd section
00000050: 10 89 eb 01 // 4 bytes : offset of the 3rd section -> 0x1eb8910
00 00 02 00 // 4 bytes : length of the 3rd section -> 0x20000
de 1e f8 00 // 4 bytes : checksum -> 0xf81ede
00 00 00 00 ...
00000060: "UBOOT" // name/id of the 3rd section
You can split the nb0 file into the corresponding parts based on the above informacion. Use your favourite hex editor, or write a script , or ... you can use dump from itsutils like below.
Code:
dump -o 0x110 -l 0x20000 "MioP550 - Osc260A R05_P09.nbh" MS_IPL.nb
dump -o 0x20110 -l 0x1e98800 "MioP550 - Osc260A R05_P09.nbh" OS_IMAGE.nb
dump -o 0x1eb8910 -l0x20000 "MioP550 - Osc260A R05_P09.nbh" BOOT.nb
The OS_IMAGE.nb file you get, can be used in most of the kitchens. The only special thing, that is has 512+8 (data+spare) bytes structure. Tadzio's imgfs tools can handle that. Below is some example output.
Code:
NBSplit.exe -data 512 -extra 8 OS_IMAGE.nb
NBSplit 2.1rc2
Using data chunk size = 0x200 and extra chunk size = 0x8
on file OS_IMAGE.nb
Done.
Code:
NBInfo.exe OS_IMAGE.nb.payload
NBInfo 2.1rc2
'OS_IMAGE.nb.payload' has valid boot sector
Partition table:
Partition 0
-----------
File System: 0x20 (boot)
Start Sector: 0x00000002
Total Sectors: 0x000008fe
Boot indicator: 0x00
First Head: 0x02
First Sector: 0x01
First Track: 0x00
Last Head: 0xff
Last Sector: 0x01
Last Track: 0x08
Partition 1
-----------
File System: 0x23 (XIP RAM)
Start Sector: 0x00000900
Total Sectors: 0x00000f00
Boot indicator: 0x00
First Head: 0x00
First Sector: 0x01
First Track: 0x09
Last Head: 0xff
Last Sector: 0x01
Last Track: 0x17
Partition 2
-----------
File System: 0x25 (imgfs)
Start Sector: 0x00001800
Total Sectors: 0x0000d500
Boot indicator: 0x00
First Head: 0x00
First Sector: 0x01
First Track: 0x18
Last Head: 0xff
Last Sector: 0x01
Last Track: 0xec
Partition 3
-----------
File System: 0x04 (FAT)
Start Sector: 0x0000ed00
Total Sectors: 0x003f0c00
Boot indicator: 0x00
First Head: 0x00
First Sector: 0x01
First Track: 0xed
Last Head: 0xff
Last Sector: 0x01
Last Track: 0x1f8
Geometry: flash has 256 virtual heads
MSFLSH50 header found at offset 0x200
(0 Reserved Entries, 3 Flash Region Entries)
Flash Region Entry 0:
---------------------
Region type: XIP
Start phys. block: 0x00000000
Size in phys. blocks: 0x00000000
Size in log. blocks: 0x00000018 -> Size in sectors: 0x00001800
Sectors per block: 0x00000100
Bytes per block: 0x00020000
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: 0x000000d5 -> Size in sectors: 0x0000d500
Sectors per block: 0x00000100
Bytes per block: 0x00020000
Compact blocks: 0x00000002
-> Bytes per sector: 0x00000200
Flash Region Entry 2:
---------------------
Region type: FILESYS
Start phys. block: 0x00000000
Size in phys. blocks: 0x00000000
Size in log. blocks: 0xffffffff -> Size in sectors: 0xffffff00
Sectors per block: 0x00000100
Bytes per block: 0x00020000
Compact blocks: 0x00000002
-> Bytes per sector: 0x00000200
Searching for IMGFS signature...
Found IMGFS at byte 0x00340000 (sector 0x00001a00).
dwFSVersion: 00000001
dwSectorsPerHeaderBlock: 00000001
dwRunsPerFileHeader: 00000001
dwBytesPerHeader: 00000034
dwChunksPerSector: 00000008
dwFirstHeaderBlockOffset: 00000200
dwDataBlockSize: 00001000
szCompressionType: LZX
dwFreeSectorCount: 000135F5
dwHiddenSectorCount: 00000100
dwUpdateModeFlag: 00000000
---
Now you can extract all parts. The SRXP compressed XIP part you need for cooking. You can use msflshtool to extract it, srpx2xip to decompress and dumprom to dump it. All these tools you can find in Scoter Kitchen. You can use Tadzio's imgfs tool to dump/modify/build the IMGFS part. You can collect the rest of the tools you need, depending on the modification you plan.
Based on the above header description, you can easily assemble a flashable image. The checksums are checked, but a wrong checksum does not prevent the flasing procedure . My today's finding : the checksum calculatin is rather easy, just create a 32 byte masked sum of all the bytes in the region in little endian format
I hope this helps for those interested in P550 ROM cooking.
-------
In addition, i possed a dump of a mio p560 rom ( which is the mio p550 with wm6),.
The 3 files here in the P560 dump correspond to Partition0/1/2 in that description. With a hexeditor you can fabricate an MBR and an MSFLSH50 header that corrensponds to P560 partition sizes and inject P560 raw files into the nb0 file and you can flash that. And there's a chance that you brick your device
I took a look at the part01.raw and what makes me sceptic, in OEM KERNEL package P560 uses a different flash driver than P550. So hw is not necessarily the same. And the above method without further cooking might not work smoothly.
Anyway as P560 is really close to P550 in hw, the above dump can be really useful in cooking a WM6 for P550. So I believe we would need help from an experience chef to proceed
So , i don't know how to do, but i want to adapt the rom !
Please, Please, Please, I need help
Is there any god who can help me !
Great thanks !!!!
Nixeus
175 view and no a little answer
Nixeus said:
175 view and no a little answer
Click to expand...
Click to collapse
Soory, but can't help you...
Maybe you should change te name of the topic, because it doesn't say anything about the real subject of the first post...
Hope someone will come by to help you...
Nixeus said:
175 view and no a little answer
Click to expand...
Click to collapse
Dear Nixeus, I agree with rvdgeer, I've been following this thread and waiting for a reply/solution all this time for my MIO P550, so please change the title of this thread to [REQ] or something very similar... Thanks.
I hope you'll find help, it would be awesome a wm6 or wm6.1 rom for my p350!
There are more and more person who wants wm6 or 6.1 for these pda, but no body help me......
I would like to help you, but the only thing I could do for you is an italian translation but i don't think it's gonna help..
I think it's not coming help here.. Are you keeping up the work?
Thanks all you had done for us! However, I am not a specialist on this. Can you please make a *.nb0 file using MioP560 with WM6 dump file? If it can be uploaded to rapidshare.com, it is easy to get it for us.
Thanks in advance.
Anson
Nixeus said:
hello everybody
I'm a user of a mio p550. I'ma développor, and i want to port à wm6 rom for this pda, because there are many users of this pda, and i want to flash my pda on wm6 !
The mio p550 have three clones : the mio p350, the Aris T620, ans the Yakumo Delat X, so there are many many users of these pda, but no wm6 rom.
SO i have begun, but, it stay a little problem !
The only available flashable image is the "famous" "MioP550 - Osc260A R05_P09.nb0" file.
The header of it looks like:
Code:
00000000: 50 6f 63 6b 65 74 50 43 5f 32 30 30 35 00 00 00 PocketPC_2005...
00000010: 10 01 00 00 00 00 02 00 5a fc 35 00 00 00 00 00 ........Z.5.....
00000020: 4d 53 5f 49 50 4c 00 00 00 00 00 00 00 00 00 00 MS_IPL..........
00000030: 10 01 02 00 00 88 e9 01 70 1f ae 1c 00 00 00 00 ........p.......
00000040: 4f 53 5f 49 4d 41 47 45 00 00 00 00 00 00 00 00 OS_IMAGE........
00000050: 10 89 eb 01 00 00 02 00 de 1e f8 00 00 00 00 00 ................
00000060: 55 42 4f 4f 54 00 00 00 00 00 00 00 00 00 00 00 UBOOT...........
The structure is somewhat easy to see:
Code:
00000000: "Pocket_PC_2005" // some sort of signature. In UBOOT section I could find the very same string, so I'd assume the update loader checks it.
00000010: 10 01 00 00 // 4 bytes : offset of the 1st section -> 0x110
00 00 02 00 // 4 bytes : length of the 1st section -> 0x20000
5a fc 35 00 // 4 bytes : checksum -> 0x35fc5a
00 00 00 00 ...
00000020: "MS_IPL" // name/id of the 1st section
00000030: 10 01 02 00 // 4 bytes : offset of the 2nd section -> 0x20110
00 88 e9 01 // 4 bytes : length of the 2nd section -> 0x1e98800
70 1f ae 1c // 4 bytes : checksum -> 0x1cae1f70
00 00 00 00 ...
00000040: "OS_IMAGE" // name/id of the 2nd section
00000050: 10 89 eb 01 // 4 bytes : offset of the 3rd section -> 0x1eb8910
00 00 02 00 // 4 bytes : length of the 3rd section -> 0x20000
de 1e f8 00 // 4 bytes : checksum -> 0xf81ede
00 00 00 00 ...
00000060: "UBOOT" // name/id of the 3rd section
You can split the nb0 file into the corresponding parts based on the above informacion. Use your favourite hex editor, or write a script , or ... you can use dump from itsutils like below.
Code:
dump -o 0x110 -l 0x20000 "MioP550 - Osc260A R05_P09.nbh" MS_IPL.nb
dump -o 0x20110 -l 0x1e98800 "MioP550 - Osc260A R05_P09.nbh" OS_IMAGE.nb
dump -o 0x1eb8910 -l0x20000 "MioP550 - Osc260A R05_P09.nbh" BOOT.nb
The OS_IMAGE.nb file you get, can be used in most of the kitchens. The only special thing, that is has 512+8 (data+spare) bytes structure. Tadzio's imgfs tools can handle that. Below is some example output.
Code:
NBSplit.exe -data 512 -extra 8 OS_IMAGE.nb
NBSplit 2.1rc2
Using data chunk size = 0x200 and extra chunk size = 0x8
on file OS_IMAGE.nb
Done.
Code:
NBInfo.exe OS_IMAGE.nb.payload
NBInfo 2.1rc2
'OS_IMAGE.nb.payload' has valid boot sector
Partition table:
Partition 0
-----------
File System: 0x20 (boot)
Start Sector: 0x00000002
Total Sectors: 0x000008fe
Boot indicator: 0x00
First Head: 0x02
First Sector: 0x01
First Track: 0x00
Last Head: 0xff
Last Sector: 0x01
Last Track: 0x08
Partition 1
-----------
File System: 0x23 (XIP RAM)
Start Sector: 0x00000900
Total Sectors: 0x00000f00
Boot indicator: 0x00
First Head: 0x00
First Sector: 0x01
First Track: 0x09
Last Head: 0xff
Last Sector: 0x01
Last Track: 0x17
Partition 2
-----------
File System: 0x25 (imgfs)
Start Sector: 0x00001800
Total Sectors: 0x0000d500
Boot indicator: 0x00
First Head: 0x00
First Sector: 0x01
First Track: 0x18
Last Head: 0xff
Last Sector: 0x01
Last Track: 0xec
Partition 3
-----------
File System: 0x04 (FAT)
Start Sector: 0x0000ed00
Total Sectors: 0x003f0c00
Boot indicator: 0x00
First Head: 0x00
First Sector: 0x01
First Track: 0xed
Last Head: 0xff
Last Sector: 0x01
Last Track: 0x1f8
Geometry: flash has 256 virtual heads
MSFLSH50 header found at offset 0x200
(0 Reserved Entries, 3 Flash Region Entries)
Flash Region Entry 0:
---------------------
Region type: XIP
Start phys. block: 0x00000000
Size in phys. blocks: 0x00000000
Size in log. blocks: 0x00000018 -> Size in sectors: 0x00001800
Sectors per block: 0x00000100
Bytes per block: 0x00020000
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: 0x000000d5 -> Size in sectors: 0x0000d500
Sectors per block: 0x00000100
Bytes per block: 0x00020000
Compact blocks: 0x00000002
-> Bytes per sector: 0x00000200
Flash Region Entry 2:
---------------------
Region type: FILESYS
Start phys. block: 0x00000000
Size in phys. blocks: 0x00000000
Size in log. blocks: 0xffffffff -> Size in sectors: 0xffffff00
Sectors per block: 0x00000100
Bytes per block: 0x00020000
Compact blocks: 0x00000002
-> Bytes per sector: 0x00000200
Searching for IMGFS signature...
Found IMGFS at byte 0x00340000 (sector 0x00001a00).
dwFSVersion: 00000001
dwSectorsPerHeaderBlock: 00000001
dwRunsPerFileHeader: 00000001
dwBytesPerHeader: 00000034
dwChunksPerSector: 00000008
dwFirstHeaderBlockOffset: 00000200
dwDataBlockSize: 00001000
szCompressionType: LZX
dwFreeSectorCount: 000135F5
dwHiddenSectorCount: 00000100
dwUpdateModeFlag: 00000000
---
Now you can extract all parts. The SRXP compressed XIP part you need for cooking. You can use msflshtool to extract it, srpx2xip to decompress and dumprom to dump it. All these tools you can find in Scoter Kitchen. You can use Tadzio's imgfs tool to dump/modify/build the IMGFS part. You can collect the rest of the tools you need, depending on the modification you plan.
Based on the above header description, you can easily assemble a flashable image. The checksums are checked, but a wrong checksum does not prevent the flasing procedure . My today's finding : the checksum calculatin is rather easy, just create a 32 byte masked sum of all the bytes in the region in little endian format
I hope this helps for those interested in P550 ROM cooking.
-------
In addition, i possed a dump of a mio p560 rom ( which is the mio p550 with wm6),.
The 3 files here in the P560 dump correspond to Partition0/1/2 in that description. With a hexeditor you can fabricate an MBR and an MSFLSH50 header that corrensponds to P560 partition sizes and inject P560 raw files into the nb0 file and you can flash that. And there's a chance that you brick your device
I took a look at the part01.raw and what makes me sceptic, in OEM KERNEL package P560 uses a different flash driver than P550. So hw is not necessarily the same. And the above method without further cooking might not work smoothly.
Anyway as P560 is really close to P550 in hw, the above dump can be really useful in cooking a WM6 for P550. So I believe we would need help from an experience chef to proceed
So , i don't know how to do, but i want to adapt the rom !
Please, Please, Please, I need help
Is there any god who can help me !
Great thanks !!!!
Nixeus
Click to expand...
Click to collapse
hi
how could i use the 3 raw files of p560 rom to restore seflash my p560?
thanks
please
please please please teach me how to make MBR and an MSFLSH50 header.
I own an p560 but in an atempt to dump rom it was broken, i d/ont know why but at the restart after mio logo and at the expected windows screen the lcd remain white and that is all, nothing happen after...
Here is a solution in order to maker a wm6 rom for our mio p550 / Airis T620 !
Thanks to ASAM !!
http://www.miousers.co.uk/viewtopic.php?t=4068

[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.

How To: Apply Rogers update without losing fastboot or data

When Rogers released a new ROM for the Dream this week, I was all excited to have the SMS bug finally fixed and see what else has change... but... I didn't want to lose fastboot or all of my data and settings. So, I figured out how to apply part of the Rogers update to my phone (boot.img and system.img ONLY). My phone still has the stock SPL (1.33.0009) and radio. Here's how I did it. These directions aren't for everyone... here's what you need to know to do this:
Hex editing, extracting a chunk of data from one file into a new one
Using a recovery image to flash boot and replace /system
WARNING: MAKE A NANDROID BACKUP FIRST!
THIS HAS ONLY BEEN TESTED BY ME, SO USE AT YOUR OWN RISK!
Here's what I did:
1.
Grab the update file from rogers.com/techsupport: RUU_Dream_Rogers_WWE_1.86.631.1_release_signed_NoDriver.exe
2.
Don't plug your phone into USB (we won't need it!). Run the updater. When it gets to the first prompt, find the installer files in your temp directory. For example, C:\Documents And Settings\Username\Local Settings\Temp. There will be a file in {Random GUID}\{Random GUID}\rom.nbh. I had to run the installer a couple times before I could find this file. Copy it to a safe place and cancel the update installer.
3.
Open the file with a hex editor. At offset 0x240 you should see:
Code:
000240 00 00 50 01 00 00 08 00 00 b0 04 00 00 e0 1c 00
01500000 00080000 0004b000 001ce000
000250 00 48 19 00 00 b5 c7 04 40 08 00 00 00 00 00 00
00194800 04c7b500 00000840 00000000
These are the sizes of the different images. The order is:
radio.img / SPL / Rogers Logo (splash1) / recovery.img
boot.img / system.img / data.img / NULL
4.
Extract each of the images (well, at least boot and system). radio.img starts at offset 0x300. Place them on your phone's SD card.
The md5sums of the files that I have are:
Code:
57d1e20d3b00ea8eb45359849d8c9e30 boot.img
16d47f934d457a1d5681eed966603af3 radio.img
a480ef5fc3c526fc3b8e015710c93deb recovery.img
7c7bc04f584c7c2f3276e6940fb1d0a5 spl.img
715e89c778663da946f5e9026153d480 splash1.img
328da2f5c5b37a8992710662c33e25ea system.img
19ecc8995c7a1f7669104a1a973975fb userdata.img
5.
Go into fastboot on your phone, run "fastboot erase system".
6.
Fastboot your phone with a recovery image that has a nandroid restore tool. I used the initrd from Amon_RA's Recovery Image RAv1.2.1G and the kernel from the stock Rogers recovery image.
7.
Use the nandroid restore to flash boot.img and system.img. You can probably use nandroid restore from the menu in Amon_RA's Recovery if you place the boot and system files from step 4 in the right place. I ended up flashing manually from an adb shell just so I could see what was going on:
Code:
mount -o rw -t yaffs2 /dev/block/mtdblock3 /system
cd /system
unyaffs /sdcard/rogers-update/system.img
# Note that we did step 5 so that /system would be nice and empty before using unyaffs.
cat /dev/zero >> /dev/mtd/mtd2
/system/bin/flash_image boot /sdcard/rogers-update/boot.img
8.
Reboot your phone and wait a long time while it rebuilds the cache. You can do an "adb logcat" to watch it scan every app while it's booting.
Done!
PS: This probably works for the Magic too, but the sizes of the images may be different. I haven't tried downloading the Magic update to check.

[REF] GT-I9305 hardware hacking

Dear Hardware Hackers, Geeks and Modders,
it always takes some time for me to switch over to a "new" device
Recently i bought a GT-I9305 for cheap, to be more exactely bought two; a broken and a working one.
Anyway, as always i need to disassemble my toys, see what's inside and investigate how things work out on the hardware base.
To follow my descriptions and findings in this thread it is recommended to grab the service manual, e.g. at cpkb.org.
As usual there are already many technical threads covering some of the hardware issues.
It's time to put some light on the unknown details here.
Starting a few weeks ago there'd been some time for reverse engineering, study documents, read posts and draw some conclusions.
I hope you'll enjoy my discoveries and give some feedback.
It might take some time though to write down everything even more detailed and get it little bit structured to post it here.
SD-card mode or complete brick recovery by re-write internal bootloader:
The sboot bootloader is capable to start from external SD-card as well and detects the media it has been started from.
To re-write the bootloader in the internal eMMC, we need an external boot media and block the internal boot process at power up.
The SD-card needs a special structure with the sboot binary right in place.
There's already a detailed thread about this procedure (see the reference links below).
Anyway, as you might have read elsewhere, replacing KNOX bootloader with an older one will not work.
The first time a KNOX bootloader is installed on the device,
some hardware protected blocks on the eMMC become active to meet the requirements of the KNOX function.
This process could not be reverted by simply overwrite the sboot section.
We need other tools for this. This might be covered later.
Prevent booting from internal eMMC by blocking MMC_CMD:
GT-I9300:
eMMC44_CH4: MMC_CMD is blocked by shorting the pull-up resistor R313
GT-I9305:
eMMC44_CH4: MMC_CMD is blocked by shorting the pull-up resistor R634
Please refer to the service manual for the correct position of the components.
Bootloader recovery will need some proof of concept, to be 100% certain that it works in the same way, as it does on GT-I9300.
SD-card booting by changing the CPU boot mode (permanently):
The boot code is set at power up by reading the logic level at special IO pins (XOM6:0).
These logic levels are set by a bunch of resistors and could be tweaked.
The boot modes for Exynos 4412 known so far:
Code:
XOM[5:1] : 1st device : 2nd device
5b'00010 : SDMMC_CH2 : USB
5b'00011 : eMMC43_CH0 : USB
5b'00100 : eMMC44_CH4 : USB
5b'10011 : eMMC43_CH0 : SDMMC_CH2
5b'10100 : eMMC44_CH4 : SDMMC_CH2
GT-I9305 (default, might need some approval by reading the registers):
Code:
XOM[5:1]
5b'10100 : eMMC44_CH4 : SDMMC_CH2
XOM0 : R612 10K PU
XOM1 : R614 100K PD
XOM2 : R615 100K PD
XOM3 : R609 10K PU
XOM4 : R616 100K PD
XOM5 : R610 10K PU
XOM6 : R617 100K PD
GT-I9305 (SD-card boot mode, needs testing!!!):
Code:
XOM[5:1]
5b'00010 : SDMMC_CH2 : USB
XOM0 : R612 10K PU (no change here)
XOM1 : R614 100K PD (no change here)
XOM2 : R615 10K PU (changed from PD to PU)
XOM3 : R609 100K PD (changed from PU to PD)
XOM4 : R616 100K PD (no change here)
XOM5 : R610 100K PD (changed from PU to PD)
XOM6 : R617 100K PD (no change here)
This relationship had been partly reverse engineered and concluded from other designs.
May need some approval though.
Same here, external booting from SD-card will need some proof of concept, to be 100% certain that it works without flaws.
There's a uncertainty concerning standard sboot, to allow a complete boot into system level (e.g. recovery) using a non default boot mode.
Maybe the code is bound to the device (internal eMMC only) in some way, or external SD-card is not fully supported as boot media.
Anyway, it is straight forward to build up a SD-card for testing.
The kernel boot parameter and parts of recovery image will need some tweaks to use the right device to boot from.
Direct access to Exynos 4412 debug UART:
The debug UART is permanently accessible on connector HDC401 (no need to block the USB port for this feature).
AP_TXD : HCD401, pin 11 (LVTTL 1.8V)
AP_RXD : HCD401, pin 17 (LVTTL 1.8V)
Please refer to the service manual for the position of connector HCD401.
These signals are fully tested and working.
The best would be to get the counter part of Panasonic AXE620124AW1 for a direct connection,
but this parts seems tobe hard to find.
As an alternative you'll need some very fine soldering iron and some tiny wires.
This way you could solder the wires directly to the pins of the connector.
You'll need some 1.8V level converter (+ USB UART) as already to be found in many projects.
Set up your terminal to 8N1 at 115200Bit/s and there you go.
E.g. enter S-Boot command line by hitting enter at boot up:
Code:
PMIC rev = PASS2(4)
cardtype: 0x00000007
SB_MMC_HS_52MHZ_1_8V_3V_IO
mmc->card_caps: 0x00000311
mmc->host_caps: 0x00000311
mmc_initialize: mmc->capacity = 30777344
Samsung S-Boot 4.0-1153417 for GT-I9305 (May 29 2013 - 17:22:39)
EXYNOS4412(EVT 1.1) / 2047MB / 15028MB / Rev 2 / I9305XXBME3
initialize_ddi_data: usable! (0:0x0)
PARAM ENV VERSION: v1.0..
init_fuelgauge: fuelgauge power ok
get_battery_detect: battery is missed
init_fuelgauge: battery is not detected, vcell(3858), soc(59)
init_fuelgauge: POR status
fuelgauge_por: POR start: vcell(3858), vfocv(3871), soc(59)
fuelgauge_por: update SDI M0 parameter
fuelgauge_por: RCOMP(0x0063), TEMPCO(0x0930)
fuelgauge_por: POR finish: vcell(3856), vfocv(3901), soc(55)
get_table_soc: vcell(3855) is caculated to t-soc(62.486)
init_fuelgauge: start: vcell(3855), vfocv(3898), soc(55), table soc(62)
init_fuelgauge: finish: vcell(3855), vfocv(3898), soc(55), table soc(62)
init_microusb_ic: MUIC: CONTROL1:0x00
init_microusb_ic: MUIC: CONTROL1:0x00
init_microusb_ic: MUIC: CONTROL2:0x3b
init_microusb_ic: MUIC: CONTROL2:0x3b
PMIC_ID = 0x02
PMIC_IRQSRC = 0x00
PMIC_STATUS1 = 0x10
PMIC_STATUS2 = 0x00
PMIC_PWRON = 0x02
PMIC_IRQ1 = 0x0c
PMIC_IRQ2 = 0x00
s5p_check_keypad: 0x0
s5p_check_reboot_mode: INFORM3 = 0 ... skip
s5p_check_upload: MAGIC(0xc0c0c0c0), RST_STAT(0x10000)
microusb_get_attached_device: STATUS1:0x38, 2:0x00
s5p_check_download: 0
microusb_get_attached_device: STATUS1:0x38, 2:0x00
check_pm_status: chargable jig, LPM boot
AST_CHARGING..
cmu_div:1, div:7, src_clk:800000000, pixel_clk:57153600
s6e8ax0_read_id :: retry: 1
s6e8ax0_read_id :: 0xd1
<start_checksum:373>CHECKSUM_HEADER_SECTOR :4096
<start_checksum:375>offset:50, size:6296
<start_checksum:379>CHECKSUM_HEADER_INFO : NeedChecksum:0 PartNo:20
Not Need Movinand Checksum
Movinand Checksum Confirmation Pass
autoboot aborted..
S-BOOT #
S-BOOT # help
Following commands are supported:
* chipinfo
* help
* log
* reset
* boot
* load_kernel
* printenv
* setenv
* saveenv
* findenv
* checksum_need
* usb
* upload
* keyread
* readadc
* usb_read
* usb_write
* sdcard
* mmcdtest
* fuelgauge
To get commands help, Type "help <command>"
S-BOOT #
That's it by now!
Consider this as a starter, i'll try to add, correct or change some things from time to time and i hope it's human readable
Please give me some feedback or tell me your thoughts
I will add pics as soon as possible and further details if there's some interest.
I will also give some credits soon, because some of these findings are based on information from the curious around here
Credits:
AdamOutler
E:V:A
References:
GT-I9300 hard-brick-fix
http://forum.xda-developers.com/galaxy-s3/general/galaxy-s-iii-gt-i9300-hard-brick-fix-t1916796
Totally Revolutionary SDCard Bootloader For Galaxy S III
http://forum.xda-developers.com/galaxy-s3/general/totally-revolutionary-sdcard-bootloader-t2061437
Port SDCard Recovery to Other Exynos4412 Devices
http://forum.xda-developers.com/showthread.php?p=34732948
Knox reset
http://forum.xda-developers.com/showthread.php?t=2504258
eMMC sudden death research
http://forum.xda-developers.com/showthread.php?t=2096045
NOTE:
I am not responsible for any damaged devices.
The technical information may need some verification by experiments!
It would be nice to add a remark and refer to this post, if you use the pics and information from this thread :highfive:
Cheers,
scholbert
technical info, datasheets... stuff
eMMC function, structure and usage
1. Basic info
The onboard eMMC is the mass storage of our device.
There's much more under the hood, than you might expect and notice during normal usage within the OS.
The area we may access from within Android OS is called USER area (all partitions belong to this area).
This part could be easily accessed and you may back up all data of this area to a disk image.
Apart from that, the eMMC is used as secure boot media.
On some of the ICS kernels there was a block device called /dev/mmcblk0boot0 (protected by ro-flag).
This device node is missing on most of the S3 devices and hence it is not possible to access this part.
Anyway, it is hidden area where Samsung placed the bootloader and stuff, the BOOT area.
If you are using still ICS bootloader it consists of at least 2 parts:
2MB area for BL1 (s-boot+TZSW+ddi-data)
2MB area for BL2 (not used, zeroed out)
If you upgraded to JB/KK bootloder another part is setup up and configured:
RPMB (KNOX counter, etc.)
I found no information about the size, but it's a multiple of 128K and may be set up between 128-512K.
Once activated the information stored in this area is controlled by internal security mechanism of eMMC.
Only trusted code is granted access and even worse, from a users sight it acts like OTP memory.
To get some info about the eMMC built in your device the sysfs entries are a good place to start.
We could grep the type of device form here, e.g. the eMMC in my GT-I9305 gives this output:
Code:
# cd /sys/class/block/mmcblk0/device
# cat name
MAG4FB
# cat manfid
0x000015
# cut -b 19,20 cid
f7 // this is the firmware revision in hex
# cat date
09/2012
See the datasheet attached (this is the exact part)
2. EFI partition and GPT
The first block of USER area of starts with traditional MBR.
Next block starts with the header for the EFI partition which is the base container for all other parts.
Code:
[SIZE="2"]45 46 49 20 50 41 52 54 Signature "EFI PART"
00 00 01 00 GPT version 1.0
00 02 00 00 header size 512 Bytes
5B DF 6D 84 CRC32 of header
00 00 00 00 reserved
01 00 00 00 00 00 00 00 Current LBA (location of this header copy)
FF 9F D5 01 00 00 00 00 Backup LBA (location of the other header copy)
22 00 00 00 00 00 00 00 First usable LBA for partitions (primary partition table last LBA + 1)
DE 9F D5 01 00 00 00 00 Last usable LBA (secondary partition table first LBA - 1)
41 4E 44 52 4F 49 44 20 4D 4D 43 20 44 49 53 4B ANDROID MMC DISK
02 00 00 00 00 00 00 00 Starting LBA of array of partition entries (always 2 in primary copy)
80 00 00 00 Number of partition entries in array
80 00 00 00 Size of a single partition entry (usually 128)
28 53 B2 A4 CRC32 of partition array
00 00 00 00[/SIZE]
The rest of this block is the GPT.
Reference:
http://en.wikipedia.org/wiki/GUID_Partition_Table
Other useful reading:
http://forum.xda-developers.com/showpost.php?p=31254495
3. PIT
This is another essential part of the USER area of eMMC and defines all partitions used by the OS.
Here's the definition of the internal structure:
Code:
[SIZE="2"]typedef int __s32;
typedef unsigned int __u32;
#define PARTITION_MAGIC 0x12349876
typedef struct _partition_header {
__u32 dwMagic; /* MAGIC CODE */
__s32 nCount; /* PARTITION (OneNAND + MOVINAND) */
/* PIT Option. */
__s32 dummy[5];
} __attribute__((packed)) partition_header;
typedef struct _partition_info {
__s32 nBinType; /* BINARY_TYPE_ (AP or CP?) */
__s32 nDevType; /* PARTITION_DEV_TYPE_ */
__s32 nID; /* PARTITION ID */
__s32 nAttribute; /* PARTITION_ATTR_ */
__s32 nUpdateAttr; /* PARTITION_UPDATE_ATTR_ */
__u32 dwBlkSize; /* BLOCK SIZE / OFFSET IN BLOCKS */
__u32 dwBlkLen; /* BLOCK LENGTH */
__u32 dwOffset; /* FILE OFFSET (obsolete) */
__u32 dwFileSize; /* FILE SIZE (obsolete) */
char szName[32]; /* PARTITION NAME */
char szFileName[32]; /* FILE NAME */
char szDeltaName[32]; /* DELTA FILE NAME FOR BOOTLOADER FOTA */
} __attribute__((packed)) partition_info;[/SIZE]
Example:
Code:
[SIZE="2"]BOOTLOADER:
00 00 00 00 nBinType; /* BINARY_TYPE_ (AP or CP?) */
02 00 00 00 nDevType; /* PARTITION_DEV_TYPE_ */
50 00 00 00 nID; /* PARTITION ID */
02 00 00 00 nAttribute; /* PARTITION_ATTR_ */
01 00 00 00 nUpdateAttr; /* PARTITION_UPDATE_ATTR_ */
00 00 00 00 dwBlkSize; /* BLOCK SIZE / BLOCK OFFSET */
C6 06 00 00 dwBlkLen; /* BLOCK LENGTH */
00 00 00 00 dwOffset; /* FILE OFFSET (in TAR) */
00 00 00 00 dwFileSize; /* FILE SIZE */
szName[32]; /* PARTITION NAME */
42 4F 4F 54 4C 4F 41 44 45 52 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
szFileName[32]; /* FILE NAME */
73 62 6F 6F 74 2E 62 69 6E 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
szDeltaName[32]; /* DELTA FILE NAME FOR BOOTLOADER FOTA */
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00[/SIZE]
4. Complete partition table (GT-I9305)
Code:
[SIZE="2"]Block Size = 0x200
BOOT AREA:
Partition Image Name OFFSET LEN in BLK LEN OS Partition Physical Partition
BOOTLOADER sboot.bin 0x00000000 0x06C6 0x000D8C00 0x50 0x50
TZSW tz.img 0x000D8C00 0x0138 0x00027000 0x51 0x51
DDI-DATA (DATA) - 0x000FFC00 0x0001 0x00000200
USER AREA:
Partition Name Image Name OFFSET LEN in BLK LEN OS Partition Physical Partition
eMMC MBR (MBR) - 0x00000000 0x0001 0x00000200
EFI PART (GPT) - 0x00000200 0x0001 0x00000200
PIT m3.pit 0x00004400 0x0010 0x00002000 0x46 0x46
MD5HDR md5.img 0x00006400 0x0800 0x00100000 0x47 0x47
BOTA0 - 0x00400000 0x2000 0x00400000 0p1 0x01
BOTA1 - 0x00800000 0x2000 0x00400000 0p2 0x02
EFS efs.img 0x00C00000 0xA000 0x01400000 0p3 0x03
m9kefs1 m9kefs1.bin 0x02000000 0x2000 0x00400000 0p4 0x04
m9kefs2 m9kefs2.bin 0x02400000 0x2000 0x00400000 0p5 0x05
m9kefs3 m9kefs3.bin 0x02800000 0x2000 0x00400000 0p6 0x06
PARAM param.bin 0x02C00000 0x4000 0x00800000 0p7 0x07
BOOT boot.img 0x03400000 0x4000 0x00800000 0p8 0x08
RECOVERY recovery.img 0x03C00000 0x4000 0x00800000 0p9 0x09
RADIO modem.bin 0x04400000 0x2c000 0x05800000 0p10 0x0A
TOMBTONES tombstones.img 0x09C00000 0x80000 0x10000000 0p11 0x0B
CACHE cache.img 0x19C00000 0x200000 0x40000000 0p12 0x0C
SYSTEM system.img 0x59C00000 0x300000 0x60000000 0p13 0x0D
HIDDEN hidden.img 0xB9C00000 0x118000 0x23000000 0p14 0x0E
OTA - 0xDCC00000 0x4000 0x00800000 0p15 0x0F
USERDATA userdata.img 0xDD400000 0x0000 0p16 0x10
[/SIZE]
5. DDI-DATA
In the hidden boot0 partition the values like the flash count are stored.
Triangle away is able to modify this data.
It's stored at 0x000FFC00 on the boot0 partition of emmc.
Code:
struct ddi_data {
int magic; // must be 0x12340012
int custom_flash_count;
int odin_count;
int binary_type; // 0 = samsung official, 1 = custom, 2 = "Unknown"
char model_name[16];
int rom_type; // this is the first 4 bytes of the decrypted 16 bytes
in the param partition. 0xFF000000 = samsung, 0xEE000000 = custom }
For details please refer to this post:
http://forum.xda-developers.com/showthread.php?p=28953690#post28953690
Further useful reading:
http://wiki.cyanogenmod.org/w/EMMC_Bugs
Thesis:
Remove KNOX bit by eMMC low level format command:
With KNOX activation at booloader level, there's an area which stores the KNOX bit information called RPMB.
During research of the eMMC sudden death, some firmware files for the eMMC controller had been reverse engineered and some of the custom commands had been discovered.
Read this and follow ups:
http://forum.xda-developers.com/showpost.php?p=49548099&postcount=121
By changing the boot mode and boot up completely from SD-card into special recovery, it might be possible to send this command with a tool called mmc-utils:
https://github.com/BenGardiner/mmc-utils
Because this will wipe out everything, it would be a great adventure and you'll need a proper backup of all significant parts from the internal eMMC. Otherwise device specific parameters will be lost forever.
See this remark as a reference as well:
http://forum.xda-developers.com/showpost.php?p=51297844&postcount=135
I'll spent some time to think about a useful SD-card layout... :laugh:
TBC
scholbert
All this looks knowledgeable
How are you at ROM/Kernel building?
Hi f0xy!
f0xy said:
All this looks knowledgeable
Click to expand...
Click to collapse
Thanks for this feedback!
I know these experiments are only for the fearless with good eyes.
For the average user there's no need to hack boot mode or stuff, unless there's some evil bricked device
I guess folks need pix
f0xy said:
How are you at ROM/Kernel building?
Click to expand...
Click to collapse
Depends...
On a hobbyist level i build many kernels, tweaked drivers and kernel code for personal use over the years.
Little less if we speak about building ROMs.
I might help out on some issues, but don't count on me for bigger projects.
Time is always lacking and often i'm too lazy to clean up the code for git
Cheers,
scholbert
Hi,
just added the complete partition table for GT-I9305 and some other stuff in the second post...
I try to sum up facts floating around as well and put it in the context of GT-I9305, so some info here is no breaking news
Anyway, enjoy the tech ride!
Regards,
scholbert
@mad_ady I seen your post in boeffla, some info here may be of help? Or maybe the @op can provide some help for you?
Regards
Thanks for the references. It helped me better understand where the partitioning information is kept. I didn't know our devices (I own a GT-9300) had a MBR/GPT table. I wonder, do other (non-samsung) devices use similar partitioning schemes? Or are there also other ways of keeping the partition layout that are in use?
Hi mad_ady!
mad_ady said:
Thanks for the references. It helped me better understand where the partitioning information is kept. I didn't know our devices (I own a GT-9300) had a MBR/GPT table. I wonder, do other (non-samsung) devices use similar partitioning schemes? Or are there also other ways of keeping the partition layout that are in use?
Click to expand...
Click to collapse
Yeah i guess other devices with onboard eMMC use GPT tables as well.
Though it is not completely clear at which level these are accessed.
I assume that the bootloader or even kernel is able to read this table during start up and is also aware of the sizes and boundaries.
The PIT table plays another role in this game.
AFAIK this is the reference for Odin/Heimdall and should match GPT boundaries.
Some experts are needed to confirm this or i'll have to dig a little deeper myself
Regards,
scholbert
Hi there,
i made a comparison between the cmdline passed to the kernel by "old" and "new" bootloaders.
Just started some investigation to fix "offline charging" with KK stock running on devices which still got the old bootloader.
Here's the default cmdline "old" vs. "new":
Code:
[SIZE="2"]JB 4.1.2 (I9305XXBME3) KK 4.4.4 (I9305XXUFNJ1)
console=ram console=ram
loglevel=4 loglevel=4
androidboot.baseband=mdm androidboot.baseband=mdm
sec_debug.level=0 sec_debug.level=0
sec_watchdog.sec_pet=5 sec_watchdog.sec_pet=5
androidboot.debug_level=0x4f4c androidboot.debug_level=0x4f4c
[email protected] [email protected]
- [email protected]
- [email protected]
s3cfb.bootloaderfb=0x5ec00000 s3cfb.bootloaderfb=0x5ec00000
lcdtype=96 lcdtype=96
consoleblank=0 consoleblank=0
lpcharge=0 -
lpj=3981312 lpj=3981312
vmalloc=144m vmalloc=176m
oops=panic oops=panic
pmic_info=67 pmic_info=67
cordon=<32-Byte hash value> cordon=<32-Byte hash value>
- connie=GT-I9305_OPEN_EUR_<32-Byte hash value>
androidboot.emmc_checksum=3 androidboot.emmc_checksum=3
- androidboot.boot_salescode=
- androidboot.odin_download=1
androidboot.bootloader=I9305XXBME3 androidboot.bootloader=I9305XXUFNJ1
- androidboot.selinux=enforcing
- androidboot.warranty_bit=1
- androidboot.sec_atd.tty=/dev/ttySAC2
androidboot.serialno=<16-Byte serial> androidboot.serialno=<16-Byte serial>
snd_soc_core.pmdown_time=1000 snd_soc_core.pmdown_time=1000[/SIZE]
As you might see there's the keyword lpcharge, which is not present on the "new" bootloaders.
On the new bootloaders there's the additional parameter android.bootmode=charger, if you start up with a charger plugged in.
On KK stock some proprietary binaries identify this keyword to activate offline charging.
Some kernel drivers (battery) react to this string as well and there's a patch already.
There'd been some attempts to fix this in initial ramdisk by hi-jacking cmdline present in /proc/cmdline and replace lpcharge=1 with android.bootmode=charger .
My first idea was, to make use of a similar function at kernel level and append android.bootmode=charger to the "old" bootloader cmdline, if lpcharge is set to 1 (similar to a conditional CONFIG_CMDLINE_EXTEND function).
The kernel itself will put this in /proc/cmdline afterwards and user space tools will be satisfied.
Some years ago i tweaked some kernel code for Archos tablets, which made use of custom ATAG keys to hand over some device specific parameters. Maybe i'll get something out of it
For my personal reference:
http://forum.xda-developers.com/galaxy-tab-3/general/kitkat-t31x-t2892792/post55863790#post55863790
TBC
Cheers,
scholbert
Hello.
Thanx for your Thread. For some summary about I9300 and I9305.
:good:
Please I need some input for my low brain...
I'm playing with I9300 and Tizen RD-PQ stuff...
My questions.
How to dump whole mmcblk0 ? Without direct eMMC Hardware...
Maximum 11 GB I can dump in internal sdcard...
http://forum.xda-developers.com/showpost.php?p=59503847&postcount=14
If I try to dump to external SD... I can only dump 4 GB...
RD-PQ sboot seems to work with I9300...
RD-PQ dump shows uboot at address 0x10000 and Tizen PIT is at 0x8000...
Tizen 32 MB dump for study...
http://forum.xda-developers.com/showpost.php?p=55514573&postcount=36
My theory... sboot is maybe at end of eMMC...
I can only check if I dump whole eMMC...
Thanx for every input.
Best Regards
The 4GB is a FAT32 limitation. You can try to format your external SD to ext3 or you can try to mount (via CIFS/NFS) a remote storage on which to dump.
Or, you can dump the device in blocks, starting with a specific offset and having a specific length:
http://superuser.com/questions/3807...m-the-specified-offset-but-not-dd-bs-1-skip-n
Hi!
adfree said:
My questions.
How to dump whole mmcblk0 ? Without direct eMMC Hardware...
Maximum 11 GB I can dump in internal sdcard...
http://forum.xda-developers.com/showpost.php?p=59503847&postcount=14
If I try to dump to external SD... I can only dump 4 GB...
Click to expand...
Click to collapse
See mad_ady's comment:
mad_ady said:
The 4GB is a FAT32 limitation. You can try to format your external SD to ext3 or you can try to mount (via CIFS/NFS) a remote storage on which to dump.
Or, you can dump the device in blocks, starting with a specific offset and having a specific length:
http://superuser.com/questions/3807...m-the-specified-offset-but-not-dd-bs-1-skip-n
Click to expand...
Click to collapse
From kernel level it is only possible to dump user area (unless you use a specific kernel with mmcblk0boot0 and mmcblk0boot1 enabled).
Read again this quote form my second post:
The area we may access from within Android OS is called USER area (all partitions belong to this area).
This part could be easily accessed and you may back up all data of this area to a disk image.
Apart from that, the eMMC is used as secure boot media.
On some of the ICS kernels there was a block device called /dev/mmcblk0boot0 (protected by ro-flag).
This device node is missing on most of the S3 devices and hence it is not possible to access this part.
Anyway, it is hidden area where Samsung placed the bootloader and stuff, the BOOT area.
If you are using still ICS bootloader it consists of at least 2 parts:
2MB area for BL1 (s-boot+TZSW+ddi-data)
2MB area for BL2 (not used, zeroed out)
Click to expand...
Click to collapse
adfree said:
RD-PQ sboot seems to work with I9300...
RD-PQ dump shows uboot at address 0x10000 and Tizen PIT is at 0x8000...
Tizen 32 MB dump for study...
http://forum.xda-developers.com/showpost.php?p=55514573&postcount=36
Click to expand...
Click to collapse
Interesting geek stuff... did you made any progress here, e.g. booting with RD-PQ?
adfree said:
My theory... sboot is maybe at end of eMMC...
I can only check if I dump whole eMMC...
Click to expand...
Click to collapse
Nope... it's at the very start of eMMC in a seperate area, normally hidden from user (see my comments above).
See datasheet attached, maybe this helps to understand how eMMC works.
EDIT:
Found the exact part which is soldered on my GT-I9305 mainboard.
See second post for reference as well:
http://forum.xda-developers.com/showpost.php?p=56747098&postcount=2
I'll leave this older datasheet her as well... this is at least a similar part.
Good luck and best regards,
scholbert
Interesting geek stuff... did you made any progress here, e.g. booting with RD-PQ?
Click to expand...
Click to collapse
I have problems to check my progress... because broken/damaged Display...
I see only black...
In Android I can use ADB stuff to see something...
Writing 32 MB RD-PQ dump not kill I9300... (no idea if this could kill IMEI, EFS or other Security stuff)
But I can't see where it hangs or if something is on Display...
Writing only s-boot-mmc.bin (200 KB sboot) from RD-PQ...
I have no idea yet, how to check if really written or ignored by I9300 sboot...
Code:
getprop ro.bootloader
Gives no anwser...
And this feature looks like Kernel related stuff...
Example why I am unsure if 200 KB sboot is accepted...
In I9300 you can find easily string ODIN in sboot...
But in RD-PQ is no ODIN text string... then why my I9300 works without problems with Odin...
I need some time to buy cheap working Display...
So I can see "visual effects" on Display...
1 goal would be this:
SDCARD MODE
COPY BINARY FROm SDCARD..
COPY BINARY TO EMMC..
SDCARD DOWNLOAD COMPLETED.
Click to expand...
Click to collapse
In Tizen world it seems mandatory to restore uboot... it contain the THOR string for THOR Downloader...
https://lists.tizen.org/pipermail/general/2013-November/002707.html
For me it is not clear enough... if RD-PQ sboot loads uboot...
sboot AND uboot is executed...
OR it is or feature...
Only uboot could be enough to executed...
About dump mmcblk0...
Code:
dd if=/dev/block/mmcblk0 skip=0 count=10000000 of=/sdcard/dump_v1.bin
dd if=/dev/block/mmcblk0 skip=10000000 count=10000000 of=/sdcard/dump_v2.bin
dd if=/dev/block/mmcblk0 skip=20000000 of=/sdcard/dump_v3.bin
This seems to work... but last 1 is again 11 GB + big...
It starts after with beginning...
I need proper count value... need some time and calculator...
I hope next week I have working Display for my testdevice...
Best Regards
eMMC hacking.... SD card boot... remove KNOX bootloader... finally?
Hi again,
i'd like to refer to a software package which seems to have leaked from a service center or similar some time ago.
Please refer to this thread, which explains how to revive hard bricked S3 devices and other Exynos devices:
http://forum.xda-developers.com/galaxy-s3/general/samsung-s3-i9300-note2-n7100-i9500-s4-t2647558
I found this package at several other places in the web as well, and it might be useful for some smart experiments :angel:
Here's what i got from it...
S3 repair contains a test suite for low level tests and tasks to setup up S3 from scratch.
You'll have to prepare a MicroSD card with a low-level tool (similar to dd command in linux).
The write script gives an idea about the offsets used on the SD card (multiples of 512 bytes), so i translated those to hex values:
emmc_auto.sbl.bin:1:499OFF: 0x00000200 LEN: 0x0003e600
E4412_S.TN.bl1.bin:9500:16OFF: 0x004a3800 LEN: 0x00002000
S5E4412_asb.bin:20000:40000OFF: 0x009c4000 LEN: 0x01388000
asb.ramfs:80000:97000OFF: 0x02710000 LEN: 0x02f5d000
From what i got by investigating the hex data of these binaries, the functions should be:
- emmc_auto.sbl.bin -> a bootloader suitable to start from SD card only
- E4412_S.TN.bl1.bin -> trustzone binary which sets up this part of the SoC for SD card boot
- S5E4412_asb.bin -> a standalone tool and testsuite compiled as a ready to run binary (no elf format here!)
- asb.ramfs -> a proprietary RMFS formatted ramdisk which carries some test files (e.g. test pattern, test videos, etc.)
A quite interesting piece of code is the S5E4412_asb.bin file.
So grepping some strings in this binary file gave this section, which is responsible for
vendor boot size change with CMD62 (refer to the eMMC datasheet as well) and seems to restore the bootloaders:
Code:
0x093DB6 0x2B APP STEP] Step 1. BL Download Address Set
0x093DE6 0x2D APP STEP] Step 2. DRAM Download Address Set
0x0943CA 0x0A NA,\NA0\NA
0x0943D6 0x0A NA$\NA(\NA
0x0943FE 0x2D APP STEP] CMD 0xEFAC62EC : RESPONSE 0x%08x %
0x094432 0x2B APP STEP] CMD 0xCBAEA7 : RESPONSE 0x%08x %
0x094462 0x32 APP STEP] Boot Partition Size : RESPONSE 0x%08x %
0x09449A 0x32 APP STEP] RPMB Partition Size : RESPONSE 0x%08x %
0x09472A 0x24 APP STEP] CMD 6 : RESPONSE 0x%08x %
0x094756 0x2B APP STEP] BL1 & BL2 loading Address : 0x%x
0x094786 0x2C APP STEP] Dram Image loading Address : 0x%x
0x0947B6 0x34 APP STEP] BL1 & BL2 compare address for Read : 0x%x
0x0947EE 0x35 APP STEP] Dram Image compare address for Read : 0x%x
As user Oranav pointed out in the eMMC sudden death research thread, there might be commands
which should initiate low level formatting of the eMMC chip:
CMD62 (ARG: 0xEFAC62EC)
CMD62 (ARG: 0xFAC0021)
This might probably delete all the chip metadata (incl. wear leveling state and bad block info)
and if these commands are correct, it will also reset KNOX counters and stuff.
In other words this is a full factory wipe of eMMC cells.
These are some snippets in S5E4412_ASB.bin located at:
0x8A41C0:
Code:
A5 A2 04 00
80 22 06 00
EC 62 AC EF = CMD62 (ARG: 0xEFAC62EC)
00 00 04 12
31 0C 62 00
71 1F 04 00
AB C2 9E FF
5A 7B B6 F0
83 68 AE 0F
CD 12 04 00
21 00 AC 0F = CMD62 (ARG: 0xFAC0021)
EE CC DE 00
A9 40 35 FF
BD AE 33 F1
80 97 72 00
1D 28 04 00
...and again at:
0x8C43F0
Code:
2D A2 04 00
CD A4 04 00
80 22 06 00
EC 62 AC EF = CMD62 (ARG: 0xEFAC62EC)
00 00 04 12
31 0C 62 00
AB C2 9E FF
5A 7B B6 F0
9F 1B 04 00
83 68 AE 0F
47 0F 04 00
21 00 AC 0F = CMD62 (ARG: 0xFAC0021)
EE CC DE 00
A9 40 35 FF
BD AE 33 F1
80 97 72 00
This could be some approval for the usage of these commands at least, because these sections are pure ARM assembly and seem to be associated with eMMC low level setup.
I'll have to find out some offsets for this machine code to try a disassembly.
Maybe this will lighten things up even more.
EDIT:
BTW, found one of the main return addresses which is at 0x40008000 (physical address at the beginning of DRAM). Let's see if this is correct.
EDIT2:
Bingo... just had a look in my boot logs i once grepped during UART session:
Starting kernel at 0x40008000...
Conclusion:
The ASB test suite (S5E4412_asb.bin) is booted/started at the same offset as the linux kernel does.
Let's see what this may give us
Another thing to mention is, that included in S5E4412_asb.bin there's a M0 test bootloader (GT-I9300).
Have a look at offset 0x08d8fe8 inside the binary
So in the end i wonder, if someone has ever used this "Service" card together with a real UART connection to the board.
Apart from the automated test and setup process, my guess is, that there should be some command line or some kind of a test menu which may give alternative choices to proceed certain tasks.
P.S.: Maybe it's hard to understand what i like to point out here... but imagine we use the following:
- emmc_auto.sbl.bin -> a bootloader suitable to start from SD card only
- E4412_S.TN.bl1.bin -> trustzone binary which sets up this part of the SoC for SD card boot
- recovery.img -> kernel + recovery to start completely from SD card (eMMC not touched here!!!)
P.P.S: Let's see if the SD card boot files look for a signature here.....
Stay tuned!
scholbert
... further experiments
Hi,
i made further progress with my attempts to boot my GT-I9305 completely from external MicroSD.
As proposed in my last post i prepared a card with the following commands:
Code:
echo "Exynos4412 FWBL1+BL2"
dd if=./emmc_auto.sbl.bin of=/dev/sda bs=512 seek=1
echo "Exynos4412 TZSW"
dd if=./E4412_S.TN.bl1.bin of=/dev/sda bs=512 seek=9500
Next is to prepare the board.
You'll need Anyway JIG or a dedicated UART connection as described in my first post.
To block access to internal eMMC the resistor R634 on the GT-I9305 mainboard got shorted.
Insert the MicroSD with the proprietary boot files into the socket.
Connect to a terminal and attach supply voltage of 3.8-4.0V to the battery connector.
Press the power button and hold it.
Here's the output so far:
Code:
TN default
<OK>
<OK>
[DVFS] INT(1) : 0
DRAM Type : LPDDR2 16G
[DVFS] MIF(3) : 0
[EPLL][VPLL][CLK_DIV] OK
<OK>
[LOCK SW/HW]ARM:0/0 INT:0/0 G3D:0/0 MIF:0/0 SHIFT:0/0
[DVFS] ARM(0) : 5
[DVFS] INT(1) : 0
[DVFS] G3D(2) : 0
[DVFS] MIF(3) : 0
[SD_INIT
SDMMC_HighSpeed:DONE]
SD_READ: 20000 20000 0x40008000 -> 422650 usec
<OK>
Inp32(uAddr) : 0x0
LINUX Bootingøq!ñ¥¡Õ
At this point there are no further outputs, as there's nothing to be executed.
Like known from the sboot, hitting enter on your terminal from the very beginning gives a commandline interface.
Unfortunately, it seems that the watchdog is not stopped at this point and maybe the PMIC is not fully initialized.
This leads to repeated resets.
Anyway if you're fast enough, you may get this command list from the proprietary bootloader:
Code:
BL>help
CMD LIST
LOG
WAIT
USB
GET
JUMP
RUN
RUN2
INIT
INIT2
DMC
CLK
DVFS
ASV
DVFSQA
EMA
PMIC
SD
EMMC
ZIP
ABB
RESET
DUMP
MEMCPY
MEMCMP
MEMSET
OUTP32
INP32
SETBITS
GETBITS
COPYRUN
MEMCPY_RUN
PATTERN
BOOT
CTA
ASB
COM
HELP
H
TEST
TN
<OK>
BL>
Some of these commands play an important role for starting up the ASB test suite if present.
These command are included in BL2 and they seem to be interpreted by ASB:
Code:
TN M0|PMIC
INIT2 3|init2|TEST
EMMC
0x10020800 1|TEST RUN
I started to mod these, but as far as i did not start the ASB image yet there's nothing to observe.
By looking at other logs from brick recoveries, i found a relationship between the first output of ASB and these commands.
My idea is that by changing these we could influence the behaviour of the ASB code for educational purpose.
As described above, without parts of ASB the PMIC seems not to be fully initialized,
because i found out that you need to hold the power button to keep the board alive.
This is little strange, as i am pretty sure that this was not the case in the begining, but maybe i'm wrong.
Anyway as far as i observed it, the board starts normally from internal eMMC after my experiments had finished.
At least nothing indicates that something got damaged...
Just to check out what happens i put a raw recovery image at position 20000 (0x9c4000) on the card.
This is the beginning of kernel code.
Afterwards i started a new terminal session and i saw that the first command of kernel code got printed,
but unfortunately after the bootcode jumps to this code there's no further output.
Something is still missing.
Could be something obvious (e.g. missing TAGS at 0x40000100) or could be not.
Maybe it would be a good idea to compile a version of u-boot and try again.
Let's see
scholbert
....grrrr
Hi again!
First of all, nice to see that at least two guys follow my binary surgery.
Second, i must admit that the platform is not that responsive as i first thought.
Due to all this signing stuff, it is easy to break something and CPU simply stops executing code.
So for now there's nothing, than further logging outputs from the console.
1. I removed some of the start up commands from BL2, which leaves TN M0|PMIC & INIT2 3|init2|TEST for ASB code.
This is what i got then:
Code:
TN default
<OK>
<OK>
[DVFS] INT(1) : 0
DRAM Type : LPDDR2 16G
[DVFS] MIF(3) : 0
[EPLL][VPLL][CLK_DIV] OK
<OK>
[CHIPID] E4412 EVT1.1
LOTID WNO X Y IDS HPM ASV_GRP FUSE SHIFT
[LOG]N571A 18 201 195 22 22 8 -1 100000 80
There's no auto booting anymore at this point.
2. I put anything back, apart from the RUN command.
During this test i used a modified ASB binary with sboot from I9305XXALI4 put in the right place.
Unfortunately the output stops after "FW Booting"
The device kept being powered though. Which is a good thing from my guess.
Here's the log:
Code:
TN default
<OK>
<OK>
[DVFS] INT(1) : 0
DRAM Type : LPDDR2 16G
[DVFS] MIF(3) : 0
[EPLL][VPLL][CLK_DIV] OK
<OK>
[LOCK SW/HW]ARM:0/0 INT:0/0 G3D:0/0 MIF:0/0 SHIFT:0/0
[DVFS] ARM(0) : 5
[DVFS] INT(1) : 0
[DVFS] G3D(2) : 0
[DVFS] MIF(3) : 0
[SD_INIT
SDMMC_HighSpeed:DONE]
SD_READ: 20000 20000 0x40008000 -> 422818 usec
<OK>
Inp32(uAddr) : 0xea00007e
FW Booting
Right now it's a bit to early for further conclusions, but maybe the signing stuff got broken at some point in both cases.
It could also be that some of the signatures is especially for GT-I9300, or in other words the CPU on GT-I9305 uses a different key set.
That's it by now, but i won't give up yet
Cheers,
scholbert
Wow, that's one of the most insightful threads about 4412 I've seen for a while.
Replying here on OP's PM for further reference:
* At LenovoK860 uboot sources:
These seem to contain private keys for some batch of 4412 - that's the first time I see private signing keys of any Exynos to leak. Previous leaks were just wild security-dropping bootloader stages signed with private keys, but no keys included.
These keys can either match batch customized for Lenovo or match all 4412 (Exynos4 public key hash fuses, in theory, meant to be factory/OEM customizable) - I'd say the latter since neither GS3 or any common device built on S5PC2xx I've seen was expected to have any grade of real security, so probably neither Lenovo or Samsung cared to customize any of Exynoses used around.
There is a way to check it by comparing dumps from 0x10100000 area between GS3 and LenovoK860 CPUs (I'm uncertain, as I'm really rusty). Probably there's also other way by comparing Lenovo stage1 public keys with GS3 0x1010_0000 dumps, considering how pubkey is validated against these bits (no idea, don't remember).
* At My and Adam's tries:
We were quite succesfull in running UBoot on I9300 and GalaxyCam GC100.
What we couldn't achieve was kernel booting - Exynos4 kernels require TZSW to be fully operating and communicating with it. I couldn't get it to load up properly.
There's quite of history of our tries under https://github.com/Rebell/exynos4_uboot/commits/master
Another option is, of course, disabling TZSW support in kernel and not booting it at all - it doesn't seem to work out-of-the-box either, and would make impossible to boot any non-modded kernels.
AFAIR (and boy, was it while ago), referenced sources were building and fusing to the SD card flawelessly and supporting both fastboot and UART terminal with most (all?) of the commands working (yes, it can do raw R/W to eMMC and whatnot in SVC mode without TrustZone supervisor interfering, because it's not loaded at all yet). Just kernel wouldn't boot. I'd say you should give it a try (if you didn't already).
The crucial part we used there was FWBL1 (there https://github.com/Rebell/exynos4_uboot/tree/master/sd_fuse) - first, already signed, stage of bootloader hat's doing nothing but loading another stage of bootloader without any security (kudos to Odroid).
We couldn't find any equivalent of signed FWBL1 for Exynos4210 (GS2 CPU) that would allow us booting eMMC hardbricked GS2 devices.
* At ASB:
First time I hear of it. Never seen this stuff before.
... just an update
Hi,
it's been a while now that i found some time to fiddle around with one of my i9305 mainboards.
In the meantime there'd been some nice conversation via PM with Rebellos as well.
u-boot on Galaxy S3
Find the sources here:
https://github.com/Rebell/exynos4_uboot
So i finally gave it a try, jumped on his work and compiled a version of u-boot for Galaxy S3 devices.
As a prerequisite you'll have to block eMMC and to make it short...
It just works!!!
Attached you'll find a log from external sdcard boot.
Maybe i'll do some tweaks in the near future, e.g. remove the annoying "pmic_s5m8767_init" messages,
as there is no such device on our S3.
s-boot for Tizen on Galaxy S3
On the Tizen Wiki (https://wiki.tizen.org/wiki/Flash_Tizen_2.2.1_Image_to_Reference_Device)
there's a link to a tar with image files (Tizen_RD-PQ_System_20131107_1.tar), which contains a s-boot file.
Unfortunately the signature of BL1 inside the s-boot image seems not fit the mass production units.
In other words no boot message here at all... at least while trying to boot from sdcard.
mass production sboot on external SD-card
On the other hand the mass production units sboot images are ready to boot from sdcard as well.
Find the second log attached below.
The error messages are normal, because i blocked eMMC all the time, to prevent bricking during my experiments.
security key validation
As you'll see in the logs i dumped the region at 0x10100000 for the security key values.
Here's a snippet of the secure boot function header in the u-boot sources:
Code:
#define MAX_EFUSE_DATA_LEN 16
typedef struct
{
unsigned char rsa_n[128]; /* RSA Modulus N */
unsigned char rsa_e[4]; /* RSA Public Exponent E */
} RawRSAPublicKey;
typedef struct
{
RawRSAPublicKey rsaPubKey; /* RSA PublicKey */
unsigned char signedData[20]; /* HMAC Value of RSA PublicKey */
} PubKeyInfo;
/* Secure Boot Context */
typedef struct
{
RawRSAPublicKey stage2PubKey; /* Stage2 RSA Public Key */
unsigned char code_SignedData[128]; /* RSA Signature Value */
PubKeyInfo pubKeyInfo; /* Stage1 RSA PublicKey and it's HMAC value */
unsigned char func_ptr_BaseAddr[48]; /* Function pointer of iROM's secure boot function */
unsigned char test_eFuse[MAX_EFUSE_DATA_LEN];
unsigned char reservedData[36];
} SecureBoot_CTX;
If i assume S3 still uses V1.1 security with 1024Bit RSA (BL1.bin is 8192Byte) the efuse key would be 128Bit, which results in 4 registers with 32Bit length.
Exported to a hex dat file this is 16Byte of Hex data.
Dump at 0x10100000 gives:
Code:
10100000: 0d19a391 2a0502af 1576987a 212121bc .......*z.v..!!!
We'll have to re-arrange the bytes for little endian order:
Code:
91a3190d af02052a 7a987615 bc212121
... use a hex-editor and put these into a file named: eFuseData.dat
Next i took codesigner_v21 and tried to validate stock BL1 files if they match.
codesigner_v21 -v1.1 <BL1.bin> <eFuseData.dat> -VERIFY
Unfortunately no succes yet... signature verification always failed.
This is a mistery, because the position of the key should be correct and i used valid bootloader files as well.
Anyway this had been only a proof of concept if we got the right tool and the right efuse values.
TBC
Cheers,
scholbert
@scholbert
Please, need collection of GT-I9305 Bootloader....
Something like this:
http://forum.xda-developers.com/galaxy-s3/general/guide-extract-bootloader-make-flashable-t2864264
http://forum.xda-developers.com/galaxy-s3/general/ref-galaxy-s3-stock-kernel-bootloaders-t2189063
For now I was only able to find
RESTORE_BOOTLOADER_I9305XXALI4.zip
http://forum.xda-developers.com/showpost.php?p=32760677&postcount=1
I need few more for stupid tests.
For now my test GT-I9300 PCB is able to start this sboot.bin from GT-I9305... with tweezer.
sboot.bin is copied successfully... but not start in "normal mode"...
Here I can see other method... sboot.bin is not copied to eMMC but fully executed from eMMC, with Boot menu:
http://forum.xda-developers.com/showpost.php?p=64664423&postcount=278
I will check if GT-I9305 has similar Bootloader and if it will executed on my GT-I9300 test PCBs.
Thanx in advance.
Best Regards
I found this:
I9305XXUFNL1-DBT.zip
Here is sboot.bin from GT-I9305 inside... I have attached.
Search for text String THOR... you can find:
Code:
- Thor is connected!
This could mean... I9305 is Tizen enebled... not only this...
Chance to play with U-Boot.
Tried on I9300 with no luck...
Volume + or Volume - do nothing... maybe Hardware Keys different...
I hope to find something working for my I9300...
Btw.
First time I saw THOR string also in Note 4 N910C:
http://forum.xda-developers.com/showpost.php?p=64663039&postcount=65
Best Regards

Categories

Resources