[EASY]Dump TrustZone/QSEE logs - Verizon Galaxy Note 3 General

Hi guys,
I've got a pretty basic one for you. It's possible to dump the TrustZone and QSEE (Qualcomm Secure Extension Environment) logs. This may benefit the right people. No risk of danger or anything with this. It makes use of the debugfs, not sure if you need to have debug on HIGH (*#9900#, then select DEBUG LEVEL HIGH if it doesn't work.)
TZ Log:
Code:
cat /d/tzdbg/log
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
QSEE Log:
Code:
cat /d/tzdbg/qsee_log
Hopefully someone finds this useful.

---

Man, you always come up with goodies when least expected. Exactly what I was looking for. I was just diggin' through these binaries trying to understand what they do. What about the device /dev/qseecom ? Any idea how it is used?

---

Just wondering here but could these logs help out with anything such as unlocking the bootloader or anything else?

---

AngryManMLS said:
Just wondering here but could these logs help out with anything such as unlocking the bootloader or anything else?
Click to expand...
Click to collapse
Certainly. QSEE is the Qualcomm Secure Extension Environment. This is Qualcomm's TrustZone kernel. This kernel has secure memory where it can store information that is heavily protected. This is where secureboot configuration information is stored, including read/write to QFPROM (QFuses), eFuses (software fuses like Speed Bin for CPU scaling, yes they also have other useful functions), and the warranty 'fuse' which is located onboard the Snapdragon CPU (unlike Exynos where the warranty bit is on the RPMB of the eMMC.) This kernel has access to low level and secure hardware. It is my belief that this kernel operates on the Hexagon DSP by Qualcomm.
I was playing around with my Z3x JTAG box, and in order to do so I had to solder to the back of our mainboard. I decided to do a little analysis of the PBA, and found a third chip labeled 'ARM'. The Hexagon DSP chip is a roughly 600Mhz processor (I believe) with Secure World access. aside from the MDM9215 (CP) and APQ8064T (AP). This DSP chip is not secret, and is actually pretty cool IMO and efficient at what it does.
Can we just hack into this kernel? No, it's VERY difficult, and it was designed to be that way. People like Dan Rosenberg are very good at what they do, as he is a professional. However it is possible there are vulnerabilities or design flaws present, it's just a matter of analyzing the code and logic. This can be complicated and take a significant amount of time.
Anyways... using the following command after boot:
Code:
cat /d/tzdbg/log
You can see (usually):
Code:
Bam Devices pointer struct size : 24 bytes
tzbsp_secure_channel_key_gen status 0
Initializing PIL
QSEE version major=1, minor=2
TYPE = 0x0
FUSE ID: 0x0
IS_WRITE: 0x0
READ: QFPROM row data 0xf03 0x0
READ: Final masked val 0x0
tzbsp_es_is_activated: row_address=[B]0xfc4b81f8[/B].row_data[0]=[B]0x1[/B].row_data[1]=[B]0x4000000.[/B]
tzbsp_es_is_activated: row_address=[B]0xfc4b81f8[/B].row_data[0]=[B]0x1[/B].row_data[1]=[B]0x4000000.[/B]
global_tz_app_id 0x555, 0x0
global_tz_app_id 0x888, 0x0
global_tz_app_id 0x789, 0x0
global_tz_app_id 0xaaa, 0x0
global_tz_app_id 0x777, 0x0
The bold addresses are QFuse addresses. This fuse in particular is what I believe to be the OEM Config fuse chain. This has all of Samsung's configuration for Secure Boot and other odds and ends.

---

ryanbg said:
... I decided to do a little analysis of the PBA, and found a third chip labeled 'ARM'. The Hexagon DSP chip is a roughly 600Mhz processor (I believe) with Secure World access. aside from the MDM9215 (CP) and APQ8064T (AP).
Click to expand...
Click to collapse
What do you mean?
The DSP is not a "chip" is part of the dye of APQ and MDM SoC's, the APQ doesn't ahve a "modem" on dye, but that doesn't mean it doesn't have a DSP.
The 3rd chip you found, must be something else. Post a picture!
Remind what device you have there again?
Also, do you have a "true" /d/ device or is it symlinked to /sys/kernel/debug like it is on the 4.2.2 i9195. (I can't find such a directory, nor the log file, but I'm not done looking either.)

---

E:V:A said:
What do you mean?
The DSP is not a "chip" is part of the dye of APQ and MDM SoC's, the APQ doesn't ahve a "modem" on dye, but that doesn't mean it doesn't have a DSP.
The 3rd chip you found, must be something else. Post a picture!
Remind what device you have there again?
Also, do you have a "true" /d/ device or is it symlinked to /sys/kernel/debug like it is on the 4.2.2 i9195. (I can't find such a directory, nor the log file, but I'm not done looking either.)
Click to expand...
Click to collapse
It appears this third chip is actually the PMIC chip. This is on a Galaxy S4. I thought it was a true debugfs but I guess I'm not sure.

---

Thanks @ryanbg for the explanation on things. I've followed the KNOX discussion over in the dev area and now knowing what you posted it makes things a bit easier for me to understand going forward - I had an idea on things but needed clarifying in regards to how much this stuff effects the boot loader itself. I really hope this leads to unlocking or at least some kind of KEXEC solution since the NC2 leak might very well get us that.

---

Qualcomm Secure Execution Communicator driver
E:V:A said:
What about the device /dev/qseecom ? Any idea how it is used?
Click to expand...
Click to collapse
maybe that is well known, but..
there is driver code at 'classic' kernel souces;
for example: CAF ver.
Code:
config QSEECOM
tristate "Qualcomm Secure Execution Communicator driver"
help
Provides a communication interface between userspace and
Qualcomm Secure Execution Environment (QSEE) using Secure Channel
Manager (SCM) interface.
config QFP_FUSE
tristate "QFPROM Fuse Read/Write support"
help
This option enables device driver to read/write QFPROM
fuses. The ioctls provides the necessary interface
to the fuse block. Currently this is supported only
on FSM targets.
Click to expand...
Click to collapse
appr. files:
Code:
...
-rw-r--r-- qfp_fuse.c 9430 log stats plain
...
-rw-r--r-- qseecom.c 113933 log stats plain
-rw-r--r-- qseecom_kernel.h 1443 log stats plain
-rw-r--r-- qseecom_legacy.h 2556 log stat splain
or googl hammerhead kernel

---

@E:V:A and @ryanbg, look to the attached file. This is the part of QSEE which work with Qfuses.