Lesson learned, head hanging down... Oh well. I tried guy. Either ways that only REINFORCES that we all need to get together and share what we know! Hence this thread:
Time for us to come together and put all of our knowledge together. Every known exploit for our bootloader, kernel, rom, ect needs to be logged in one area. All our partitions / sizes / locations / offsets need to be logged. Any and all information that can be gleamed from out fxz/sbf's need to be logged.
I have my own root exploit I want to work on for 5.0 and below... If that time comes, I'll release that. For now I'll keep this updated
Planned todo in order :
safestrap (Will boost Dev's, makes testing roms a breeze!)
kexec (Now Dev's can start juggling kernels) (maybe even forcefully reduce original kernels memory use) (reclaiming resources?, turning off unneeded original kernels modules ect... why not full hijacking of original kernel? Can you write to ANY memory region? (See graphics buffer vulnerability below.....hmmm 5.0 and under "AIO root / kexc / safestrap"? )
cm kernel (Hopefully a Dev beats me to it, as I have next planned....)
5.0 and below root (via graphics buffer vulnerability) https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-1474
How to backup critical files/partitions
**Just tried this, some partitions/files are assumed to be read protected...
So far, looks like we got data. I'm pretty sure its the kind you'd want if there was a brickfix in the future... sometimes each device has its own signature required for easy brickfix... Mines backed up in three different places already*
http://forum.xda-developers.com/dro...-aio-information-thread-t3138839/post61435029
XT1254 WRITE PROTECT :
if you bothered to read the init.rc files, you'd see that you can hijack the boot system early enough to disable qe if you're bothered by write protection, since this happens on fs stage:
# arrange access to the overlay
exec /system/bin/checknmount -d -s -m -t ext4 -r /overlay/sysupdate /cache/overlay/sysupdate.simg /cache/overlay/sysupdate.jar
# use the overlay, if it is compatible
exec /system/bin/stacker -d -c -r -t overlayfs /system /overlay/sysupdate[/HIDE]
How to copy your /firmware/image/*.* easily. *****Just tried this, some partitions/files are assumed to be read protected...
with efs explorer
copy /firmware/image/ folder to /sdcard/firmware/
with PC in MTP mode copy /image/ folder to PC
So far, looks like we got data. I'm pretty sure its the kind you'd want if there was a brickfix in the future... sometimes each device has its own signature required for easy brickfix... Mines backed up in three different places
List of partitions/files copied : (Remember, I havn't had time to even look further, the first one I opened wasn't blanked out.)
[email protected]:/ $ cd firmware
[email protected]:/firmware $ cd image
[email protected]:/firmware/image $ ls
acdb.mbn
adsp.b00
adsp.b01
adsp.b02
adsp.b03
adsp.b04
adsp.b05
adsp.b06
adsp.b07
adsp.b08
adsp.b10
adsp.b11
adsp.b12
adsp.mbn
adsp.mdt
apps.mbn
bdwlan11.bin
bdwlan20.bin
cmnlib.b00
cmnlib.b01
cmnlib.b02
cmnlib.b03
cmnlib.mdt
dsp2.mbn
efs1.bin
efs2.bin
efs3.bin
isdbtmm.b00
isdbtmm.b01
isdbtmm.b02
isdbtmm.b03
isdbtmm.mdt
keymaster.b00
keymaster.b01
keymaster.b02
keymaster.b03
keymaster.mdt
mba.mbn
otp11.bin
otp20.bin
playready.b00
playready.b01
playready.b02
playready.b03
playready.mdt
prov.b00
prov.b01
prov.b02
prov.b03
prov.mdt
qdsp6sw.mbn
qwlan11.bin
qwlan20.bin
rpm.mbn
sampleapp.b00
sampleapp.b01
sampleapp.b02
sampleapp.b03
sampleapp.mdt
sbl1.mbn
securemm.b00
securemm.b01
securemm.b02
securemm.b03
securemm.mdt
tqs.b00
tqs.b01
tqs.b02
tqs.b03
tqs.mdt
tz.mbn
utf11.bin
utf20.bin
widevine.b00
widevine.b01
widevine.b02
widevine.b03
widevine.mdt
[email protected]:/firmware/image $
Partition Table:
? ? ? Total size flash location partition name size notes:
179 0 30535680 "mmcblk0 " 32GB Flash Chip
179 1 131072 mmcblk0p1 " modem" 0x0000000008000000
179 2 384 "mmcblk0p2 " ? Sbl1 0x0000000000060000
179 3 56 "mmcblk0p3 " ? Sdi 0x000000000000e000
179 4 16 "mmcblk0p4 " sec: 0x0000000000004000
179 5 32 mmcblk0p5 " ddr" 0x0000000000008000
179 6 1024 mmcblk0p6 " aboot" 0x0000000000100000
179 7 256 mmcblk0p7 " rpm" 0x0000000000040000
179 8 512 mmcblk0p8 ? Utags 0x0000000000080000 contains imei, take note of backup partition
179 9 500 mmcblk0p9 ? Tz 0x000000000007d000
179 10 3072 mmcblk0p10 " factorytune1" 0x0000000000300000
179 11 1084 mmcblk0p11 " padA" 0x000000000010f000
179 12 384 mmcblk0p12 sbl1bak: 0x0000000000060000
179 13 1024 mmcblk0p13 " abootBackup" 0x0000000000100000
179 14 256 mmcblk0p14 ?rpmBackup 0x0000000000040000
179 15 512 mmcblk0p15 ? utagsBackup 0x0000000000080000 backup
79 16 500 mmcblk0p16 ? tzBackup 0x000000000007d000
179 17 1024 mmcblk0p17 " mdm1m9kefs1" 0x0000000000100000
179 18 1024 mmcblk0p18 " mdm1m9kefs2" 0x0000000000100000
179 19 2620 mmcblk0p19 " padB" 0x000000000028f000
179 20 2048 mmcblk0p20 " logs" 0x0000000000200000
179 21 32768 mmcblk0p21 " persist" 0x0000000002000000
179 22 256 mmcblk0p22 " mdm1hob" 0x0000000000040000
179 23 32 mmcblk0p23 " mdm1dhob" 0x0000000000008000
179 24 1024 mmcblk0p24 ? Sp 0x0000000000100000
179 25 128 mmcblk0p25 " cid" 0x0000000000020000
179 26 3072 mmcblk0p26 " pds" 0x0000000000300000
179 27 8192 mmcblk0p27 " logo" 0x0000000000800000
179 28 11264 mmcblk0p28 ? Clogo 0x0000000000b00000
179 29 1024 mmcblk0p29 " misc" 0x0000000000100000
179 30 1632 mmcblk0p30 " padC" 0x0000000000198000
179 31 780 mmcblk0p31 " mdm1m9kefs3" 0x00000000000c3000
259 0 1 mmcblk0p32 " mdm1m9kefsc" 0x0000000000000400
259 1 8 mmcblk0p33 ? Ssd 0x0000000000002000
259 2 8192 mmcblk0p34 " kpan" 0x0000000000800000
259 3 16384 mmcblk0p35 " boot" 0x0000000001000000
259 4 16400 mmcblk0p36 " recovery" 0x0000000001004000
259 5 16416 mmcblk0p37 " factorytune2" 0x0000000001008000
259 6 1469392 mmcblk0p38 " cache" 0x0000000059af4000
259 7 3457024 mmcblk0p39 ? System 0x00000000d3000000
259 8 25309056 mmcblk0p40 ? Userdata 0x0000000608be0000
179 32 4096 mmcblk0 rpmb (Replay Protected Memory Block) RPMB is not a regular partition and a different command sequence(CMD6-->CMD23-->CMD25-->CMD23-->CMD18) as mentioned in JEDEC Standard No. 84-A441, is required to access it, then why mmc initialisation code is using the wrong command sequence(CMD6-->CMD23-->CMD18) to access it?
Old Partition table:
(bootloader) sdi.git: git=MBM-NG-V70.47-0-gf291c61
(bootloader) sbl1.git: git=MBM-NG-V70.47-0-ga007c2c
(bootloader) rpm.git: git=MBM-NG-V70.47-0-g66204d2
(bootloader) tz.git: git=MBM-NG-V70.47-0-g4cdbfd4
(bootloader) aboot.git: git=MBM-NG-V70.47-0-gc723802
(bootloader) partition-size:modem: 0x0000000008000000
(bootloader) partition-size:sbl1: 0x0000000000060000
(bootloader) partition-size:sdi: 0x000000000000e000
(bootloader) partition-size:sec: 0x0000000000004000
(bootloader) partition-size:ddr: 0x0000000000008000
(bootloader) partition-size:aboot: 0x0000000000100000
(bootloader) partition-size:rpm: 0x0000000000040000
(bootloader) partition-size:utags: 0x0000000000080000
(bootloader) partition-size:tz: 0x000000000007d000
(bootloader) partition-size:factorytune1: 0x0000000000300000
(bootloader) partition-sizeadA: 0x000000000010f000
(bootloader) partition-size:sbl1bak: 0x0000000000060000
(bootloader) partition-size:abootBackup: 0x0000000000100000
(bootloader) partition-size:rpmBackup: 0x0000000000040000
(bootloader) partition-size:utagsBackup: 0x0000000000080000
(bootloader) partition-size:tzBackup: 0x000000000007d000
(bootloader) partition-size:mdm1m9kefs1: 0x0000000000100000
(bootloader) partition-size:mdm1m9kefs2: 0x0000000000100000
(bootloader) partition-sizeadB: 0x000000000028f000
(bootloader) partition-size:logs: 0x0000000000200000
(bootloader) partition-sizeersist: 0x0000000002000000
(bootloader) partition-size:mdm1hob: 0x0000000000040000
(bootloader) partition-size:mdm1dhob: 0x0000000000008000
(bootloader) partition-size:sp: 0x0000000000100000
(bootloader) partition-size:cid: 0x0000000000020000
(bootloader) partition-sizeds: 0x0000000000300000
(bootloader) partition-size:logo: 0x0000000000800000
(bootloader) partition-size:clogo: 0x0000000000b00000
(bootloader) partition-size:misc: 0x0000000000100000
(bootloader) partition-sizeadC: 0x0000000000198000
(bootloader) partition-size:mdm1m9kefs3: 0x00000000000c3000
(bootloader) partition-size:mdm1m9kefsc: 0x0000000000000400
(bootloader) partition-size:ssd: 0x0000000000002000
(bootloader) partition-size:kpan: 0x0000000000800000
(bootloader) partition-size:boot: 0x0000000001000000
(bootloader) partition-size:recovery: 0x0000000001004000
(bootloader) partition-size:factorytune2: 0x0000000001008000
(bootloader) partition-size:cache: 0x0000000059af4000
(bootloader) partition-size:system: 0x00000000d3000000
(bootloader) partition-size:userdata: 0x0000000608be0000
cat_/proc/partitions
Start_______End address_____major__minor__#blocks_____name____partition name
?0x?0?0?0?0__0x?0?0?0?0?___179_____0___30535680__mmcblk0
?0x?0?0?0?0__0x?0?0?0?0?___179_____1_____131072__mmcblk0p1 modem
?0x?0?0?0?0__0x?0?0?0?0?___179_____2_____384__mmcblk0p2 sbl1
?0x?0?0?0?0__0x?0?0?0?0?___179_____3______56__mmcblk0p3 sdi
?0x?0?0?0?0__0x?0?0?0?0?___179_____4______16__mmcblk0p4 sec
?0x?0?0?0?0__0x?0?0?0?0?___179_____5______32__mmcblk0p5 ddr
?0x?0?0?0?0__0x?0?0?0?0?___179_____6____1024__mmcblk0p6 aboot
?0x?0?0?0?0__0x?0?0?0?0?___179_____7_____256__mmcblk0p7 rpm
?0x?0?0?0?0__0x?0?0?0?0?___179_____8_____512__mmcblk0p8 utags
?0x?0?0?0?0__0x?0?0?0?0?___179_____9_____500__mmcblk0p9 tz
?0x?0?0?0?0__0x?0?0?0?0?___179____10____3072__mmcblk0p10 factorytune1
?0x?0?0?0?0__0x?0?0?0?0?___179____11____1084__mmcblk0p11 padA
?0x?0?0?0?0__0x?0?0?0?0?___179____12_____384__mmcblk0p12 sbl1bak
?0x?0?0?0?0__0x?0?0?0?0?___179____13____1024__mmcblk0p13 abootBackup
?0x?0?0?0?0__0x?0?0?0?0?___179____14_____256__mmcblk0p14 rpmBackup
?0x?0?0?0?0__0x?0?0?0?0?___179____15_____512__mmcblk0p15 utagsBackup
?0x?0?0?0?0__0x?0?0?0?0?___179____16_____500__mmcblk0p16 tzBackup
?0x?0?0?0?0__0x?0?0?0?0?___179____17____1024__mmcblk0p17 mdm1m9kefs1
?0x?0?0?0?0__0x?0?0?0?0?___179____18____1024__mmcblk0p18 mdm1m9kefs2
?0x?0?0?0?0__0x?0?0?0?0?___179____19____2620__mmcblk0p19 padB
?0x?0?0?0?0__0x?0?0?0?0?___179____20____2048__mmcblk0p20 logs
?0x?0?0?0?0__0x?0?0?0?0?___179____21___32768__mmcblk0p21 persist
?0x?0?0?0?0__0x?0?0?0?0?___179____22_____256__mmcblk0p22 mdm1hob
?0x?0?0?0?0__0x?0?0?0?0?___179____23______32__mmcblk0p23 mdm1dhob
?0x?0?0?0?0__0x?0?0?0?0?___179____24____1024__mmcblk0p24 sp
?0x?0?0?0?0__0x?0?0?0?0?___179____25_____128__mmcblk0p25 cid
?0x?0?0?0?0__0x?0?0?0?0?___179____26____3072__mmcblk0p26 pds
?0x?0?0?0?0__0x?0?0?0?0?___179____27____8192__mmcblk0p27 logo
?0x?0?0?0?0__0x?0?0?0?0?___179____28___11264__mmcblk0p28 clogo
?0x?0?0?0?0__0x?0?0?0?0?___179____29____1024__mmcblk0p29 misc
?0x?0?0?0?0__0x?0?0?0?0?___179____30____1632__mmcblk0p30 padC
?0x?0?0?0?0__0x?0?0?0?0?___179____31_____780__mmcblk0p31 mdm1m9kefs3
?0x?0?0?0?0__0x?0?0?0?0?___259_____0_______1__mmcblk0p32 mdm1m9kefsc
?0x?0?0?0?0__0x?0?0?0?0?___259_____1_______8__mmcblk0p33 ssd
?0x?0?0?0?0__0x?0?0?0?0?___259_____2____8192__mmcblk0p34 kpan
?0x?0?0?0?0__0x?0?0?0?0?___259_____3___16384__mmcblk0p35 boot
?0x?0?0?0?0__0x?0?0?0?0?___259_____4___16400__mmcblk0p36 recovery
?0x?0?0?0?0__0x?0?0?0?0?___259_____5___16416__mmcblk0p37 factorytune2
?0x?0?0?0?0__0x?0?0?0?0?___259____6__1469392__mmcblk0p38 cache
?0x?0?0?0?0__0x?0?0?0?0?___259____7__3457024__mmcblk0p39 system
?0x?0?0?0?0__0x?0?0?0?0?___259____8_25309056__mmcblk0p40 userdata
?0x?0?0?0?0__0x?0?0?0?0?___179____32____4096__mmcblk0rpmb *"protected data"
* The "RPMB partition is special and can not be accessed
by normal eMMC read / write CMDs". It will cause a kernel error, buffer I/O error"
BOOTLOADER:
Aboot:
Snaipersky said:
interesting stuff regarding ABOOT. newandroidbook.com/Articles/aboot.html?s. I have a Dev MX13, so I'm just here for ideological reasons.
As I understand it, the Turbo's WP is handled by ABOOT. Now, Moto has a bad habit of altering the bootloader so that downgrading is infeasible, and increments it. So it is possible to alter ABOOT.
According to NAB, most of the time (barring cases such as Samsung and Amazon, so we shouldn't have an issue- SHOULD being key) This is secured by a signature check rather than hashing, and the signature is of a fixed size.
One can retrieve the signed image, and if rooted, retrieve the image, sans-signature. Now, if we have the file with and without the signature, could one not create a WP-less, unsigned ABOOT, and then manually paste the signature (Forge it?) in front of it? It would be binary editing, Which I think would be the main challenge.
Could we daisychain this with MoFo to create an effective bootloader unlock? It would be a rootable, system flashable, and without WP, should be able to take a custom recovery.
I may be talking out my *** here, but just my understanding of things.
Click to expand...
Click to collapse
do some disassembly of tz.mbn and find a vulnerability to be able to blow the unlocking qfuse (assuming the device isn't permalocked by SBD_EN qfuse Moto uses)
a known bootloader exploit:
version: MBM-NG-V70.47-0-gcXXXXXX
https://www.codeaurora.org/projects...unds-checking-when-flashing-sparse-images-cve
KNOWN VULNERABILITIES :
bypass's intended restrictions on cryptographic operations, via a long key name:
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-3100 -?? patched already?
https://www.exploit-db.com/docs/33864.pdf - ?? patched already?
Graphics buffer vulnerability :
https://packetstormsecurity.com/files/130778/Google-Android-Integer-Oveflow-Heap-Corruption.html
http://seclists.org/fulldisclosure/2015/Mar/63
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-1474
Safestrap :
safestrap/kexec. Safestrap can be changed to "reuse" certain existing partitions or emulate any of them.
/cache 2.3mb used......... 1.36GB FREE! can be used for /system
/firmware 77mb used ...... 45MB FREE! can be used for /cache
start by being able to load /system on to /cache
then look deeper into partitions for another one
or
go the create a Xgb file on the data partition and load it as a data partition
reserved for kexec
HARDWARE:
[/HIDE]Hardware-ish:
https://www.codeaurora.org/cgit/qui...r&id=82117399ba17ea60b7f771c641ff5b1c9283bdc9
https://www.codeaurora.org/cgit/qui...r&id=82117399ba17ea60b7f771c641ff5b1c9283bdc9
https://www.codeaurora.org/cgit/qui...r&id=82117399ba17ea60b7f771c641ff5b1c9283bdc9
https://www.codeaurora.org/cgit/qui...r&id=82117399ba17ea60b7f771c641ff5b1c9283bdc9
https://www.codeaurora.org/cgit/qui...=AU_LINUX_ANDROID_JB_3.2.1.3.04.03.00.176.156
http://forum.xda-developers.com/showthread.php?t=1914359
https://gitlab.com/k2wl/g2_kernel/commit/c3bbe60c733a17a2295241b558d8162b4c782154?view=parallel
http://forum.xda-developers.com/showthread.php?t=2136738
http://forum.xda-developers.com/showthread.php?t=1235219
https://github.com/dtsinc/DTS-Eagle...ob/master/arch/arm/boot/dts/qcom/apq8084.dtsi
http://pastebin.com/tX06Yp3q
http://forum.gsmhosting.com/vbb/f609/atf-drive-v12-30-update-19-may-2015-a-937102/index5.html
http://forum.xda-developers.com/showthread.php?t=1914359
http://faq.riffbox.org/content/10/5...emmc-efi_pit_mbr_ebr-partitioning-plugin.html
Qualcomm APQ8084 TLMM block
This binding describes the Top Level Mode Multiplexer block found in the
MSM8960 platform.
Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for
a general description of GPIO and interrupt bindings.
Please refer to pinctrl-bindings.txt in this directory for details of the
common pinctrl bindings used by client devices, including the meaning of the
phrase "pin configuration node".
The pin configuration nodes act as a container for an arbitrary number of
subnodes. Each of these subnodes represents some desired configuration for a
pin, a group, or a list of pins or groups. This configuration can include the
mux function to select on those pin(s)/group(s), and various pin configuration
parameters, such as pull-up, drive strength, etc.
PIN CONFIGURATION NODES:
The name of each subnode is not important; all subnodes should be enumerated
and processed purely based on their content.
Each subnode only affects those parameters that are explicitly listed. In
other words, a subnode that lists a mux function but no pin configuration
parameters implies no information about any pin configuration parameters.
Similarly, a pin subnode that describes a pullup parameter implies no
information about e.g. the mux function.
The following generic properties as defined in pinctrl-bindings.txt are valid
to specify in a pin configuration subnode:
- pins:
Usage: required
Value type: <string-array>
Definition: List of gpio pins affected by the properties specified in
this subnode. Valid pins are:
gpio0-gpio146,
sdc1_clk,
sdc1_cmd,
sdc1_data
sdc2_clk,
sdc2_cmd,
sdc2_data
- function:
Usage: required
Value type: <string>
Definition: Specify the alternative function to be configured for the
specified pins. Functions are only valid for gpio pins.
Valid values are:
adsp_ext, audio_ref, blsp_i2c1, blsp_i2c2, blsp_i2c3,
blsp_i2c4, blsp_i2c5, blsp_i2c6, blsp_i2c7, blsp_i2c8,
blsp_i2c9, blsp_i2c10, blsp_i2c11, blsp_i2c12,
blsp_spi1, blsp_spi2, blsp_spi3, blsp_spi4, blsp_spi5,
blsp_spi6, blsp_spi7, blsp_spi8, blsp_spi9, blsp_spi10,
blsp_spi11, blsp_spi12, blsp_uart1, blsp_uart2, blsp_uart3,
blsp_uart4, blsp_uart5, blsp_uart6, blsp_uart7, blsp_uart8,
blsp_uart9, blsp_uart10, blsp_uart11, blsp_uart12,
blsp_uim1, blsp_uim2, blsp_uim3, blsp_uim4, blsp_uim5,
blsp_uim6, blsp_uim7, blsp_uim8, blsp_uim9, blsp_uim10,
blsp_uim11, blsp_uim12, cam_mclk0, cam_mclk1, cam_mclk2,
cam_mclk3, cci_async, cci_async_in0, cci_i2c0, cci_i2c1,
cci_timer0, cci_timer1, cci_timer2, cci_timer3, cci_timer4,
edp_hpd, gcc_gp1, gcc_gp2, gcc_gp3, gcc_obt, gcc_vtt,i
gp_mn, gp_pdm0, gp_pdm1, gp_pdm2, gp0_clk, gp1_clk, gpio,
hdmi_cec, hdmi_ddc, hdmi_dtest, hdmi_hpd, hdmi_rcv, hsic,
ldo_en, ldo_update, mdp_vsync, pci_e0, pci_e0_n, pci_e0_rst,
pci_e1, pci_e1_rst, pci_e1_rst_n, pci_e1_clkreq_n, pri_mi2s,
qua_mi2s, sata_act, sata_devsleep, sata_devsleep_n,
sd_write, sdc_emmc_mode, sdc3, sdc4, sec_mi2s, slimbus,
spdif_tx, spkr_i2s, spkr_i2s_ws, spss_geni, ter_mi2s, tsif1,
tsif2, uim, uim_batt_alarm
- bias-disable:
Usage: optional
Value type: <none>
Definition: The specified pins should be configued as no pull.
- bias-pull-down:
Usage: optional
Value type: <none>
Definition: The specified pins should be configued as pull down.
- bias-pull-up:
Usage: optional
Value type: <none>
Definition: The specified pins should be configued as pull up.
- output-high:
Usage: optional
Value type: <none>
Definition: The specified pins are configured in output mode, driven
high.
Not valid for sdc pins.
- output-low:
Usage: optional
Value type: <none>
Definition: The specified pins are configured in output mode, driven
low.
Not valid for sdc pins.
- drive-strength:
Usage: optional
Value type: <u32>
Definition: Selects the drive strength for the specified pins, in mA.
Valid values are: 2, 4, 6, 8, 10, 12, 14 and 16
Example:
tlmm: [email protected] {
compatible = "qcom,apq8084-pinctrl";
reg = <0xfd510000 0x4000>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
interrupts = <0 208 0>;
uart2: uart2-default {
mux {
pins = "gpio4", "gpio5";
function = "blsp_uart2";
};
tx {
pins = "gpio4";
drive-strength = <4>;
bias-disable;
};
rx {
pins = "gpio5";
drive-strength = <2>;
bias-pull-up;
};
};
};
APQ Memory... This may or may not match, as it was not pulled off a turbo.
soc: soc { };
memory {
#address-cells = <2>;
#size-cells = <2>;
qsecom_mem: [email protected] {
linux,reserve-contiguous-region;
reg = <0 0 0 0x1100000>;
label = "qseecom_mem";
};
secure_mem: [email protected] {
linux,reserve-contiguous-region;
reg = <0 0 0 0xfc00000>;
label = "secure_mem";
};
tz_apps_and_debug_mem: [email protected] {
linux,reserve-contiguous-region;
linux,reserve-region;
linux,remove-completely;
reg = <0x0 0xd400000 0x0 0x700000>;
label = "tz_apps_and_debug_mem";
};
peripheral_mem: [email protected] {
linux,reserve-contiguous-region;
linux,reserve-region;
linux,remove-completely;
reg = <0x0 0x0db00000 0x0 0x1d00000>;
label = "peripheral_mem";
};
external_image_mem: [email protected] {
linux,reserve-contiguous-region;
linux,reserve-region;
linux,remove-completely;
reg = <0x0 0x0f800000 0x0 0x800000>;
label = "external_image_mem";
};
};
};
reserved for qualcomm download mode and recovery / backdoor flashing info
www.github.com/jcsullins/qdloader
http://forum.xda-developers.com/showthread.php?t=2136738
RANDOM INFO :
USB:
ProductID's the XT1254 can present:
VendorID 22b8 (Motorola, this never changes)
ProductID
2ea4 - MTP mode, software install Off
2ea5 - MTP mode, USB debugging on
2ea6 - PTP mode
2ea7 - PTP mode, USB debugging on
2ea8 - MTP mode, software install On
2e24 - MTP mode, with USB tethering active
NOTE: It is not possible to enable software install in PTP mode, or with USB debugging turned on.
For Google to find them together: VIDID 22b8:2ea4 22b8:2ea5 22b8:2ea6 22b8:2ea7 22b8:2ea8
Credit : http://jamesmcrow.com/node/11
Just in case you need another post reserved - let me know and I can transfer this one to you.......
jerdog said:
Just in case you need another post reserved - let me know and I can transfer this one to you.......
Click to expand...
Click to collapse
Hey, I plan on making this a MONSTER thread of information... I WILL work on this phone like I did the ms910. I can only find faint hints on xda that I ever even owned the phone... I still have this though :
http://androidforums.com/threads/de...esteem-4g-lg-ms910.722075/page-3#post-5867057
and this :
https://github.com/saschaelble?tab=repositories
This will be my :
RANDOM INFO TO BE DIGESTED,
http://lwn.net/Articles/600110/ -hardware?
https://github.com/razrqcom-dev-team/android_device_motorola_quark -cm12 kernel github for xt1225!!
https://www.google.com/search?q=mmcblk0 rpmb&ie=utf-8&oe=utf-8
http://www.digitalinternals.com/mobile/android-mmc-mmcblk-partition-layout/259/
https://forums.oneplus.net/threads/solution-how-i-recovered-my-oneplus-one-from-hard-brick.184927/
http://forum.xda-developers.com/showthread.php?p=50336648#post50336648
https://github.com/gokulnatha/GT-I9...ation/devicetree/bindings/ocmem/msm-ocmem.txt
https://github.com/dtsinc/DTS-Eagle...ob/master/arch/arm/boot/dts/qcom/apq8084.dtsi
https://www.google.com/search?q=emmc_appsboot.mbn&ie=utf-8&oe=utf-8
I have finished unbrick for Motorola Droid Turbo, if I understand you correctly.
http://forum.xda-developers.com/droid-turbo/general/turbo-unbrick-t3139811
Continuing to peddle your warez and hacked up nonsense, even via PM, has earned you a nice vacation. Closing thread.
I have replaced new empty eMMC flash memory in change of previous dead one.
Reason: bootloop, google logo, no boot, no fastboot (no LED blinking), device detected only in Intel DNX fastboot (MOOREFIELD):
Code:
New USB device found, idVendor=8086, idProduct=0a2c, bcdDevice= 0.a0
New USB device strings: Mfr=2, Product=1, SerialNumber=3
Product: MOOREFIELD
Manufacturer: INTEL
Instead of android fastboot mode:
Code:
New USB device found, idVendor=18d1, idProduct=4ee0, bcdDevice=ff.ff
New USB device strings: Mfr=2, Product=3, SerialNumber=4
Product: fugu
Manufacturer: Android
xFSTK Downloader (used files from ZenFone) doesn't work. Player disconnecting during flashing.
Actually I need partitions dumps or full RAW dump.
Code:
Setting interface to EasyJtag2/E-Socket
Setting bus width to 8 Bit
Setting frequence to 42 MHz
EMMC Device Information :
EMMC CID: 110100303038474530006625C95B71F1
EMMC CSD: D05E00320F5903FFFFFFFFEF924000D3
EMMC Manufacture : TOSHIBA , EMMC NAME: 008GE0 , HEX: 303038474530 , S/N: 6625C95B , rev. 0x00
EMMC Manufacture ID: 0x11 , OEM ID: 0x00 , Device Type: BGA (Discrete embedded) , Date: 7/2014
EMMC ROM 1 (Main User Data) Capacity: 7456 MB (0001D2000000)
EMMC ROM 2/3 (Boot Partition 1/2) Capacity: 4096 KB (000000400000)
EMMC RPMB (Replay Protected Memory Block) Capacity: 4096 KB (000000400000) Counter: 716 , Response: Not Clean
EMMC Permanent Write Protection: No
EMMC Temporary Write Protection: No
Extended CSD Information :
Extended CSD rev: 1.7 (MMC 5.0, MMC 5.01)
Boot configuration [PARTITION_CONFIG]: 0x00 , Boot from: no boot
Boot Bus Config: 0x00 , width 1bit
H/W Reset Function [RST_N_FUNCTION]: 0x00, RST_n signal is temporarily disabled
Supported partition features [PARTITIONING_SUPPORT]: 0x07
Device supports partitioning features
Device can have enhanced technological features in partitions and user data area
Device can have extended partitions attribute
Partition Settings [PARTITION_SETTING_COMPLETED]: 0x00
Backup saved: 008GE0_6625C95B_20191117_171608.extcsd
EMMC Init completed.
Warning: Health report is very BAD
Device Life Time Estimation (MLC) [269]: 0x00 Not defined
Device Life Time Estimation (SLC) [268]: 0x0B Exceeded its maximum estimated device life time
Pre EOL information [267]: 0x01 Normal
Scanning soft partitions
GPT header is found and is valid
Partition: boot, [000000005000 - 000001005000], size: 000001000000 (16,0 MB)
Partition: recovery, [000001005000 - 000002005000], size: 000001000000 (16,0 MB)
Partition: fastboot, [000002005000 - 000003005000], size: 000001000000 (16,0 MB)
Partition: factory, [000003005000 - 000003605000], size: 000000600000 (6,00 MB)
Partition: splashscreen, [000003605000 - 000003A05000], size: 000000400000 (4,00 MB)
Partition: panic, [000003A05000 - 000003E05000], size: 000000400000 (4,00 MB)
Partition: misc, [000003E05000 - 000003F05000], size: 000000100000 (1,00 MB)
Partition: temp, [000003F05000 - 000004F05000], size: 000001000000 (16,0 MB)
Partition: cache, [000004F05000 - 000014F05000], size: 000010000000 (256 MB)
Partition: system, [000014F05000 - 000054F05000], size: 000040000000 (1,00 GB)
Partition: userdata, [000054F05000 - 0001D1FFBE00], size: 00017D0F6E00 (5,95 GB)
GPT header successfully parsed
Dump status:
ROM1 - failed !
ROM2/3 (bootloader = ifwi - 164 bytes ?) - ok
RPMB - ok
Partially I can get boot, recovery, fastboot (droidboot), splashscreen, system from official google firmwares.
But more important is factory partition.
Anyway it would be nice to have full RAW dump.
Thanks.