Hey guys,
Tonight, Elite Recognized Developer Rebellos and myself managed two very major breakthroughs for Samsung Exynos based devices.
1. Stable implementation of the Open Galaxy Bootloader (based on Uboot)
Code:
��BL2
U-Boot 2010.12-00051-g02bdbef-dirty (Dec 23 2012 - 01:53:11) for EXYNOS4_GALAXY
CPU: S5PC220 [Samsung SOC on SMP Platform Base on ARM CortexA9]
APLL = 1000MHz, MPLL = 800MHz
DRAM: 1 GiB
[I2C] CLK_GATE_IP_PERIL: 0xFFFFFFFF, enabling channel 7
[I2C] channel 7 initialised with freq 400000 and timeout 1000000.
[I2C] ePrescaler: 16 nPrescaler: 15.
[I2C->ERR] Timeout Slave Address
pmic_s5m8767_init set reg 0xE to 0x6F with mask 0x0
pmic_s5m8767_init set reg 0x5A to 0x58 with mask 0x0
pmic_s5m8767_init set reg 0x5B to 0xB4 with mask 0x0
pmic_s5m8767_init set reg 0xA to 0xE with mask 0xE
pmic_s5m8767_init set reg 0x11 to 0xE with mask 0x0
pmic_s5m8767_init set LDO2 to enable 0x1
pmic_s5m8767_init set LDO4 to enable 0x1
pmic_s5m8767_init set LDO5 to enable 0x0
pmic_s5m8767_init set LDO6 to enable 0x1
pmic_s5m8767_init set LDO7 to enable 0x1
pmic_s5m8767_init set LDO8 to enable 0x1
pmic_s5m8767_init set LDO9 to V 1800
pmic_s5m8767_init set LDO10 to enable 0x1
pmic_s5m8767_init set LDO11 to V 1950 with enable 0x1
pmic_s5m8767_init set LDO12 to enable 0x1
pmic_s5m8767_init set LDO13 to enable 0x0
pmic_s5m8767_init set LDO14 to V 1950 with enable 0x1
pmic_s5m8767_init set LDO15 to enable 0x1
pmic_s5m8767_init set LDO16 to enable 0x1
pmic_s5m8767_init set LDO18 to enable 0x1
pmic_s5m8767_init set LDO19 to V 1800 with enable 0x1
pmic_s5m8767_init set LDO20 to V 3300
pmic_s5m8767_init set LDO21 to V 3300
pmic_s5m8767_init set LDO22 to V 2800
pmic_s5m8767_init set LDO27 to V 1500
PMIC: S5M8767
====================
S5M8767 PMIC registers
====================
ID = 0x05
ONSRC = 0x01
STATUS1 = 0x11
STATUS2 = 0x11
STATUS3 = 0x07
IRQ1 = 0x09
IRQ2 = 0x38
IRQ3 = 0x00
PWROFFSRC = 0x00
PMIC_RTC_WTSR_SMPL_REG = 0x80
S5M8767_REG_BUCHG = 0x6f
i2c_gpio_new_port virtual channel 0 registered
max77693 charger PMIC rev = PASS2, REG_ID2: 0x4
BL1 version: 20111128
Checking Boot Mode... EMMC4.41
REVISION: 1.1
[ERROR] response timeout error : 00000104 cmd 1
FAIL: waiting for status update.
MMC Device 0: 0 MB
MMC Device 1: 7580 MB
MMC Device 2 not found
FAIL: waiting for status update.
FAIL: waiting for status update.
mmc read failed
*** Warning - using default environment
Hit any key to stop autoboot: 0
GALAXY #
GALAXY #
What's this mean? We can now work INSIDE the Samsung TrustZone on production devices! This means some serious debugging of bootloaders is possible.
2. fastboot on the Galaxy Camera
Code:
[email protected]:~/Desktop/GCAMBoot$ sudo fastboot devices
SMDKEXYNOS-01 fastboot
[email protected]:~/Desktop/GCAMBoot$ sudo fastboot boot ./BOOT.bin
downloading 'boot.img'...
OKAY [ 1.642s]
booting...
OKAY [ 0.217s]
finished. total time: 1.859s
[email protected]:~/Desktop/GCAMBoot$
What does this REALLY mean? It means that not only do we have a way to get away from Samsung closed source bootloaders, but we can now boot TOTALLY from SDCard on the Galaxy Camera and the Galaxy S3.... What's that mean? We can fix brick-bugged Galaxy S3 devices!
I need a Galaxy S3 to work with. Anyone have a brick or a GS3 they're not using? I need it.
I will be performing the following:
1. EMMC Disable hardware mod (can be undone later)
2. UART hookups for debugging and working in fastboot mode.
3. attempting to rework GS3 Ramdisk for SDCard boot.
4. recreating the proper partition structure on a 16 gig.
From the current track record, i'm guessing that just about everyone will need this in a year or so. We hope to have this ready fairly quickly so anyone can just open their device, drop a bead of solder over a resistor, insert an SDCard and boot up again.
The further implications of this are: directly booting ubuntu, Chrome OS, WebOS or just about anything else... This tool will make it easy!
I estimate this will take 3-6 weeks of research. If you can donate a GS3 or do an extended loan, it will help out many people with bricked EMMCs. The device can even be bricked.
Very good news. Great work Adam
Great waiting for somebody to donate his dead s3
Sent from my GT-I9300 using xda app-developers app
Thanks for all your hard work .
jje
brilliant.....
loking foreward to experimental roms to boot from my separate sd card
like cyanogen, ubuntu and so on!!!
Good news just before x-mas
Thanks
Thank god! Adam,
at least there is now hope for 'to be dead' S3s
+1
AWESOME!
Ty for your great work guys!
so in theory we could not only boot any ROM from SD to unbrick, but also boot Linux natively from our SD card instead of chrooting in?
Leave it to Adam and other Elite Developers to find such awesomeness! It's great to know that you can't truly hard brick a phone. And running ANY rom you want from the sdcard? That sounds freaking awesome!
Great news.
Good job.:thumbup:
Verzonden door mijn GT-I9300 met xda premium
Just some questions to get the picture.
1. EMMC Disable hardware mod (can be undone later)
This would be a semi-permanent resistor shortening (same as we would do when following the instructions of the official samsung unbrick guide) or am I wrong?
3. attempting to rework GS3 Ramdisk for SDCard boot.
What ramdisk do you mean? do you want to boot a rom from sd or a custom bootloader from sd?
Love your work guys think u will be going down in The History Of The Galaxy S3 lol
Keep up the goods
Sent from my GT-I9300 using Tapatalk.Siyah Kernel Rules The Galaxy
theq86 said:
Just some questions to get the picture.
1. EMMC Disable hardware mod (can be undone later)
This would be a semi-permanent resistor shortening (same as we would do when following the instructions of the official samsung unbrick guide) or am I wrong?
3. attempting to rework GS3 Ramdisk for SDCard boot.
What ramdisk do you mean? do you want to boot a rom from sd or a custom bootloader from sd?
Click to expand...
Click to collapse
Yes and the ramdisk needs to be reworked for uboot and booting from SDCard.
I'd appreciate it if you guys kept the "thanks" to a minimum.. I need a device to work with. Nothing has been done for GS3 yet and nothing will until we get a device. Extra posts make people think that something's already happened. It hasn't. I need a device.
Thanks, hopefully somebody loan a device
Please make out a sticky too
Sent from my GT-I9100 using xda app-developers app
Hmm.. thinking about it
Sent from my GT-I9300 using Tapatalk 2
thank you very much for sharing the info and for all the hardwork.
Great work!
I suggest crowd funding. Add a donate button, i will give 10 $. 49 sponsors needed left.
Sent from my GT-I9300 using xda app-developers app
jo_keks said:
Great work!
I suggest crowd funding. Add a donate button, i will give 10 $. 49 sponsors needed left.
Click to expand...
Click to collapse
I'll pledge to this as well. Perhaps we dont need 500, because a used s3 can be obtained for less, and if I understood correctly adam can even work with a "sudden death" victim?
jo_keks said:
Great work!
I suggest crowd funding. Add a donate button, i will give 10 $. 49 sponsors needed left.
Sent from my GT-I9300 using xda app-developers app
Click to expand...
Click to collapse
+1 :good:
sodeknetters said:
I'll pledge to this as well. Perhaps we dont need 500, because a used s3 can be obtained for less, and if I understood correctly adam can even work with a "sudden death" victim?
Click to expand...
Click to collapse
He requires a SDS(sudden death syndrome) Galaxy S3. We can even ask a SDS victims to sell his device to adam instead of sending it for a repair. The money can for this can be generated through crowd funding .
i like the idea and hope it will be turned into a tool kit for those situations as the S3 SDS can potentially affect any S3.
Not much but here you go Confirmation number: 9CY83908VJ862193J
Related
Hey geeks,
you might know my hardware hacking thread already:
http://forum.xda-developers.com/showthread.php?t=1199450
Some time ago i started thinking about starting with an open bootloader for Archos Gen8.
So i started from scratch and made use of external boot mode to completely start from external MicroSD and leave the internal memory alone.
Remark: This is a geek project, there's no GUI or something. So don't expect anything useful right now.
At the moment you'll need some hardware hacking, because you'll need a serial console over uart3.
Unfortunately you'll also need a dirty hack to power up the MicroSD permanently.
Don't hesitate to ask for details about it.
So this is for the weird ones out there...
Right now there's work in progress, because stock kernel stucks at some point in the boot process.
Maybe there's some setup missing in the bootcode (it's very basic at the moment) or stock kernel relies heavily on avboot at some point.
I will work on this issue whenever i'll find some time.
Anyway it might be still an interesting project for at least a very few of you, so here's the source code:
- x-loader-archos
- u-boot-2011.09-archos
As pointed out the Archos implementation is very basic at the moment, but the code itself works very well and had been tested on A101IT Gen8.
To further devices, e.g. A70S Gen8, the machine id had to be included in the board file, the rest of the setup in early stage should be very similar.
The code bases:
- x-loader (https://gitorious.org/x-loader/x-loader)
- u-boot (taken from this archive: http://www.technexion.com/images/downloads/ARM_CPU_Modules/TDM-3730/linux-2.6.32-tdm3730.tar.xz)
I'd like to switch to official u-boot release 2011.09 as a base soon.
To start playing with it:
- open your case and start hacking, to get serial console working
- tweak the hardware to power the MicroSD slot permanently
- create a bootable MicroSD for OMAP systems
- place the binaries on your card
- insert the card and use vitalifs kernel module to reboot your device in external bootmode
Please refer to these posts from vitalif (thanks a lot for contributing!!!):
http://forum.xda-developers.com/showpost.php?p=22719203&postcount=105
http://forum.xda-developers.com/showpost.php?p=22765441&postcount=108
You might start digging in the source code and create your own loader:
- use a linux machine with a recent distribution
- setup a cross environment with ARM cross compiler suitable for ARMV7
- extract the sources to directory of your choice
- to compile x-load:
Code:
cd ./x-loader-archos
make archos_config
make
- to compile u-boot-2011.09-archos:
Code:
cd ./u-boot-2011.09-archos
make a101it_config
make
It might be required to tweak the top-level Makefiles to point at your toolchain.
I used my ready to work toolchain (for 32-bit linux only) here:
http://forum.xda-developers.com/showthread.php?t=1328027
Unfortunately i haven't found some time to create a project page at gitorious,
but hopefully i'll manage to do so in the next weeks...
I know this is a very very special project, but anyway if there's some interest, this might lead to something useful in the end.
If the bootcode is working very nice some day, it might also be possible to replace stock loader, but that's fiction yet.
You might ask what for...
I say... it's just for fun!
cheers,
scholbert
Boot console output... so far
Hey,
it had been posted already but her again for completeness...
The console log on UART3 starting custom kernel configured with stock config:
Code:
Texas Instruments X-Loader 1.5.1 (Mar 26 2012 - 20:41:11)
Found 0256 MB
Archos Gen8
Reading boot sector
Loading u-boot.bin from mmc
Done!
U-Boot 2011.09 (Mar 23 2012 - 18:53:39)
OMAP3630/3730-GP ES1.2, CPU-OPP2, L3-165MHz, Max CPU Clock 1 Ghz
Archos 101IT Gen8 + LPDDR/MMC
I2C: ready
DRAM: 256 MiB
MMC: OMAP SD/MMC: 0
Using default environment
In: serial
Out: serial
Err: serial
Die ID #144800029ff800000160a4bb18027009
Hit any key to stop autoboot: 0
reading boot.scr
** Unable to read "boot.scr" from mmc 0:1 **
reading uImage
2987000 bytes read
Booting from mmc ...
## Booting kernel from Legacy Image at 82000000 ...
Image Name: Linux-2.6.29-omap1
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2986936 Bytes = 2.8 MiB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
Uncompressing Linux.............................................................
................................................................................
..................................................... done, booting the kernel.
<6>Initializing cgroup subsys cpu
<5>Linux version 2.6.29-omap1 ([email protected]) (gcc version 4.4.1 (GCC) ) #1
PREEMPT Thu Mar 22 23:59:34 CET 2012
CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387f
CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine: Archos A101IT board
fixup_archos: [console=ttyS2,115200n8 androidboot.console=ttyGS0 init=/linuxrc d
ebug omapdss.debug=0 vram=4915200 omapfb.vram=0:4915200 omapfb.debug=0 mmc_block
.split=0.0001:512M]
Memory policy: ECC disabled, Data cache writeback
<7>On node 0 totalpages: 65536
<7>free_area_init_node: node 0, pgdat c05fd368, node_mem_map c06a5000
<7> Normal zone: 512 pages used for memmap
<7> Normal zone: 0 pages reserved
<7> Normal zone: 65024 pages, LIFO batch:15
<4>L2 CACHE is enabled in bootloader
<6>OMAP3630 ES1.2
<6>DIE ID: 144800029FF800000160A4BB18027009
<6>FEATURE_STATUS: 00000c00
<6>SRAM: Mapped pa 0x40200000 to va 0xfc800000 size: 0x100000
<6>Reserving 4915200 bytes SDRAM for VRAM
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
<5>Kernel command line: console=ttyS2,115200n8 androidboot.console=ttyGS0 init=/
linuxrc debug omapdss.debug=0 vram=4915200 omapfb.vram=0:4915200 omapfb.debug=0
mmc_block.split=0.0001:512M
<3>Unknown boot option `androidboot.console=ttyGS0': ignoring
<3>Unknown boot option `omapdss.debug=0': ignoring
<6>Clocking rate (Crystal/DPLL/ARM core): 26.0/332/600 MHz
BTW, i extracted the function from Archos loader setup up PLL and MPU stuff.
Need some time to extract the stock setup for PLL at early stage.
Maybe this will give some answers.
One of my next plans is, to build some kind of bare bone kernel (console only), which may be used for recovery and debug purpose.
Maybe this gives it a kick and things start up to a login shell
TBC
Have fun!
scholbert
One of my next plans is, to build some kind of bare bone kernel (console only), which may be used for recovery and debug purpose.
Maybe this gives it a kick and things start up to a login shell.
Click to expand...
Click to collapse
Seems like an internal monologue... but i like to point out that i stopped this project for a while.
So don't expect anything like a brick recovery tool or similar.
If others will join in it might be possible that it would led to something,
but as long as no one even starts hacking the hardware this is just for me...
Happy days!
scholbert
scholbert said:
Seems like an internal monologue... but i like to point out that i stopped this project for a while.
So don't expect anything like a brick recovery tool or similar.
If others will join in it might be possible that it would led to something,
but as long as no one even starts hacking the hardware this is just for me...
Happy days!
scholbert
Click to expand...
Click to collapse
Shame you stopped your efforts for now, I always followed your posts with much interest. However I can understand it is frustrating being on your own.
Thanks for what you did this far and for posting your info .
divx118
Sorry to read that, this was a very very interesting reading.
But I don't have the knowledge to make the necessary hardware hack, and above all, my wife would kill me if she saw me opening the tab
Thanks again for all that amazing information scholbert
Hey,
first off all thanks for your interest and your replies
Some words on your comments though...
divx118 said:
Shame you stopped your efforts for now, I always followed your posts with much interest. However I can understand it is frustrating being on your own.
Click to expand...
Click to collapse
I did not want to sound frustrated, because i'm not.
All i do with the device and all that hacking stuff is fun and mostly for educational purpose
Maybe i'll continue working with this stuff, but for now i wanted to point out to not expect too much.
Some guys out there, bricked their devices and were looking for a solution.
That's why i wrote it down.
Basically it should be possible to recover bricks by using external boot procedure, but it's still far from a simple solution.
grim-a101 said:
Sorry to read that, this was a very very interesting reading.
But I don't have the knowledge to make the necessary hardware hack, and above all, my wife would kill me if she saw me opening the tab
Click to expand...
Click to collapse
Yeah that's a good point, the barrier for this kind of hacking is little high.
Unfortunately you'll have to tweak the hardware, to gain access to the serial debugging port and cheat the power management of the MicroSD slot.
Most of you simply want to use the device and do some less harder tweaks at system level.
Anyway, there are some other possibilities as well (e.g. using USB and TI Flash) to access the platform. Maybe i'll do some research here as well.
Thanks again for appreciation!!!
Regards,
scholbert
Can somebody give me an overview of the nook filesystem? There are some files I would like to change but I'm not sure what to change it to.
NMGxda said:
Can somebody give me an overview of the nook filesystem? There are some files I would like to change but I'm not sure what to change it to.
Click to expand...
Click to collapse
Your question is way too general to be answered. The Nook Color has an Android file system, dependent on whether it's stock or the various versions of Android that can be loaded on it. What files do you want to change? What are you trying to accomplish? Maybe then help and advice.
Sorry about that
I think my file://sys/power files may be messed up because it always says "Not Charging" in the quick settings when plugged in. It could also be because I used the wrong cord once. It could also be both. Could you maybe give me the default values in the files (if you have a Nook)? You can use the OpenExplorer app and open the files with a browser.
NMGxda said:
I think my file://sys/power files may be messed up because it always says "Not Charging" in the quick settings when plugged in. It could also be because I used the wrong cord once. It could also be both. Could you maybe give me the default values in the files (if you have a Nook)? You can use the OpenExplorer app and open the files with a browser.
Click to expand...
Click to collapse
What ROM are you using? Stock, rooted, CM7, CM9? I'll upload the file once I know.
OK
It's running stock v1.4.3
I had trouble copying my files values last post so I backspaced them all. I'm going to try again.
Filename/data
file:///sys/power/sr_vdd2_autocomp
1
file:///sys/power/sr_vdd1_autocomp
1
file:///sys/power/sr_steps
37500
file:///sys/power/sr_steps_1g
62500
file:///sys/power/sr_vnom_steps
50000
file:///sys/power/sr_adjust_vsel
oppid: [nominal v] [dynamic Vnom] [calib v] [calib step v] mpu 1: 0x20 0x1b 0x14 0x17 mpu 2: 0x2d 0x26 0x1f 0x22 mpu 3: 0x38 0x2f 0x28 0x2b l3 1: 0x1e 0x18 0x18 0x18 l3 2: 0x2d 0x20 0x20 0x20
file:///sys/power/vdd2_lock
0
file:///sys/power/vdd1_lock
0
file:///sys/power/vdd2_opp
2
file:///sys/power/vdd1_opp
2
file:///sys/power/dsp_freq
520000000
file:///sys/power/tick
I get this error
Web page not available
The Web page at file:///sys/power/tick could not be loaded as: Invalid argument
file:///sys/power/fb_state
awake
file:///sys/power/wait_for_fb_wake
awake
file:///sys/power/wait_for_fb_sleep
It would not load.
file:///sys/power/wake_unlock
It would not load.
file:///sys/power/wake_lock
It would not load.
file:///sys/power/pm_test
It would not load.
file:///sys/power/state
It would not load.
Mine always says "not charging" when plugged into my computer.
turdferguson92 said:
Mine always says "not charging" when plugged into my computer.
Click to expand...
Click to collapse
It happens when I plug it into the wall.
NMGxda said:
It's running stock v1.4.3
I had trouble copying my files values last post so I backspaced them all. I'm going to try again.
--SNIP--
Click to expand...
Click to collapse
Based on the number of files, the fact that it's not rooted, and other things, I think your best option is to go the 8 boot route and reinstall the software.
I know that there are many guides about unlocking bootloader and things have been posted a million times.
From what i've learned from various sources all over the web there's still a lot of confusion,
if and how a device could be unlocked and what is really happening under the hood.
In fact i didn't want to create yet another unlocking bootloader thread, but hopefully a collection of facts,
already known about the process and if it's safe or could be done this way or the other.
Another thing i'd like to put some light on, are some details about the boot process in general.
Please refer to this older thread as well:
http://forum.xda-developers.com/showthread.php?t=1429038
Noob's posting will never end, unless we lift some secrets and make more clear how the processes are basically working.
This should as well cover some basics on how the bootloader/kernel are protected by the manufacturers.
Would be better to use the term security locked/unlocked bootloader anyway.
See this nice page (also referenced in the thread above), which describes the whole boot process on Qualcomm CPU's:
http://www.anyclub.org/2012/02/android-board-bring-up.html
You'll find a link to the original document in the 2 post.
Please prepare for some boring technical details, but as well for some essential guidelines,
how to proceed with your device. Anyway, consider this as a starter...
Enough talking, let's define some headlines or topics to be discussed.
Bootmodes and Protocols
Just to sum up three known modes residing in different stages of bootcode:
- QDL
(PBL loader, lowest level, entered by powering up without battery and testpoint pulled to GND)
- QHUSB_LOAD
(a.k.a. SEMC USB Flash, a.k.a green LED mode, entered by powering up with back button pressed)
- FASTBOOT
(a.k.a blue LED mode, entered by powering up with menu button pressed)
unlocking security vs. SIM-lock
Description:
Locked/unlocked security of the bootloader and SIM-lock are different tracks,
though there's an important dependency between them.
Your device is SIM-locked if service menu gives "bootloader unlockable: no"
or simply refuses SIM-cards from another carrier.
What we know:
- fastboot is disabled on SIM-locked phones
- without removing the SIM-lock there's no way to unlock these phones for free
- normally you may purchase SIM unlock code from your provider
- removing the SIM-lock seems to give access to the fastboot option (confirmed by gen_scheisskopf, thanks!!)
- some devices seem to have restrictions here, result: no fastboot even after removing SIM-lock (this was pointed out once in another thread)
What we need to know:
Please confirm, if bootloader unlock is working after SIM-lock is removed!
In other words will you get fastboot feature after removing SIM-lock?
See the feedback from gen_scheisskopf:
http://forum.xda-developers.com/showpost.php?p=36783582&postcount=8
Result:
As long as you're able to remove the SIM-lock and your phone is old security you would be able to unlock bootloader as well!
old security vs. new security
Description:
Old/new security is independent of the EROM version (e.g. 1241-3656 R9B031) but relates to certain manufacturing dates,
or better the CPU types.
I got trustworthy reports about R9B031 getting unlocked with s1tool.
This date code may vary between the device models, but it seems to be proven,
that devices manufactured in Q2 2012 and later (~12W11..12W16) are new security.
I found out as well, that the manufacturing date of the device and the mainboard may be different.
This might explain why there are some diverging reports for devices in this period.
From what i got so far, the chain of trust includes the secondary bootloader (SBL) on all devices.
In other words SBL is signed code in any case.
At least the fuse setup for this feature is common on most of the Xperia 2011 series.
On a new security device patching or replacing the SBL (s1boot) will fail because OTP ROM could not be cheated.
If you got the "qcreceivepacket" error, your device is new security or at least not supported by s1tool (e.g. MSM8255T models seem not to work).
Only known method to unlock new security is Sony official method (grey market may work as well...).
What we know:
- testpoint method does not work on new security
- it should be safe to try the testpoint method because it won't break anything (if it is done correctly)
- right now there's only one way to check for new security (try and error)
- breaking new security would take ages or is impossible
What we need to know:
Perhaps someone needs to confirm that official Sony method works without flaws on new security.
Result:
Testpoint method should not result in a bricked device.
Official method should do it in these cases.
SEMC patch (testpoint method) vs. Sony official (oem key method)
Description (need some feedback though):
Sony official method to unlock security in the bootloader is done by flashing a generated key to a certain region of NAND.
The keys are device specific and the IMEI is part of the key generation (maybe serial number as well).
The fastboot command oem with the valid key certifies the unlock process and device specific key gets written in the TA section.
Unpatched SBL (s1boot) will always scan for a valid key in this section of NAND.
If there's a valid key, routine will report success and security checks of kernel code will be overriden.
The testpoint method seemse to make use of a bug inside the chips primary bootloader (OTP PBL).
It had been found out that this bug existed in the early Xperia 2011 series and could be used to rewrite parts of NAND flash.
This opened the door to patch parts of the NAND bootcode (s1boot) or even replace the bootloader code.
As a result, the bootloader leaves further security checks aside and continues booting even with an unsigned kernel.
So how could we apply a patch to the bootloader?
By setting the testpoint to GND (force WE# of NAND to GND) external NAND is blocked and the phone gets started on the bare metal.
Only PBL is running at that point.
Though the procedure is not 100% understood, it is for sure that a tiny loader is transfered to the SoC's IRAM and gets executed.
This loader then allows to overwrite first blocks of external NAND memory and replace or at least patch the bootloader.
What we know:
Sony way:
- Sony official method works well with fastboot enabled devices
- DRM get's lost with Sony official method and could not be reverted (it's gone... and yes: no way back!!!)
- If using Sony official method, bootloaders could be re-locked by deleting the key
S1tool way:
- testpoint method does not work on new security (and will never work!)
- By pressing the restore button in S1tool everything is virgin again
- OS is not aware of the patched bootloader
- FOTA will cause bricks
What we need to know:
Basically we need so more details about bootloaders on Xperia 2011 from the cracks here...
Result:
Better understanding of "black box" procedures.
Debugging features at boot level
Description:
Parts of the boot code could still be dumped from memory with Android up and running.
We could dump the specific memory areas by reading the content with tools, such as viewmem.
The areas of interest are accessible in RAM area at:
Code:
0x00000000 - ~0x000023a0
0x00090300 - ~0x000ab190
By disassembling these dumped areas or simply extracting the strings of that region you may get a clue of the bootloaders secrets.
For the geeks and kernel developers its even more interesting to follow the startup procedure of the bootloader and early kernel inits,
with a console hooked up on a serial interface.
In fact we got this debug UART on most of the Xperia 2011.
This interface is present as dev/ttyMSM2 in the Android base system as well and is attached to UART3 of the MSM8255 SoC.
See this post for details:
http://forum.xda-developers.com/showpost.php?p=37660319&postcount=76
The debug UART was at least identified on the MK16i mainboard.
If you need more details, please ask!
We got the testpoints confirmed to be working on lt18i as well.
See here for the location:
http://forum.xda-developers.com/showpost.php?p=37701777&postcount=82
... and the logs:
http://forum.xda-developers.com/showpost.php?p=37983019&postcount=109
Thanks a lot for contribution!
See this beautiful hack for the X8/10 as well:
http://forum.xda-developers.com/showthread.php?t=2064108
What we know:
- parts of NAND could only be accessed with some "evil" tricks (e.g. kexec method)
- there are extensive debugging features available in our bootcode
What we need to know:
It would be nice to find a way to activate a cmdline interface at bootlevel.
Result:
Get some insights of the implemented functions in bootcode.
O.k. i'll stop writing for now.
If this thread will draw some attention, i'll continue
You're always welcome to correct me or leave a comment here.
If you like more technical reading tell me as well.
Opinions and discussion welcome!!!
P.S:
If anyone could point me to some code to write a NAND mtd mapper for 2.6.32-9 stock kernel, you're welcome!
Background: I'd like to get mtdblock4 & 5 access on rooted but security locked device.
CREDITS (no particular order):
Dilesh Perera (for s1tool logs, which helped a lot to draw some conclusions)
gen_scheisskopf (for very useful discussion all over this thread)
hillbeast (for confirmation of UART3 testpoints on LT18i and logs)
...all others who helped to get a better understanding of the fuse registers!
Hugh thanks!!!
TBC
Cheers,
scholbert
Hi,
in the meantime i was able to identify some of the OTP registers used on MSM8255(T), a.k.a. fuse registers.
There's another interesting factory register which identifies the type of CPU.
Though it seems that of "old" and "new" security chip could not directly identified using these registers, it is a nice journey to the internals.
We need a tool to dump these values from userland.
Check out viewmem:
http://blog.maurus.be/index.php/2011/01/samsung-i9000-irom-dump/
Grab the viewmem tool from http://blog.maurus.be/wp-content/uploads/viewmem
Copy to /data/local on your device and execute the tool as root.
HW_REVISION_NUMBER
I started some investigation again and made some dumps using this tool.
./viewmem 0xabc00270 0x4 | hexdump -C
As an example given my device got this ID:
HW_REVISION_NUMBER 0xabc00270 = 0x205720e1
This equals to the JTAG Core ID of the Qualcomm chip.
The other one used for JTAG is the TAP ID = 0x27B360E1
I found these Core ID values of derivates in the web:
CPU: Qualcomm MSM8255
Core ID: 0x205700E1
and
Core ID: 0x205720E1
There's this one as well:
CPU: Qualcomm MSM8255T
Core ID: 0x2057A0E1
If someone likes to contribute, please run the viewmem command given above and post it here.
This way we might get an idea which chip revisions are floating around.
MSM_TCSR_CONF_FUSE
I stumbled over the MSM_TCSR register set by looking into bootloaders and disassembled parts of s1_boot as well.
These gave the same offset in some code snippets.
So here we go...
Code:
MSM_TCSR_PHYS 0xab600000
TCSR_CONF_FUSE_0 0xab60005c // TCSR_CONF_FUSE_0 register (base security setup)
TCSR_CONF_FUSE_1 0xab600060 // TCSR_CONF_FUSE_1 register (enhanced debug)
TCSR_CONF_FUSE_2 0xab600064 // TCSR_CONF_FUSE_2 register (feature setup)
TCSR_CONF_FUSE_3 0xab600068 // TCSR_CONF_FUSE_3 register (unique serial#)
TCSR_CONF_FUSE_4 0xab60006c // TCSR_CONF_FUSE_4 register (L1&L2 clocking)
TCSR_CONF_FUSE_5 0xab600070 // TCSR_CONF_FUSE_5 register (not used)
These are the values i dumped from my device:
Code:
0xab60005c = 0x00716d4b
0xab600060 = 0xc8041447
0xab600064 = 0x28040815
0xab600068 = 0x695888c0 (unique serial number of CPU)
0xab60006c = 0x200001b0
0xab600070 = 0x00000000
MSM8255 based:
Xperia pro (MK16)
FUSE(0-5): 00716d4b c8041447 28040815 695888c0 200001b0 00000000
Which looks very similar to these (found on the web over various forums):
MSM8255 based:
Xperia arc (LT15)
FUSE(0-5): 00716d4b c8041447 28040815 fe53ed80 200001b0 00000000
MSM8255 based (according to GSM forum this is a new security device):
Sony Walkman (WT19i)
FUSE(0-5): 00714b6d c8041447 28040815 14b248a0 200001b0 00000000
MSM8255 based (security unknown):
Xperia neo V (MT11)
FUSE(0-5): 00714b6d c8041447 28040815 13789bc0 200001b0 00000000
MSM8255T based (security unknown):
Xperia arc S (LT18)
FUSE(0-5): 00714b6d e8041447 28040815 e99f59a0 200001b0 00000000
MSM8255T based (new security):
Xperia arc S (LT18)
FUSE(0-5): 00714b6d c8041447 28040815 c25cf0a0 200001b0 00000000
MSM8655 based (security unknown):
Xperia acro (IS11S)
FUSE(0-5): 00714b6d 08041447 28000816 5244e280 200001b0 00000000
We need to confirm if this is true...
Copy viewmem to /data/local on your device and execute the tool as root.
Read out the value of TCSR_CONF_FUSE_0:
./viewmem 0xab60005c 0x4 | hexdump -C
result: 4b 6d 71 00
which is LSB first so please rearrange to get MSB first...
result: 00 71 6d 4b
This is one of the things that still need some clarification:
value = 0x00716d4b old and newsecurity
value = 0x00714b6d definitely new security
This is not proven and maybe it's not the correct register to look at.
Anyway this will be mostly guessing because i'm missing documents.
It's still unknown at which position the trusted boot bit is located and if it play a role for "old" vs "new" security setup.
I will need some more dumps of these registers. So i really would appreciate any help here...
At least dumping that register of:
one device successfully unlocked with s1tool
and
one from a device giving that packet error.
EDIT:
There's no difference here... as far as we got it right now.
How to participate?
First i need information about your device:
- model
- manufacturing date form the sticker under the battery
Second you need root, busyboy installed (with hexdump feature) viewmem tool (see 2nd post) and Android terminal or working adb.
- grab viewmem from the link in 2nd post
- put the viewmem binary on your device in /data/local
- type:
cd /data/local
chmod 0755 ./viewmem
- post the output of your Hardware ID, type:
./viewmem 0xabc00270 0x4 | hexdump -C
- post the output of your TCSR_CONF_FUSE_0..5
./viewmem 0xab60005c 0x14 | hexdump -C
Additionally you might give some details if you already tried to unlock with s1tool and if you got the paket error.
Thanks for all the fish :laugh: !!
MARM_ANY_MODE_DEBUG_DISABLE
Apart from the location of the trusted boot bit this is another very interesting fuse bit.
More to come on this topic soon!
Any help would be appreciated to shed some light on this!
Please join in :victory:
To get a better idea of all this stuff you might have a brief look into the application note attached to this post.
To the admins:
I know that some confidential data could be found all over in this forum, but please tell me if you see conflicts with the forum rules.
Geek stuff link collection:
If you like engineer stuff, check out this comprehensive thread:
http://forum.xda-developers.com/showthread.php?t=1856327
This as well:
http://www.anyclub.org/2012/05/qpst-emergency-download-support.html
EDIT:
This document will give you a good idea what happens on bootup and how parts interact with each other:
http://dl.dropbox.com/u/69550833/Android_Board_Bringup - 80-VM984-1-B.pdf
Hugh thanks to Antagonist42 for this beautiful document collection!!
I may add some referals to the parts used on the Xperia 2011 series...
I will clean up here from time to time and write down conclusions in the first post.
TBC
Regards,
scholbert
Nice post, would put a few more spaces between sentences to make for easier reading though.
Sent from myushi
i dont understank
Thanks for this. It would be good if you could add info on how device owners can determine whether they have a device with "old security" or "new security".
Kris-lam said:
i dont understank
Click to expand...
Click to collapse
What?
Whole world?
Life?
... or the reason why i wrote this thread?
pelago said:
Thanks for this. It would be good if you could add info on how device owners can determine whether they have a device with "old security" or "new security".
Click to expand...
Click to collapse
That would be on of the goals... see my comment in the first post again:
We need the register offset for the security efuse bank on MSM7x30 (MSM8255 as well) devices!
Click to expand...
Click to collapse
Once we got the offset, we may try to dump this region and look for different bits on same models.
If my conclusions are correct, old & new security hardware differ by a single efuse bit and as a result using different signatures and stuff inside NAND.
EDIT:
As an example, here's a driver implementation for LG device using APQ8064:
https://android.googlesource.com/ke...f6e/arch/arm/mach-msm/lge/lge_qfprom_access.c
These are the values on that platform:
Code:
...
#define QFPROM_HW_KEY_STATUS 0x702050
#define QFPROM_SECURE_BOOT_ENABLE 0x700310
#define QFPROM_OEM_CONFIG 0x700230
#define QFPROM_DEBUG_ENABLE 0x700220
#define QFPROM_SECONDARY_HW_KEY 0x7002A0
#define QFPROM_READ_PERMISSION 0x7000A8
#define QFPROM_WRITE_PERMISSION 0x7000B0
#define QFPROM_OVERRIDE_REG 0x7060C0
#define QFPROM_CHECK_HW_KEY 0x123456
...
Little further in that code...
Code:
...
/* addr LSB MSB */
//{ QFPROM_SECURE_BOOT_ENABLE, 0x00000020, 0x00000000}, /* SECURE ENABLE */
//{ QFPROM_OEM_CONFIG, 0x00000031, 0x00000000}, /* OEM ID */
//{ QFPROM_DEBUG_ENABLE, 0xC1000000, 0x0000006F}, /* JTAG DISABLE */
//{ QFPROM_CHECK_HW_KEY, 0x0, 0x0},
//{ QFPROM_READ_PERMISSION, 0x0C000000, 0x00000000}, /* READ PERMISSION */
//{ QFPROM_WRITE_PERMISSION, 0x54100000, 0x00000000}, /* WRITE PERMISSION */
...
Regards,
scholbert
Hi again,
though this thread is drawing less attention, i'd like to inform you about my process.
In the meantime i reviewed some low level code for the MSM7x30 (e.g. AMSS bootcode, moboot bootloader repository) to get a hint how to identify security level on the Xperia 2011 platforms.
As far as i got it the MSM7x30 is the base for the MSM8255 devices as well and i assume that most register offsets and peripheral I/O maps are equal.
First i found an interesting offset definition in the moboot bootloader:
Code:
#define HW_REVISION_NUMBER 0xABC00270
I compiled a little tool for my Xperia, which could be used to read back the content from memory mapped registers (a.k.a. memdump).
By addressing 0xabc00270 some mechanism got triggered and my device rebooted immediately.
My guess is that this is offset belongs to the security area and accessing this area is simply prevented by causing a reboot.
No output here at Android userland...
Next i had a look into the AMSS sources for the Hisense TS7008 development platform.
This seems to be reference code for the modem bootloader (baseband processor) which is a previous step before we boot the oem bootloader ( application processor) in our phones.
Anyway, the interesting part is, that i found another offset address, which is included in the moboot sources as well:
Code:
#define MSM_CRYPTO_BASE 0xA8400000
There are many references to this address and the related registers inside the routines for the crypto stuff (e.g. validate hash values).
I'm gonna try to read some content in this area this afternoon.
EDIT:
O.K. just tried to access these areas... seems like a no go from userland.
My phone freezes, after a while something like a watchdog timeout comes in and resets the device.
This is different to accessing the HW_REVISION_NUMBER, which caused an immediate reset.
Anyway, i guess i give up on this issue...
No discusssion, less interest, no comments from the cracks... the_laser is far away as well...
Cheers,
scholbert
scholbert said:
What we need to know:
Please confirm, if bootloader unlock is working after SIM-lock is removed!
In other words will you get fastboot feature after removing SIM-lock?
Click to expand...
Click to collapse
Yes, bootloader unlock is working after removing SIM-lock.
My ArcS was SIM-locked and I had to remove the lock in order to use the phone. Unlock was done using a code generator. I didn't touch the bootloader in case phone is somehow damaged (bought it as "unused second-hand")
Later I unlocked the bootloader using Wotan server (testpoint method)- no problems during the process, phone works fine.
One question regarding s1boot comes to my mind- how it manages partitioning (and would it be possible co create custom partition layout)?
Flashing official ICS using flashtool changed default (Gingerbread) partition sizes
Hey gen_scheisskopf,
it's a pleasure to meet you again over here :highfive:
How are things rollin' ?
gen_scheisskopf said:
Yes, bootloader unlock is working after removing SIM-lock.
Click to expand...
Click to collapse
Thanks for the feedback.
Just to make it clearer, after applying removing the SIM-lock, the fastboot feature got available... is this right?
gen_scheisskopf said:
My ArcS was SIM-locked and I had to remove the lock in order to use the phone. Unlock was done using a code generator. I didn't touch the bootloader in case phone is somehow damaged (bought it as "unused second-hand")
Later I unlocked the bootloader using Wotan server (testpoint method)- no problems during the process, phone works fine.
Click to expand...
Click to collapse
Mmmh, do you know what's behind this Wotan server method?
Is the bootloader patched as well (real bypass like s1tool) or is there a key generated and flashed to the phone (like official method)?
Just for the statistics... could you please tell me the date code of your phone?
gen_scheisskopf said:
One question regarding s1boot comes to my mind- how it manages partitioning (and would it be possible co create custom partition layout)?
Flashing official ICS using flashtool changed default (Gingerbread) partition sizes
Click to expand...
Click to collapse
This is very interesting indeed and i guess it's possible... someone should spend some time on investigating.
Will require to tweak TA sections or something. BTW i'm not sure if the TA parts are covered by certificates or something.
Anyway it would be required to get a good understanding of this process, otherwise this would cause bricks
Best regards,
scholbert
scholbert said:
Hey gen_scheisskopf,
it's a pleasure to meet you again over here :highfive:
How are things rollin' ?
Click to expand...
Click to collapse
Thanks, everything is OK. Still messing around with my devices (tweaking Toshiba ac100 Froyo now, got usb gamepad+GamepadIME working without any need for chmod-ing )
scholbert said:
Thanks for the feedback.
Just to make it clearer, after applying removing the SIM-lock, the fastboot feature got available... is this right?
Click to expand...
Click to collapse
Honestly I didn't check fastboot availability before removing SIM-lock. For sure it worked after removing the lock
scholbert said:
Mmmh, do you know what's behind this Wotan server method?
Is the bootloader patched as well (real bypass like s1tool) or is there a key generated and flashed to the phone (like official method)?
Click to expand...
Click to collapse
I'm not sure but it's possible that it flashed a patched bootloader- some files were downloaded in order to make the unlock but I didn't investigate what's inside. Client software was "unpack when executed then clean up" exe.
scholbert said:
Just for the statistics... could you please tell me the date code of your phone?
Click to expand...
Click to collapse
11W51 (December 2011?)
scholbert said:
This is very interesting indeed and i guess it's possible... someone should spend some time on investigating.
Will require to tweak TA sections or something. BTW i'm not sure if the TA parts are covered by certificates or something.
Click to expand...
Click to collapse
For sure we can investigate tft files themselves (GB vs ICS). Maybe for repartitioning it would be enough to prepare and flash custom .sin images? Official update seems to work this way, it was reported to work also for Arc using ArcS files
EDIT:
Correction- loader.sin flashing is also required for partition layout modification- original topic
However loader.sin provided in the mod is the same file as the one found in ArcS's baseband 70 and 72
gen_scheisskopf said:
Thanks, everything is OK. Still messing around with my devices (tweaking Toshiba ac100 Froyo now, got usb gamepad+GamepadIME working without any need for chmod-ing )
Click to expand...
Click to collapse
Cool!!
Once thought to buy one, there are many cool hacks floating around.
... off-topic though
gen_scheisskopf said:
Honestly I didn't check fastboot availability before removing SIM-lock. For sure it worked after removing the lock
Click to expand...
Click to collapse
Again thanks for this feedback, will add it to the first post soon...
gen_scheisskopf said:
I'm not sure but it's possible that it flashed a patched bootloader- some files were downloaded in order to make the unlock but I didn't investigate what's inside. Client software was "unpack when executed then clean up" exe.
Click to expand...
Click to collapse
O.k. it's not that important... i'd really like to know a little more about this low level stuff of the unlocking procedure on Xperia 2011, that's why i asked.
gen_scheisskopf said:
11W51 (December 2011?)
Click to expand...
Click to collapse
So s1tool would have worked as well...
gen_scheisskopf said:
For sure we can investigate tft files themselves (GB vs ICS). Maybe for repartitioning it would be enough to prepare and flash custom .sin images? Official update seems to work this way, it was reported to work also for Arc using ArcS files
EDIT:
Correction- loader.sin flashing is also required for partition layout modification- original topic
However loader.sin provided in the mod is the same file as the one found in ArcS's baseband 70 and 72
Click to expand...
Click to collapse
Great, thanks a lot for the link... i'll have a look what's up with it.
Regards,
scholbert
fuse register dump
Hey geeks,
still not giving up... i have a clue now
Just to remember...
I am looking for a way to identify "old" and "new" security chipsets on the Xperia 2011 series.
Few days ago i posted that i could not read the some parts of the internal
register space.
Seemed to be an issue with the tool i used (perhaps wrong flags) which caused system resets.
EDIT:
Updated second post http://forum.xda-developers.com/showpost.php?p=36264032&postcount=2
I'd really find some indication for security level...
If you need some explanation, please ask...
Cheers,
scholbert
My result: 0x00716d4b
Arc S 11w51, unlocked using Wotan server (tespoint method, most likely s1tool-like)
I'll check other registers tomorrow
scholbert said:
Please i need some help here...
At least dumping that register of:
one device successfully unlocked with s1tool
and
one from a device giving that packet error.
Would be very helpful to shed some light on this!
Please join in :victory:
If you need some explanation, please ask...
Cheers,
scholbert
Click to expand...
Click to collapse
Sadly, I have an Arc S 12W16 (edit: Sorry, I was mistaken: it was 12W14 and I'm unlocked via testpoint today), so S1 doesn't work AFAIK (and I read that people that can unlock with SETool doesn't touch any 12W16, so I didn't checked the unlock possibilities/prices). Anyway, I dunno if I did it right but, here's a screen: http://s1.postimage.org/wujbqrs5r/2013_01_25_14_50_41.png - looks like the result is 4b 6d 71 00
Amazing work, btw. I always asked to myself if there was a way to check the type of security (old X new).
Hi,
just to make it clear again... right now i'm still trying to sort things out, that's why i need little help :fingers-crossed:
gen_scheisskopf said:
My result: 0x00716d4b
Arc S 11w51, unlocked using Wotan server (tespoint method, most likely s1tool-like)
I'll check other registers tomorrow
Click to expand...
Click to collapse
Thanks!
So i guess we could definitely mark this as old security fuse setting.
The other values should be similar to the ones i already listed (apart form your unique serial of course).
panda0 said:
Sadly, I have an Arc S 12W16, so S1 doesn't work AFAIK (and I read that people that can unlock with SETool doesn't touch any 12W16, so I didn't checked the unlock possibilities/prices). Anyway, I dunno if I did it right but, here's a screen: http://s1.postimage.org/wujbqrs5r/2013_01_25_14_50_41.png - looks like the result is 4b 6d 71 00
Amazing work, btw. I always asked to myself if there was a way to check the type of security (old X new).
Click to expand...
Click to collapse
Thanks as well... looks O.K. for me. So this is the same value.
Did you try the testpoint method already?
If my assumption is correct, then you might be lucky and got old security as well. BTW, i don't want to be responsible for bricked devices
At least this was my intention to get a real indicator for old security and give a clear statement:
Yes, it's safe to try the testpoint method.
So maybe you just be a little patient...
Some words on the production date:
I found out that the sticker on the back gives the production date of your phone.
There's another one on the processor under the shield on the mainboard.
This one is more related to the series of processors used for your mainboard.
My device is marked as 12W11 (sticker under the battery), while the sticker on the processor states 11W44.
See the pic attached.
In other words, they produced an amount of mainboards back in 2011, but the phone itself got assembled in 2012.
Thanks a lot for helping out, i really appreciate this!
Regards,
scholbert
hi i have a arc s 12w28 i i tryed to execute the viewmem but got nothing
Code:
[email protected]:/data/local # ./viewmem 0xab60005c 0x4 | hexdump -C
sh: hexdump: not found
[INFO] Reading 4 bytes at 0xab60005c...
am i doing something wrong ??
scholbert said:
Hi,
just to make it clear again... right now i'm still trying to sort things out, that's why i need little help :fingers-crossed:
Click to expand...
Click to collapse
:fingers-crossed:
scholbert said:
Thanks as well... looks O.K. for me. So this is the same value.
Did you try the testpoint method already?
If my assumption is correct, then you might be lucky and got old security as well. BTW, i don't want to be responsible for bricked devices
Click to expand...
Click to collapse
Not yet. But if everything works as we're expecting, indeed, I might be a lucky one. I'll see this question ASAP to give some feedback.
Re: [REF]Booting/Unlocking Xperia 2011 series: What's under the hood?
danielgek said:
hi i have a arc s 12w28 i i tryed to execute the viewmem but got nothing
Code:
[email protected]:/data/local # ./viewmem 0xab60005c 0x4 | hexdump -C
sh: hexdump: not found
[INFO] Reading 4 bytes at 0xab60005c...
am i doing something wrong ??
Click to expand...
Click to collapse
Partly... the tool hexdump is used to get a formatted output for console.
You'll need at least a version of busybox with the hexdump feature installed.
Maybe your missing some symbolic links.
Try again with this command:
./viewmem 0xab60005c 0x4 | busybox hexdump -C
If the error persists, your version of busybox is missing that feature.
Would be very interesting to get your output though...
Good luck,
scholbert
scholbert said:
Partly... the tool hexdump is used to get a formatted output for console.
You'll need at least a version of busybox with the hexdump feature installed.
Maybe your missing some symbolic links.
Try again with this command:
./viewmem 0xab60005c 0x4 | busybox hexdump -C
If the error persists, your version of busybox is missing that feature.
Would be very interesting to get your output though...
Good luck,
scholbert
Click to expand...
Click to collapse
Code:
[email protected]:/data/local # ./viewmem 0xab60005c 0x4 | busybox hexdump -C
[INFO] Reading 4 bytes at 0xab60005c...
00000000 4b 6d 71 00 |Kmq.|
00000004
its an arc s 12w18 loked bootloader and sim loked
Re: [REF]Booting/Unlocking Xperia 2011 series: What's under the hood?
danielgek said:
Code:
[email protected]:/data/local # ./viewmem 0xab60005c 0x4 | busybox hexdump -C
[INFO] Reading 4 bytes at 0xab60005c...
00000000 4b 6d 71 00 |Kmq.|
00000004
its an arc s 12w18 loked bootloader and sim loked
Click to expand...
Click to collapse
Mmmh, still the same value... if we trust the statements about date code i would say that this should be new security...
but as i tried to point out already, this could not be taken for granted.
Anyway, locked or unlocked doesn't matter, because i'm looking for security bit in fuse registers.
Did you ever try testpoint method on your device?
Guess we need someone, who already tried the s1tool procedure and got the paket error with his device.
If this phone would give different value on FUSE0 register, it would prove that i'm on the right way.
Thanks for contributing!
Regards,
scholbert
Duplicated from top-level "general" questions, coz I'm desperate:
NO EMAIL on a "new" (pre-owned) Samsung Galaxy Note 3, rooted (? don't know what method) and running 4.4.2. Root is confirmed via supersu, File Manager (rhmsoft) recognizes root permission for an interactive session. I'm a Moto man, fairly clueless on Samsungs thus far.
This problem starts right at FDR, can't get logged into existing gmail. The default email app will accept a hotmail account config, but then never gets the mail.
Same problem on data and wifi. Internet is there, etc, but email doesn't seem to work at all.
Kies 3.0 (on Win7) recognizes the phone model, etc.
Bootloader:
ODIN MODE
PRODUCT NAME: SM-N900V
CURRENT BINARY: Samsung Official
SYSTEM STATUS: Custom
KNOX KERNEL LOCK: 0x0
KNOX WARRANTY VOID: 0x0
QUALCOMM SECURE BOOT: ENABLE (CSB)
RP SWREV: S1. T1, R1, A3, P1
WRITE PROTECTION: Enable
UDC START
DOWNLOADING...
RECOVERY:
Recovery booting...
Android system recovery <3e>
KOT49H.N900VVRUCNC4
(bottom of screen)
# MANUAL MODE #
-- Appling Multi-CSC...
Applied the CSC Code : VZW
Successfully applied multi-CSC.
- - - - - - - - - - - - - - - - - - - - - - - -
.
Update:
Aquamail seems to work, which saves me from having to tell the lady that the phone I recommended was a dud. But what gives with the stock email? And she can't use play store because gmail refuses to get anywhere at all.
Maybe whoever rooted it installed broken 4.4.2 firmware. All I can do for now is guess.
**
http://forum.xda-developers.com/showthread.php?t=2259645&page=1152
**
Moondroid said:
Duplicated from top-level "general" questions, coz I'm desperate:
NO EMAIL on a "new" (pre-owned) Samsung Galaxy Note 3, rooted (? don't know what method) and running 4.4.2. Root is confirmed via supersu, File Manager (rhmsoft) recognizes root permission for an interactive session. I'm a Moto man, fairly clueless on Samsungs thus far.
This problem starts right at FDR, can't get logged into existing gmail. The default email app will accept a hotmail account config, but then never gets the mail.
Same problem on data and wifi. Internet is there, etc, but email doesn't seem to work at all.
Kies 3.0 (on Win7) recognizes the phone model, etc.
Bootloader:
ODIN MODE
PRODUCT NAME: SM-N900V
CURRENT BINARY: Samsung Official
SYSTEM STATUS: Custom
KNOX KERNEL LOCK: 0x0
KNOX WARRANTY VOID: 0x0
QUALCOMM SECURE BOOT: ENABLE (CSB)
RP SWREV: S1. T1, R1, A3, P1
WRITE PROTECTION: Enable
UDC START
DOWNLOADING...
RECOVERY:
Recovery booting...
Android system recovery <3e>
KOT49H.N900VVRUCNC4
(bottom of screen)
# MANUAL MODE #
-- Appling Multi-CSC...
Applied the CSC Code : VZW
Successfully applied multi-CSC.
- - - - - - - - - - - - - - - - - - - - - - - -
.
Update:
Aquamail seems to work, which saves me from having to tell the lady that the phone I recommended was a dud. But what gives with the stock email? And she can't use play store because gmail refuses to get anywhere at all.
Maybe whoever rooted it installed broken 4.4.2 firmware. All I can do for now is guess.
**
http://forum.xda-developers.com/showthread.php?t=2259645&page=1152
**
Click to expand...
Click to collapse
Verizon version you have. Hard to root. Good you have it.
Hi,
I am the 'proud' owner of an SM-T533 Value Edition WiFi, specs: http://pdadb.net/index.php?m=specs&id=7941&c=samsung_sm-t533_galaxy_tab4_ve_10.1_lte-a
What I am looking for is a custom recovery for this thing. It has an Snapdragon 410 processor and is an update of the older Tab 4 10.1
Currently the latest official KitKat 4.4.4 is installed, rooted with Kingo Root.
Questions:
- is there a Cyanogen or Blisspop ROM available for this model? (preferably Bliss, because I have this on my Moto G and like it very much)
- if yes, can I flash it with Flashify if there is no TWRP/CWM available?
thanks
Hans
h,
it's a qcom/msm8916 device with a snapdragon 410,
it's likely you can use another sm-t53xx 's [lte] custom recovery without issue, twrp or philz/cwm.
keep hold of your firmware, and since you are rooted, dump a copy of stock recovery from your device to your pc
and package it for odin flashing jic.
your recovery partition would likely be mmcblk0p15, so in terminal run,
dd if=/dev/block/mmcblk0p15 of=/sdcard/stock-recovery.img
then pull it to your pc and package it for flashing through odin, [lookup instuctions].
then get a copy of twrp or philz for sm-t53x lte model and flash it through odin and see if it works out.
if good. then make a full backup of your rom via recovery and then give one of the lte rom releases a try.
m
moonbutt74 said:
h,
it's a qcom/msm8916 device with a snapdragon 410,
it's likely you can use another sm-t53xx 's [lte] custom recovery without issue, twrp or philz/cwm.
keep hold of your firmware, and since you are rooted, dump a copy of stock recovery from your device to your pc
and package it for odin flashing jic.
your recovery partition would likely be mmcblk0p15, so in terminal run,
dd if=/dev/block/mmcblk0p15 of=/sdcard/stock-recovery.img
then pull it to your pc and package it for flashing through odin, [lookup instuctions].
then get a copy of twrp or philz for sm-t53x lte model and flash it through odin and see if it works out.
if good. then make a full backup of your rom via recovery and then give one of the lte rom releases a try.
m
Click to expand...
Click to collapse
M,
You called? I pulled this from the SM-T533 5.1.1 build, XEO Region (Poland). Hope it suits your fancy (the tar is obviously in the zip)
https://www.androidfilehost.com/?fid=24269982086992814
T
moonbutt74 said:
h,
it's a qcom/msm8916 device with a snapdragon 410,
it's likely you can use another sm-t53xx 's [lte] custom recovery without issue, twrp or philz/cwm.
keep hold of your firmware, and since you are rooted, dump a copy of stock recovery from your device to your pc
and package it for odin flashing jic.
your recovery partition would likely be mmcblk0p15, so in terminal run,
dd if=/dev/block/mmcblk0p15 of=/sdcard/stock-recovery.img
then pull it to your pc and package it for flashing through odin, [lookup instuctions].
then get a copy of twrp or philz for sm-t53x lte model and flash it through odin and see if it works out.
if good. then make a full backup of your rom via recovery and then give one of the lte rom releases a try.
m
Click to expand...
Click to collapse
Hi moonbutt74, I downloaded the stock recovery and tomorrow I will try to flash TWRP/Philz
thanks a bunch
Hans
HausiX10 said:
Hi moonbutt74, I downloaded the stock recovery and tomorrow I will try to flash TWRP/Philz
thanks a bunch
Hans
Click to expand...
Click to collapse
- flashed "T533XXU1BOI3_T533OXA1BOI3" to get latest bootloader -> OK
- flashed "TWRP-2.8.7.0-SM-T5XX-150901_matisse_wifi_3g_lte" -> RECOVERY IS NOT SEANDROID ENFORCING
- flashed "cwm-recovery" -> RECOVERY IS NOT SEANDROID ENFORCING
so I'm back to square one (KitKat)
n.B. flashing the provided stock recovery results in a black screen :crying:
HausiX10 said:
- flashed "T533XXU1BOI3_T533OXA1BOI3" to get latest bootloader -> OK
- flashed "TWRP-2.8.7.0-SM-T5XX-150901_matisse_wifi_3g_lte" -> RECOVERY IS NOT SEANDROID ENFORCING
- flashed "cwm-recovery" -> RECOVERY IS NOT SEANDROID ENFORCING
so I'm back to square one (KitKat)
n.B. flashing the provided stock recovery results in a black screen :crying:
Click to expand...
Click to collapse
Sorry to hear about the stock recovery, I did what I always do. You can still fix it by flashing an Odin firmware
N.B. it says "recovery is not seandroid enforcing" even when the custom recovery is working properly, so that doesn't tell us anything. I assume you were trying to say TWRP didn't work
thisisapoorusernamechoice said:
Sorry to hear about the stock recovery, I did what I always do. You can still fix it by flashing an Odin firmware
N.B. it says "recovery is not seandroid enforcing" even when the custom recovery is working properly, so that doesn't tell us anything. I assume you were trying to say TWRP didn't work
Click to expand...
Click to collapse
correct, just the message and no recovery (TWRP|CWM) :crying:
HausiX10 said:
correct, just the message and no recovery (TWRP|CWM) :crying:
Click to expand...
Click to collapse
okay, that's what i wanted to know, display drivers in kernel, quit your whining by the way.
so i'll need to get hold of kernel source, oh joy.
i'll get back to this thread when i have a kernel compiled and tinker with the recovery image.
re-flash your stock recovery.
m
moonbutt74 said:
okay, that's what i wanted to know, display drivers in kernel, quit your whining by the way.
so i'll need to get hold of kernel source, oh joy.
i'll get back to this thread when i have a kernel compiled and tinker with the recovery image.
re-flash your stock recovery.
m
Click to expand...
Click to collapse
great, appreciate your effort
moonbutt74 said:
okay, that's what i wanted to know, display drivers in kernel, quit your whining by the way.
so i'll need to get hold of kernel source, oh joy.
i'll get back to this thread when i have a kernel compiled and tinker with the recovery image.
re-flash your stock recovery.
m
Click to expand...
Click to collapse
M,
Idk if this will help but I'm giving you the stock 5.1.1 boot.img (zipped and attached), I'm still working on getting the /system/lib/modules/ listing. Also, and idk if this is significant, but unlike all other Tab 4 models, the SM-T533 is 64 bit, google it if you don't believe me but I'm 95% confident on the veracity of that statement.
okay guys,
i am NOT finding a source for t533 ,
this model is sm-t533 ?
for now i'll take a spin with sm-t535 LL source release, the 64 bit thing is iffy though.
m
moonbutt74 said:
for now i'll take a spin with sm-t535 LL source release, the 64 bit thing is iffy though.
m
Click to expand...
Click to collapse
I know right? I can't even get the system.img.ext4 to play nicely, otherwise I'd have the /system/lib/modules/ listing for you. But this SM-T533 seems to be a real challenge. But if it's any help, yes, it's definitely 64 bit (DogBlamn, right??!)
thisisapoorusernamechoice said:
I know right? I can't even get the system.img.ext4 to play nicely, otherwise I'd have the /system/lib/modules/ listing for you. But this SM-T533 seems to be a real challenge. But if it's any help, yes, it's definitely 64 bit (DogBlamn, right??!)
Click to expand...
Click to collapse
T,
is anything in the firmware, to identify the display? also H, download and install cpuz from playstore and post all the info it spits out.
m
thisisapoorusernamechoice said:
M,
Idk if this will help but I'm giving you the stock 5.1.1 boot.img (zipped and attached), I'm still working on getting the /system/lib/modules/ listing. Also, and idk if this is significant, but unlike all other Tab 4 models, the SM-T533 is 64 bit, google it if you don't believe me but I'm 95% confident on the veracity of that statement.
Click to expand...
Click to collapse
@this...
it is 100% 64Bit as per the specs I linked in my firts post
keep going guys and thanks
Hans
HausiX10 said:
@this...
it is 100% 64Bit as per the specs I linked in my firts post
keep going guys and thanks
Hans
Click to expand...
Click to collapse
M, here comes CPUZ stuff, if need more or different, just say...
moonbutt74 said:
T,
is anything in the firmware, to identify the display? also H, download and install cpuz from playstore and post all the info it spits out.
m
Click to expand...
Click to collapse
M,
Sorry , I'm always running (at least) one step behind you. I got the listing of the /system/lib/modules folder, also zipped and attached below. I'm going to go through the system folder (and then take a look at the other images in the tar if that doesn't work) to see if I can find anything about the display.
/system/lib/modules/ listing:
A folder named pronto (so /system/lib/pronto/) with a single file, pronto_wlan.ko
ansi_cprng.ko
core_ctl.ko
dma_test.ko
evbug.ko
gator.ko
mmc_block_test.ko
mmc_test.ko
msm-buspm-dev.ko
oprofile.ko
radio-iris-transport.ko
spidev.ko
tcp-htcp.ko
tcp_westwood.ko
test-iosched.ko
UPDATE: I know this isn't what you're asking for but these lines in the build.prop seemed interesting enough to mention:
Code:
ro.product.device=matissevewifi
ro.product.board=MSM8916
ro.chipname=APQ8016
ANOTHER UPDATE @moonbutt74, am I annoying you yet? :silly: I opened a couple files (/system/usr/idc/Synaptics_RMI4_TouchPad_Sensor.idc and /system/usr/idc/Synaptics_RMI4_TouchPad.idc) and they both talk about "Atmel Maxtouch touch screen", is this what you were looking for? I'm going to keep combing the system folder to be thorough. And screw it, I'm going to zip and attach those two files, since why the hell not?
for reference
CPU-Z for Android Report - 1.15
CPUs : 4
SoCs : 1
CPU 0 : ARMv7 Processor rev 0 (v7l)
Name : Qualcomm Snapdragon 400/410
CPUs : 4
Core set 0 : ARM Cortex-A53
Core set 0 Nb Cores : 4
Core set 0 Max Clock : 1190 MHz
Core set 0 Impl.id : 0x41
Core set 0 Arch.id : 0x7
Core set 0 Var.id : 0
Core set 0 Part.id : 0xd03
Core set 0 Rev.id : 0
Core set 0 Revision : r0p0
Arch : 4x ARM Cortex-A53 @1.19 GHz
Codename :
Process : 28 nm
GPU Vendor : Qualcomm
GPU Renderer : Adreno (TM) 306
Model : SM-T533 (matissevewifixx)
Manufacturer : samsung
Board : MSM8916
Hardware : qcom
Android Ver. : 4.4.4
Kernel Arch. : armv7l
Battery capacity : 6800
--- CPUInfos ---
abi : armeabi-v7a
abi2 : armeabi
processor : 0
model name : ARMv7 Processor rev 0 (v7l)
BogoMIPS : 38.40
Features : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 0
processor : 1
model name : ARMv7 Processor rev 0 (v7l)
BogoMIPS : 38.40
Features : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 0
processor : 2
model name : ARMv7 Processor rev 0 (v7l)
BogoMIPS : 38.40
Features : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 0
processor : 3
model name : ARMv7 Processor rev 0 (v7l)
BogoMIPS : 38.40
Features : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 0
Hardware : Qualcomm Technologies, Inc APQ8016
Revision : 0002
Serial : b38cd6490de57cef
Processor : ARMv7 Processor rev 0 (v7l)
--- Debug Infos ---
4=400000000
5= 0 1028763655
8=400000000 310000000 200000000
15=-1
20=tsens_tz_sensor0=39
21=tsens_tz_sensor1=36
22=tsens_tz_sensor2=34
23=tsens_tz_sensor4=36
24=tsens_tz_sensor5=37
25=pm8916_tz=29345
26=pa_therm0=10
27=stc3117-fuelgauge=-4000
28=battery=27400
51=tsens_tz_sensor0=39
52=tsens_tz_sensor1=36
53=tsens_tz_sensor2=34
54=tsens_tz_sensor4=36
55=tsens_tz_sensor5=37
56=pm8916_tz=29345
57=pa_therm0=10
58=stc3117-fuelgauge=-4000
59=battery=27400
clock0=1190400
clock1=-1
clock2=-1
clock3=-1
i am guessing this is the panel -- samsung_panel_init : ss_dsi_panel_TC358764_LTL101A106_WXGA
HausiX10 said:
M, here comes CPUZ stuff, if need more or different, just say...
Click to expand...
Click to collapse
H,
can you run uname -a in terminal or give me a screenshot of the tab in your settings that shows kernel version information?
also can you run the following command,
ls -al /proc/config.gz
if it comes back with an actual listing of that file, i need it, if so then run
cp /proc/config.gz /sdcard/config.gz and attach that to your post.
@sub77 has resources for a twrp build for matissevewifi using prebuilt kernel,
https://github.com/GalaxyTab4/twrp_device_samsung_matisseve/blob/twrp-cm12/BoardConfig.mk
if he has a build of twrp available for your tab then
that would be the way to go.
i did stumble onto this source for a kernel https://github.com/MSM8916-Samsung/android_kernel_samsung_e53g
it has dts's for your device,
Code:
/dts-v1/;
#include "msm8916-sec-matissevewifi-eur-r00.dtsi"
#include "msm8916-memory.dtsi"
so once my internet gets fixed maybe i'll be able to clone that and get something working.
from uname -a:
Linux localhost 3.10.28-4271302 #1 SMP PREEMPT Wed Jul 8 14:21:44 KST 2015 armv7l GNU/Linux
there is no config.gz in the kernel
btw I tried the twrps from sub77, but none would install/display
hans
HausiX10 said:
from uname -a:
Linux localhost 3.10.28-4271302 #1 SMP PREEMPT Wed Jul 8 14:21:44 KST 2015 armv7l GNU/Linux
there is no config.gz in the kernel
btw I tried the twrps from sub77, but none would install/display
hans
Click to expand...
Click to collapse
sub & moon,
copied a few logfiles from cache/recovery, maybe that helps ...
hans