be a decent person and rename this to "frida-cycript"

[saurik]

I left a comment on your blog post (which was eaten in some way due to moderation/spam), left a comment on reddit, and also sent you some e-mails, but I see that you are now back on GitHub coding away on this fork of my project.

My comments in various places have a bunch of complaints about this architecture and the characterization of my project, as I think it is entirely unfair and you seem to fundamentally miss the point of what Cycript even is at its core.

Regardless, this is the one thing that I think is downright evil: I'm morally opposed to GitHub, so Cycript is never going to have an official home here. Yet, you have now made a public fork of my project which you are intending to maintain seemingly forever, one which I am never going to merge (and I explain why in those other places), one which is extremely different internally from my implementation and which you are likely going to go around advertising as "better" (which again, I disagree for various reasons): and yet you didn't even have the common decency to change the name to something like "frida-cycript" to avoid confusion. You have bumped the version number 1.0.0, and have a release page that makes it look like the releases just continue right on from my most recent 0.9.594 release from last week. You even seem to be intending to register npm packages named "cycript-*" (though I don't quite know enough about npm to be sure of what that particular package is for).

A lot of people, for worse (only, as this is absolutely not a good thing) equate open source software distribution and storage with GitHub, so now people are going to look on GitHub and essentially always find your project as the most current and maintained and highest version of Cycript. You are essentially hijacking my project directly by name. This seems like it should be really simple, and is kind of "the least you could do".

[dweinstein]

Hey @saurik, just wanted to ack that we got your message. By the way, your message on the blog was also posted--we do moderate on the blog because of the big potential for spam.

As you know, naming things is always a bit of a challenge but we hear you loud and clear regarding the potential for confusion and totally agree. I'll have a chat with @oleavr so we can think of an appropriate name going forward.

[dweinstein]

For now I'll just rename it to frida-cycript to alleviate your immediate concern while we decide on a longer term name going forward.

[dweinstein]

oh and by the way just to give a little context to why we originally kept it named cycript was that the goal was to see if you might consider upstreaming some of this as it really started out as a fork. It's pretty clear that you don't have much interest in that at this time, so it makes it that much easier for us to feel comfortable changing the name.

Thanks for your original work on cycript and for providing your explanations to us. It's pretty clear that we're probably not going to agree on all the technical reasons for the fork, but that's ok!

[saurik]

When you make a hard fork, particularly one which the original author is going to find out from an arrogant "our software is better than yours and hopefully you merge our stuff but if not we don't care and will maintain this forever", without talking to upstream first to look into the best architecture for the changes (as I mentioned in my various other comments there are tons of great ways Frida could work with Cycript in a more natural way, providing modules for its function hooking and building a more reusable process injection tool), and I'm going to say especially when you do it in a way that is a total affront to the morals of the person you are pretending to work with (in this case, putting a ton of code up on GitHub), it just seems obvious to me that you should rename the repository. Even in cases where you are hoping for some kind of theoretical merge one day and even have some support from upstream, such as nodejs-chakracore, it still seems obvious that one should rename the repository.

(FWIW, I specifically suggested "frida-cycript" as I am OK with that name given how you are supposedly intending to make minimal modifications in general and track the upstream language, even if your backend is incompatible. Like, using Cycript as a frontend to translate into Frida's JavaScript engine seems extremely reasonable to me: I would even be happy to set Cycript up so it can be used like "rlwrap for JavaScript" over frida-repl, something I already had been thinking of doing for node.js, which would be yet another example of a cleaner architecture for integration, as I already have a mode where Cycript can be built without any of my runtime and is just a potentially-interactive translator.)

BTW: I want you to really seriously notice that I never advertise Cydia Substrate or even Cycript to security researchers. I don't encourage people to use Substrate for anything but a really narrow developer-oriented and limited use case surrounding "fun extensions on mobile phones", and it is thereby optimized for things like runtime memory usage, backwards compatibility, and easy deployment with a reasonably small number of small decoupled binaries. I don't give talks at security conferences about Substrate, and I currently have no intentions of doing so: on a grand scale it just isn't worth talking to people about as it isn't actually novel. Why you continually insist on complaining about Substrate and including Substrate in comparisons with Frida makes no sense to me: if people are choosing to use a closed source tool marketed at a different audience in their work, despite all your attempts at marketing and all your comparison charts, maybe you should take a step back and ask yourself what is really going on... as an example, I imagine Pegasus shipped Substrate because of its decoupled architecture, and I would have been shocked if they had tried to bundle Frida ;P.

Maybe you don't even realize the use cases where Substrate shines vs. Frida, or why Cycript is interesting to some people vs. Frida, because I consider it incredibly inappropriate and combative to randomly take aim at active projects targeting different users with comparison charts, particularly lopsided ones :/. I think the only time I have ever marketed Substrate against something was Xposed, and I avoided doing that until I had some really key people essentially demand a web page that defended the existence of Substrate, because the exact same market was being targeted... and even then I feel like it was only truly justified as Substrate predated Xposed and many people didn't realize that. (If Xposed had truly predated my work I likely would have never even built Substrate.) The only time I mentioned Xposed in the release notes for Substrate was one time when Xposed actively broke something that affected Substrate. I never tweeted about deficiencies in Xposed.

I honestly don't pay much attention to Frida: I never think "oh, someone is using Frida, that's bad for me and my software". I literally don't care if every single talk at a security conference is about Frida: I am proud when my work is used and discussed, but it certainly hasn't been because I asked anyone to do so... I was seriously shocked when I learned people were talking about Cycript. When I release updates to Cycript or Substrate, my goal is not to convert people using Frida. Why you insist on being combative in your release notes to my software is thereby just beyond me, and so even if you for some reason had much much better tooling than I did--and this is clearly wrong: I mean, I tried to allocate and ignore ten thousand NSObjects in a for loop to benchmark frida-cycript vs. cycript and Frida couldn't even do it correctly--I am never going to work with you as I simply don't think you are very nice people; and even if in some contexts you are, you have proven you don't want to be nice to me, and that's what really matters.

I mean, you didn't even contact me before you embarked on this massive fork of my work: that tells me a lot about your character and how we would be able to interact about design decisions in the future, even before reading the explicit challenges in your blog post and readme. I work on Cycript because I enjoy doing it, and my intention is to port most of my website backends to the language once I finish my Python bridge work, and I can tell you that I have no interest in working on it with someone who would choose to spring this sort of thing on someone. I just don't need that in my life. So you are welcome to have fun with my code (which is AGPL-3, not GPL-3: I noticed you made a mistake on that in one of your manifests), but the idea that, from a social perspective, you thought this could ever lead to any of this work being upstreamed is crazy to me: next time you want to work with someone, make friends with them before you start challenging them and complaining about their software, and be prepared for discussions, not a bunch of massive patches, as your first contact.

[remi6397]

@saurik I know this is a very old thread and one might consider what I'm about to say unrelated, but I hope you'll understand. You complained about other people not complying to your project's license, but in fact it's (ironically) you who always failed to comply to that license of your choice. Even when explicitly asked to publish build instructions, you didn't. As a matter of fact, publishing reliable build instructions is indeed required by AGPL!

Would you mind to listen to the voice of your followers this time and after all these years actually tell us how to reliably build cycript?

And please pardon my somewhat harsh tongue; I mean no harm to you, and also I'm nobody to assume that you've ever meant any harm to anybody else. I have huge respect for all of your hard work that inspired (and still inspires) countless amounts of people around the world.

[saurik]

@remi6397

1. I do not pay attention to Twitter mentions. Why exactly you assume I am actively ignoring you or something is beyond me :/. My Twitter bio even used to (until only a few months ago) explicitly said that I don't pay attention to anything said on Twitter.

2. My complaint here had nothing to do with licenses: it was about morals. Legally, there was nothing wrong with this fork of cycript (and I didn't even hate the fork: just the exact name--I didn't even ask for it to not use the word Cycript or anything--which was the "final straw" in what felt like a long sequence of transgressions that seriously included oleavr deciding to unilaterally rename my programming language to "cylang"... like, seriously?).

3. (FWIW, I actually have newer versions of Cycript--with support for Windows and a web console and lots of fixes to its transforms... months straight of work on nothing but Cycript from 2017--that I don't release to people; I stopped working on Cycript in public because of oleavr, as he just made it so actively demoralizing with his "manifest destiny" approach to Frida, and I just did not want to deal with any of it anymore: he managed to make this entire space of tooling actively un-fun to work on :/. But, I digress: the point here is that I am not bound to the AGPL on my own code; I am bound to the GPL on my old released versions due to linking against readline, but I even removed readline--which happens to be developed by a coworker of mine, so this was awkward--from later, "internal" versions I gift to close friends occasionally, for complete compliance.)

4. I do not have any secret build instructions for Cycript: everything I ever used to personally build it is checked into my public repository. Why would I keep that secret? I was so proud of how much work I put into making that build system universally accessible.

Regardless: I just checked out the current public code for Cycript on a random computer (running some arbitrary LTS of Ubuntu), did a submodule update, and--no surprises here--./configure && make built a working version of Cycript... with a notable legitimate exception that there is apparently a "bug" where the new module loader requires the analyzer and I never realized that, but the analyzer is normally optional via configure :(. Either not using the module loader or passing --with-libclang='-lclang-3.8 -lpthread' to configure fixed that.

So... I just don't understand your complaint. Maybe you just don't know how to use autotools? It is just that how you would build Cycript for any random platform is identical to how you compile absolutely any other autotools project for that platform. If it helps, autotools is extremely well documented, and is one of the most commonly used build systems for native projects (used by almost all GNU projects). Cycript is (in my opinion) a really high-quality use of it as I honestly cared so much about making the build system work off-the-shelf / out-of-the-box for everyone :(.

[remi6397]

@saurik

I stopped working on Cycript in public because of oleavr, as he just made it so actively demoralizing with his "manifest destiny" approach to Frida, and I just did not want to deal with any of it anymore: he managed to make this entire space of tooling actively un-fun to work on :/.

Why would you possibly even do that? Because of some random person's jealousy? No matter what people say, or what they do, nothing could possibly diminish the hours you spent carefully chiseling your awesome projects! Actually, cycript is so great that its success makes some people who invested in similar projects really uncomfortable! After years and years of progress in technologies, nothing really came even close to the quality of cycript's awesome readline TUI, its brilliant design and its API, they are just wonderful and unbeatable! Not just me, dozens of people who look up to you will defend your achievements too! Don't even dare to think otherwise! Have faith in yourself! 😊

Cycript is (in my opinion) a really high-quality use of it as I honestly cared so much about making the build system work off-the-shelf / out-of-the-box for everyone :(.

It might be as well my fault, but I just can't get the Parser to compile. I think cycript relies on certain versions of its dependencies, because on bison3.7.3/flex2.6.4 I get some errors, such as no member named 'empty_symbol' in 'cy::parser'. It's just an example of what fails, I would be willing to describe that in detail if you had an issue tracker.

[saurik]

@remi6397 FWIW, and seriously: thank you for your commentary. I'll seriously at least consider a new release of Cycript (maybe even on GitHub? I dunno. I have had an identity for so many years of being anti-GitHub, but realistically a lot changed for my issues with them after Microsoft purchased the company--I actually like Microsoft somewhat, and in certain contexts, while I realize many don't at all--and the benefits for these kind of issues from having the free public CI that came from the Azure integration has become extremely compelling).

FWIW, I know these work with the public version (they happen to be what I had on that Linux machine I tested with yesterday, which is running something old: I think Ubuntu Xenial).

# flex --version
flex 2.6.0

# bison --version
bison (GNU Bison) 3.0.4
Written by Robert Corbett and Richard Stallman.

Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

So, to examine further, I just compiled Cycript on my macOS 10.14.6 box using Xcode 11.3.1. I ran into my insistence on -Werror burning the bison compile (this has finally convinced me to never put that in a build script; I knew that academically, and at least never told anyone else to do it, but I was still doing it in my code... I now appreciate this viscerally). I also had to manually select the older JDK (as Java infuriatingly stopped supporting old class file formats... really disappointing). I didn't bother trying to get --with-libclang= to work, so I simply deleted the module loader. It seems macOS doesn't come with libreadline anymore, which was also annoying (as my configure script doesn't defend against someone trying to slip me libedit).

$ git clone git://git.saurik.com/cycript.git
$ cd cycript
$ git submodule update --init --recursive
$ sed -i -e 's/ -Werror / /' Makefile.in
$ ./configure \
    CPPFLAGS='-Wno-inconsistent-missing-override'  \
    LDFLAGS='-L/usr/local/Cellar/readline/8.0.4/lib'
$ JAVA_HOME=`/usr/libexec/java_home -v 1.8` make -kj5
$ rm -f libcycript.cy

This built cycript fine. It crashes when you hit enter :(, but I spent some time debugging that and I tracked the issue down to a bug in readline 8 that has affected other projects (including tig); a patch was sent upstream to Chet a month ago by Debian, but hasn't yet filtered down through to Homebrew.

https://lists.gnu.org/archive/html/bug-readline/2020-09/msg00000.html

$ flex --version
flex 2.5.35 Apple(flex-32)

$ bison --version
bison (GNU Bison) 3.5.4
Written by Robert Corbett and Richard Stallman.

Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I finally managed to reproduce your issue by upgrading to Bison 3.7.

$ flex --version
flex 2.6.4

$ bison --version
bison (GNU Bison) 3.7.1
Written by Robert Corbett and Richard Stallman.

Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I dunno... it just seems unreasonable to try to call me out for somehow not providing you build instructions when it is pretty obvious from the error message itself that this was going to be related to using a version of Bison (in this case, 3.6: they did something complex that I don't really understand and which broke some of my symbol hacks) that seems to have just come out a few months ago (all of 3.5-7 were from 2020: they were "on a roll") and which is so new the only version of Ubuntu which even ships with it is Groovy Gorilla, which literally came out earlier today (every version of Ubuntu from before today ships with bison 3.5 or below, which is compatible with Cycript). :(

I spent an hour just now messing with this, and most of that was spent trying to fix the Bison 3.6 issue, but I'm in the middle of other things and seem to be sick today, so I'm not really in a position to try to port Cycript to Bison 3.6+: just downgrade to a more contemporary version of Bison. If I do release an updated version of Cycript I will make sure it works with Bison 3.7.

[remi6397]

@saurik

FWIW, and seriously: thank you for your commentary.

No need to thank me, as I just stated the facts, and nothing much more. 😊

maybe even on GitHub? I dunno.

There is of course also GitLab, BitBucket, and many, many more. Of course you don't need to restrict yourself to just one code hosting platform, as FWIW Git is a Distributed Version Control System. 😉

This built cycript fine. It crashes when you hit enter :(

It's my bad that I'd forgotten to tell you that I already solved that yesterday (at about 9 AM PDT or 6 PM of my time, CEST). You know what I've found? frida-cycript has actually never fixed that bison bug, and they keep a whole copy of bison in this very repository! Pointing cycript to use that worked nicely, and I have a freshly compiled working copy of cycript now! 😁

Now I'm just trying to figure out how to inject it to a macOS app (during launch or during runtime, doesn't matter). Is it even possible to compile cynject for macOS maybe?

[I] seem to be sick today

That doesn't sound good, especially in these present times. Get well soon!