[GUIDE] Samsung Galaxy S7 UART

Search This thread

lSDriim

Member
Aug 21, 2017
27
36
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:
drawing.jpg


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:
 
Last edited:

cb3rob

New member
Aug 26, 2018
2
0
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.
 

lSDriim

Member
Aug 21, 2017
27
36
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.
 
Last edited:

cb3rob

New member
Aug 26, 2018
2
0
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)
 

lSDriim

Member
Aug 21, 2017
27
36
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.
 
  • Like
Reactions: cb3rob

Top Liked Posts

  • There are no posts matching your filters.
  • 5
    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:
    drawing.jpg


    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:
    1
    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.