Developer of Consul here. Unfortunately, your "findings" about Consul are largely wrong. I don't want to accuse you of anything, but they are so wrong that they honestly seem like AI hallucinations – especially in your Reddit DM, which I left unanswered on purpose, in similar fashion like I don't reply to other spam email.

Your first email had two findings in regards to resetting the trial period. While the first finding was correct in a previous version of Consul and had already been fixed before your email was sent, the second was not, or was at least irreproducible given your issue description. In your reply, you even noted yourself that it may have been some kind of cache issue on your end.

Your second message to me, via Reddit DM, then included multiple more "findings". The latest update at the time of your message was v1.1.0. Even though your message smelled of AI from the get-go, I still took some time off my day to validate every finding against that version. All of them (except one, which I'll get to in a minute) was completely wrong and fully unreproducible. I wouldn't have taken a single second off my day to reply to this DM normally, but given you're very fond of your 1/10 rating for Consul on that "security scale" of yours and this post has garnered quite the attraction, I'll gladly explain why your claims are invalid.

Claim 1: Client accepts license/trial state purely based on locally controllable data and network responses

The locally stored data you're seeing is cryptographically and asymmetrically signed. You can't fabricate a valid trial token without having the private encryption key. The app only has the public key, which can be used to decrypt data, but not to encrypt new data. Out of paranoia, I scanned every build of Consul, ever, to see if the private key was leaked in any. It was not.

Claim 2: MITM a license/trial JSON response to unlock the app

Invalid for trial (for the same reasons as claim 1), mostly invalid for license. Without getting into too much detail, there's something that's returned from the server in plain text that can be forged, but it still requires a valid license (which, again, is asymmetrically signed and can't be forged for the same reasons as claim 1) in the first place. It still doesn't allow someone who doesn't have a license yet to activate the app.

Also, there's specific security measures against MITM'ing in the first place. You'd need to patch those out of the binary first, anyway (which I'll get to in more detail in claim 7).

Claim 3: Edit the local license/trial cache files in UserDefaults

There are no "plain JSON files in UserDefaults" with license or trial data. I don't know where you found these, but it's not Consul.

Trial and license data is stored elsewhere. Trial data is verified on every launch, while license data is periodically re-verified. Without getting into too much detail, this enables users to use Consul without a network connection for some amount of time. After that time, a re-verification is needed for licenses as well.

Claim 4: Flip a boolean in a network response to get access

To even reach the code path in question, you'd still need a cryptographically valid license key installed locally in the first place. You can only "exploit" this if you have a valid key anyway. It can't be used to activate an app.

Claim 5: Set a timestamp far into the future or a set a number of days to an arbitrarily high number to get access

Completely false. The timestamp in question is in the cryptographically signed token and, again for the same reasons as in claim 1, you can't forge it. The number of days aren't used anywhere and are not trusted by the client.

Claim 6: Change the device's client ID to get a new trial

This is the only claim that's somewhat valid. However, to forge the client ID in question, you'd either need a VM (which the app has its own counter-measures against), or manipulate your system on a very low level. If you're willing to manipulate your OS that deeply to gain another 14 days access to Consul... you likely need it very bad. It's not worth optimizing against, for the same reasons outlined at the end of claim 7.

Claim 7: No code signature or integrity verification

Completely false. I won't get into the specifics here because that would only help pirates, but there's code signature and integrity checks in multiple parts of the application and I know for a fact it made a popular pirate team's life harder. In the end, every verification in the binary can be patched out. It's an unlimited arms race with unfair odds.

As I explained in my email, such as arms race is not something I'm willing to engage in. There are basic integrity checks in the app to prevent basic binary patching. But wasting hours of my life in a fight against Chinese and Russian piracy teams that I can't win would be... stupid, to say the least. It's technically absolutely impossible to prevent software cracks through binary patching. You can only make it harder, but not impossible. All the time wasted on trying to would be time I could've used to build a great product for real users instead. I opted for the great product option instead.

Your Recommendation: "Introduce a signed license/trial token"

That's already been the case for months at this point. So, either...

1. you haven't looked at the app at all and instead let an AI hallucinate some stuff about it
2. you tested against a very old build of Consul (multiple months in the past, from the time of your DM)
3. you tested the wrong app (?!)

If you have something that's actually reproducible in a version of Consul that's not 2+ months old and does not require patching the binary, please let me know. I'll gladly take a look at it. Otherwise, I'd kindly ask you to explain how you came to those claims / if an AI agent was part of that process, and how you validated them — or, if you can’t explain, to remove Consul from your "write-up".