[T-Mobile, Samsung Galaxy SIII] DocHoliday77:
Hey everyone! Sorry I haven't been on much the past few days. Barely been able to jump on to even read a little! Anyway, I have more consistent, better tested results to share real quick. I will update the OP with this info as well, probably tomorrow or the next day, depending on life!

First, let me clear up that I was mistaken on two of my earlier claims: 1. SysScope is NOT triggering the flash counter. While it is still related to device modification detection, it is not increasing the counter at each boot.

2. Using a deodexed Rom will NOT trigger the flash counter at each boot.

From what I can tell, they both will contribute to the Status in Settings > About Device, reporting as Modified. I am starting to think this may also have an impact on some of the DRM issues people have been experiencing. I cannot say definitively yet, though.

So after realizing there were a few things I had failed to consider, and noticing that my testing yesterday was netting significantly different results than before, I decided today to start from scratch, with nothing but an unmodded system (except for root of course) and work my way, one change at a time, to a modified, deodexed Rom.

Here is what I've found so far:

Installing custom recovery using Goo/Rom Manger app

, the install will not trip the counter. Rebooting the phone will not trip the counter. But rebooting into custom recovery DOES trip the counter.

Flashing custom recovery via Mobile Odin

(using just the recovery.img), phone will auto reboot into recovery immediately after flash, which will trip the counter. (Judging from other instances, Mobile Odin is not tripping the counter when used this way, its being triggered by the reboot into recovery)

Flashing stock recovery via Mobile Odin

(using just the recovery.img), phone will auto reboot into recovery immediately after flash, but it will NOT trip the counter.

Flashing stock kernel via Mobile Odin (using stock full fw file) did NOT trip counter

Flashing stock kernel via Mobile Odin (using just the boot.img) did NOT trip counter

Flashing stock kernel via Mobile Odin (using flashable .zip file) DOES trip counter

SO...Mobile Odin will flash individual partition images and also from the stock firmware without tripping the counter, but if used with a recovery .zip file, it will trip the counter. Could be helpful to know later....​

Deodexed Roms do not trigger the counter on each boot. However, custom kernels do re-trigger the counter EVERY bootup. If you are using a custom Rom, but keep the pure stock kernel on your phone, it will not trip the counter.

Custom Recoveries will not trigger the counter on each boot. However, any time you boot into the custom recovery, it will trip the counter.

In short, it appears the primary triggers for tripping the flash/binary counter are

Custom Kernels during normal bootup

, and

Custom Recoveries only when booting into Recovery

.

If you use Mobile Odin, flashing either individual partitions, or firmware .tar files will not trip the counter. Mobile Odin will trip the counter

when using it as a custom recovery

and flashing a .zip file.

SysScope, while related to modification detection, is NOT the cause of the counter being tripped.

The counter does not appear to ever go above "1", regardless of how many times you boot up on a custom kernel, or how many times you reboot recovery, or flash a .zip in recovery. It most likely will still increase further by flashing non-official firmware in PC Odin (just like we've become used to with ICS). I will try to test this tomorrow, unless someone else would like to give it a go for me!

Download Mode reports the following on my current setup; Deodexed, CIQ removed, Custom Kernel, TWRP.

Custom Binary Download: Yes (1 Counts)

Current Binary: Custom

System Status: Official

Qualcomm Secureboot: Enable

We CAN still go back to full stock unrooted without a tripped counter using Triangle Away, so those that were worried about that part of it, need not worry. Ive decompiled several apps to try and figure out why some things no longer work. No luck so far, but I am looking. If anyone knows how to convert our .mbn partition files into a raw readable format, please share! I think this would be of great help! Otherwise I guess we can just examine the source code to see if we can find it there.

I will post back with more later. Thanks everyone for all of your input!