There are multiple things at play here. There is definitely mention of eFuses in the bootloader, close to the KNOX related code. That is why I first suspected eFuses may be involved. It could well be KNOX bootloaders use eFuses if available and uses a software counter if not (like the original flash counters). It may of course also be the case that it's indeed just a few bits somewhere that get flipped (possibly inside an encrypted section).
The big difficulty here is that the KNOX counter is only settable once. So it is very difficult to pin down where this value is stored, if even in a user-accessable place, which doesn't need to be the case at all. Remember that on Exynos4 devices it was an engineering mistake that even made us find the counter the first time (and then the cat was out of the bag). Anyway, you'd need an exact flash dump of before and after, then maybe it would be easier to pin down.
The next problem however becomes write protections. One reason I stopped working with Triangle Away on the Note 3, is that certain areas of the flash memory are write protected. These protections are set inside the bootloader (== protected code) and cannot be unset, they cover the sections containing the flash counter data. Even if we knew where the data was stored and how (assuming it's not an eFuse), we'd still have to beat those write protections. These protections were also used in the Exynos S4, which is why there is no Triangle Away for that specific device. I'm not completely sure if all the devices that are getting KNOX support this hardware feature, but I believe so - it's fairly common.
Mind you, I know a theoretical exploit that may beat the write protection, but I have not worked it out in practise (not even attempted), as it'll be lengthy, device model specific, difficult, and probably dangerous. As long as those write protections are there, we can't reset the status, but as long as we don't know where or how the KNOX data is stored, it is of no use trying to crack the write protections. That is, even assuming that data we want is even accessable from kernel and/or userland, which doesn't have to be the case at all.
RIFF boxes and ORT connectors have raw access to the flash, by the way, that's why it would be trivial to do with that equipment if you know where the data is at. Of course, you can also use a RIFF box to downgrade bootloaders due to said access. When we were hacking the original Samsung Galaxy Tab's locked bootloaders that's exactly how we tested things
