FORUMS
Remove All Ads from XDA

[GUIDE] Samsung Galaxy S7 UART

26 posts
Thanks Meter: 32
 
By lSDriim, Junior Member on 2nd February 2018, 09:56 AM
Post Reply Email Thread
It is happened that I needed to obtain UART access on Galaxy S7. I tried Google search, apparently. I have found several threads on XDA dedicated to this question; however, they all are a bit outdated (2012-2013 years), containing information about an old loader.
Moreover, they are describing information in a very limited way, mostly telling the reader only about how to use UART with loader and do not going deeper into details.
Finally, despired to find any valuable piece of information, I performed my own research and here I will structure all the information I gathered and discovered.

To begin with, there is an USB multiplexing unit between USB-connector and USB-controller, aimed to measure the value of resistance between ID and GND, and setup a USB controller mode in dependance of that. That is not a new thing: the same way works, for instance, USB OTG.
But there exist other work modes which are hidden from the normal user. These work modes are utilized by a special device which is used by Samsung engineers. One can order a device like this on Ebay, but I do not se any reason for. Source codes of the mobile phone kernel are available for download and include a multiplexing unit driver.

The S7's MUIC name is MAX77854, which comes with lack of documentation, but we have a driver, which, obviously, has source codes which are available here: drivers/muic/max77854-muic.c. Going through the sources, I found an actual table of the resistance values and work modes for this device:
  • OTG =*GND
  • MHL = 1K
  • VZW_ACC = 28.7K
  • VZW_INCOMPATIBLE = 34K
  • RDU_TA = 40.2K
  • HMT = 49.9K
  • AUDIODOCK = 64.9K
  • USB_LANHUB = 80.07K
  • CHARGING_CABLE = 102K
  • GAMEPAD = 121K
  • TYPE1_CHG = 200K
  • JIG_USB_OFF = 255K
  • JIG_USB_ON = 301K
  • DESKDOCK = 365K
  • TYPE2_CHG = 442K
  • JIG_UART_OFF = 523K
  • JIG_UART_ON = 619K
  • TA = OPEN
  • USB = OPEN
  • CDP = OPEN
  • UNDEFINED_CHARGING =*UNDEFINED
  • ATTACHED_DEV_NUM = NUM


I have no idea what the listed most modes mean, but I see one very interesting mode JIG_UART_ON, which has been researched a bit and which allowes us to connect a device through USB-UART adapter and get a SBOOT boot log. I was inspired by an article about SBOOT where a guy researched the possibility of hijacking the boot loader and discovered a way how to change boot parameters including kernel boot parameters.

First of all, we need to build a JIG(UART) adapter. For that purpose we need to have any USB-UART adapter (I used FT232) and resistance unit for 619kOm (I have purchased one for 620kOm in the shop next to my house). Then we need to get them together as on the scheme:
USB <-> UART

The newly created adapter we need to plug in to the computer and wait for a new device name (on my system it set as /dev/ttyUSB0), then connect to this device through a terminal application (I used minicom).

Code:
sudo minicom -D /dev/ttyUSB0
I am not sure what settings will you have for your terminal application, that's why I highly recommend you to set up your port settings and disable the hardware flow control setting. After all things done, you have to plug a mobile phone to this adapter and turn it on using the key combo: Vol-(Volume Down) + Power.

As symbols on the screen start displaying, you need to quickly press Enter key as minimum as 3 times until we see the command line. Congratulations! We are in the SBOOT console! Run the following command:

Code:
setenv CMDLINE console=ttySAC4,115200 loglevel=4
saveenv
After its execution complete, press and hold Vol-(Volume Down) (if the above mentioned key has not been pressed, SBOOT will not print anything in the console) and enter the command into the SBOOT console:

Code:
reset
The device will reboot and we will see a SBOOT boot log and a part of kernel boot log. Why only a part? Because as of my research, a small bug is located in the kernel sources, I give you a patch for it below:

Code:
diff --git a/drivers/muic/universal/muic_apis.c b/drivers/muic/universal/muic_apis.c
index 342bc51..5af193c 100755
--- a/drivers/muic/universal/muic_apis.c
+++ b/drivers/muic/universal/muic_apis.c
@@ -796,7 +796,7 @@ int detach_jig_uart_boot_off(muic_data_t *pmuic)
*/
int attach_jig_uart_boot_on(muic_data_t *pmuic, muic_attached_dev_t new_dev)
{
- int com_index = COM_OPEN;
+ int com_index = COM_UART_AP;
int ret = 0;

pr_info("%s:%s JIG UART BOOT-ON(0x%x)\n",
After it has been applied, we will be able to see all the kernel boot log; however, we will break the GSM component of the mobile device. This UART port is used be system to communicate with a GSM modem. At this stage we can use it for kernel debugging, but it wasn't our goal.
Now let's get mobile device console access through UART, using the information received above.

To achieve this, we have to install TWRP on our device and using it, get root access. Then we have to install busibox, which includes getty application and that is the only its difference from the original. Afterwards, we boot our device, install a terminal emulator and switch the device to the airplane mode.
Now start the emulator and enter the following commands:

Code:
su
echo 1 > /sys/devices/virtual/sec/switch/uart_en
echo AP > /sys/devices/virtual/sec/switch/uart_sel #на этом этапе должен появиться лог ядра 
su root -c "getty -n -L -l /system/bin/sh 115200 ttySAC4 vt102"
Useful links:
The Following 3 Users Say Thank You to lSDriim For This Useful Post: [ View ] Gift lSDriim Ad-Free
 
 
26th August 2018, 03:52 PM |#2  
Junior Member
Thanks Meter: 0
 
More
and you connected the 3.3v line -why- exactly? the samsung won't power your max232 (if it does, like with usb otg, it will supply 5v, not 3.3 or usb converter and 3.3v won't power the samsung. just txd rxd and gnd is enough. also the 301ohm one always turns on the phone and boots to factory 'odin' mode for mass deployment of new firmware. (normal usb tho). when using them with the rs232 resistor value they'll output some crap at 115k2 during the bootloader.
26th August 2018, 04:09 PM |#3  
lSDriim's Avatar
OP Junior Member
Thanks Meter: 32
 
More
Quote:
Originally Posted by cb3rob

and you connected the 3.3v line -why- exactly? the samsung won't power your max232 (if it does, like with usb otg, it will supply 5v, not 3.3 or usb converter and 3.3v won't power the samsung. just txd rxd and gnd is enough. also the 301ohm one always turns on the phone and boots to factory 'odin' mode for mass deployment of new firmware. (normal usb tho). when using them with the rs232 resistor value they'll output some crap at 115k2 during the bootloader.

I connected 3.3v because it normal to connect this line and it works. Probably without this line it will work. Everything that I write was tested by me. If you see crap during bootloader check minicom config.
26th August 2018, 04:31 PM |#4  
Junior Member
Thanks Meter: 0
 
More
Quote:
Originally Posted by lSDriim

I connected 3.3v because it normal to connect this line and it works, ft232 won't power Samsung because it's not working like that. Everything that I write was tested by me. If you see crap during bootloader check minicom config.

connecting a 3.3v line to a 5v line (regardless of which way the power goes) doesn't seem very practical for long time use. :P at least for 'factory odin' mode the phone can be powered from the 5v usb side during the firmware deployment (as usually the batteries aren't all too full when we pull them out of the box anyway

nah not crap as in frame errors and random bytes crap. crap as in some status messages but nothing useful. could not find any way to stop it and drop into a machine language monitor, get any type of prompt, inject code to be booted, or anything else that would be useful from there. it literally just seems to be some debug messages of the bootloader(s)

1650 pages of leaked "samsung confidential" datasheet but finding how to actually -use- the things for anything 'not android' (as in registers, memory map instruction set)? nah. it's more work to figure out how samsung screwed things up and get rid of all their 'monopoly' code which they try to pass off as 'security' than to just design a new phone and order it into production :P

anyway, the age of the post of the resistor values doesn't matter. the values are the same for every samsung device i've tried (we only use s7's but i got boxes full of other models, including very old ones. the resistor cables work exactly the same way all of those - although the 'magic bytes' for samsungs 'modified' simg format are different for each model, as are obviously the partition sizes. and really old ones seem to use a different and incompatible version of the odin protocol alltogether). haven't tried it with those usb-c connectors on those j5/a5 or whatever those things are called, as i don't have usb-c male pcb connectors in stock, but most likely there too. it's also not very picky on the actual resistor value. 300 ohm instead of 301 is fine. as long as it's 'close enough' it'll go to the desired mode. (as their specified values are weird, you can't buy 301 ohm resistors (pretty much all of them do uart mode and turn on+odin factory mode)
26th August 2018, 04:43 PM |#5  
lSDriim's Avatar
OP Junior Member
Thanks Meter: 32
 
More
Quote:
Originally Posted by cb3rob

connecting a 3.3v line to a 5v line (regardless of which way the power goes) doesn't seem very practical for long time use. :P at least for 'factory odin' mode the phone can be powered from the 5v usb side during the firmware deployment (as usually the batteries aren't all too full when we pull them out of the box anyway

nah not crap as in frame errors and random bytes crap. crap as in some status messages but nothing useful. could not find any way to stop it and drop into a machine language monitor, get any type of prompt, inject code to be booted, or anything else that would be useful from there. it literally just seems to be some debug messages of the bootloader(s)

1650 pages of leaked "samsung confidential" datasheet but finding how to actually -use- the things for anything 'not android' (as in registers, memory map instruction set)? nah. it's more work to figure out how samsung screwed things up and get rid of all their 'monopoly' code which they try to pass off as 'security' than to just design a new phone and order it into production :P

anyway, the age of the post of the resistor values doesn't matter. the values are the same for every samsung device i've tried (we only use s7's but i got boxes full of other models, including very old ones. the resistor cables work exactly the same way all of those - although the 'magic bytes' for samsungs 'modified' simg format are different for each model, as are obviously the partition sizes. and really old ones seem to use a different and incompatible version of the odin protocol alltogether). haven't tried it with those usb-c connectors on those j5/a5 or whatever those things are called, as i don't have usb-c male pcb connectors in stock, but most likely there too. it's also not very picky on the actual resistor value. 300 ohm instead of 301 is fine. as long as it's 'close enough' it'll go to the desired mode. (as their specified values are weird, you can't buy 301 ohm resistors (pretty much all of them do uart mode and turn on+odin factory mode)

I write from my phone, because I am on vacation now and can't write long messages(too lazy now). But in this guide I write how to get bootloader prompt and change kernel start command and you can change kernel and boot anything you want... I already do this to boot up normal linux. In links there are link to guy that tried to hack sboot, may be he can help you.
The Following User Says Thank You to lSDriim For This Useful Post: [ View ] Gift lSDriim Ad-Free
Post Reply Subscribe to Thread

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes