[AT&T Samsung Galaxy Note5] Reverse-anastomosis:
I am in a similar frame of mind as you. I love android, and I love learning new things. I started years ago with my asus transformer tf101 and my og kindle fire. It felt like there were no boundaries. There were people unlocking bootloaders, building custom roms, porting Linux mucking around with partitions....it was the wild wild west! I don't know if those talented people are all in industry now, or if things are just that much harder. There were always things to try. Now-it seems like custom android is TWRP, Lineage and magisk. A bootloader unlock comes along every now and then which is fun! I don't know enough to be helpful with new devices, but I figure this these older devices are a good place to start. It would be nice if we had someone with more expertise to weigh in and help steer us in the right direction, or point out what could be a simple fix. I am afraid that those people are busy with newer devices, or tied up in the industry. I think if we are going to get anywhere we will have to do it ourselves. Perhaps we will learn enough along the way to help with newer devices someday.

My current state with the s-boot console research.

I have played with a bunch of the commands, but there is very little information available on how to use them. I don't know Linux/unix or any programming language to punt and figure it out myself, so I am just muddling through.

S-BOOT # printenv
: REBOOT_MODE: 0
: SWITCH_SEL: 3
: DEBUG_LEVEL: 20300
: SUD_MODE: 0
: DN_ERROR: 0
: CHECKSUM: 3
: ODIN_DOWNLOAD: 1
: SALES_CODE: 0
: SECURITY_MODE: 1526595585
: NORMAL_BOOT: 0
: CP_DEBUG_LEVEL: 22015
: USERBOOT_MODE: 0
: DIAG_MODE: 0
: CHARGING_MODE: 48
: INT_RSVD14: 0
: LCD_RES: 0
: CMDLINE: loglevel=7
: BARCODE_INFO: (null)
: KEEP_LOG: (null)

I played with the checksum value and ended up not being able to boot past a screen that printed checksum 5 times. Couldn't get back to the console, couldn't get to recovery. I was able to get into download and reflashed everything.

I have changed the sales code without any apparent effect.

I set diag mode to 1 without any apparent effect

I have no idea what the INT_RSVD14 option is/does, but it looks interesting.

When I issue the command

setenv BOOT_DELAY 3

The console accepts the command and lists the arguments, leading me to believe that it stores the arguments, even if they aren't actually valid. Apparently in earlier versions of the console this was an environmental variable, which is why I tried it. It does not appear to have any effect.

I have not found part 2 of the hex detective blog, however the author(Nitay Artenstein) gave a presentation, where he talks about the actual exploit. I do not have enough low level understanding to fully grasp what he did. Given the fact that he never wrote it up and published his findings leads me to believe that it is the exploit that we need. I posted a link to the video, and I recommend that you give it a watch. I think that it actually is the holy grail for us and I am trying to learn enough to apply it.

What I understand right now: From within the s-boot console arbitrary code can be loaded into memory and executed via arguments to commands, as they are not verified in any way. I need to do more studying on the subject because it is way over my head, but I think it is doable.

It is difficult, because the presentation is to people who understand what he is talking about, and at this point I hear "words, words words" then have to look up everything and try to understand. He talks about the stack, argv and a return pointer.

At this point, I am interested in getting unsigned code running on the device. If we can get unsigned code running early enough we should be able to do something like the amonet exploit does for the kindle fire hd 8.