I don't understand why there is discussion of shuttle functions. I used this app every day until it was shut down, mainly the web version since it came out (and even the .eu site when I had issues during high volume during December). Were these functions perhaps in beta versions of the desktop app? I never saw shuttles on the North American version or the EU web version. Maybe it was only there briefly before being brought down due to a bug being found?
Fast forward a bit to the part that describes the result of the shuttle part as well as shows a scoring chart from the last event of a certain player.
Ok, I just watched a bit, and then the chart.
The shuttle code looks ugly, and that's just it. And as far as I know, it was never operational/available to the users. Why did he use a loop with the 21 iterations? I don't know, there is a chance that he just copy pasted code from dilemmas and that's just it.
The chart... Says nothing. Some player made a ton of points, wich could be by a lot of legit means in game (as the guy in the video says, it proves nothing). It's exactly the same situation every event when people start asking how the guys in the top manage to do points to quickly (tons of boosts, tons of dillithium speeding up, using requisition shuttles, etc). The only way to actually prove that code does what they suspect, is running it, which I don't see.
I really wish someone with good experience in JS could step in, 'cause I see a lot of "I don't know but it looks" and some of the assumptions seems to be flat wrong.
And I would love an answer to the question, if the code in dilemmas was there since July, and it worked getting multiple rewards (not because of changes in 7.0.9, but since July at least), how is it that no one noticed until last week? No one used the random choice button until then? Everyone who used kept the secret? (out of, how many users of the app?)
I really want an answer there, 'cause that code doesn't require any trickery, it does the 21 calls just by using it as intended (one click/tap). It's impossible that it was there just to be used by one or two people. Either IamPicard was a cheating tool for half a year, or the code was stupid but inoffensive (relying on server behaviour that is the way it's working now) and it only became an issue due to server changes in 7.0.9.
I used the random choice many times, especially when I knew I had to choose among useless greens. I've never received multiple rewards.
That was an awesome Youtube video by Frank and Roonis and all the supporters that put work into this research. Thank you for putting this together. I must say I really appreciate getting the whole story, or at least as much as can possibly be expected.
I am still going to miss the good parts of the IAP tool, since the crew/inventory sorting and voyage crew suggestions were invaluable to me, but I didn't realize how much of an impact it was having, especially the potential on events. Multi-tapping is one thing, but the apparent maliciousness behind the code is inexcusable. I won't condemn someone without giving the chance to explain, but I will no longer be supporting a We Are Picard tag.
I see the term "public API" used a lot. Where was it documented? Being a software developer for 20+ years, public APIs are usually documented toolkits for public use. I am not aware of any documentation provided by DB detailing how to call their game API.
If you buy some flatpack from Ikea, and it has no instructions, is it no longer flatpack?
I've been developing software for 20 years as well, and writing web-based APIs before they were called that, chucking out comma or pipe delimited values as neither XML nor JSON were a thing back in the very early 2000s.
A public API is one that allows third parties to interact with it without authenticating the third party, or any collection of endpoints that don't authorize access from said third party.
Third party authentication is easy enough - from using n items of static data, a timestamp and a shared secret encrypted in a header, all the way to certificate-based calls. From which you can create authorize claims to secure individual endpoints.
Now, it could be that DB didn't intend the API to be public, however it is.
NB - the use of user authentication tokens isn't the same thing, as that is account access, not API access.
If you didn't get a chance to watch the live Twitch stream yesterday, please take the time to watch the Youtube video about IAmPicard and its creator so that we don't get another 11 pages of mostly nonsensical and erroneous information.
Is there a breakdown of the video anywhere? I prefer reading to watching, as I can keep referring to bits then rather than rewinding/fast forwarding.
I'd definitely be curious if IAP exploited any bugs. Might be an idea for DB to do a bug bounty too.
I'd be very surprised if DB if worked along lines of defensive programming, or even bother with idempotence tokens for POST/PUT/PATCH requests, so imagine the API is as buggy has the client can be.
Following Shan’s update and other bits of information that have come to light, I am no longer supporting wearing I Am Picard tags.
I also watched the Frank and Roonis analysis. It gives an outline of most of the story if you want to be brought up to speed.
It is missing or omitting some bits of information and facts that may paint a slightly different picture, for example, why did the IAmPicard developer remove the random choice dilemma option but not take the site down until several hours later? I’m just not quite so convinced about what might have been put in the tool intentionally and if tekmanro is fully to blame.
But I think that just goes to show that as time goes on it gets clearer that none of us know enough to work it all out properly. A little learning is a dangerous thing and we should be careful not to assume anything.
Do I still believe tekmanro was threatened and/or doxxed? Judging by some of the comments I’ve seen on the forums and elsewhere, yes. Even if he was fully responsible for putting the exploits into the tool, I can still believe that part of his goodbye statement.
I think DB should publically retract all previous recommendations, endorsements and approvals of the tool. Removing the pinned thread and Shan’s latest update does go someway on this, but it’s still a little murky as to whether players are allowed to use the tool on a computer as long as they don’t activate any of the exploits or modify it to do so. And hopefully they can close the holes in the games security quickly.
Maybe DB could also cheer us all up a little by committing to bring some of the quality of life features over to the game?
As stated in the video, my coding experience is below novice with mainly just an understanding of concepts.
I had several experienced folks look at it, and walk me through it, having other fleets have their in house folks inspect as well.
It certainly looks like there is another piece that really makes it ramp up that isnt present in the desktop app but was in the web version. The consensus though was that the script itself is 100% written to allow repetition, there is no other apparent reason to loop to allow 20 promises on one shuttle claim.
Ok, after reviewing the code, with my limited knowledge, I believe:
1 - The code featured in the video ("_chooseDilemma" function) is called with one click of the option "Random choice", as well as when you make the choice yourself
2 - When you choose, the index parameter is your choice
3 - When "Random" is selected, the third parameter is the negative amount of choices in the dilemma (if there is 2 choices, index is -2, if there are 3 choices, index is -3)
4 - In that scenario, the for loop creates an array of 21 "promises", divided almost equally among the possible choices (if there 2 choices, 10 of those is one choice, 11 is the other choice)
5 - all 21 are invoked (call to "resolveDilemma"), errors are ignored
6 - An aditional call to "resolveDilemma" is made, I presume is invalid 'cause it uses the original index passed as the choice, wich is a negative number.
Conclusion:
The 21 calls to resolve the dilemma happen EVERY TIME the user selects random, using the app as intended. No multi taps, or anything weird necessary. Just one click.
If this code is in the app since a long time ago (since July?), and the problem was detected this week, the logical conclusion is that since then, the server only accepted the first call, and rejected the others (remember errors are ignored), and the update to 7.0.9 removed that restriction, resulting in the bug.
This would explain why the developer wrote that code: The developer knew this, and when choosing "Random", the app creates 21 requests to solve, with equal amounts of choices,when only one can win (wich one depends of network traffic I suppose), this "race" simulates a random "winner". The develper used this to pick a random choice instead of using a RNG.
Also, I believe the restriction is back in the server, I'll test it as soon as possible.
UPDATE: I just tested the code. Only one set of rewards.
Thank you for the clear explanation of your interpretation. I’ve little knowledge of programming but I do know that sometimes getting a random number can be more difficult than it might sound.
I’d suggest that people be careful about accepting explanations of how a particular part of code works.
While the above explanation makes sense to me (and no offence to @Kanon meant at all), it could still be incorrect as far as I know. People shouldn’t build up big claims of what may or may not be exploiting/cheating or of intention, based just on someone else’s interpretation.
It will be interesting to see if any of those people who blasted this community for poor treatment of Tekman come back and admit they may have been hasty in making such a critical judgement.
Let's be clear here: he would absolutely be in the wrong if there was malicious intent, but so would anyone who doxxed him. No one deserves that, and two wrongs do not make a right.
So far i haven t seen any proof at all that he was doxxed or threatened or anything. Just because someone claims stuff, it doesn t mean it has to be true.
And considering the hole situation and new reveals about what the app was capable and what was in the code, his good bye message(playing the innocent victim that has nothing done wrong) feels really fishy to me(already did before, but doesn t matter).
But thats just my personal opinion, and if he really was doxxed or threatened by others, thats of course not ok as well, regardless what he has done with his cheat App.
First at all thanks to Roonis and Frank, your video was very informative.
In the end nobody knows 100% what has happened but I am sure that DB did the right thing with to take the sticky down and it is good that the dev of the tool took the tool down.
Interesting to see that a lot of people, who were screaming loudest in the start, are now very quiet, understandable.......
I hope that DB can close the holes, but I am afraid that some people out there are still cheating and will ever do.
I am still a proponent of the tool, and it earliest functions. If DB released their own version of it, I would switch to that in a heart beat.
My wallet remains closed until DB makes a statement.
I really appreciate Frank and Roonis taking the time to research and share
Per @Kanon ‘s line of thinking, I agree it is dangerous to read intent into a snippet of code that is not fully understood. The loop in question jumped out at me as odd even before they started narrating it in the podcast, but odd in a what does that do sort of way, not a sinister one. There are other Occam’s Razors than “a bit of code I don’t understand must be an intentional hack”. Such as, hypothetically, “the dang server doesn’t respond as its supposed to all the time and must be hammered until it does.” I have no evidence for that, and didn’t review the whole code base, and am not offering it as an alternative, but coders having to kludge in fixes is not unheard of and kludges usually don’t make walking around sense unless documented. Just, be really careful about ascribing intent. A third Occams Razor would say that putting a hack into the public domain for all to see is a dumb idea. And a huge unanswered question is why all IAP users weren’t getting multiple rewards all the time, or why those that stumbled in via multi tap didnt always get multiple, or 21, rewards. That for loop is very deterministic. My outcome: I take the second half of the podcast with a grain of salt w.r.t. implications of malintent, and I really don’t care, because:
the intent argument is obscuring the much more important and, I think, irrefutable point made in the first half of their podcast, which is that allowing more than read only access was a slippery slope that created a vulnerability, or rather, exposed a built in vulnerability to further exploit. Days ago I thought the slippery slope argument was unnecessary hand wringing; I was wrong and I appreciate Frank and Roonis for helping me understand why I was wrong. I really don’t care who the bad people were. In-app gameplay, rather than in-app read only crew/item management, was a step too far, but not for the reason that it gave good faith users some microscopic advantage at hunting for lottery tickets in gauntlet or whatnot, but because it amplified a risk of exploit. That risk dwarfs all the angels dancing on a head of a pin debates, IMHO.
If you didn't get a chance to watch the live Twitch stream yesterday, please take the time to watch the Youtube video about IAmPicard and its creator so that we don't get another 11 pages of mostly nonsensical and erroneous information.
Is there a breakdown of the video anywhere? I prefer reading to watching, as I can keep referring to bits then rather than rewinding/fast forwarding.
I'd definitely be curious if IAP exploited any bugs. Might be an idea for DB to do a bug bounty too.
I'd be very surprised if DB if worked along lines of defensive programming, or even bother with idempotence tokens for POST/PUT/PATCH requests, so imagine the API is as buggy has the client can be.
The video is basically a portion about the function that handles the resolution of dilemmas in IamPicard ("_chooseDilemma"), and a interpretation (that I don't agree with) that is intended as malicious multitapper (and that is activated by the user by multitapping, wich I'm 100% sure is incorrect)
Then, a similar code in the shuttles section, regarding claiming shuttles, with similar conclusions. And a chart showing a regular player in an event, getting points in constant amounts, and a top player, getting a lot of points suddenly (this is not impossible, there are legit in game ways of doing it, it is acknoledged on the video but it still is show as "suspicious")
And then there are a lot of chats captures that I didn't really paid attention. If I recall, it was all people talking about IamPicard, asking the author via PM about the code, with no answarers.
The "exploit" in question was programmed, in the IamPicard app, in July, for a bug in the server that (observation sugests) didn't exist until last week, and don't exists anymore. That's a big hole in the "the app was created to cheat" theory.
As stated in the video, my coding experience is below novice with mainly just an understanding of concepts.
I had several experienced folks look at it, and walk me through it, having other fleets have their in house folks inspect as well.
It certainly looks like there is another piece that really makes it ramp up that isnt present in the desktop app but was in the web version. The consensus though was that the script itself is 100% written to allow repetition, there is no other apparent reason to loop to allow 20 promises on one shuttle claim.
Ok, after reviewing the code, with my limited knowledge, I believe:
1 - The code featured in the video ("_chooseDilemma" function) is called with one click of the option "Random choice", as well as when you make the choice yourself
2 - When you choose, the index parameter is your choice
3 - When "Random" is selected, the third parameter is the negative amount of choices in the dilemma (if there is 2 choices, index is -2, if there are 3 choices, index is -3)
4 - In that scenario, the for loop creates an array of 21 "promises", divided almost equally among the possible choices (if there 2 choices, 10 of those is one choice, 11 is the other choice)
5 - all 21 are invoked (call to "resolveDilemma"), errors are ignored
6 - An aditional call to "resolveDilemma" is made, I presume is invalid 'cause it uses the original index passed as the choice, wich is a negative number.
Conclusion:
The 21 calls to resolve the dilemma happen EVERY TIME the user selects random, using the app as intended. No multi taps, or anything weird necessary. Just one click.
If this code is in the app since a long time ago (since July?), and the problem was detected this week, the logical conclusion is that since then, the server only accepted the first call, and rejected the others (remember errors are ignored), and the update to 7.0.9 removed that restriction, resulting in the bug.
This would explain why the developer wrote that code: The developer knew this, and when choosing "Random", the app creates 21 requests to solve, with equal amounts of choices,when only one can win (wich one depends of network traffic I suppose), this "race" simulates a random "winner". The develper used this to pick a random choice instead of using a RNG.
Also, I believe the restriction is back in the server, I'll test it as soon as possible.
UPDATE: I just tested the code. Only one set of rewards.
Thank you for the clear explanation of your interpretation. I’ve little knowledge of programming but I do know that sometimes getting a random number can be more difficult than it might sound.
I’d suggest that people be careful about accepting explanations of how a particular part of code works.
While the above explanation makes sense to me (and no offence to @Kanon meant at all), it could still be incorrect as far as I know. People shouldn’t build up big claims of what may or may not be exploiting/cheating or of intention, based just on someone else’s interpretation.
Thanks, I tried to break it down as much as possible so people can see how I got to what I believe it happened, can make their or conclusions, or challenge mine.
I would love if someone with more experience (mine is almost null) in JS/Angular/Vue/Npm/whatever it was used, and server-client architecture could shed some light about this (My question to an expert would be "is there a way, as invoked via the random choice in the UI, that the code doesn't call multiple time to the server, thus it should have been giving multiple rewards since July if the server didn't change its behaviour?")
I really appreciate Frank and Roonis taking the time to research and share
Per @Kanon ‘s line of thinking, I agree it is dangerous to read intent into a snippet of code that is not fully understood. The loop in question jumped out at me as odd even before they started narrating it in the podcast, but odd in a what does that do sort of way, not a sinister one. There are other Occam’s Razors than “a bit of code I don’t understand must be an intentional hack”. Such as, hypothetically, “the dang server doesn’t respond as its supposed to all the time and must be hammered until it does.” I have no evidence for that, and didn’t review the whole code base, and am not offering it as an alternative, but coders having to kludge in fixes is not unheard of and kludges usually don’t make walking around sense unless documented. Just, be really careful about ascribing intent. A third Occams Razor would say that putting a hack into the public domain for all to see is a dumb idea. And a huge unanswered question is why all IAP users weren’t getting multiple rewards all the time, or why those that stumbled in via multi tap didnt always get multiple, or 21, rewards. That for loop is very deterministic. My outcome: I take the second half of the podcast with a grain of salt w.r.t. implications of malintent, and I really don’t care, because:
the intent argument is obscuring the much more important and, I think, irrefutable point made in the first half of their podcast, which is that allowing more than read only access was a slippery slope that created a vulnerability, or rather, exposed a built in vulnerability to further exploit. Days ago I thought the slippery slope argument was unnecessary hand wringing; I was wrong and I appreciate Frank and Roonis for helping me understand why I was wrong. I really don’t care who the bad people were. In-app gameplay, rather than in-app read only crew/item management, was a step too far, but not for the reason that it gave good faith users some microscopic advantage at hunting for lottery tickets in gauntlet or whatnot, but because it amplified a risk of exploit. That risk dwarfs all the angels dancing on a head of a pin debates, IMHO.
The problem with 3 is that this is not A public API, is THE public API. To remove all "write access" methods would break the game (it would make the game read only was well). The problem is that DB made the server calls available to third party apps. It should have secured the client (the game) - server communication, and provide a different way (a true public, documented API) to access it, to tone down efforts to break that security. God only knows what else is available to do on the server that the IamPicard developer didn't allow (I'm 100% sure with very little effort that he could have made a tool that solves entire space battles with the click of a button)
There's also a piece about the suspiciousness of developer choosing a certain point in time to finally opt out.
Since I don't know when to shut up, allow me to share a personal anecdote which leaves me open to alternate interpretations of what to make of that snippet:
Several years ago, I started a project to translate all of the historical genealogical records for my family's European town of origin, and run the logic of assembling them into a publicly available, fully integrated tree/genealogy of the entire town. I did this (a) because it was cool and I was passionate, and (b) because I wanted to support the community of descendants in finding their roots
As a sidebar, the market value of this resource in monetized genealogist research time was somewhere between $500K-$1M, but I never once considered charging for it, on principle
The research part of that project, for me, was very much equivalent I think to the coding challenge part for Tekman. Fun, challenging, beneficial to the community and skill developing. Quad-fecta of great hobby attributes.
What I did not anticipate was the exponentially increasing rate of "customer support" that would balloon as the database grew.
At a certain point, it began to eclipse the rest of my life. It was becoming more than a second job. If that sounds familiar, it's exactly the commentary Tekman shared weeks or months ago when the Patreon banner went up. At the equivalent point in my project, I was seriously considering cost/benefit/impact and whether to continue. If I take his comments at face value, I very much "get it". I soldiered on, but was spending more time on interacting with people, not all of them nice, than completing the project.
Along the way, I would occasionally get nastygrams from people scolding me for not documenting my work. Which was a real treat, since every record I translated had citations added in the tree, they just didn't know the hosting genealogy service well enough to look in the right place to find them. Lesson learned: people passionate about their hobby, especially amateurs, can be real pieces of work, especially in an online environment that doesn't encourage civility. Even though infrequent, every nastygram definitely chipped away at the reserve of internal fortitude it took to keep soldiering through the project. Some people have excess reserves of entitlement and righteousness, and your dermal layers have to regenerate faster than those peoples' appearance in your ever growing support base to want to keep going.
As a rough estimate, this town has several million descendants, and if 1-2% of them are actively doing genealogy research, that's not dissimilar to the number of STT players. I believe there is a built in limit to the volume of "support" one person can humanly do in a volunteer effort, without help, before it eats their life.
At a certain point, the tech support time : IRL time ratio simply got to the point where I had to opt out completely. I walked away. The genealogy going back to 1600 or so is about 85% complete, which will have to do. I have the satisfaction of knowing I created something that didn't exist before and helped/is helping alot of people, but now they're on their own.
Now: if, around the time I was on the cusp of opting out, a subset of these people suddenly came forward and accused me of intentionally corrupting data, or paving the way towards future profiteering or some such, I GUARANTEE it would have hastened my exit. It wouldn't have mattered if the accusation came from a highly respected genealogist/Admiral, and was made in a thinly veiled rather than direct fashion. I can easily see where my reaction would have been, "y'know what, that's it. I'm over it. I tried. Last Straw. I hope you enjoyed all the stuff you got for free, feel free to leverage anything I've done already using your own effort, but you're on your own now."
So, projecting my own experiences, I would be very, very, very, very cautious about spotting black helicopters flying around the developer's opt-out timing. Walk a mile. Could it have been malintent and CYA? Sure. Could it also have been other factors. YES. I'm reserving judgment.
You guys are also missing the fact there were two web iampicard urls and that as far as I know the voyage multitap exploit reports were in the lesser known beta.iampicard.com one not www.iampicard.com most people used.
You guys are also missing the fact there were two web iampicard urls and that as far as I know the voyage multitap exploit reports were in the lesser known beta.iampicard.com one not www.iampicard.com most people used.
There was also eu.iampicard.com which was setup to offer better performance for European players.
I see the term "public API" used a lot. Where was it documented? Being a software developer for 20+ years, public APIs are usually documented toolkits for public use. I am not aware of any documentation provided by DB detailing how to call their game API.
If you buy some flatpack from Ikea, and it has no instructions, is it no longer flatpack?
I've been developing software for 20 years as well, and writing web-based APIs before they were called that, chucking out comma or pipe delimited values as neither XML nor JSON were a thing back in the very early 2000s.
A public API is one that allows third parties to interact with it without authenticating the third party, or any collection of endpoints that don't authorize access from said third party.
Third party authentication is easy enough - from using n items of static data, a timestamp and a shared secret encrypted in a header, all the way to certificate-based calls. From which you can create authorize claims to secure individual endpoints.
Now, it could be that DB didn't intend the API to be public, however it is.
NB - the use of user authentication tokens isn't the same thing, as that is account access, not API access.
Even though the API is public facing, no where did DB state is was for public use. My college has an API exposed to the internet for use by 3rd party integration services. It is exposed to the public, but it is not a public API. There is a difference.
You guys are also missing the fact there were two web iampicard urls and that as far as I know the voyage multitap exploit reports were in the lesser known beta.iampicard.com one not www.iampicard.com most people used.
If that is correct, it makes all analisys of the code in question, useless. That function with the for loop, wich is the closest thing to evidence, is inconsequential as it is part of the main app since July. That is, until there are reports that the bug ocurred also on the main app. It would explain the behaviour though, and prove that the initial analysis (the video) doesn't understand what it does and its intent.
There's also a piece about the suspiciousness of developer choosing a certain point in time to finally opt out.
Since I don't know when to shut up, allow me to share a personal anecdote...
<snipped for space>
So, projecting my own experiences, I would be very, very, very, very cautious about spotting black helicopters flying around the developer's opt-out timing. Walk a mile. Could it have been malintent and CYA? Sure. Could it also have been other factors. YES. I'm reserving judgment.
Thanks for that, 5Q. And for your previous post, which stated in part:
I agree it is dangerous to read intent into a snippet of code that is not fully understood. The loop in question jumped out at me as odd even before they started narrating it in the podcast, but odd in a what does that do sort of way, not a sinister one. There are other Occam’s Razors than “a bit of code I don’t understand must be an intentional hack”. Such as, hypothetically, “the dang server doesn’t respond as its supposed to all the time and must be hammered until it does.” I have no evidence for that, and didn’t review the whole code base, and am not offering it as an alternative, but coders having to kludge in fixes is not unheard of and kludges usually don’t make walking around sense unless documented. Just, be really careful about ascribing intent. A third Occams Razor would say that putting a hack into the public domain for all to see is a dumb idea.
There's been just as much (if not more... and more precarious) speculation going on recently from certain people who believe they have "all the facts" as there was from many of us who weren't initially aware of some of those additional facts. The only thing we know for sure are that the code could potentially be used for some pretty severe exploits — exploits which only a small percentage of the tool's users took advantage of, or were even aware of, but which still were obviously problematic.
It's actually pointless to publicly speculate about the intentions of the author of the tool at this juncture. It does nothing but impugn someone based on suppositions — and besides that, it does not move us forward at all. I agree that there is still value in certain parts of what was created, and that proceeding in a manner which abides more clearly by rules that DB can easily live with is the most prudent and desirable course of action. However, any public statements accusing the author of nefarious intent are just reckless and spiteful. Let's focus on the future here, not the past, yeah?
Could you please continue the petty bickering? I find it most intriguing. ~ Data, ST:TNG "Haven"
They use a web service that doesn't authenticate the client and doesn't encrypt the data. It will take actual programming on DB's part to fix the API. There is no other way to prevent similar exploits.
@Data1001 agree completely. And to be clear, i’m not trying to throw Roomis and Frank under the bus by saying that’s what they were trying to do. I take their stated intent of researching and providing facts for the community good at face value, because I nor anyone else I know has a +10 on my Remote Mind Meld roll. Somewhere on the road from stated intent to execution to my perception, I was left with a sense that that could be implied, but that’s on me and I wouldn’t assume or impugn intent, because I want to live in a world where folks like them put the time and energy into creating things for the greater good, and questioning intent greatly inhibits the desire to volunteer.
Data1001 agree completely. And to be clear, i’m not trying to throw Roomis and Frank under the bus by saying that’s what they were trying to do. I take their stated intent of researching and providing facts for the community good at face value, because I nor anyone else I know has a +10 on my Remote Mind Meld roll.
Understood — and you'll forgive me if it sounded like I was putting words in your mouth. My words are my own, even though occasionally they have to share mouth space with the foot I've also put in there.
Could you please continue the petty bickering? I find it most intriguing. ~ Data, ST:TNG "Haven"
You might change that view when the full extent of the exploits become apparent.
Double taps are possible even now in the game. The main problem remains - DB is unable to fix flaws and not interested in giving the customers what one man did for free.
May I remind everyone that the Star TREK licence expires next year ?
So, you’re saying it’s a good time stop spending money then. Good info to have.
It expires every year with the option to renew another year. I don’t see them giving up this license when it’s the only game they have and their only source of revenue
I've read the comments, participated in the debates, and for 2+ days I've subconsciously run ALL of this material through an empathy filter in my brain, and while my opinion of the AIP app has not changed, I now believe I understand WHY those of you who are/were big fans loved it so much, and WHY you now are feeling like you've been punched in the gut.
Here was my epiphany, and I have @5000 Quatloos primarily to thank for this: I read everything 5Q writes, and if there was one theme to all of them, it is that 5Q is methodical, detailed, organized, and has a compulsion to achieve optimization. To people like 5Q, IAP was not simply an app, it was a life preserver.
I can send out a voyage, spend a few seconds crunching the numbers roughly in my head, hit send, and generally feel good about my choice, so I was never really going to feel the true value of the IAP tool, but for people like 5Q, it allowed you to save yourselves from yourselves, because I now understand that you simply cannot turn off that need to make sure you are always hitting maximum efficiency/value.
On that level, I am very sorry for you guys. If I can be of service, please do not hesitate to reach out to me and I will do what I can to assist you
Well, I think you have helped me to an epiphany as well! What you have written describes me very accurately, and while I have been neglecting my gameplay of late (due to real-world time constraints) I have just been gearing up to get back into it a bit more... just to come back and find this rather sad situation.
I don't know if I will continue. Right now, it just feels like a mountain to climb. I have spreadsheets, but they're very much out of date now, and manually updating them (and then keeping them updated) would be a chore. Combine that with how very time-consuming the events have felt like lately, and... I dunno. The effort-reward ratio just seems off. Could I learn to play more casually instead, and switch off that need to "always hit maximum efficiency", as you put it? I just don't know about that either. Some introspection will be required.
Half of me wants to just condemn my time (and money) spent on this game to the trashcan of lessons learnt, and resolve to:
- avoid "freemium" games
- avoid any games with in-app purchases for anything other than expanded content
- avoid any games that require me to show up during a specific time slot in order to remain competitive.
The other half of me feels a bit nostalgic about the crew complement I've built up and can't quite let it go like that. But then I am reminded of two things:
1. DB is adding several new crew every single week. I would always be playing catch-up, and always be tempted to use real money to save on real time. But both are too valuable to waste.
2. The saying: “Don’t cling to a mistake just because you spent a lot of time making it.”
To be clear, I never used the "Crew Management" app to do anything that I couldn't do without it. (I am still not aware of any way that I could have, either, short of adapting the code.) The only advantage it ever gave me - fair or not, is your call - was by saving me time. And even with that help, I still haven't enough time lately to play competitively.
This might be it for me, guys. If this does turn out to be my last post ever on these forums, please know that most of you have been absolutely awesome. Many times it was only the community (and my ex-fleet, in particular) that kept me playing. LLAP!
Whelp, we're not going to get too involved here. Just suffice it to say it's too bad we've let a couple of self-righteous people with no understanding of programming completely reframe things for their own self interest using histrionics and selective snippets, all the while assaulting others and proving such assaults that they "denounce" have taken place.
Comments
I used the random choice many times, especially when I knew I had to choose among useless greens. I've never received multiple rewards.
I am still going to miss the good parts of the IAP tool, since the crew/inventory sorting and voyage crew suggestions were invaluable to me, but I didn't realize how much of an impact it was having, especially the potential on events. Multi-tapping is one thing, but the apparent maliciousness behind the code is inexcusable. I won't condemn someone without giving the chance to explain, but I will no longer be supporting a We Are Picard tag.
If you buy some flatpack from Ikea, and it has no instructions, is it no longer flatpack?
I've been developing software for 20 years as well, and writing web-based APIs before they were called that, chucking out comma or pipe delimited values as neither XML nor JSON were a thing back in the very early 2000s.
A public API is one that allows third parties to interact with it without authenticating the third party, or any collection of endpoints that don't authorize access from said third party.
Third party authentication is easy enough - from using n items of static data, a timestamp and a shared secret encrypted in a header, all the way to certificate-based calls. From which you can create authorize claims to secure individual endpoints.
Now, it could be that DB didn't intend the API to be public, however it is.
NB - the use of user authentication tokens isn't the same thing, as that is account access, not API access.
Is there a breakdown of the video anywhere? I prefer reading to watching, as I can keep referring to bits then rather than rewinding/fast forwarding.
I'd definitely be curious if IAP exploited any bugs. Might be an idea for DB to do a bug bounty too.
I'd be very surprised if DB if worked along lines of defensive programming, or even bother with idempotence tokens for POST/PUT/PATCH requests, so imagine the API is as buggy has the client can be.
I also watched the Frank and Roonis analysis. It gives an outline of most of the story if you want to be brought up to speed.
It is missing or omitting some bits of information and facts that may paint a slightly different picture, for example, why did the IAmPicard developer remove the random choice dilemma option but not take the site down until several hours later? I’m just not quite so convinced about what might have been put in the tool intentionally and if tekmanro is fully to blame.
But I think that just goes to show that as time goes on it gets clearer that none of us know enough to work it all out properly. A little learning is a dangerous thing and we should be careful not to assume anything.
Do I still believe tekmanro was threatened and/or doxxed? Judging by some of the comments I’ve seen on the forums and elsewhere, yes. Even if he was fully responsible for putting the exploits into the tool, I can still believe that part of his goodbye statement.
I think DB should publically retract all previous recommendations, endorsements and approvals of the tool. Removing the pinned thread and Shan’s latest update does go someway on this, but it’s still a little murky as to whether players are allowed to use the tool on a computer as long as they don’t activate any of the exploits or modify it to do so. And hopefully they can close the holes in the games security quickly.
Maybe DB could also cheer us all up a little by committing to bring some of the quality of life features over to the game?
Thank you for the clear explanation of your interpretation. I’ve little knowledge of programming but I do know that sometimes getting a random number can be more difficult than it might sound.
I’d suggest that people be careful about accepting explanations of how a particular part of code works.
While the above explanation makes sense to me (and no offence to @Kanon meant at all), it could still be incorrect as far as I know. People shouldn’t build up big claims of what may or may not be exploiting/cheating or of intention, based just on someone else’s interpretation.
So far i haven t seen any proof at all that he was doxxed or threatened or anything. Just because someone claims stuff, it doesn t mean it has to be true.
And considering the hole situation and new reveals about what the app was capable and what was in the code, his good bye message(playing the innocent victim that has nothing done wrong) feels really fishy to me(already did before, but doesn t matter).
But thats just my personal opinion, and if he really was doxxed or threatened by others, thats of course not ok as well, regardless what he has done with his cheat App.
In the end nobody knows 100% what has happened but I am sure that DB did the right thing with to take the sticky down and it is good that the dev of the tool took the tool down.
Interesting to see that a lot of people, who were screaming loudest in the start, are now very quiet, understandable.......
I hope that DB can close the holes, but I am afraid that some people out there are still cheating and will ever do.
My wallet remains closed until DB makes a statement.
Then, a similar code in the shuttles section, regarding claiming shuttles, with similar conclusions. And a chart showing a regular player in an event, getting points in constant amounts, and a top player, getting a lot of points suddenly (this is not impossible, there are legit in game ways of doing it, it is acknoledged on the video but it still is show as "suspicious")
And then there are a lot of chats captures that I didn't really paid attention. If I recall, it was all people talking about IamPicard, asking the author via PM about the code, with no answarers.
The "exploit" in question was programmed, in the IamPicard app, in July, for a bug in the server that (observation sugests) didn't exist until last week, and don't exists anymore. That's a big hole in the "the app was created to cheat" theory.
Public profile
Captain Zombie's Combo chain calculator
I would love if someone with more experience (mine is almost null) in JS/Angular/Vue/Npm/whatever it was used, and server-client architecture could shed some light about this (My question to an expert would be "is there a way, as invoked via the random choice in the UI, that the code doesn't call multiple time to the server, thus it should have been giving multiple rewards since July if the server didn't change its behaviour?")
Public profile
Captain Zombie's Combo chain calculator
Public profile
Captain Zombie's Combo chain calculator
Since I don't know when to shut up, allow me to share a personal anecdote which leaves me open to alternate interpretations of what to make of that snippet:
So, projecting my own experiences, I would be very, very, very, very cautious about spotting black helicopters flying around the developer's opt-out timing. Walk a mile. Could it have been malintent and CYA? Sure. Could it also have been other factors. YES. I'm reserving judgment.
There was also eu.iampicard.com which was setup to offer better performance for European players.
Even though the API is public facing, no where did DB state is was for public use. My college has an API exposed to the internet for use by 3rd party integration services. It is exposed to the public, but it is not a public API. There is a difference.
Public profile
Captain Zombie's Combo chain calculator
Thanks for that, 5Q. And for your previous post, which stated in part:
There's been just as much (if not more... and more precarious) speculation going on recently from certain people who believe they have "all the facts" as there was from many of us who weren't initially aware of some of those additional facts. The only thing we know for sure are that the code could potentially be used for some pretty severe exploits — exploits which only a small percentage of the tool's users took advantage of, or were even aware of, but which still were obviously problematic.
It's actually pointless to publicly speculate about the intentions of the author of the tool at this juncture. It does nothing but impugn someone based on suppositions — and besides that, it does not move us forward at all. I agree that there is still value in certain parts of what was created, and that proceeding in a manner which abides more clearly by rules that DB can easily live with is the most prudent and desirable course of action. However, any public statements accusing the author of nefarious intent are just reckless and spiteful. Let's focus on the future here, not the past, yeah?
Could you please continue the petty bickering? I find it most intriguing.
~ Data, ST:TNG "Haven"
Understood — and you'll forgive me if it sounded like I was putting words in your mouth. My words are my own, even though occasionally they have to share mouth space with the foot I've also put in there.
Could you please continue the petty bickering? I find it most intriguing.
~ Data, ST:TNG "Haven"
It expires every year with the option to renew another year. I don’t see them giving up this license when it’s the only game they have and their only source of revenue
Well, I think you have helped me to an epiphany as well! What you have written describes me very accurately, and while I have been neglecting my gameplay of late (due to real-world time constraints) I have just been gearing up to get back into it a bit more... just to come back and find this rather sad situation.
I don't know if I will continue. Right now, it just feels like a mountain to climb. I have spreadsheets, but they're very much out of date now, and manually updating them (and then keeping them updated) would be a chore. Combine that with how very time-consuming the events have felt like lately, and... I dunno. The effort-reward ratio just seems off. Could I learn to play more casually instead, and switch off that need to "always hit maximum efficiency", as you put it? I just don't know about that either. Some introspection will be required.
Half of me wants to just condemn my time (and money) spent on this game to the trashcan of lessons learnt, and resolve to:
- avoid "freemium" games
- avoid any games with in-app purchases for anything other than expanded content
- avoid any games that require me to show up during a specific time slot in order to remain competitive.
The other half of me feels a bit nostalgic about the crew complement I've built up and can't quite let it go like that. But then I am reminded of two things:
1. DB is adding several new crew every single week. I would always be playing catch-up, and always be tempted to use real money to save on real time. But both are too valuable to waste.
2. The saying: “Don’t cling to a mistake just because you spent a lot of time making it.”
To be clear, I never used the "Crew Management" app to do anything that I couldn't do without it. (I am still not aware of any way that I could have, either, short of adapting the code.) The only advantage it ever gave me - fair or not, is your call - was by saving me time. And even with that help, I still haven't enough time lately to play competitively.
This might be it for me, guys. If this does turn out to be my last post ever on these forums, please know that most of you have been absolutely awesome. Many times it was only the community (and my ex-fleet, in particular) that kept me playing. LLAP!
There is a reason why books are still a thing.