Database Users

Is it possbale to unlock EXTROM space?

It seems that there is about 100 MB Missing... I just guess is EXTROM
It could very easy to test that - different EXTROM but same Flash.bin.
The total free ROM space unchanged, even your EXTROM just used a few MB
If the EXTROM could be used, then it could be great help for cooking
The files may relate to FLASH.Header and partition.mbn. could anyone have a good try?
But...
pdocread.exe -l
411.25M (0x19b40000) DSK1:
| 1.87M (0x1df000) Part00 BOOT SECTION image
| 5.00M (0x500000) Part01 XIP RAM Image
| 84.25M (0x5440000) Part02 IMGFS file system
| 320.13M (0x14020000) Part03 legit DOS partition
handle#1 ef638fc6 320.13M (0x14020000)
handle#2 ef6adea6 84.25M (0x5440000)
handle#3 2f6ade82 5.00M (0x500000)
handle#4 4f6ade3a 1.87M (0x1df000)
Total is just 411.25, about 100MB (0x064C0000) seems missing....
For Part02, I could know is imgfs, and Part00 seems EXTROM, but where is disappear 100M?
partition table:
Code:
Partition-Info :
------------------
MIBIB
---------------------------------------------------------
Page: 0x6
Size: 0x4
Address: 0x000C0000 - 0x00140000
Block: 0x00000180 - 0x00000280
Flash: 0xFEFFFFFF
SIM_SECURE
---------------------------------------------------------
Page: 0x4
Size: 0x2
Address: 0x00080000 - 0x000C0000
Block: 0x00000100 - 0x00000180
Flash: 0xFEFFFFFF
FSBL
---------------------------------------------------------
Page: 0x180
Size: 0x1E
Address: 0x03000000 - 0x033C0000
Block: 0x00006000 - 0x00006780
Flash: 0xFFFFFFFF
OSBL
---------------------------------------------------------
Page: 0x180
Size: 0x1E
Address: 0x03000000 - 0x033C0000
Block: 0x00006000 - 0x00006780
Flash: 0xFFFFFFFF
AMSS
---------------------------------------------------------
Page: 0x4650
Size: 0x708
Address: 0x8CA00000 - 0x9AB00000
Block: 0x00119400 - 0x00135600
Flash: 0xFFFFFFFF
EFS2
---------------------------------------------------------
Page: 0x1F40
Size: 0xC8
Address: 0x3E800000 - 0x40100000
Block: 0x0007D000 - 0x00080200
Flash: 0xFFFFFF01
DSP1
---------------------------------------------------------
Page: 0x3E80
Size: 0x258
Address: 0x7D000000 - 0x81B00000
Block: 0x000FA000 - 0x00103600
Flash: 0xFFFFFFFF
FOTA
---------------------------------------------------------
Page: 0x80
Size: 0x64
Address: 0x01000000 - 0x01C80000
Block: 0x00002000 - 0x00003900
Flash: 0xFFFFFFFF
EXTROM
---------------------------------------------------------
Page: 0xC350
Size: 0x7D0
Address: 0x86A00000 - 0x96400000
Block: 0x0010D400 - 0x0012C800
Flash: 0xFFFFFFFF
APPSBL
---------------------------------------------------------
Page: 0x300
Size: 0x32
Address: 0x06000000 - 0x06640000
Block: 0x0000C000 - 0x0000CC80
Flash: 0xFFFFFFFF
APPS
---------------------------------------------------------
Page: 0x80
Size: 0xC
Address: 0x01000000 - 0x01180000
Block: 0x00002000 - 0x00002300
Flash: 0xFFFFFFFF
EFS2APPS
---------------------------------------------------------
Page: 0xFFFFFFFF
Size: 0xFFFF
Address: 0xFFFE0000 - 0xFFFC0000
Block: 0x001FFFC0 - 0x001FFF80
Flash: 0xFFFF02FF

good investigation ! I hope you can find a Way to reduce the allocated space, sadly I can't help you with this...keep the research !

Arto said:
good investigation ! I hope you can find a Way to reduce the allocated space, sadly I can't help you with this...keep the research !
Click to expand...
Click to collapse
Thank you also
The difficult problem is that, I'm not much understanding NAND Flash...
But, it seems that, after flashing ROM with new partition.mbn, the size of ExtRom could be changed.
At this moment, I'm not sure that the Hex files should be also changed or not ...
Code:
EXTROM
---------------------------------------------------------
[COLOR="Red"] Page: 0xC350
Size: 0x7D0[/COLOR]
Address: 0x86A00000 - 0x96400000
Block: 0x0010D400 - 0x0012C800
[COLOR="Red"] Flash: 0xFFFFFFFF[/COLOR]
Form Page (seems like format pagepool), the maximum ExtROM could be 50MB, that's the limit for a cook to modify ExtROM.
Of cause, if we could modify ExtROM size, then we could include more module in to Image
Moreover, including ExtROM, the boot system could used up to 93.674MB

my extrom take 7mb...so if the extrom allocated space can be changed it would be reallocated to application space? Qazer found a way to change page pool size, maybe it can help you on this !
edit, what is NAND flash?

Arto said:
my extrom take 7mb...so if the extrom allocated space can be changed it would be reallocated to application space? Qazer found a way to change page pool size, maybe it can help you on this !
edit, what is NAND flash?
Click to expand...
Click to collapse
After rearranged the partition table, it could be like this:
Code:
offset size
SIM_SECURE 0x4 0x2
MIBIB 0x6 0x4
FOTA 0x80 0x64
APPS 0x80 0xC
FSBL 0x180 0x1E
OSBL 0x180 0x1E
APPSBL 0x300 0x32
EFS2 0x1F40 0xC8
DSP1 0x3E80 0x258
AMSS 0x4650 0x708
EXTROM 0xC350 0x7D0
EFS2APPS 0xFFFFFFFF 0xFFFF
It could be much strange that some 'partitions' are overlapping!
Emmm, I forgot the order flashing these programs (.mbn), however, the ExtROM could be the last one to flash in the phone...
If somebody could tell me the order, then it could be much clear the process
Seems changed size could be OK, but I just wonder that what about ImageFS...
BTW, for term 'NAND flash', just wikipedia it

the best thing we can do is to reallocate this space in a virtual ram driver, and dont use the extrom space anymore. I noticed that the extrom files (cabs,tsk..) are in the windows folder of the device when you explore the windows folder.
So Is there a virtual ram driver or is there a way to do that, we don't need space, we need ram alternative.
anyway, don't know if it is possible to do such a thing on winmo devices...
( a kind of swap space....)

ocman said:
the best thing we can do is to reallocate this space in a virtual ram driver, and dont use the extrom space anymore. I noticed that the extrom files (cabs,tsk..) are in the windows folder of the device when you explore the windows folder.
So Is there a virtual ram driver or is there a way to do that, we don't need space, we need ram alternative.
anyway, don't know if it is possible to do such a thing on winmo devices...
( a kind of swap space....)
Click to expand...
Click to collapse
I think we should hardmod to add more RAM instead of using NAND flash, to avoid damaging it faster
Emmm, at this time I could not be sooooooo brave to flash my only phone
I just only change 0x7D0 (D0 07 00 00) to 0x3E8 (E8 03 00 00)....
If I try to flash with new partition.mbn,the phone turn into FTM Mode
But I just put partition.mbn, extrom.bin and two hex files only to the flash tool...
It sounds like I should put all files in that...
Then, finally these two hex files ENPRG8650.hex and NPRG8650.hex should be also modified.

[Q] Tried every guide I can find, can't get S-Off

I've tried every guide here on XDA...tried the Cyanogen Wiki...ever tried the Unlockr's guide...I can root the phone, but I can't get S-Off. This is my third Mytouch 4G, and the only one I've been unable to get S-Off on. the other ones I was able to use rage to root and get S-Off on, but this one I only seem to be able to root. I've even tried visionary and can still only get root but not S-Off. I'm just so frustrated at this point I feel like smashing the phone and telling T-Mobile the replacement came like this...

mytouch4g ya say?
hmm..
http://forum.xda-developers.com/showthread.php?t=858996
look for gfree.

Are you getting a "failed to powercycle eMMC" error?

synaesthetic said:
Are you getting a "failed to powercycle eMMC" error?
Click to expand...
Click to collapse
Yes...the guide at the CM wiki said if I get that to use gfree .05 instead, but then when I get this running this part again
Code:
./gfree -f -b hboot-eng.img -y recovery.img
./root_psn
sync
it says that the -y parameter isn't recognized

Just run ./gfree -f
Everything else can be done later.
http://forum.xda-developers.com/showthread.php?t=858996

Followed that page..this is what I get
Code:
# ./gfree -f
./gfree -f
--secu_flag off set
--cid set. CID will be changed to: 11111111
--sim_unlock. SIMLOCK will be removed
Section header entry size: 40
Number of section headers: 44
Total section header table size: 1760
Section header file offset: 0x000138b4 (80052)
Section index for section name string table: 41
String table offset: 0x000136fb (79611)
Searching for .modinfo section...
- Section[16]: .modinfo
-- offset: 0x00000a14 (2580)
-- size: 0x000000cc (204)
Kernel release: 2.6.32.21-g899d047
New .modinfo section size: 204
Attempting to power cycle eMMC... OK.
Searching for mmc_blk_issue_rq symbol...
- Address: c02a63a4, type: t, name: mmc_blk_issue_rq, module: N/A
Kernel map base: 0xc02a6000
Kernel memory mapped to 0x40011000
Searching for brq filter...
- Address: 0xc02a63a4 + 0x34c
- 0x2a000012 -> 0xea000012
Patching and backing up partition 7...
Error opening copy file.
#

Mackster248 on YouTube... he's got a great tutorial video using the gfree method...
Sent from my HTC Glacier using XDA App

try a different usb port?
I had some issues rooting an entirely different device where it had difficulty copying files, it basically all boiled down to the usb port i was trying to use. Bypass any hubs, plug directly into rear of machine.
Shot in the dark, worth a try tho...

cbutt said:
Mackster248 on YouTube... he's got a great tutorial video using the gfree method...
Sent from my HTC Glacier using XDA App
Click to expand...
Click to collapse
Yea..ok..I dunno what the hell it was, but I followed that guide word for word last night and it didn't work. Went fine just now...thanks

Try this
http://forum.xda-developers.com/showthread.php?t=995549
Sent from my HTC Glacier using XDA App

[Q] Restore the S-ON Fail [Solved]

Hello, (Solved)
I would like to restore the S-ON for Warranty. I have sucessfully install the official ROM and Bootloader but I can't S-ON.
I have try :
adb push psneuter /data/local/tmp/psneuter
adb shell chmod 777 /data/local/tmp/psneuter
adb shell /data/local/tmp/psneuter
adb shell
adb push gfree /data/local/tmp/gfree
adb shell chmod 777 /data/local/tmp/gfree
/data/local/tmp/gfree -r /sdcard/part7backup-1308605970.bin
sync
All seem to be ok but when I reboot the phone it's always S-OFF
I have try with but same problem
/data/local/tmp/gfree -s on -c ORANG202
sync
PS : The log
# /data/local/tmp/gfree -r /sdcard/part7backup-1308605970.bin
/data/local/tmp/gfree -r /sdcard/part7backup-1308605970.bin
--restore set. Partition 7 will be restored from file: /sdcard/part7backup-13086
05970.bin
Section header entry size: 40
Number of section headers: 44
Total section header table size: 1760
Section header file offset: 0x000138b4 (80052)
Section index for section name string table: 41
String table offset: 0x000136fb (79611)
Searching for .modinfo section...
- Section[16]: .modinfo
-- offset: 0x00000a14 (2580)
-- size: 0x000000cc (204)
Kernel release: 2.6.32.21-g132894e
New .modinfo section size: 204
Attempting to power cycle eMMC... OK.
Write protect was successfully disabled.
Searching for mmc_blk_issue_rq symbol...
- Address: c02adc44, type: t, name: mmc_blk_issue_rq, module: N/A
Kernel map base: 0xc02ad000
Kernel memory mapped to 0x40002000
Searching for brq filter...
- Address: 0xc02adc44 + 0x34c
- ***WARNING***: Found fuzzy match for brq filter, but conditional branch isn't
. (0xea000012)
Backing up current partition 7 and restoring specified backup...
Backing up partition /dev/block/mmcblk0p7 to /sdcard/part7backup-1312490872.bin
...
Writing image /sdcard/part7backup-1308605970.bin to partition /dev/block/mmcblk0
p7 ...
Done.
# sync
sync
#
Click to expand...
Click to collapse
Guifort
PS : I have the rom : Orange_FR-B2B_1.85.73.2
Thanks

Solved downgrade to 1.34 and that is ok

[BOOTLOADER] Analysis

Brief synopsis
Bootloader unlock isn't likely. Amazon provide the facility to unlock the bootloader, but there is no way of getting the key.
The program which is locking the bootloader appears to be specific to MediaTek and Amazon, therefore, there isn't any source code.
The partitions with an Android bootimg header are all signed with two Amazon certificates. This includes the Little Kernel (LK) and the kernel itself.
The preloader is custom built for Amazon. The preloader doesn't respond to SP Flash Tool because it's constantly in a reboot loop when in 'META mode'. I presume it's intentional; a different version can however be installed (See 'However...').
However...
@bibikalka has found some strings in tz.img refering to a bootloader unlock. There is an amzn_unlock_verify function in lk too.
There must be a is a way to get the preloader to work properly with SP Flash Tool. However, this won't allow you custom ROMs, just reinstall Amazon's software. The software installed is still verified during the boot process. See this unbrick guide to install a different preloader. The preloader is not signed or checked by the boot process.
There is a small chance some part of the boot process could be fooled.
Downgrade potential
An anti-rollback program appears to have been built in to the bootloader which prevents any attempt at downgrading the software on the device. This is rather irritating, and means that downgrading is almost impossible. Only the preloader seems to be unaffected by this anti-rollback system – so, if you attempted to downgrade, and caused your device to become bricked, then you can restore the version you left.
Note that I vaguely reference to the preloader, uboot and lk collectively as 'the bootloader'.
Original post
I previously had downloaded the 5.0.1 and 5.1.1 LK versions, and thought, why not run these through binwalk?
For the old, 5.0.1 bootloader, putting lk.bin through binwalk gave:
Code:
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
204256 0x31DE0 SHA256 hash constants, little endian
292292 0x475C4 Android bootimg, kernel size: 0 bytes, kernel addr: 0x5D73255B, ramdisk size: 1869570592 bytes, ramdisk addr: 0x6D692074, product name: ""
330144 0x509A0 Unix path: /mnt/build/workspace/fireos-release_500-patch-build/bootable/bootloader/ufbl-features/project/../features/common_openssl/crypto/
330752 0x50C00 Unix path: /mnt/build/workspace/fireos-release_500-patch-build/bootable/bootloader/ufbl-features/project/../features/common_openssl/crypto/
334248 0x519A8 Unix path: /mnt/build/workspace/fireos-release_500-patch-build/bootable/bootloader/ufbl-features/project/../features/common_openssl/crypto/
339912 0x52FC8 Unix path: /mnt/build/workspace/fireos-release_500-patch-build/bootable/bootloader/ufbl-features/project/../features/common_openssl/crypto/
341028 0x53424 Unix path: /mnt/build/workspace/fireos-release_500-patch-build/bootable/bootloader/ufbl-features/project/../features/common_openssl/crypto/
350360 0x55898 Unix path: /mnt/build/workspace/fireos-release_500-patch-build/bootable/bootloader/ufbl-features/project/../features/common_openssl/crypto/
351732 0x55DF4 Certificate in DER format (x509 v3), header length: 4, sequence length: 1067
353656 0x56578 Certificate in DER format (x509 v3), header length: 4, sequence length: 1069
369736 0x5A448 CRC32 polynomial table, little endian
397548 0x610EC LZMA compressed data, properties: 0x91, dictionary size: 33554432 bytes, uncompressed size: 134217728 bytes
Whilst the 5.1.1 bootloader's lk.bin gave:
Code:
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
204960 0x320A0 SHA256 hash constants, little endian
293720 0x47B58 Android bootimg, kernel size: 0 bytes, kernel addr: 0x5D73255B, ramdisk size: 1869570592 bytes, ramdisk addr: 0x6D692074, product name: ""
332024 0x510F8 Unix path: /mnt/build/workspace/fireos-ship_511-patch-build/bootable/bootloader/ufbl-features/project/../features/common_openssl/crypto/cry
332628 0x51354 Unix path: /mnt/build/workspace/fireos-ship_511-patch-build/bootable/bootloader/ufbl-features/project/../features/common_openssl/crypto/mem
336096 0x520E0 Unix path: /mnt/build/workspace/fireos-ship_511-patch-build/bootable/bootloader/ufbl-features/project/../features/common_openssl/crypto/asn
341712 0x536D0 Unix path: /mnt/build/workspace/fireos-ship_511-patch-build/bootable/bootloader/ufbl-features/project/../features/common_openssl/crypto/evp
342820 0x53B24 Unix path: /mnt/build/workspace/fireos-ship_511-patch-build/bootable/bootloader/ufbl-features/project/../features/common_openssl/crypto/obj
352064 0x55F40 Unix path: /mnt/build/workspace/fireos-ship_511-patch-build/bootable/bootloader/ufbl-features/project/../features/common_openssl/crypto/x50
353420 0x5648C Certificate in DER format (x509 v3), header length: 4, sequence length: 1067
355344 0x56C10 Certificate in DER format (x509 v3), header length: 4, sequence length: 1069
371656 0x5ABC8 CRC32 polynomial table, little endian
So there you go! The bootloader uses OpenSSL to check the partition against two DER format certificates. Ignore the LZMA header for now; binwalk thinks almost everything is LZMA compressed.

Can you run binwalk with -e and post the 5.1.1 certs here

benwaffle said:
Can you run binwalk with -e and post the 5.1.1 certs here
Click to expand...
Click to collapse
Look at the thread about the 5.1.1 lk.bin in this forum and download the binary so you can run binwalk on it yourself.
Here is the lk.bin file, zipped. You can try and run '-e' on this binary.
The extracted certificates appear to contain format strings for decompression/compression error and debug messages. It doesn't look right. But the top of the files are valid certificate headers (or appear to be to the untrained eye).
Thanks @benwaffle.

Good effort!
I shall note that Amazon must have a way to un-brick the devices with MTK tools, they would not swap motherboards in order to revive them ...
The problem with the public MTK tools that it's even impossible to create a scatter file automatically (read only operation), meaning that the formats are such that MTK tools don't understand:
http://forum.xda-developers.com/fire-hd/help/mtk-tools-people-hopeless-bricks-t3139784
There is also an attempt to look at which partitions change when 5.0.1 goes to 5.1.1, and frankly, it's not many places to hide (only a couple of partitions):
http://forum.xda-developers.com/amazon-fire/help/understand-5-1-1-bootloader-bricking-fix-t3301991
On Fire 2014 I also looked at the strings within the bootloaders, and they had some interesting stuff regarding unlocking:
http://forum.xda-developers.com/showpost.php?p=61288384&postcount=57
I wonder if it's possible to patch the very first thing that boots (preloader), and have it pass the unlocking flags around ? Or is preloader also encrypted fully ?

bibikalka said:
Good effort!
I shall note that Amazon must have a way to un-brick the devices with MTK tools, they would not swap motherboards in order to revive them ...
The problem with the public MTK tools that it's even impossible to create a scatter file automatically (read only operation), meaning that the formats are such that MTK tools don't understand:
http://forum.xda-developers.com/fire-hd/help/mtk-tools-people-hopeless-bricks-t3139784
There is also an attempt to look at which partitions change when 5.0.1 goes to 5.1.1, and frankly, it's not many places to hide (only a couple of partitions):
http://forum.xda-developers.com/amazon-fire/help/understand-5-1-1-bootloader-bricking-fix-t3301991
On Fire 2014 I also looked at the strings within the bootloaders, and they had some interesting stuff regarding unlocking:
http://forum.xda-developers.com/showpost.php?p=61288384&postcount=57
I wonder if it's possible to patch the very first thing that boots (preloader), and have it pass the unlocking flags around ? Or is preloader also encrypted fully ?
Click to expand...
Click to collapse
Thanks @bibikalka!
Yes – Amazon must have a way of flashing firmware. I wonder if there is a JTAG header on the board as well. The Fire HD 6 had a 'JDEBUG' port, as seen in iFixit's teardown photographs: https://www.ifixit.com/Teardown/Kindle+Fire+HD+6+Teardown/29815#s70239
There might be a bootloader unlock then! It might need someone to decompile uboot to see how to trigger the unlock.
I've only managed to get the preloader_prod.img at this moment in time (I haven't taken preloader.img off). The SHA256 hash starts at around 95% (117KB out of 121KB) of the file, according to binwalk.

Hi,
I'm sorry to shatter hopes for bootloader rollback, but I was looking at the strings in preloader_prod.img and found this:
Code:
$ strings images/preloader_prod.img | grep -i rollback
[ANTI-ROLLBACK] Processing anti-rollback data
[ANTI-ROLLBACK] Failed to read block 0
[ANTI-ROLLBACK] PL: %x TEE: %x LK: %x
[ANTI-ROLLBACK] Need to update version
[ANTI-ROLLBACK] Invalid checksum!
[ANTI-ROLLBACK] Checksum validated
[ANTI-ROLLBACK] PL version mismatch!
[ANTI-ROLLBACK] L: %x R: %x
[ANTI-ROLLBACK] Updating PL version
[ANTI-ROLLBACK] TEE version mismatch!
[ANTI-ROLLBACK] Updating TEE version
[ANTI-ROLLBACK] LK version mismatch!
[ANTI-ROLLBACK] Updating LK version
[ANTI-ROLLBACK] All checks passed
[ANTI-ROLLBACK] Updating RPMB block...
[ANTI-ROLLBACK] Unable to update RPMB block (wc)
[ANTI-ROLLBACK] Unable to update RPMB block (write)
[ANTI-ROLLBACK] RPMB block updated
[RPMB] Failed to initialize anti-rollback block
[RPMB] Anti-rollback block initialized
[RPMB] Valid anti-rollback block exists
[ANTI-ROLLBACK] Invalid anti-rollback state, skipping
There is more stuff when looking for rpmb...
A little bit of googling leads to: https://docs.google.com/viewer?url=patentimages.storage.googleapis.com/pdfs/US20140250290.pdf
This doesn't look good at all
These strings might give a bit hope:
Code:
[RPMB] Invalid magic, re-creating...
[RTC] clear rpmb program mode flag in rtc register
So something could be stored in the realtime clock and the device might recover if the RPMB block gets destroyed. I can't find any mention of OTP or fuses in the image.
EDIT: It seems rpmb can be accessed through /dev/block/mmcblk0rpmb. I've uploaded mine (5.0.1) to: http://bork.cs.fau.de/~michael/fire/
It seems to only contain a few ones and many zeroes.
It would be interesting to get the rpmb of a 5.1.1 device to compare:
Code:
$ adb shell
[email protected]:/ $ su
[email protected]:/ # dd if=/dev/block/mmcblk0rpmb of=/sdcard/rpmb.bin
1024+0 records in
1024+0 records out
524288 bytes transferred in 0.093 secs (5637505 bytes/sec)
I would not advise trying to flash the 5.0.1 rpmb to a 5.1.1 device!
Regards,
Michael

stargo said:
Hi,
I'm sorry to shatter hopes for bootloader rollback, but I was looking at the strings in preloader_prod.img and found this:
Code:
$ strings images/preloader_prod.img | grep -i rollback
[ANTI-ROLLBACK] Processing anti-rollback data
[ANTI-ROLLBACK] Failed to read block 0
[ANTI-ROLLBACK] PL: %x TEE: %x LK: %x
[ANTI-ROLLBACK] Need to update version
[ANTI-ROLLBACK] Invalid checksum!
[ANTI-ROLLBACK] Checksum validated
[ANTI-ROLLBACK] PL version mismatch!
[ANTI-ROLLBACK] L: %x R: %x
[ANTI-ROLLBACK] Updating PL version
[ANTI-ROLLBACK] TEE version mismatch!
[ANTI-ROLLBACK] Updating TEE version
[ANTI-ROLLBACK] LK version mismatch!
[ANTI-ROLLBACK] Updating LK version
[ANTI-ROLLBACK] All checks passed
[ANTI-ROLLBACK] Updating RPMB block...
[ANTI-ROLLBACK] Unable to update RPMB block (wc)
[ANTI-ROLLBACK] Unable to update RPMB block (write)
[ANTI-ROLLBACK] RPMB block updated
[RPMB] Failed to initialize anti-rollback block
[RPMB] Anti-rollback block initialized
[RPMB] Valid anti-rollback block exists
[ANTI-ROLLBACK] Invalid anti-rollback state, skipping
There is more stuff when looking for rpmb...
A little bit of googling leads to: https://docs.google.com/viewer?url=patentimages.storage.googleapis.com/pdfs/US20140250290.pdf
This doesn't look good at all
These strings might give a bit hope:
Code:
[RPMB] Invalid magic, re-creating...
[RTC] clear rpmb program mode flag in rtc register
So something could be stored in the realtime clock and the device might recover if the RPMB block gets destroyed. I can't find any mention of OTP or fuses in the image.
EDIT: It seems rpmb can be accessed through /dev/block/mmcblk0rpmb. I've uploaded mine (5.0.1) to: http://bork.cs.fau.de/~michael/fire/
It seems to only contain a few ones and many zeroes.
It would be interesting to get the rpmb of a 5.1.1 device to compare:
Code:
$ adb shell
[email protected]:/ $ su
[email protected]:/ # dd if=/dev/block/mmcblk0rpmb of=/sdcard/rpmb.bin
1024+0 records in
1024+0 records out
524288 bytes transferred in 0.093 secs (5637505 bytes/sec)
I would not advise trying to flash the 5.0.1 rpmb to a 5.1.1 device!
Regards,
Michael
Click to expand...
Click to collapse
How interesting. Thanks @stargo! I've updated the OP accordingly to your findings. Yes, it seems more complex than previously thought. I'll upload my 5.1.1 rpmb binary soon.

Hi there! As se en within I read mtk is a very hard platform to work with, because they are very closed, and they hardly ever release any source, so most Roms are ports of a similar decide. I'll have a search for a device with this same soc to ser if i can come back with related info. That's why I'm surprised we have cm here!

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

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