Those familiar with TriangleAway by XDA Elite Recognized Developer Chainfire will take comfort in knowing that the app has been updated to add compatibility with the Samsung Galaxy S III and the International Galaxy Note. For those unfamiliar with the app, it does as its name implies by removing the triangle and resetting the flash counter on your device.

Let’s backtrack for a minute and find out exactly why the app had to be updated, and what made this time a little different than before. At the application’s start, the kernel flash counter was relatively easy to take care of. Simply resetting the value would remove the counter. However, with the release of the Galaxy Note, Samsung made things more difficult by hiding the data. And now on the Samsung Galaxy S III, Samsung has made it even more difficult thanks to a background service that searches for the telltale signs of rooting.

According to Chainfire’s development blog:

With the Galaxy S II, Samsung introduced a custom kernel flash counter and custom kernel warning triangle. This is where Triangle Away came in – it reset the flash counter and removed the warning triangle.
On the Galaxy Note, Samsung tried hiding the data once more, so Triangle Away would not work.
On the Galaxy S III (among other new devices), Samsung has gone a step further, and has introduced a background service that runs on your device and checks for things such as a modified /system, apps running with root access, etc.

For the moment, this service does not do anything malicious, but who knows what the future will bring ? Tracking of IMEI’s that have ever ran root, disabling of services, etc ?

Scary, isn’t it? The last line should jump out at you, as it’s not too much of a stretch to think that future revisions of the service could be used as such. And by looking at the update log, you can clearly see the battle between Chainfire and Samsung:

Update 16.02.2012: Users have confirmed TriangleAway works on the I9220 SGNote ICS leak !
Update 13.05.2012: TriangleAway does *not* work on the latest official SGNote ICS firmwares. There will be a fixed version soon, but it has to wait for my Note to return from repairs, else I cannot test it 
Update 04.06.2012: v1.50 should work with the I9220 and N7000 SGNote’s again

Right about now, you may be wondering why exactly Samsung or any other OEM would feel the need to keep tabs on your ORD. One can assume that it has to do with warranty, but is this really a valid reason on Samsung’s part? After all, if the hardware functioned properly, why should an improper firmware flash even have the capacity to damage the hardware?

Once again, according to Chainfire himself:

Custom ROMs, root, bricks, and warranty

I am not sure what the reason is Samsung wants to track all this. My reason for wanting to “break” their tracking is one thing: warranty.

Being able to run the software I want on devices I own without losing hardware warranty should be a right by law. As for as I can see, there’s only two ways you can really break your device with root access:

(1) overclocking to the point where hardware is damaged
(2) flashing nonsense to your bootloader partitions

I’m not sure how to handle (1). I personally never overclock – and I don’t think it’s strange to deny overclockers warranty. Surely this must be preventable in the hardware. Case number (2) however is wholly Samsung’s fault. Adam Outler has shown time and again that these devices are perfectly able to be made unbrickable - so any bootloader brick is IMHO Samsung’s fault. If Adam Outler can prevent the situation with a soldering iron, the original design is broken.

Regardless, hardware should be under warranty – if I have my device rooted or not. Leaked service center documents show that devices should be checked for root, and if present, deny warranty. (This is not just Samsung, all the major OEMs do this.)

That is simply unacceptable. Any OEM following that policy is a bad OEM – in some countries this may even be an unlawful practise (though good luck winning in court). HTC has once refused to replace a defective digitizer on my HTC Diamond (a common hardware issue with this device) due to HSPL being present. They claimed HSPL had irreversibly damaged the mainboard, and the entire innards of the device would have to be replaced. Riiiiight.

Root by itself is not a crime, nor a pointer that a device is broken in any way that should not fall under warranty. But in the eyes of the OEMs it seems we are criminals.

If the purpose of the tracking is related to corporate security and such, I can see why Samsung would want to lock down further. I can certainly understand that, though I don’t necessarily agree.

If this reminds you of the mid-nineties, you are forgiven. As Chainfire writes, there is nothing inherently malicious or criminal in being able to use our own devices as we see fit. Yet, various OEMs employ tactics aimed at preventing us from truly customizing our devices to our hearts’ content for fear of a voided warranty.

If (using Chainfire’s personal example) broken digitizer hardware has absolutely nothing to do with flashed firmware, why is that justification for denying warranty service. For those who tinker with their cars, this is akin to voiding a Powertrain Warranty because you added an aftermarket radio. There is simply no justification—morally anyhow. Luckily for those in the US, the Magnusun-Moss Warranty Act offers a sliver of protection—but good luck trying to take that to court. And in other countries, you may be entirely out of luck.

This then leads to the question of what would be best, both practically and ethically. Chainfire has assessed the situation stating:

And thus we come full circle – if Samsung goes another step further in protecting their custom flash data, will I even attempt to bypass it ? Should I ? A big part of me thinks not.

Those simply looking to absolve their triangle and flash counter for what is possibly the last time can purchase a donation version of the app on Google Play or head to the original release thread for the free version. Those simply looking to learn more on the issue should head over to Chainfire’s development blog post.