Hello all,
Lately I've been interested in running custom code on the *fun* processors of my phones (the modem baseband cores).
Problem: The firmware images are supposed to be signed by the OEM, and I needed to bypass this signature check.
I have developed tools to do it on instances of Qualcomm MSM8960 based phones, namely the Sony Xperia SP and the Samsung s7275r.
Here are the repositories:
tzexec : A kernel module that exploit a bug in Qualcomm TrustZone code (discovered by Dan Rosenberg and described here: Reflections on Trusting TrustZone
pymdt : A python library to unsplit/patch/split firmware images and fix the hash segments.
(This is developer-intended code, don't ask me what you can do with it.)
Msm8960? Like the Verizon s4...... Hmmm
totor48 said:
Hello all,
Lately I've been interested in running custom code on the *fun* processors of my phones (the modem baseband cores).
Problem: The firmware images are supposed to be signed by the OEM, and I needed to bypass this signature check.
I have developed tools to do it on instances of Qualcomm MSM8960 based phones, namely the Sony Xperia SP and the Samsung s7275r.
Here are the repositories:
tzexec : A kernel module that exploit a bug in Qualcomm TrustZone code (discovered by Dan Rosenberg and described here: Reflections on Trusting TrustZone
pymdt : A python library to unsplit/patch/split firmware images and fix the hash segments.
(This is developer-intended code, don't ask me what you can do with it.)
Click to expand...
Click to collapse
Thanks to you for dis. Where can one get more general information about reading, mounting modem partitions?
Related
Sony "MediaTek SoC" Cross-Device Development: C4 C5 XA XA1 L1 E5 M5 and others
Hi Sony MediaTek SoC Device owners This is a WIP and I stand to be corrected by any dev regarding my grasp or explanation of things.
In this OP I will share all what I know or think I know about the Sony Device line that use MediaTek SoC's (System on Chip).
In my opinion most users will fall into one of two camps
Camp 1. Those who have always used Sony Devices and purchased one of these MediaTek based phones probably due to the price point.
Camp 2. Those who are well use to MediaTek based phones typically having used or owned previous cheaper Chinese branded devices. (I am in this camp mainly )
Camp 1. users will be well use to all the terms used in association with Sony device development.
Camp 2. users will be baffled and left scratching their heads saying "what" "what's that" "how do you mean" "I don't get it"
So for the benifit of Camp 2. users and noobs I present a list of the most often used Sony Terms and tools along with a very brief explanation and links where applicable.
1 FlashTool (meaning a Sony Specific tool to flash firmware packages using Sony's S1 Protocols in our case (http://www.flashtool.net/index.php Note: the Warning to C4/C5 users in the Downloads section. To use that version you need a custom FSC if one exists if not then there is a older version which is safe to use but it does have some limitation but more on this later)
2 TA (meaning Trim Area This is a impotant /partition and contains info specific to the device like IMEi, Serial Number, DRM keys, also Keys for Sony specific stuff which are called "Proprietary's" (more on this later)
3 FOTAKERNEL (meaning a For Over The Air Kernel a /partition basically this is the /recovery partition
4 .sin (meaning a Sony Specific archive tool kinda like .zip When you get stock sony firmware it comes packaged in .sin archives eg: system.sin boot.sin fotakernel.sin these .sin's all contain Sony Signatures i believe
5 .elf (meaning Sony's Preferred Format for the boot and recovery instead of the standard .img the .elf's are contained within the .sin's as explained above.
6 XperiFirm (meaning a firmware downloader and extraction Tool which allows you to choose your device and any Stock Firmware package for it. It will then download the firmware and automatically extract the file's contained within the .sin's. Stand Alone XperiFirm Thread Here This Tool is also integrated in to FlashTool which is at the top of this list XperiFirm is denoted within FlashTool by the XF tab/button at the top.
The following Info and Tools below are Mainly For Dev's. Some of the Tool's are beta and untested so ONLY experienced dev's should consider using them. When you brick a Sony it's usually just that a brick Unlike other MediaTek devices which are pretty unbrickable :good:
7 UnSIN (meaning a Tool by the dev of XperiFirm and is a stand alone tool for unsining .sins and would be most useful to dev's. (Note: for dev's it works using "mono" on Linux systems although I have to do a tune2fs on the system.ext4 before it can be extracted this could be just a glitch in my setup on yours it may well work just fine. ) UnSIN Thread Here
8 AIK (meaning Android Image Kitchen by @osm0sis this tool will unpack the .elf's and repack them as AOSP .img's by default :good: I did notice the default pagesize seems to be 4096 but most if not all the MediaTek .img's I come across seem to use 2048 so I usually change this from the default 4096. Main Thread HERE
9 Trim Area Proof Of Concept (meaning a tool by @munjeni to replace DRM fix likley this tool needs to be tested/adapted to MediaTek devices. Main thread HERE
10 Xflasher (meaning a tool again by @munjeni This tool is a cmdline tool and can flash devices using the S1 protocol in download mode. I tested this on the L1 Flashing only the system, boot, recovery etc but not the "boot delivery" preloader lk etc and it worked well but further testing is needed regarding the "boot delivery" Main Thread HERE
11 Unpack any Sony firmware (meaning a tool again by @munjeni Main Thread Here
To be continued..............
This is a draft OP so may change thing around depending on comments and certain dev's etc etc
Maybe a meeting point for Sony MediaTek SoC Device to meet share and get help from across the different device threads.
There is 98% + commonality between all our devices so It make sense to share and swap info in one common thread.
I am pretty sure what works for one device will most likely work for another.
Comments welcome.
@DerTeufel1980
Road to full Root
Since I am asked many times here is a super quick bullet listed workflow.1. is needed as there is no workaround for this at the moment!!
1. Unlock Bootloader (Get a backup of /ta partition first if possible just search xda for mtk-su )
2. Extract the stock sony boot/kernel.sin to .elf format. (Tools listed in OP)
3. Convert the boot/kernel.elf to .img (Tools listed in OP)
4. Patch the .img with Magisk (Search xda)
5. Flash to the device. (Fastboot, TWRP if you have one or use dd method with tmp root)
Hey mate! Great thread!
I need some help with my Xperia L3..
I backed up the TA partition with dd and I want to restore it now. How I can do it?
Thanks!
Rortiz2 said:
Hey mate! Great thread!
I need some help with my Xperia L3..
I backed up the TA partition with dd and I want to restore it now. How I can do it?
Thanks!
Click to expand...
Click to collapse
Sorry for the mega late reply but I did not get any notification
I guess you probably sorted it already but just incase see this post here https://forum.xda-developers.com/showpost.php?p=69971015&postcount=16 as that pretty much covers it.
Note you must reflash 100% Stock ROM when using the restored TA.
Also check this thread HERE if you want to run none stock.
Note I have not tested any of these myself so please ask any specific questions in the relative threads.
:highfive: :highfive:
You can use this link to find your model:
http://opensource.lge.com/osSch/list?types=NAME&search=G710 <<< Find your model, you must use Linux to compile this code.
Models:
LMG710N - USA model (Carrier unlocked model)
LMG710PM - Pre-release codename Judy
LMG710PS - ?
LMG710AWM - Likely this was the AT&T model that was changed to the V35 ThinQ
LMG710TM - T-Mobile model
LMG710VM - Verizon model
The files are coded with R, P, & X which I am guessing is Release Candidate, Production, and scrapped version.
The readme files are really helpful in explaining how to compile the software.
Under the bootloader section:
This product includes cryptographic software written by "EDITED for Psuedo Privacy". This product includes software written by "EDITED for Psuedo Privacy".
I figured that we could either create a custom bootloader that's NOT encrypted, but still follows the same boot up process. If bootup requires an encryption, then we could set the the process to accept anything, for example: if encryption = 1 or 0 then proceed to bootup.
I hope this helps development on this phone in creating a kernel, custom roms, etc...
But your links are about LG G7, and we are speaking here on Q7
Searching for the 610I at that sure produces a result for the Q 610ta10s that I am on.
source Q7+ Japan http://opensource.lge.com/osSch/list?types=NAME&search=03K
Welcome everyone!
This project has started, becouse we need real solution for the problem. The problem of hard bricked Moto devices. It is like a curse.
When my device bricked I have done solid research, I have gathered many informations and files essential to revive my cellphone but 5 years experience of linux, rooting, compiling kernels and roms weren't enough to make it work.
But nevermind. I am even more determinated and I am asking ALL of You guys here to help me. Together we will come to solution.
Here is what I got, happy reading :
DICTIONARY:
PBL - Primary bootloader of the chip - this is like BIOS for phone so it checks chip for damage and problems and then it tries to load SBL but if SBL is corrupted or checksum doesn't match, PBL invokes Qualcomm HS-USB QDLoader 9008 emergency mode. PBL is hard flashed into SoC and can't be corrupted by firmware.
SBL - Second stage bootloader wich is more advanced than PBL. It initializes phone hardware and ABOOT.
ABOOT - Application bootloader (HBOOT). You probably know this one well. Android botloader.
Full mmcblk0 backup - Backup of whole phone flash storage byto to byte.
blankflash - method of repairing msm phones in 9008 state
programmer.mbn - Special type of software programmer that is being sent to chip in Qualcomm 9008 emergency mode. There it comunicates with pc via firehose protocol. Each phone has set of their own programmers, they are unique to phone and other programmers don't work. These programmers are signed so tampering it results in not working one.
firehose protocol - it is used to tell programmer what operations it must do on chip.
singleimage.bin - this package contains instructions for programmer and set of files it need (for example to replace)
gpt_main0.bin - Partition layout
rawprogram0.xml - instructions for programmer
patch0.xml - I don't know yet
STAR.exe - Application for managing and editing contents of singleimage.bin aka blankflash files
QPST - Flash tool from Qualcomm it basic function is to handle blank-flashing in a better way, also it allows for in-depth debugging of the process
Qualcom Premium Tool - Program made by Mppg Myanmar that is capable of making unlocking bootloader, OEM locks, making backup/restore of chip firmware, handling blank-flashing in VERY specific way (creating instructions for programmer), reading eMMC structure from firmware (can generate gpt layout so very useful!!!), modyfing FW and removing Xiaomi account. It also contains ALL programmers
for more:
https://forum.xda-developers.com/android/general/info-android-device-partitions-basic-t3586565
https://alephsecurity.com/
https://github.com/alephsecurity/firehorse
https://github.com/aravindvnair99/Motorola-Moto-E-XT1022-condor-unbrick
INFO:
1. What causes the brick
I bet 100$ that you hard-bricked your Moto Z Play by installing OTA updates after downgrading firmware. This is only known reason for me at the time of writing this. There is most probable reason why it happens, look:
There are two most common chips on which smartphones are built - Qualcomm and Mediatek. While Mediatek chips are "modification friendly" and simple, Qualcomm chips are somewhat more advanced and have many features that can be enabled or disabled during prorammming in factory. One of them is PBL signature checking. During programming of your phone, proper signatures of SBL are written to it. When someone tries to override default SBL with the new one, it checksums are compared with that stored. If they match, new one is flashed, if not, then update does not happen.
Ok, but what it has to do with brick?!
I explain:
1. You decide to downgrade your firmware
2. During flashing, everything goes "well" (Phone boots), but trully update is partial:
FW in chip is (obviously) more recent that the one you downgrade to, and SBL signature is different (updated), so when it is compared to the signature of SBL from FW you want to flash, it don't match. That don't rise error and flashing continues. Only partition that stays untouched is bootloader, but all other partitions get replaced by those in FW zip. SBL is still compatible with the new partition offsets and partition layout overall so phone functions normally.
3 When OTA is executed, it checks the version of currently installed firware. The most reliabe way to do it is to check checksum of SBL which is pretty logical becouse it's checksum is like "fingerprint" of firmware. Normally, if it would detect the old firmware, OTA would be stopped, but newer SBL tricks it and OTA installs anyway.
4 Results are horrible, becouse OTA does not check GPT table and flashes partitions in bad sectors, corrupting FW.
This causes bootloader to go into Qualcomm HS-USB QDLoader 9008 safe mode.
5 Viola! Hard brick!
2. How to fix it?
That is jolly good question! What we have to do is to reflash full chip firmware. Suprisingly I see some solutions, but those need to be developed:
A) SD-BOOT
It turns out that our fancy chip can probably boot from SD-CARD! The procedure works like this:
- When chip starts, one of the very first things it does is loading the memory, so it can actually work. The trick, is that chip loads it from specific disk, marked with exact name (I don't remember which, but I will do research). Speccially repared SD-CARD can appear with that name, so chip boots from it, not from internal memory. (This trick is proved to work on this model)
How to do it?
- Get full dd of working phone - it must be phone with the SAME chip and very likely the same model
- flash it to SD-CARD of 32GB or more, class 10 speed or higher, directly to card, not partition
- put card in phone, turn it on and wait
- you should see HBOOT
- select fastboot and flash new FW via it
- viola!
!!!THIS IS COMPLICATED PROCEDURE, I WILL MAKE DETAILED THREAD SOON, BUT FOLLOW IT ONLY IF YOU KNOW WHAT ARE YOU DOING!!!
B) FIREHOSE/SAHARA ATTACK
This could be achieved by sending payload via Firehose programmer that would allow to break verification of SBL or somehow allow SBL to be flashed. Now, PBL blocks attempts to update SBL. I have thesis that it is becouse PBL do not allows for SBL downgrade, so it's version must be higher, but we try to flash same version of SBL so it doesn't work. That thesis needs confirmation.
C) CRAFT BLANKFLASH
This would be last resort. It will work for sure, but this method needs knowledge and I don't know if it is doable.
STEP 1: Get white-listed blankflash checksums from OTA (we would need to reverse engineer those)
STEP 2: Break hash
STEP 3: Craft blankflash with needed hash
STEP 4: Flash
NEVER USE BLANKFLASH (ATTENTION!)
DO NOT try any blankflash files. They can make situation a lot worse and even physically (!) dmage your phone.
D) JTAG
Medusa Box etc.
E) Qualcomm Premium Tool
This can even work, but it is untested and there is a slight chance that can worsen state of phone (needs confirming).
The tool is very advanced and I need to gather info about usage, so very probable to be a good solution if we will learn how to use it!
E) METHOD 7
Interesting method from this guy: (7th option, I have contacted him if it is compatibile)
https://github.com/aravindvnair99/Motorola-Moto-E-XT1022-condor-unbrick/blob/master/Unbrick%20methods.md
3. DOWNLOAD
(Links will be aded *soon*)
XDA:DevDB Information
Unbrick Developement for Moto Z Play (addison) Full-Brick, Tool/Utility for the Moto Z Play
Contributors
Bobernator, Artim_96, Camarda
Version Information
Status: Testing
Created 2019-05-03
Last Updated 2019-05-03
Hi, same problem. Did you solve it?
Sony-MTK Devices
Hi and welcome to the Sony-MTK Devices development thread.
This is a meeting place for Sony-MTK dev's to meet and exchange information and idea's while developing for various Sony devices that use the MediaTek SoC.
Since MediaTek devices in general are very much alike there is a lot information regarding flashing, source code, leaks, official source code, etc, etc widely available.
The problem comes when we have to deal with Sony's implementation of their own specifics.
Things begin to diverge quite quickly and things can soon become very confusing.
Hopefully in this thread we can begin to bring order to the chaos and confusion for new and experienced dev's alike.
I will reserve a few threads below for the following.
Flashing Rooting Tool's etc.
MediaTek SoC brief but just for those new to mtk.
Sony specifics.
Sony MediaTek based devices.
Flashing Rooting Tool's etc.
Ok so where do I start
Tools:
Most of these tools following are specific to Sony but not all.
Most are for Linux and or Windows. I work with Linux only nowadays so others may need to help out with the Windows specifics.
If I refer to something you don't understand like .sin for example check the Sony specifics in Posts below.
GUI stands for General User Interface you know point click drag drop enter sort of stuff.
cmd stands for a command line tool run in a terminal or cmd prompt.
Androxyde FlashTool (Sony Specific, GUI, Linux (Needs Mono installed) Windows)
Androxyde FlashTool is a Sony Specific tool to download and flash Sony firmware packages and more. It use Sony's S1 Protocols when flashing Most of the MediaTek devices that Sony produce but the newer L3 L4 models may use the new protocol. Thread here https://forum.xda-developers.com/showthread.php?t=920746 website is here http://www.flashtool.net/index.php Note: the Warning to C4/C5 users in the Downloads section M5 users should also be included. To use that version you need a custom FSC if one exists if not then there is a older version which is safe to use but it does have some limitation but more on this later)
XperiFirm (Sony specific, GUI, Linux (Needs Mono installed) Windows)
XperiFirm is a Standalone version of the same tool built into Androxyde FlashTool. this tools allows you to get the official Sony firmware for your device. It taps into the Sony repository I assume Sony's official Xperia Companion Tool uses. It will download the firmware and unpack it for you.
Main Thread is HERE
UnSIN (Sony specific, GUI, Linux (Needs Mono installed) Windows)
UnSIN is a standalone version of the same tool built into Androxyde FlashTool/XperiFirm it extracts the .elf and ext4 image files from the Sony firmware .sin's
Main Thread HERE
NOTE: munjeni's "Unpack any Sony firmware" see below does the same thing.
MTK-SU (MediaTek Specific, cmd, device binary Linux & Windows)
Thanks to dev @diplomatic All Sony Mediatek devices should now be able to obtain a /ta partition backup before unlocking their bootloader. (Yes I know see Sony specifics below for /ta explanations.)
It works by getting temporary "root" with a easy to use method which will then allow you to grab a /ta backup via the dd cmd
I did some testing for diplomatic and I can confirm this works for Sony MediaTek devices XA, XA1 C4, C5, M5, L1, L2 and L3 and all their variants. diplomatic's Thread is HERE for instructions and details also remember to Hit his Thanks Button or the Thumbs Up Button if your using a phone app.
AIK (Android universal, cmd, device binary also Linux & Windows)
This tool should be familiar to almost all dev's but where it stands out from the crowd is it's support for Sony's .elf format boot and recovery. (Yes I know see Sony specifics below for .elf explanations.) This tool takes the .elf unpacks it and repacks it in the more familiar AOSP .img format (It's not just a renaming exercise) which make life so much easier so big thanks to osm0sis for this.
AIK (meaning Android Image Kitchen by @osm0sis this tool will unpack the .elf's and repack them as AOSP .img's by default :good: I Main Thread HERE
munjeni's Sony Tools collection (Sony specific, cmd, device binary also Linux & Windows)
Sony dev @munjeni has produced a host of standalone open sourced dev tools. :good:
Unpack any Sony firmware does what it says really. It will extract the .img from the .sin's in the firmware packages. (Yes I know see Sony specifics below for .sin explanations.) Main Thread Here
Xflasher This tool is a standalone cmdline tool and can flash devices using the S1 protocol in download mode. I tested this on the L1 with noloader XA and XA1 with loader and it worked fine flashing boot.sin system userdata etc etc but flashing the boot area (preloader lk etc) is not fully tested as yet. The C4 failed as did the M5 so I suspect these older devices are not supported. Main Thread HERE
Sony Backup Tool/Script by bigrammy (Sony specific, cmd, Linux & Windows)
This is a little helper script to backup Sony Mediatek devices and is used in conjunction with MTK-SU prior to unlocking your boot loader.
It will backup your /ta /nvram and some other partitions. It also creates a dd-backup.txt which lists all the partitions on your device in dd backup format.
Sony Backup Script
Other cool things too so be sure to keep checking his threads :good:
MediaTek SoC brief but just for those new to mtk.
WIP Work In Progress
Sony specifics.
WIP
Hi all,
I see that unsigned "raw binary aarch64 executables" can be run using the recently developed tool here:
https://github.com/frederic/exynos-usbdl
My question is - does this open up the possibility to get a mainline u-boot.bin (and using that, mainline linux kernel) running on the Exynos S7? That would be exciting...
Thanks all,
Jack K
no, because it only bypasses FLASH signature checking, but exynos bootrom always checks on boot if it is oem signed bootloader or some other custom bootloader. mainline linux MAYBE could be possible for just one boot, because it will stay in memory of course, but don't think that there will be some super new and super cool technology that will allow to change bootrom, because that won't happen, bootrom is placed directly in cpu memory, only way to change bootrom is to change the cpu
On the contrary all you need is the bootROM as uboot. If you were to want the phone running on a linux environment you could always port a linux build into a gsi or create a multiboot script. Or even more crafier yet you could make an OTA with an alternate fstab?