[Q] error status 6 on pac_honami-nightly-20140918.zip - PAC Q&A

I've installed nighty_0915 on my C6902, but when i tried to install nighty_0917&0918, the error status 6 kept bothering me.
I use the "OTA Verification" app to verify the 0918, and it says:
Failed expression at line #19:
sha1_check(read_file("/tmp/releasekey"),"7241e92725436afc79389d4fc2333a2aa8c20230") && abort("Can't install this package on top of incompatible data. Please try another package or run a factory reset");
Selected file to process:
/storage/sdcard0/Download/pac_honami-nightly-20140918-1.zip
================
Analysis
================
statements read: 120
expressions processed: 25
true statements: 24
false statements: 1
inaccessible count: 0
- there were (1) failed expressions encountered (see details above)
Device information:
Device: honami
Maker: Sony
Model: Xperia Z1
Carrier:
Board: MSM8974
Name: C6903----------------------------------->>>i donno why it's 6903, i'm sure i bought a C6902.
Bootloader: s1
Android OS: 4.4.4
plz help:crying:, thx!!

Related

[Q] htc update on trophy

Hi,
I flashed touch-it rom on my trophy and later on tried to flash the htc original which half bricked my bootloader (one line only). So I'm stuck on touch-it. I installed dutch language and updated to 7740 through cab method.
Recently zune mentions theres a htc update, so I try it but it fails with error 0x80180048. Exact error:
================================================
START OF UPDATEVALIDATOR ERROR MESSAGES
================================================
ERROR: E_INVALID_SIGNATURE:
Package: \OSRoot\Application Data\Microsoft\DeviceUpdate\Packages\11E534F5-CAC2-4E07-AD88-F9CD61673A14.101.pks\HTC_OEMAPPS.cab.pkg FROM Version: 0.0.0.0 TO Version: 2250.21.51006.401 GUID = {47C557C0-08B2-493C-A380-08C72D78E3BA}
ERROR: E_CANNOT_UPDATE_TO_HIGHEST_VERSION: CreatePaths: For package named: HTC_OEMAPPS cannot find a path to highest expected version of: 2250.21.51006.401
ERROR: UpdateOrderFromFileList: MAIN OS Update: MAIN OS Update Failed with HRESULT : 0x80180048
=====================================================================
GOOD PACKAGES AND BAD PACKAGES LIST
=====================================================================
UpdateOrderFromFileList failed with code 0x80180048
BAD PACKAGE: HTC_OEMAPPS.cab.pkg ERROR CODE: 0x80180008 Total number of Bad Packages: 1
Process Failed with code 0x80180048
Is there anybody that can help me please? Or is there no other option but to send to repair centre? Thanks for your trouble

Flashing failes everytime I try to flash. Rsdlite error included

This was my first time.
I did all what was required.
But when I started the flash through RSD lite after just 1 min it showed me FAIL
It went from 1% to 100% once, and then it showed FAIL
Now when I unplugged the USB and remove the battery and insert it back again it automaticaly goes into bootloader and then I tried to flash again which gave me same result.
This is my phone status.
The screen shows
Code Corrupt
Battery OK
OK to Program
Trasnfer Mode:
USB
This is what the Rsdlite Error log file has.
22:32:29, May 13, 2012
Line: 537
ERROR: AP Die ID: 1140010e560368010000dcff0200
22:32:29, May 13, 2012
Line: 544
ERROR: BP Die ID: 0000000000000000000000000000
22:32:29, May 13, 2012
Line: 551
ERROR: AP Public ID: 785fdd0a961a8e4b1e6a0497d703ee271d20c5c0
22:32:29, May 13, 2012
Line: 558
ERROR: BP Public ID: 0000000000000000000000000000000000000000
22:32:29, May 13, 2012
Line: 709
ERROR: Phone[0000]: Error erasing subscriber unit. Device API Error: 0xE0030040 Command: ERASE
File: D:\GitProjectsReleases\hdt_windows_flash\flash\code\flashdll\ErasingOp.cpp
Device ID: 0
22:32:29, May 13, 2012
Line: 1195
ERROR: Phone[0000]: Flash failed.
File: D:\GitProjectsReleases\hdt_windows_flash\flash\code\flashdll\PST_FP_FlashThread.cpp
Device ID: 0
22:32:29, May 13, 2012
Line: 610
ERROR: Flash failure: Phone[0000]: Error erasing subscriber unit. Device API Error: 0xE0030040 Command: ERASE (Error Code: e0030040),
Detailed Error Details: Direction of the Error=2000, Command Value=100000, Code Group Number=No Codegroup
File: D:\GitProjectsReleases\hdt_windows_flash\flash\code\flashdll\FlashHdlr.cpp
Device ID: 0
Click to expand...
Click to collapse
Please someone reply asap.
use the recommened rsdlite version...i have seen many other version of rsdlite gives such errors..i actually dont remember the exact version ..haven't used it for a while..
do a search in this forum..
All the best
I have read few other places and it said to use RSDLITE 4.9, which I did.
try version 3.4.8 if m not wrong..
Which one do you used for flashing?
i think the above version only..i have recommended the same version to many people and it works like a charm in past..search this forum for rsdlite stable version by experience of people..
I did successfully flash my Defy+ with RSDLite v5.6 (search the forum or google)
Maybe there's something wrong with your sbf-file? Just a wild guess, don't know if the error message tells actually something different...
Thanks for your time guys. I was trying to flash on my Desktop with no avail.
Tried on my lappy and Bingo its all done perfectly.
Happy I have finally upgraded to CM7 its really nice and fast.

bricked!

well here is my brick!
If I flash my phone nimporte what SBF says "flash error"
2012/05/07 13:45:13 | -- | ERROR: AP Die ID: 0ab0010b107660010000d8ff0100
2012/05/07 13:45:13 | -- | ERROR: BP Die ID: 0000000000000000000000000000
2012/05/07 13:45:13 | -- | ERROR: AP Public ID: e53a8a292b0b38ade4b76e0e3be0cde12a8d02bd
2012/05/07 13:45:13 | -- | ERROR: BP Public ID: 0000000000000000000000000000000000000000
2012/05/07 13:48:22 | 0 | ERROR: Phone[0000]: Error verifying Code Group 31 checksums. File: 0xB975, Phone: 0x9A68 ->(1557)FlashOp
2012/05/07 13:52:22 | 0 | ERROR: Phone[0000]: Error geting subscriber unit checksum. Device API Error: 0xE003003F Command: RQRCS ->(1511)FlashOp
2012/05/07 13:52:22 | 0 | ERROR: Phone[0000]: Error verifying Code Group 33 checksums. File: 0xFC1B, Phone: 0x4805 ->(1557)FlashOp
2012/05/07 13:56:22 | 0 | ERROR: Phone[0000]: Error geting subscriber unit checksum. Device API Error: 0xE003003F Command: RQRCS ->(1511)FlashOp
2012/05/07 13:56:22 | 0 | ERROR: Phone[0000]: Error verifying Code Group 34 checksums. File: 0xAB80, Phone: 0x4805 ->(1557)FlashOp
2012/05/07 13:57:22 | 0 | ERROR: Phone[0000]: Error geting subscriber unit checksum. Device API Error: 0xE0030009 Command: RQRCS ->(1511)FlashOp
2012/05/07 13:57:22 | 0 | ERROR: Phone[0000]: Error verifying Code Group 35 checksums. File: 0x41F4, Phone: 0x4805 ->(1557)FlashOp
2012/05/07 13:58:22 | 0 | ERROR: Phone[0000]: Error geting subscriber unit checksum. Device API Error: 0xE0030009 Command: RQRCS ->(1511)FlashOp
2012/05/07 13:58:22 | 0 | ERROR: Phone[0000]: Error verifying Code Group 39 checksums. File: 0x830D, Phone: 0x4805 ->(1557)FlashOp
2012/05/07 13:59:23 | 0 | ERROR: Phone[0000]: Error geting subscriber unit checksum. Device API Error: 0xE0030009 Command: RQRCS ->(1511)FlashOp
2012/05/07 13:59:23 | 0 | ERROR: Phone[0000]: Error verifying Code Group 42 checksums. File: 0x4BB7, Phone: 0x4805 ->(1557)FlashOp
2012/05/07 14:00:23 | 0 | ERROR: Phone[0000]: Error geting subscriber unit checksum. Device API Error: 0xE0030009 Command: RQRCS ->(1511)FlashOp
2012/05/07 14:00:23 | 0 | ERROR: Phone[0000]: Error verifying Code Group 45 checksums. File: 0xA9B3, Phone: 0x4805 ->(1557)FlashOp
2012/05/07 14:01:23 | 0 | ERROR: Phone[0000]: Error geting subscriber unit checksum. Device API Error: 0xE0030009 Command: RQRCS ->(1511)FlashOp
2012/05/07 14:01:23 | 0 | ERROR: Phone[0000]: Error verifying Code Group 47 checksums. File: 0xDE21, Phone: 0x4805 ->(1557)FlashOp
and when I restart the "code corrupt"
1 i made an SBF with the GC32 and my phone but remains redemare Blocke sue the blue LED
2 i have access to stck recovery
"e: can not mount cache: recovery / command
e: can not mount cache: recovery / caller
e: can not mount cache: recovery / log "
even after a wipe such toujour "
3 i have access to bootmenu but nothing works
"error: busybox rootfs Was Not created
error: cp not found "
thank you for your help
which rom SBF did u use?
I tested: 3.4.2-179-2 cee deblur
3.4.2-177-5 nordic deblur
3.4.2-177-3 ITA Blur
3.4.2-177-3 GB Blur
3.4.2-164 France (NU, Orange, SFR)
without success
Have you renamed the SBF in short name like "ABC.sbf"?
Have you pushed this short named SBF in the main Folder of RSD Lite?
Maybe your data cable is damaged.
Have made a factoryreset before flashing?
RATTAR
1 dont work
2 yes
3 i m tested for 3 data cable by moto
4 yes of course
only cg31, cg32, cg34, cg53, cg61, cg64 and cg65 pass
I fear your Defy is really bricked, i have read a nearly similiar thread on german forum.
The only solution for this User was to put his Defy to SC.
In his case the motherboard (probably damaged flash-memory) of the Defy was changed by SC.
i feel sorry with you.
thank you
R.I.P my defy
I would take the Defy to the Service Center.
The user i told you, made it and AFAIK the Service Center repair his phone in warranty.
Give your SC a try, the only thing could happend is, that the SC will tell you the repair costs something.
Then you can decide if you want to repair it or not.
The costs for repair are among to 120€.
I defy have longer under warranty and I did not want to be paid € 120 for the repaired while it costed me 50 €.
I bought a new phone
Have you considered selling it for parts for example? 'Cause if the price is right, I might be interested...
Hi
Hi , plz i want to ask you, what you did to your phone with this problem, because this is happening to me now and i don't know what i should do

[Q] Errors when attempting to SBF reset

So I Found my old Droid X earlier this week the battery was bad so I got a new one and I attempted to restore the device using tomsgt123's (RootJunky) video (I can't post links ) and RSDlite must have froze on me because it got stuck and 98% of something to do with ram (I can't find a log so I can't rely be more specific) and then I let it sit thinking it was just taking a while and I came back nothing was on the program and my device just says code corrupted battery low cannot program.
So what I am wondering is if I can retry If i can manage to get the battery charged or if this thing just became a brick
I should also mention that when I pressed start on RSDlite my battery was fully charged
Thank You in advance if you can help me.
Edit I found a log actually
2014/07/04 10:51:29 | -- | ERROR: AP Die ID: 1e300210fa903a0a0000d8ff0100
2014/07/04 10:51:29 | -- | ERROR: BP Die ID: 0000000000000000b55432890485
2014/07/04 10:51:29 | -- | ERROR: AP Public ID: 2469367a1407acd048a3f1e89f054bd90523fa08
2014/07/04 10:51:29 | -- | ERROR: BP Public ID: 040000000500000002000000ffff00002d003289
2014/07/04 11:14:29 | 0 | ERROR: Interface BP: Error sending RAM download for bootloader. Device API Error: 0xE003003F Address: 0x156000 Command: ADDR ->(970)RDLOp
2014/07/04 11:14:29 | 0 | ERROR: Phone[0000]: Flash failed. ->(1195)PST_FP_FlashThread
2014/07/04 11:14:31 | 0 | ERROR: Flash failure: Interface BP: Error sending RAM download for bootloader. Device API Error: 0xE003003F Address: 0x156000 Command: ADDR (Error Code: e003003f),
Detailed Error Details: Direction of the Error=2000, Command Value=200000, Code Group Number=257 ->(625)FlashHdlr
Motorola Drivers are not installed on windows.
Install drivers or use DX (MB810) ezSBF & Root 2.3.4/4.5.621
Ill Try
Ok, Thanks I thought I had the drivers installed already though as Ive already done some work on other motorola devices this week. But I'm ordering a battery charger should be here in a couple days and I'm going to try the live CD method Ive already burned the CD so Thanks

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

Categories

Resources