[N920A][R&D] Revision 4 BL 5.1 Rooted Rom / 6.0.1 Upgrade

Search This thread

Reverse-anastomosis

Senior Member
Oct 31, 2018
288
172
First [email protected] can you help me with this? the script is in python. Source is here. The tool is a memory dump tool based on a tool built by Nitay Artenstein, the guy behind the hex detective blog. I can't figure out how to actually get the memory dump.

Code:
[email protected]:~/Downloads/Phone stuff/N920V/Sboot hacking/sboot_dump-master$ sudo python3.7 samupload.py

SUC - Samsung Upload Client v1.0 (c) B. Kerler 2018, Email: info @ revskills.de
  CONFIGURATION 1: 50 mA ===================================
   bLength              :    0x9 (9 bytes)
   bDescriptorType      :    0x2 Configuration
   wTotalLength         :   0x43 (67 bytes)
   bNumInterfaces       :    0x2
   bConfigurationValue  :    0x1
   iConfiguration       :    0x0 
   bmAttributes         :   0xc0 Self Powered
   bMaxPower            :   0x19 (50 mA)
    INTERFACE 0: CDC Communication =========================
     bLength            :    0x9 (9 bytes)
     bDescriptorType    :    0x4 Interface
     bInterfaceNumber   :    0x0
     bAlternateSetting  :    0x0
     bNumEndpoints      :    0x1
     bInterfaceClass    :    0x2 CDC Communication
     bInterfaceSubClass :    0x2
     bInterfaceProtocol :    0x1
     iInterface         :    0x0 
      ENDPOINT 0x83: Interrupt IN ==========================
       bLength          :    0x7 (7 bytes)
       bDescriptorType  :    0x5 Endpoint
       bEndpointAddress :   0x83 IN
       bmAttributes     :    0x3 Interrupt
       wMaxPacketSize   :   0x10 (16 bytes)
       bInterval        :    0x9
    INTERFACE 1: CDC Data ==================================
     bLength            :    0x9 (9 bytes)
     bDescriptorType    :    0x4 Interface
     bInterfaceNumber   :    0x1
     bAlternateSetting  :    0x0
     bNumEndpoints      :    0x2
     bInterfaceClass    :    0xa CDC Data
     bInterfaceSubClass :    0x0
     bInterfaceProtocol :    0x0
     iInterface         :    0x1 SAMSUNG
      ENDPOINT 0x81: Bulk IN ===============================
       bLength          :    0x7 (7 bytes)
       bDescriptorType  :    0x5 Endpoint
       bEndpointAddress :   0x81 IN
       bmAttributes     :    0x2 Bulk
       wMaxPacketSize   :  0x200 (512 bytes)
       bInterval        :    0x0
      ENDPOINT 0x2: Bulk OUT ===============================
       bLength          :    0x7 (7 bytes)
       bDescriptorType  :    0x5 Endpoint
       bEndpointAddress :    0x2 OUT
       bmAttributes     :    0x2 Bulk
       wMaxPacketSize   :  0x200 (512 bytes)
       bInterval        :    0x0

Probed device:
---------------
32-Bit, Devicename: "SM-N920V"

Detected upload areas:
---------------------
0:"kernel debug" (0x0,0x46800000)
1:"ÿÿŸF" (0x62656420,0x6775)
2:"" (0x0,0x1)
3:"o debug" (0x46e00000,0x0)
4:"" (0x67,0x0)
5:"" (0x1,0x616d6974)
6:"" (0x0,0x48201fff)
7:"" (0x0,0x0)
8:"" (0x707374,0x0)
9:"" (0x48285fff,0x0)
10:"pmu" (0x0,0x48288000)
11:"ÿ(H" (0x0,0x0)
12:"" (0x0,0x1)
13:"" (0x40000000,0x0)
14:"" (0x0,0x0)
15:"" (0x1,0x7061)
16:"" (0x0,0xfe7fffff)
17:"" (0x4e2d4d53,0x56303239)
Traceback (most recent call last):
  File "samupload.py", line 208, in <module>
    main()
  File "samupload.py", line 182, in main
    areas=suc.probe()
  File "samupload.py", line 113, in probe
    [ptype,pname,pstart,pend]=struct.unpack("<I 16s I I",data[i:i+0x1C])
struct.error: unpack requires a buffer of 28 bytes

Second: s-boot console commands
I have attached a log. I put some notes in there, but please, if there is something specific that you want me to try let me know. I am not really even scared about bricking the device. I just hope to gain some knowledge and have some fun.

3rd-I was unable to extract the apk of the logging app that I talked about in earlier posts. I did find the package name, and downloaded the apk from apkmirror. I have not tested the apk on any firmware, so I have no idea if it will work, but it is a handy tool on the combo firmware. If the app works, hit the 3 dots in the upper righthand corner, hit dump, and it gives a bunch of logging options.
 

Attachments

  • com.sec.OneJigBinary_V143_170412-3_minAPI16(nodpi)_apkmirror.com.apk
    19.3 MB · Views: 20
  • sboot_commands.txt
    38.1 KB · Views: 34

xenomorph318

Senior Member
Jun 30, 2018
63
9
Nexus 7
@Delgoth hey guess what. I got your v1 rom to boot up, in a custom slot btw :p What i did was while in safe strap wipe everything on stock slot except data, then in custom slot make a backup of everything but system and restored everything over the stock slot. i dunno what or why that made it work but it works. Including two screens of the about page
 

Delgoth

Senior Member
Dec 1, 2010
636
183
This is pretty interesting, and has some good info on memory addresses. Just posting for reference. I'm guessing that this exploit is patched in the current bootloader, but if we can get the bootloader rolled back....everything is laid out here for a complete patch for loading unsigned images.
https://wikileaks.org/ciav7p1/cms/files/cadmium.pdf

Reading the first 11 pages, it seems like it could still be potentially possible on the G925v Combo FW. Like I said before about the memory mapping. It is actually different on the 64GB variant than it is on the 32GB variant. Maybe that is how Super-Boot booted, and why I still think the Radio/Modem has some potential. It has been almost 4 years now since I've had a usable S6Edge. Most Combo Firmware recoveries based on 6.0.1 or lower don't actually boot up. They use just a little space for keys and such. A lot of possibilities now that I see this pdf that I didn't notice before.



First [email protected] can you help me with this? the script is in python. Source is here. The tool is a memory dump tool based on a tool built by Nitay Artenstein, the guy behind the hex detective blog. I can't figure out how to actually get the memory dump.

3rd-I was unable to extract the apk of the logging app that I talked about in earlier posts. I did find the package name, and downloaded the apk from apkmirror. I have not tested the apk on any firmware, so I have no idea if it will work, but it is a handy tool on the combo firmware. If the app works, hit the 3 dots in the upper righthand corner, hit dump, and it gives a bunch of logging options.


I will look into it some more, I uploaded a "sboot-dump-master.zip" from github that was this project. I don't know if it was the original or the forked version. Yes though, I have highly considered this program since you posted about having UART connectivity.

But look for the app called "APK Extractor Lite". I've been able to extract even system apps with it on a non rooted device before on my (old) G925v and N920a.

@Delgoth hey guess what. I got your v1 rom to boot up, in a custom slot btw :p What i did was while in safe strap wipe everything on stock slot except data, then in custom slot make a backup of everything but system and restored everything over the stock slot. i dunno what or why that made it work but it works. Including two screens of the about page

But didn't you say that it booted to the combo firmware? Did I accidentally use the wrong system.img from the wrong folder because it was like 3am at that point? I know that I used the 2APB2 system.img contents for the v1.2 rom zip.
 
Last edited:

xenomorph318

Senior Member
Jun 30, 2018
63
9
Nexus 7
But didn't you say that it booted to the combo firmware? Did I accidentally use the wrong system.img from the wrong folder because it was like 3am at that point? I know that I used the 2APB2 system.img contents for the v1.2 rom zip.


yes v1.2 booted to the combo firmware but i had a feeling v1 was so close and just needed a little playing around with. So i kept fiddling with v1. So i deleted the assert line in the script cuz NOBLE rom didnt have that line, at this point i was trying everything and i doubt that had any thing todo with it cuz the argument was correct anyway. So I wiped everything on the stock slot except for data cuz if u wipe data i think the phone bugs out and reboots without SS. then swapped to custom slot, made a backup of every thing via SS backup, swapped back to the stocked slot and restore the backup. But when i restored the backup i had to uncheck system cuz it wont let u restore system but it will let u restore system image and the rest. I lost SS, but im sure its just a matter of flashing again with flashfire.
 
Last edited:
  • Like
Reactions: Delgoth

Reverse-anastomosis

Senior Member
Oct 31, 2018
288
172
Sanity check time.

My 1st idea, which I think is actually possible for us to do with the tools and knowledge that we have.

Flash stock 7.0, or really whatever firmware you want. Get to s-boot prompt(which I have tested and its still accessible in 7.0) load the kernel. Add kexec support to the kernel via Nitay Artenstein's code injection method. Go ahead and boot the kernel (may need an argument to enable kexec). Once booted, kexec a custom kernel with root support and sepermissive. Install permanent root via adb root shell. I'm not sure if we would be able to keep root under the stock kernel after installing via adb, or if we would have to kexec a custom kernel with each reboot. This should be stable enough that a tethered root wouldn't be a big deal. The system should still be usable under the stock kernel if you had to reboot for some reason.

Todo

1. get memdump working
2. Figure out exactly how nitay's exploit works(he's still alive I think so we could maybe reach out to him)
3. Write code necessary to add kexec function to stock kernel(I don't know how to do this, but I think that if we have all of the other pieces put together we can find a dev who knows C to write it for us.

Second idea is more outlandish, but hear me out. Safestrap doesn't work with custom ROMs, only because the custom kernel can't get past the locked bootloader. As far as I know, you can actually flash the whole custom ROM sans the kernel and the bootloader doesn't care. So, if we could figure out how to load a custom kernel from the sboot console, we should be able to boot a custom ROM....I think.
 
  • Like
Reactions: Delgoth

Delgoth

Senior Member
Dec 1, 2010
636
183
Sanity check time.

My 1st idea, which I think is actually possible for us to do with the tools and knowledge that we have.

Flash stock 7.0, or really whatever firmware you want. Get to s-boot prompt(which I have tested and its still accessible in 7.0) load the kernel. Add kexec support to the kernel via Nitay Artenstein's code injection method. Go ahead and boot the kernel (may need an argument to enable kexec). Once booted, kexec a custom kernel with root support and sepermissive. Install permanent root via adb root shell. I'm not sure if we would be able to keep root under the stock kernel after installing via adb, or if we would have to kexec a custom kernel with each reboot. This should be stable enough that a tethered root wouldn't be a big deal. The system should still be usable under the stock kernel if you had to reboot for some reason.

Todo

1. get memdump working
2. Figure out exactly how nitay's exploit works(he's still alive I think so we could maybe reach out to him)
3. Write code necessary to add kexec function to stock kernel(I don't know how to do this, but I think that if we have all of the other pieces put together we can find a dev who knows C to write it for us.

Second idea is more outlandish, but hear me out. Safestrap doesn't work with custom ROMs, only because the custom kernel can't get past the locked bootloader. As far as I know, you can actually flash the whole custom ROM sans the kernel and the bootloader doesn't care. So, if we could figure out how to load a custom kernel from the sboot console, we should be able to boot a custom ROM....I think.

Your first idea had been considered in the past, But they didn't have the combo firmware or solid root yet. Not to mention SS and the sboot jig.

With our new resources I believe we should revisit the idea of kexec'ing a kernel. It has indeed worked with other devices in the past.

I had been given a weird modified kernel in the past that would flash over my rev3 fw in ODIN but wouldn't boot due to an incorrect header. They wouldn't tell me where they got it, what it was, or how it was modified. But the bootloader hung at the Samsung screen due to incorrect header layout.

@TechNyne66 care to share now?

But I have free time tonight and all day tomorrow. I'll get some more work done to help. Full Flashing to 7.0 first and then flashing back to the combo without wiping cache should let you read the recovery logs from 7.0 as well as 5.1.1 to compare the address space layout.

Thanks for the commands. I should have more info tomorrow. Yesterday was hellish and today wasn't much better. But I have time over the next day or so.
 
  • Like
Reactions: Reverse-anastomosis

Reverse-anastomosis

Senior Member
Oct 31, 2018
288
172
@Delgoth So I think that I figured out the problem with the memory dump tool. For some reason it is returning the n920v as a 32Bit device, and should be returning as a 64bit device.
Code:
Probed device:
---------------
32-Bit, Devicename: "SM-N920V"

I have not had a chance to append the code to fix this, but I think I can just force it to execute only the 64 bit commands by copying lines 118-125 to lines 109-116. If you have other suggestions please let me know. I don't know python well enough to do this in a more elegant way...but this should work I think.

Code:
103         def probe(self): 
104         self.cdc.write(b"PrObE\0") 
105         data = self.cdc.read() 
106         count=0 
107         devicename = self.bytetostr(struct.unpack("16s", data[0:16])[0]) 
108         if (devicename[0]!="+"): 
109             print("\nProbed device:\n---------------\n64-Bit, Devicename: \"%s\"\n" % devicename[1:]) 
110             probetable = [] 
111             print("Detected upload areas:\n---------------------") 
112             for i in range(16, len(data), 0x28): 
113                 [ptype, pname, pstart, pend] = struct.unpack("<I 20s Q Q", data[i:i + 0x28]) 
114                 probetable.append([ptype, self.bytetostr(pname), pstart, pend]) 
115                 print("%d:\"%s\" (0x%x,0x%x)" % (count, self.bytetostr(pname), pstart, pend)) 
116                 count += 1 
117         else: 
118             print("\nProbed device:\n---------------\n64-Bit, Devicename: \"%s\"\n" % devicename[1:]) 
119             probetable = [] 
120             print("Detected upload areas:\n---------------------") 
121             for i in range(16, len(data), 0x28): 
122                 [ptype, pname, pstart, pend] = struct.unpack("<I 20s Q Q", data[i:i + 0x28]) 
123                 probetable.append([ptype, self.bytetostr(pname), pstart, pend]) 
124                 print("%d:\"%s\" (0x%x,0x%x)" % (count, self.bytetostr(pname), pstart, pend)) 
125                 count += 1
 
  • Like
Reactions: Delgoth

Reverse-anastomosis

Senior Member
Oct 31, 2018
288
172
@Delgoth So I think that I figured out the problem with the memory dump tool. For some reason it is returning the n920v as a 32Bit device, and should be returning as a 64bit device.

I got it working-I have attached the working version.

Edit: You can use this tool to dump memory without the uart jig. You should be able to hold power and vol - to force your device into upload mode. Then connect with a USB cable and dump memory if you are interested for any reason. You can compare the tool to the source, but all I did was replace the the lines in the 32 bit section with the lines from the 64 bit section, so the tool still says it is a 32 bit device, but the tool runs the 64 bit commands. You may need to create a directory wherever you run the tool that is named "memory" for the tool to dump your memory files. I ended up with 13 bin files after running the tool.
 

Attachments

  • samupload64.py.tar
    9.5 KB · Views: 13
Last edited:
  • Like
Reactions: Delgoth

Delgoth

Senior Member
Dec 1, 2010
636
183
@xenomorph318 , @Reverse-anastomosis , @droidvoider , @JeSTeRH4CK3D , @TechNyne66

Here Is a conversation I was trying to have awhile back. Let me Leave it here for further insight and inspiration. There has already been a lot of trial and error done. But there are still plenty of avenues to explore given what information we do have already. I just still haven't gotten another device to help test with. I can still only help by offering advice and insight at this point in time. Right now, you guys are the real work horses. I'm relying on your tests to help explain further what we were trying to do before. To finish the project. Keep going. We are closer now than ever.


new post to jester
Long ago
Apr 15, 2017

thread:
https://forum.xda-developers.com/at...te-5-n920a-teather-root-t3356666/post70325570


Sorry about my sarcasm I was on this project for awhile and the 2nd layer of security blocked me and the 500 times I repaired my phone sucked so I had to part ways........I eventually kernel rooted my phone with a Ubuntu style kernel exploit and it seemed to get me the furthest but brick wall again so I gave up.

Sent from my SAMSUNG-SM-N920A using XDA-Developers mobile app

|*****
| ***
| *


Can you explain to me what you did, when referring to this? With The Greyhat Root Project in full swing again, we might be able to join forces and get over the final hump. I've seen your posts scattered around here and there. So you seem to know a lot bout decompiling and getting to the bottom of our device. SELINUX may still new to me, but Android is not.

I have a **** ton of files for the N920A specifically, and many of the other variants. The other variants files I have for when the day comes I find the opportune moment/context to spoof a signature check and temp boot a TWRP build or something. There is actually about ~300GB-500GB worth of Files I have pertaining to Android Modding and Firmwares. I collected it all because I was losing my internet at the time. I still have been without a solid reliable connection to Google & XDA since the beginning of 2017. So now I have a mega offline backup. There aren't too many ODIN/OTA Packages I DONT have. I WISH I had the Sideloadable OTA zip that upgrades the August PH4 build to the next incremental build that I believe is 3CPJ1. If I could get my hands on an OTA zip I can actually use, I might be able to finagle the new Greyhat Tools @droidvoider whipped up into patching the contents of the OTA package as the Android system executes 'applypatch' to parse the OTA and extract it. Which would be the easiest method for Our tools to work in their current state. I just don't remember where I found a lot of my files, and better yet, I stil don't even understand half of the data I do have my hands on, or how to utilize fully. I need advice from a fresh pair of smarter eyes that is willing to serious consider the work Droidvoider & Myself have spent the last 5-6 months working on almost nonstop.

Trust me, we aren't asking questions lightly. If you look at our threads: "Injecting Root & Setting SELinux", and, "The Current State of Root 1/31/17", you will see we've put a lot of time in this ourselves just like you. But you started all this way before either of us began working on the Note 5. But we've greatly expanded upon your work since then, from what I can see. That's why now that you claim you are back, I desperately want to know, what you know. Especially how did you manage to modify a copy of ODIN to remove the SHA-1 checks? In what contexts will that help us? How does bypassing that check help flashing things? And how did you actually manage to even edit the program without affecting it's natural operating functions? I need to know this, because if I can wrap my head around modding a Version of ODIN, we may just be able to get some custom code handlers injected into the ODIN app that can take advantage of our new Dirtycow based utilities that can fork/maintain control of a system level process running out of the context we choose. We currently can run root commands using the system_server or install_recovery contexts. Which is the first step in trying to at least temp boot a custom recovery image. Anymore, it is just really hard to find well versed Android Developers that are familiar with Samsung's newer Builds & Devices, that will take the time to explain what they know. Because most Dev's have left the N920A behind never to return, thinking it is a complete lost cause. Their attitude against our device, leaves us @droidvoider and @Delgoth) spinning our wheels, while we try to either kang someone else's wheels or reinvent a new one. Just because the device has remained locked for almost 2 years, does not mean we are going to give up, once you give it up, it most assuredly will never get done.

|*****
| ***
| *

I'm currently on a Binary 3 Bootloader Device. Download mode reads at the bottom, underneath the secure boot text, "B:3 A:0 S:0". And that is what it has always read since I recieved my device. Nothing I've done up to now has ever tripped my knox warranty bit. It's always remained '0x0', even when purposefully trying to flash bad things. This could be due to the fact that I've been using the UCS3BPH4 cm.bin and param.bin, with the Factory PH1 eng sboot.bin, almost the whole time I've had my phone. I didn't stick with stock MM Ph4 long, after I found out I could use an Engineering Kernel if I downgraded my AP File back to a 5.1.1 Build. Once I acquired the Full {3A}Ph1 firmware package though, I did successfully downgrade the cm+param bins from the {3B}Ph4 to the versions shipped with the Factory Binary. Flashed the first time, no troubles. The Combination Bootloader must have a special kind of signature key embedded into it, because the {MM} PH4 bootloader just allowed me to overwrite all the files without blinking. This could be either the signature key I just mentioned, or the fact that both PH4 and PH1 both have the same build dates on them {NOW KNOWN AS 'bootloader revision rollback protection', they were both rev 3.}. Technically speaking, even though PH1 is Lollipop and therefore "older" by strict definitions, the Note 5 device doesn't see it as a downgrade because of the build times. This also leads me to believe that like the VZW Galaxy S7, that shipped to Users with a Locked Bootloader, we can use a newer Firmware Package than the currently installed FW, in order to bypass any protections from the carrier. The Bootloader hates being downgraded, but it eats it up everytime we tell it to upgrade to a new edition. We can capitalize on that fact if we have everything staged at the opportune moment.

I fully downgraded all of the ODIN firmware parts from 6.0.1 UCU3BPH4 (Aug 2016), to the Combination Factory Binary of 5.1.1 UCU3APH1 (Also Aug 2016, also the SAME build date/time). PH4 ships as the standard ODIN 4-file .tar.md5 package. It contains the standard issue BL,AP,CP, and CSC files. It is also accompanied by an extra .PIT file that should be used by anyone using a 16GB version of the Note 5.

The Factory Binary Firmware, [COMBINATION_FA51_N920AUCU4APL1_CL6053901_QB11816686_REV00_user_mid_noship.tar], did not come to me as a 4 file ODIN Package. The tarbal listed above, instead had each piece contained in all the 4 files, in the top level directory of the archive. Check the Injecting Root & Setting SELINUX thread for a full break down of this FW package. It is still a signed MD5 Firmware package though. Unpacking the tarball and repacking still produces errors when trying to flash it to the device. Maybe if we can patch the checksum binaries on the device before we try and flashed a modified combination package, maybe we can just leave the signature of the tar.md5 intact. If we have the on device binaries patched to not generate it's own checksum and to use the one supplied in the flashed file instead of, we win.

I don't buy into the story of our device being completely locked into flashing only AT&T supplied signed firmware. Utilizing the premise of the Dirtycow exploit, we can get around that hurdle no problem. It just isn't the most straight forward route to getting this accomplished is all. Not impossible, just way out of the ordinary and not a standard way to aquire root by any means.

I'm back to Lollipop. I cannot however, get the cm/param.bin files to downgrade any further than I have now. Cm & Param (effectively, the /CPEFS partition, housing the CP or Radio as well your EFS/IMEI). I can downgrade my modem.bin to any of the modems I have attempted. Most of the time, the baseband menu in "About Device" will read as 'Baseband Unknown' if the persistent partions on the device are newer than the radio firmware itself. For awhile I was unable to downgrade my radio at all, and was stuck using the baseband from the PH4 build. Then I found an Unlocked version of the CP/Radio modem for the PH4 build. Now I can edit my APN settings just by flashing in this newer modem binary. Once I had the unlocked modem in place, my device started allowing me to flash older modems from old builds. I have not had any problems with my modem affecting operation of my device. But I don't use AT&T phone service anyways, so if my telephony services don't currently work, I wouldn't know or care really. I know that getting the modem configured correctly is one of the biggest things to a lot of people however. MY Phone is currently only a Wifi/Test device until I can carrier unlock it or root it. Only paid 80 bucks for it too. Woop. Too bad the sister inlaw just HAD to do a factory reset and software update before giving it to me. The device had been a Binary 2 BL, using the PB2 build. I could have had an easier time getting to where I am now otherwise.

Because I honestly feel like when Samsung/AT&T upgraded their code from Binary 2, to Binary 3, there were a lot of changes made under the hood that we just aren't privy to yet. And these changes I'll bet is why many

|*****
| ***
| *

YET THERE IS STILL GOOD NEWS: Since the factory binary is a LP build, we can still flash the UCE2APB2 eng kernel to get ADB Root with the Factory Binary. I've also found the ENG sboot for this Combination Firmware. Meaning I have ADB Root running under the selinux context 'u:r:su:s0' at runtime, and I also have early access to ADB before the boot process has finished completely. Not always right at boot, but normally the ADB Devices command picks up my phone as soon (maybe a couple seconds after) as the AT&The logo appears. My device also gives me root adb access while the phone is powered off but still connected via USB. Interesting stuff here.

The factory firmware also changes the wording on the OEM Unlock toggle switch. The Factory FW shows the toggle like normal, reading "Toggle OEM Unlock", but the description underneath the toggle actually says this: "Allow the bootloader to be unlocked." That description is very different from the official stock ROM description of, "Allow the device to be OEM Unlocked."

I know it's just a difference of a single hard coded string, but what if the factory FW doesn't have the extra restrictions AT&T placed in their shipped User builds disabling BL unlocking.

I bring that up because, When I try to flash the stock U2APB2 sboot.bin from the ODIN Package you posted, I always recece an error during the flash that says "Device 3 : Binary 2", which is normally what happens when downgrading to an old firmware. Many people ask about that error not knowing that the number after UCU/UCS is the Software Revision Number that now plays a huge role since I've been using LP builds.

But even though I can't flash the PB2 sboot over top of the PH4 sboot, I can however successfully flash the PB2 sboot to my device if I flash it over top of the Combination PH1 sboot. The factory sboot does not check anything when flashing. It is technically still signed, so it flashes perfectly. But, It has let me overwrite it with whatever N920A sboot I have thrown at it. I don't know if this is because I use the ENG PH1 sboot.bin instead of the stock sboot that ships with the Factory Binary.

But just Flashing an older sboot alone, without also downgrading CM & PARAM, is not enough to get your BL downgraded. The sboot binary is the piece of the bootloader that loads the Kernel. I found this out when I found the PH1 eng sboot before I had the full firmware. I flashed the eng sboot overtop of the full MM based PH4 firmware, and then my phone bootlooped at the Samsung logo forever. It wasn't until I flashed a Lollipop AP file to the device that I found out the eng sboot, just won't fully boot a MM based system.

During the infinite bootloops I found out an important detail. Please read on for a possible workaround for small stuff:

I started with the full 6.0.1 UCS3BPH4 ODIN Package. Fully booted fine. Then I flashed the Factory Engineering sboot.bin from PH1, my phone would not boot. SO I flashed the LP based PB2 eng kernel to see if I could get it to boot without having to do a full flash. I had no such luck with the PH4 ROM w/ eng kernel & sboot.

After leaving it sit to continue looping, hoping I was wron, I heard my computer ding as if something plugged in! ADB detected my device! Detected it even though it was still hanging itself on the Samsung boot logo. I had ADB Root access to the entire marshmallow based system during its boot up procedure all thanks to the Lollipop ENG Kernel. The drawback there being, I only has Command Line Access to the device. The Kernel and SBoot can't finish booting MM Builds. This is how I found out the PH1 sboot.bin could load a LP Kernel, that in turn showed me, I could fully boot any 5.1.1 ROM. Big news for anyone that hasn't taken one of the Binary 4 updates.

Because I'd venture to say that the S/W Rev. 4 Factory Combination Firmware "UCU4APL1" is a MM based build. The Binary 3 factory FW "UCU3APH1" is based on LP. It would be awesome if the binary 4 combination file was a LP build as well, then everyone can have the eng kernel at their disposal.

****
XDA Browsable Resources Folder
(look for 'N920AUCE2APB2.tar' & 'N920A_UCU3APH1_ENGSBOOT.7z')

1.) Someone should try and root the rev4 combo FW like standard.
2.) Then install safestrap.
3.) Then use it to flash the 2APB2 ENG Kernel.

~~~ ONLY if the 1AOGG files won't work any type of way with the 4aPL1 combo sboot ~~~~
4.) Then use it or Flashfire to flash the 3APH1 Actual Eng Sboot.bin to the device. ~{To see if the the rev4 rejects the eng keys}~
~~~rev3 eng sboot needs tested if rev4 pl1 cant do it~~~

5.) Then Flash the 1AOGG Odin Package WITHOUT [boot.img, sboot.bin, cm.bin, param.bin, modem.bin]
+++ Meaning Flash the AP file without the 'boot.img', and flash the carrier CSC file

6.) Meaning, Clean flash to 4APL1. Then Root. Then Safestrap. Then Flash 2APB2 Eng Kernel [ODIN or Safestrap], Then Flash 3APH1 sboot.bin only. Then Flash 1AOGG AP ODIN file, and the Carrier CSC File at the same time in the right slots, after deleting the stock boot.img from the AP odin package.

*7.)* If TEST FAILS: We might even want to try and use the ODIN re-partition option in conjunction with the 1AOGG PIT File before/after flashing the 4APL1 combo and before+after the 2APB2 kernel. When I used to use the eng kernel. I could remount things in 5.1.1 without as many errors as rev4 MM. so the pit file might make a difference to the kernel/system/cache flashing ability. It sounds risky, but even on my worst flash, I still always seemed to have download mode. It was nigh unbrickable. @Reverse-anastomosis , do you think you're device is unlocked enough that you could try booting any bits of the N920A FW itself without locking yourself down? How unlocked are you really, and what is your GOTO FW for MM & LP builds?

Maybe we can get the rev3 eng sboot to flash still somehow, with ODIN or SS. That would provide less sig checks on roms with the eng kernel in tow. We could make ramdisk changes again then [only some changes work]. We will probably have to keep the rev4 combo modem though for service unless the rev3 eng sboot can flash and allow to downgrade to unlocked rev3 eng modem. ** If the eng sboot.bin can downgrade its own sw revision in ODIN, maybe it allows carrier flashing as well?
 

Attachments

  • KnoxStatus.png
    KnoxStatus.png
    192.8 KB · Views: 22
  • Settings.AboutDevice.png
    Settings.AboutDevice.png
    216.5 KB · Views: 22
Last edited:

Reverse-anastomosis

Senior Member
Oct 31, 2018
288
172
@Delgoth I'm not a whole lot further than where I was. I'm still working from my 5.1 combination firmware, because it has fairly stable root. I'm still working on kexec. I just got the binaries loaded and working last night. The problem is that there are no kernels with support for the hard reset kexec. I want to work on that because...I think I can treat this a little like multiboot and kexec from 5.1 to a rooted 7.0 or whatever. If I have time today I'm going to try working on patching a stock kernel with the hard reset patch, just to see if I can kexec from one to the other. Do you know if any of the eng kernels are open sourced? Or am I going to have to go to a stock kernel?
 

Delgoth

Senior Member
Dec 1, 2010
636
183
@Delgoth I'm not a whole lot further than where I was. I'm still working from my 5.1 combination firmware, because it has fairly stable root. I'm still working on kexec. I just got the binaries loaded and working last night. The problem is that there are no kernels with support for the hard reset kexec. I want to work on that because...I think I can treat this a little like multiboot and kexec from 5.1 to a rooted 7.0 or whatever. If I have time today I'm going to try working on patching a stock kernel with the hard reset patch, just to see if I can kexec from one to the other. Do you know if any of the eng kernels are open sourced? Or am I going to have to go with a stock kernel?

http://opensource.samsung.com/reception/receptionSub.do?method=sub&sub=F&searchValue=Sm-n920a

Unless we convince Samsung to release the 2APB2 sources. We only have 2BPE6, and 2AOJ1 sources to work with. The N920A Eng Kernel was built right in between the two builds they published the source code to. And we can really only use 2AOJ1 right now at this stage. I'm told we can still request the sources for other builds on the device though.

I wonder how similar the 4A and 2A loaders are though. With the exynos chip, I'm still kind of convinced that "aboot" revision A is about the same across "sboot" revisions 1-4. That's why the 2APB2 eng kernel can be booted all on four revisions of the exynos7420 sboot.

If you think about it though the used "aboot" A for 5.1 builds. Used "aboot" B for 6.0.1 builds. Then they had to upgrade to "aboot" C to patch the dirtyc0w exploit for the boot.img and system.img loaders. Aboot revision D came along for Nougat.

It would be easier to step to a rooted 6.0.1 system from 5.1 since rev4 still supports MM & we should still be able to load a revision 2A system.img. Because even though we have root on 5.1 we could still dirtyc0w patch 5.1 and 6.0.1. That means we might be able to leverage dirtyc0w within a Safestrap Flashable Zip.

This makes it far and away easier to enter SafeStrap from a Stock build on the Note5 than it is for the S8/Note8. Because I do believe that if we dirty flashed the combo lp sboot and eng lp kernel over a stock MM, we should still have ADB access while the phone is offline or hangs at boot. I achieved that on the G925V.

I found that a new device might only run me $130. But I need to find one still on revision 4. On 5.1.1 we have root and then can flash a permissive kernel afterwards. On 6.0.1 we have ADB Root and a rev4C recovery.img that can bypass dm-verity checks. So essentially the same method on both. I think we have an Avenue open to use SS to inject DC with.

We can still root with enforcing selinux, we just need to know the sepolicy better.
 

Reverse-anastomosis

Senior Member
Oct 31, 2018
288
172
So if you're just interested in a device to play with I could probably send you the N920v, or the g925v if you're more familiar with that device(when I finally get a replacement from eBay). I know that a lot of your work has been with the n920a device. From my perspective it doesn't really matter what device I'm working with right now-as I'm not really looking for firmware specific exploits with my sboot console work.

My goal, ultimately is to do something on this device that no one has done before. Its been a huge learning experience, and I continue to learn new things every day.

The end goal for me is a custom ROM-but I'm happy with anything I get in between.

I really think that kexec can work for us...especially with safestrap available to us.

Here is how I think this will work; get on a rootable firmware, install the kexec binaries, reboot to safestrap, kexec a new kernel with hardboot, boot into safestrap with the kexec kernel, load whatever system image from whatever slot we want.

I think the with the current kexec binaries I should be able to load any kernel that I want since I'm starting with a rooted system. I need to figure out the proper arguments to pass to the new kernel in order to get kexec to load it. I do now have a log of all of the current standard arguments for the combination kernel which may be helpful. I'll attach the terminal output of my first kexec attempt for reference.

A couple of potential problems:kexec might not work correctly on 64bit systems, I know its been worked on, but I'm not 100% sure my binaries are patched.

The kernel that I am currently using may need a patch for hardboot(I think hardboot will be essential due to switching systems), which I should be able to inject and load via sboot console.

The slots need to be fixed and functional in safestrap. It sounds like xenomorph has been using them, but afaneh says they are broken. I have not tried using slots yet, but I imagine its fixable.

This method should work regardless of which device you have. If there is any kernel work or ROM building needed I could really use some help.

I know that I have not been very helpful to you in your endeavours, but with firmware specific exploits I really can't be.

I'm probably never going to get where I want to be with this device, but I do think it is possible-i just don't have the necessary knowledge. I am learning a ton though.

If you are interested, I can solder up a UART jig for you and send you the jig and the g925v(when I get the replacement from eBay) so we can work together on this. You would have to get the serial to USB converter and a multimeter that has the proper ranges.

---------- Post added at 10:28 PM ---------- Previous post was at 10:11 PM ----------

Forgot to attach the console output.

[email protected]:/sdcard/bangin # kexec --load-hardboot zImage-dtb --initrd=initramfs.cpio.gz --mem-min=0x0 --command-line="$(cat /proc/cmdline)"
kexec version: 16.02.07.19.31-g364a380
arch_process_options:112: command_line: console=ram loglevel=4 androidboot.baseband=mdm2 sec_debug.level=1 androidboot.debug_level=0x494d androidboot.bcd_im_offset=7342672 androidboot.bcd_me_offset=7342752 androidboot.bcd_sn_offset=7342832 androidboot.bcd_pr_offset=7342912 androidboot.bcd_sku_offset=7342992 sec_debug.enable_cp_debug=1 androidboot.cp_debug_level=0x5500 softlockup_panic=0 asv_table_version2=8735 ess_setup=0x46000000 charging_mode=0x0 [email protected] [email protected] [email protected] [email protected] [email protected] s3cfb.bootloaderfb=0xe2a00000 lcdtype=136260 consoleblank=0 lpj=239616 vmalloc=384m sec_debug.reset_reason=7 ehci_hcd.park=3 oops=panic pmic_info=107 cordon=558051cdf630920e8d963e67f1f13aaa connie=SM-N920V_VZW_USA_bd2d07da0a76e0d4f555a2128541d6fa fg_reset=0 androidboot.emmc_checksum=3 androidboot.boot_salescode= androidboot.odin_download=1 androidboot.bootloader=FA51_N920VVRU3API2 androidboot.selinux=enforcing androidboot.hw_rev=9 androidboot.warranty_bit=0 androidboot.sec_atd.tty=/dev/ttySAC1 androidboot.serialno=0316034cd5093c04 snd_soc_core.pmdown_time=1000 [email protected]
arch_process_options:114: initrd: initramfs.cpio.gz
arch_process_options:115: dtb: (null)
arch_process_options:117: port: 0x0
Try gzip decompression.
kernel: 0x7f7e100000 kernel_size: 0x1267330
read_sys_dtb: No such file or directory
Modified cmdline:
Unable to find /proc/device-tree//chosen/linux,stdout-path, printing from purgatory is diabled
unrecoverable error: propnames overrun
[email protected]:/sdcard/bangin #
 

xenomorph318

Senior Member
Jun 30, 2018
63
9
Nexus 7
@Delgoth so semi bad news. At this moment i no longer have a n920a but im in the process of getting another one as long as im not being toyed with. If it isnt on rev 4 i will update it to rev 4 just so i can keep testing stuff for u guys. I should have it hopefully within a week or so, but like i said, as long as someone isnt pulling my chain. I do have 4 n920a working motherboards, and i mean
like the whole entire build except i dont have any digitizers and last i checked they were friggin 150$+ @Reverse-anastomosis i remember u saying you wanted one to play with. For science, If either of you two want one, just lemme know cuz i honestly cant do near as much with them as you two. They are just collecting dust in possesion
 

Delgoth

Senior Member
Dec 1, 2010
636
183
@Delgoth so semi bad news. At this moment i no longer have a n920a but im in the process of getting another one as long as im not being toyed with. If it isnt on rev 4 i will update it to rev 4 just so i can keep testing stuff for u guys. I should have it hopefully within a week or so, but like i said, as long as someone isnt pulling my chain. I do have 4 n920a working motherboards, and i mean
like the whole entire build except i dont have any digitizers and last i checked they were friggin 150$+ @Reverse-anastomosis i remember u saying you wanted one to play with. For science, If either of you two want one, just lemme know cuz i honestly cant do near as much with them as you two. They are just collecting dust in possesion

So what happened? And have you done any additional tests/modifications on the SS Flashable Zip I uploaded since the last time you posted? How would update it to Rev4 if it wasn't already on it? I feel like you'd be hard pressed to find one still on Rev4. If you could find a Revision 3 device, you'd be better off for what we are doing in this thread, as as Rev3 device could work with LP & MM builds just the same, only you'd have better access. Rev3 would be prime, it has the most development friendly FW available.

Are you saying you can access the chip and set a Rev4 Build to it then? Rev3 would be better, and I personally could help even more than I'm trying to now for Rev3. I've never tested a Rev4 device myself, I'm only going on the research I've done over the past couple years.

I know someone else in the same boat as you technically too oddly enough. What do you mean by pulling your chain though?

I wonder if, (probably would), if that board would fit inside my G925V shell. It needs a new board, but I have a slightly cracked screen that the techs I know don't want to mess with because they think they'd end up breaking it more taking the screen off. Otherwise it has no dead spot and is in pretty good condition, just has no partition table anymore for the bootloader because I basically overwrote the "sdb" block device and it won't boot anymore.

I'd actually like to get one of those really, PM me and maybe we can discuss this.

You seems to a bit about a bit though, which is what makes me think you could still take my zip and make something of it. Seems like we can boot the system with a custom build.prop, so we actually have a way in it seems. This was unheard of a few years ago, but it was a viable method this whole time apparantly. I wonder it is only coming to light now....
 

4APL1 root

New member
Sep 26, 2020
1
0
Hi I was reading your post about downgrading. I have experienced bootloop or flash failure when trying to flash anything rev 3 with the 4apl1 rooted combo. I have done the nand erase all. I have rooted first with king 4.8.2 root then changed it to SuperSU using terminal emulator method. You can google this root method YouTube or XDA. Anyway now I am at the stage now I have gotten the n920a noble zero ROM here on XDA to boot up but I had to modify it, add libs and a different updater script and updater binary. It booted up over the 4apl1 rooted combo right to the ROM startup page. The problem I have now is NFC has stopped, android process has stopped, soft keyboard has stopped, errors poping up so I cannot enter into the com startup page. I am thinking the apks are incomparable in the ROM or not signed. So this is where I am at now and I dont know what to do next???
 
give me 2 hours i'll be home by the pc to flash on odin again
but yes im 100% sure the rev 2 pb2 eng kernel flashed over the top of PL1,
here is the recovery directory u asked for after a fresh flash of the rev 2 LL eng kernel

sorry its taking me so long, i cant find a site that doesnt cap my download speed but i will have the pb2 stock downloaded in like 50 mins
Check these links out it all works and the phone reboots with supersu root without running any commands
and
 
give me 2 hours i'll be home by the pc to flash on odin again
but yes im 100% sure the rev 2 pb2 eng kernel flashed over the top of PL1,
here is the recovery directory u asked for after a fresh flash of the rev 2 LL eng kernel

sorry its taking me so long, i cant find a site that doesnt cap my download speed but i will have the pb2 stock downloaded in like 50 mins
Check this link
 

Top Liked Posts

  • There are no posts matching your filters.
  • 2
    @Delgoth hey guess what. I got your v1 rom to boot up, in a custom slot btw :p What i did was while in safe strap wipe everything on stock slot except data, then in custom slot make a backup of everything but system and restored everything over the stock slot. i dunno what or why that made it work but it works. Including two screens of the about page
    1
    Hello,

    Any news on the testing?

    Regards,

    Yes, I've updated the OP and added more of a road map for current active development.
    1
    I have successfully built a UART jig and booted to a s-boot console on the n920v. This has been done on a few different devices, so it isn't exactly a new thing, but as far as I can tell it has never been done on any exynos 7420 devices. I am still exploring what is possible, and if anyone has any additional guidance on what to do with this access I'm all eyes/ears! I'll attach the 2 logs that I have so far that I find the most interesting.

    Idea time: could we fry our bootloader somehow and replace it with a more favorable one? Like for the n920g? External SD card boot is possible through the s-boot console I think, but we don't have an external SD.

    I have a kindle fire that uses a bootrom exploit to redirect the loading point for the bootloader so that it will load unsigned firmware/recovery/kernel stored elsewhere on eMMC.

    Booting unsigned firmware/recovery/kernel might be possible through use of the tflash option in heimdall, however again...no external SD. I have been able to flash a TWRP image in heimdall on my n920v, but couldn't get it to boot.

    I am in way over my head, but I have done a lot of reading over the last few weeks. Given the fact that our devices are now no longer being patched, and exploits have continued to be discovered we should be able to figure something out.
    1
    I'll attach the 2 logs that I have so far that I find the most interesting.

    Forgot to attach them.
    1
    @Delgoth So I think that I figured out the problem with the memory dump tool. For some reason it is returning the n920v as a 32Bit device, and should be returning as a 64bit device.

    I got it working-I have attached the working version.

    Edit: You can use this tool to dump memory without the uart jig. You should be able to hold power and vol - to force your device into upload mode. Then connect with a USB cable and dump memory if you are interested for any reason. You can compare the tool to the source, but all I did was replace the the lines in the 32 bit section with the lines from the 64 bit section, so the tool still says it is a 32 bit device, but the tool runs the 64 bit commands. You may need to create a directory wherever you run the tool that is named "memory" for the tool to dump your memory files. I ended up with 13 bin files after running the tool.