[AT&T Samsung Galaxy Note5] Delgoth:
Well it is totally dead boot bricked. It used to charge still I think, even though the screen wouldn't turn on or give indication of anything ever.

But after using the multi downloader with the LSI serial drivers to try and restore parts of the sboot back to the emmc, I lost my serial connectivity and I don't think it will charge anymore.

I don't think the tool I used was a real emmc programmer like we've seen for QC EDL Mode. I've seen firehose file for the G925F, but as far as I'm aware only the modems really are straight QC FW, and the only thing in sboot QC is the aboot section of it. Because I thought that sboot was forked from U-Boot, but still uses an aboot for a small portion of the boot process.

Like in newer devices we have something like N950SQU "5ARG2", "5CRK1", and "5DSC1". The digit after the BL revision number, is actually the 'aboot' revision on most Samsung devices. ESPECIALLY on the exynos7420 line. Back then "3BPH4" and "3CPI2" would have meant an upgrade to the aboot on the revision 3 bootloader. "aboot" is still basically what loads our system image and starts the kernel, but it is tucked away deep inside the exynos sboot.bin. The rest of it is essentially HW inits. I think that's why the one (i think malware) root I found needed to use the combo fw to root and talk to the modem, in order to get the map to boot modaco's superboot. YES. I managed, ONE TIME, to get super-boot to boot on my G925v but that person's thread was removed from the forums a long time ago I didn't know what I was looking at, at the time and thought I'd be able to go back to that thread. I can't remember how it did it. I had to downgrade though, flash half a FW, use Realterm to use SendCommand.exe and flash back, then use maintenance boot mode before first boot to enable debugging/connectivity. It was a process in a specific order that probably still applies. Verizon has that boot mode, AT&T removed that feature from their FW though. The Exynos7420 I still think is primarily SW/FW Locks in place. Unless the carrier devices really each have their own version of the 7420 SoC, it's all still the same but with different one way streets to get there from here.

I say all that because the tool I used still worked on my G925V, unless someone special wants to chime in, no one I've ever heard of or seen post anywhere has ever seen firehose loaders specifically for the G925V. The tool I used, literally just needed the LSI Serial Drivers for the Exynos. And the tool was originally built for the Exynos5 platform, not the Exynos7. But it still could read my device and send data to the flash chip. All you needed was to know the hex map of the binary, and I don't own IDA so I couldn't figure it out specifically.

We had the sboot map for a G925F and could repair the level 1, 2, and 3 bootloaders, so we could say for sure we were transmitting data to the correct addresses, but the other carrier variants place the data in different spots in all. That was their game. The chip wasn't untouchable at all, but someone needs to be well versed in hex reading/editing. Because each carrier has the same data at different offsets, figure out the memory map and the things can still be serial flashed.

There are (were?) on the G925v Rev4 & N920A Rev3, many ways to communicate directly with the modem firmware using a serial terminal such as RealTerm from the factory binary. And being that the radio group is basically second only to root, the correct AT commands hold a lot of power to the chip.

This is probably why the Kernel patch for the sboot console breaks the modem when it usurps control of that com port. Because we can still connect directly to the CP via serial.

I really need to get a Note5 or S6Edge again. I just don't know where to find one that hasn't been fully updated. In the last year, the few times I did try to pick up a new testing device, the people for some reason factory reset and fully updated it first, so I didn't want them anymore.

I wish I still had my revision 3 note5. I got it when the PHA update was still the newest thing. For a G925v, I'd suggest PH1 if you can do it. You want PH1 & PI2 (with both CSC's preferably.) for a G925v, because PI2 was an overlay update for the base PH1 system. I used to have the PI2 ODIN FW with both CSC's in it, I accidentally deleted the HOME_CSC thinking it was what kept infecting my device because I modified it. And the FW package I put out with only the carrier CSC is what everyone mirrored. I can't find the HOME_CSC package to the PI2 firmware anymore. But we need it. I think I used VT Studio to actually open it and re-sign it with the same signature, and I think it worked still back then. Because I still have a testkey.pk8 and testkey.x509.pem that I swore at the time I got from/for the PI2 firmware for the G925v that actually worked part way. Because ODIN firmware packages always seem to come with test-keys signed kernels but release-keys signed systems.

I've seen references to PKCS#1, #8 , #11, and #12, in how the certs are done for FW signatures. Starting from HW Boot up to system and its apps (kind of respectively almost). And since the Exynos7420 has reached EOL with no support anymore, I feel it'd be more acceptable to start breaking down how the chip works nowadays. In the newer devices/HW they've moved on to implement more security features besides these. And just yesterday looking through some of the Box Services available it seems that there really are new methods now to really get RW access even to the G925v flash. (G925v Combo is 5.0 and not 5.1.1 too which is weird.)

If I can't get a Note10+ ordered soon, I'm going to get a new S6Edge to being with again. That's where my Note5 journey started. I only moved onto the Note5 because I got a brand new one for $50 after I bricked my S6Edge. All my solid information came from looking at the G925v which is only half applicable to the N920a FW. Because there was a time in the Beginning of the G925v rev4 BL that we couldn't downgrade to an eng kernel because of Build Revision checks. ODIN refused to let me downgrade when I first started working on my device. I even made a thread I thought about it. Because I was able to flash firmware at the time I could have sworn ODIN had refused to flash before. But everywhere I go tells me it would be more expensive to replace my g925 board than it would be to buy a new device because of the broken screen. Everywhere around me still wants like 200-250 bucks to replace the s6edge screen, plus like 40 bucks at least for a motherboard. I could get a new 925v for like 150 max.

EDIT: [MENTION=9533319]Reverse-anastomosis[/MENTION] , [MENTION=9270077]xenomorph318[/MENTION]

That's why I'm still interested in what you can do on your current device, and any playing around you've done on the console. What kind of usage text each command has. Because the Article you linked about the sboot console was never explained on their end and they left out the part detailing the commands left for the unpublished part2. How do the read commands work? Can they actually pull data off the flash, and in how big of chunks? We could use that to form the memory map for the LSI multi-downloader flasher possibly. I still want to do work on the G925v. It is literally my favorite thing Samsung has ever made and is what got me to learn everything I know. (Which isn't always the most or even super low-level). I've only been connecting dots / reasoning it out from the high-level.

I'll admit this is my first foray into trying to make a ROM. I've read a lot about it, know a lot of the process, but never tried out the process myself physically. Just like someone who has read a lot of books on making tiramisu, but has never made it, they are still two separate beasts in their own right. Now I actually have the dev environment setup, and I'm learning the muscle memory on how the tools work.

This is why I have big walls of text in most posts, because I have the solid concepts, but they are still Black Box Systems to me. I'm still looking for the more well-versed people to show me the words actually used to describe the processes. I use the wrong words to describe things sometimes because that's how I reasoned it all out. I'm not necessarily wrong per-se, but when talking to someone who does know what I mean, I kind of sound like I don't know anything at all.

Remember the Exynos7420 was a HUGE thing when it hit the market. It did change the game on the security front. That's when MM hit, and Samsung redesigned a lot of it. But that's where I started my Android Research. I knew noting about anything really from ICS to LP. I went from a Captivate (S1 GB 2.3), to an S3, to a Xoom Stingray, and the xoom only got the ICS rom a month before I got rid of it. I didn't really have anything to do with the dev scene at all until I got my S6Edge and S5 at the same time, I hadn't paid attention to any of the new kinds of dev work required with KK & LP.

It just seems like once TWRP came out and CF left Samsung work because of LP, there were no new methods really invented/discovered. Those can't be the ONLY way to get the things done, but just that those are the only methods fleshed out for everyone. And the old way keep getting tougher and tougher as time goes on as we move further away from the AOSP methods. Even now, people still tout Magisk as basically the only way to root. Is that because it is, or because it is simply the most researched way? See my point? When the systemless root method was put out, literally everyone forgot about system rooting a device, and the information became really hard to find out why/when to use the two different methods. If "systemless root" was the only way to root device on 6.0.1+ then we wouldn't be forced to use the system root method nowadays like we do. We've gone back to it after all the systemless tests have failed. MM was just too short lived to have enough work done I think. And it is hard to get the better devs to go back when they can do so much with the new devices still. MM was still a different type of system though, I get it. But we have methods of dm-verity bypass without the Combo Firmware on N920a Rev4 6.0.1 BL's. Still just need the injection/springboard part.

This thread is here now, so that it isn't just one person making a ROM and just keeping the method behind the scenes because the zip works. I'm more about getting more people to ask more questions and get answers so we can step back towards the open sharing world XDA was built on. The Spirit of Open Information. I know it takes us hobbyist a lot of hard work in our free time unpaid. But I've never asked for donations, and always try to ask questions in threads themselves. The more others can do the less any one single person has to do and maintain. I've never claimed ownership of anything really done in any of my two Note5 threads except the design of the GHR Project itself and how it went its approach. Everything was is normally built/written by others. All I did was put two and two together, or get people talking to each other.

I don't mind taking the time to write out what I know and have considered at all. I'll put it all there with no restrictions. I just wish someone would grace me with their more low-level knowledge to help me do it myself or finish what others left to be finished. I know google is a thing, and I've searched a lot. But this particular generation of Samsung Phones is really what started their break-away from AOSP altogether. One can search, but articles are still focused on AOSP methodology. The order of operations are different. And I never owned an F Variant to do test on that board's fw, and people just like to simply patch the boot.img for root instead of going the long/hard way around. It is still really hard to get people to spill the beans man.

I might have big shoes to fill with my thread title and all, but I'm really not trying to do it all myself or take credit for it all. I know there is a method and we are close. But this device has always been a little different. But I still want this to work and I'm not sure what is wrong with the zip. It could still either be my rom zip, or the combo fw not letting it all happen. I just can't test it myself. I'm going to have to similar tests on my Note8 to see how to make it work and then backport the same method as much as possible. That's the only way I can right now and it might not even be the same really considering 5.1 vs 7.1.

I'm going to need more time to develop the zip with my decent knowledge yet limited experience to see what I'm missing. It seems just like a tiny detail somewhere. Anyone around made working rom zips for an exynos7420 device that could chime in on why my rom zip wouldn't work?

EDIT2: I just noticed that at least on Android 9.0, the device will take the ODIN Firmware and actually sign it after the flash. Because I can open the 5DSC1 FW for the N950U, and the ramdisk specifies test-keys kernel. But after flashing and booting up fully, the kernel is now signed with release-keys. MEANING, somewhere after ODIN is done flashing, the signature is called up and used to resign the boot.img. That didn't use to happen though. It would just stay test-keys signed. This can't just be a Cert VPN thing can it? Isn't the update binary specific to the device and/or its build in a few ways? And does this mean the signature is tied to BL revision and not simply the aboot? This is something I just noticed. I wonder if it were possible to do this before on older build but the carriers never did it....Hmm. I'm told the fota tools could work if we only had some kind of master script to call them all up in the correct order with the proper arguments. Well it seems that somewhere on the device itself, this master script is either downloaded or generated during a FW update. That should mean, we should have an avenue available to watch this happen.