[Suggestion] CLI support to invoke FLEX on process other than apps and SB — daemons

[yur1xpp]

Do you think such implementation is possible? Currently it can only be activated on processes that's visible to the eyes (apps, springboard, Lock Screen etc), but not other processes such daemons. This would be super useful for development. The idea would probably be more or less the same as cycript, flexall -p processname. What do you think?

[DGh0st]

Its definitely possible to allow activating FLEX (libFLEX) from CLI, but the problems come when displaying the information.

Potential Implementation of Proposed Feature

If FLEX was "activated" via CLI, it would be sending a message to process to tell it to show FLEX toolbar. For daemons (or other non-UI processes) there would be no graphics context since its not visible so this would fail. So instead of displaying the info via toolbar, it would need to be communicated back to the CLI tool for display via output stream.

But from a functionality perspective Cycript provides everything that FLEX can do so I don't really see any benefits of doing that. An UI exploration tool for daemons would be very useful for development, though I don't think FLEX is the right tool for that.

Current Restrictions

FLEX was designed for iOS app debugging so it heavily depends on UI elements for providing its info. This creates a lot of limitations on what processes FLEX can be loaded in. Not all daemons load UIKit and lot of the ones that do would easily reach its memory limit (and crash) if FLEX was loaded into those processes.

Past Attempt

Though the number of processes it can be used in was very small, we (Shepgoba mostly) had tried to load FLEX in those processes and then try to display the UI via a remote view. But that had its own roadblocks, biggest one being the entitlements needed to host a remote view in the process.

UI For Cycript (New Proposed Solution # 1)

One option would be create a UI for Cycript, the functionality range provided by the UI would be very limited as compared to Cycript's full potential but that's a different story. Essentially it would be performing Cyrcript commands and then parsing the output to be displayed in the UI. This is going to create a some overhead of parsing the data.

UI With New Lightweight FLEX Tool (New Proposed Solution # 2)

Another option would be to create a more lightweight FLEX tool, helper tool really that doesn't heavily rely on UI to get all the information. The lightweight tool would be loaded in the process and then the information would need to be communicated via IPC to the process displaying the UI (either in SpringBoard or a new app). The only benefit this provides over first solution is that we can control both sides of the serialized data.

I'd personally prefer the 2nd approach, but I am open to other ideas.

[yur1xpp]

Honestly, I didn't expect it to be quite this complex. Though I'd much prefer the proposed solution # 1, but with current state of Cycript, at least on arm64e, I would say it's not the best choice? With that said, solution # 2 sounds much more appealing and independent, and it make much more sense for the purpose of exploration (I really loves the "Heap objects" from FLEX I must say, can Cycript do/list this?) of the interested process, instead of the parsing overhead from Cycript. Solution # 2 sounds like it'll be a separated development from current FLEX though, I'll be very interested if you guys decided to pick up on this, would be a really nice addition to current development tools .