I recently started using flex 3 to patch games and get more aware of coding and what certain things do.
I made a patch for this app called Highrise and was successful in getting it to operate by giving the user +3,000 bubbles when their profile is liked instead of the programmed +2 bubbles.
The only problem now is that it gives the user the amount but it disappears once you leave the room or close the app and it doesn't process when going to purchase something in the games store.
I received one suggestion so far which was to try "Reversing the subtract algorithm" but I don't understand what that means. I'm fairly new to coding and have a lot more knowledge to gain.
Can anyone help? I posted pictures from my patch below.
Thanks!
!(IMG_0808.PNG)
!(IMG_0809.PNG)
!(IMG_0810.PNG)
!(IMG_0811.PNG)
!(IMG_0812.PNG)
That's because the app you're trying to Hack is server-sided. Flex 3 isn't that useful anymore when it comes to hacking iOS applications unless you're trying to modify a basic offline non server-sided game.
To be a bit more clear, when you're trying to modify how much "Bubbles" you receive in Highrise with Flex 3, it doesn't work because those "Bubbles" are stored on a server. When they're being used, the game will fetch them from the server.
The only problem now is that it gives the user the amount but it disappears
That's because Flex 3 only changes the Visual number of the "Bubbles" and not the actual server-sided stored amount.
I received one suggestion so far which was to try "Reversing the subtract algorithm" but I don't understand what that means.
This is a bit of a more Advanced way to hack an application. You basically load the application's binary in a disassembler program like IDA Pro find the algorithm that subtracts the "Bubbles". This is a very long subject to understand to I suggest you go on this website https://www.iosgods.com and learn how to hack games using a disassembler + debugger. They have nice tutorials on how to get started.
Related
I've got a big ask here, but I am hoping someone might be able to help me. If there's another site you think this should be posted on, please let me know.
I'm the developer of the free app Amphetamine for macOS and I'm hoping to add a new feature to the app - keeping a Mac awake while in closed-display (clamshell) mode while not having a keyboard/mouse/power adapter/display connected to the Mac. I get requests to add this feature on an almost daily basis.
I've been working on a solution (and it's mostly ready) which uses a non-App Store helper app that must be download and installed separately. I could still go with that solution, but I want to explore one more option before pushing the separate app solution out to the world.
An Amphetamine user tipped me off that another app, AntiSleep can keep a Mac awake while in closed-display mode, while not meeting Apple's requirements. I've tested this claim, and it's true. After doing a bit of digging into how AntiSleep might be accomplishing this, I've come up with 2 possible theories so far (though there may be more to it):
In addition to the standard power assertion types, it looks like AntiSleep is using (a) private framework(s) to apply non-standard power assertions. The following non-standard power assertion types are active when AntiSleep is keeping a Mac awake: DenySystemSleep, UserIsActive, RequiresDisplayAudio, & InternalPreventDisplaySleep. I haven't been able to find much information on these power assertion types beyond what appears in IOPMLibPrivate.h. I'm not familiar at all with using private frameworks, but I assume I could theoretically add the IOPMLibPrivate header file to a project and then create these power assertion types. I understand that would likely result in an App Store review rejection for Amphetamine, of course. What about non-App Store apps? Would Apple notarize an app using this? Beyond that, could someone help me confirm that the only way to apply these non-standard power assertions is to use a private framework?
I suspect that AntiSleep may also be creating a virtual keyboard and mouse. Certainly, the idea of creating a virtual keyboard and mouse to get around Apple's requirement of having a keyboard and mouse connected to the Mac when using closed-display mode is an intriguing idea. After doing some searching, I found foohid. However, I ran into all kinds of errors trying to add and use the foohid files in a test project. Would someone be willing to take a look at the foohid project and help me understand whether it is theoretically possible to include this functionality in an App Store compatible app? I'm not asking for code help with that (yet). I'd just like some help determining whether it might be possible to do.
Thank you in advance for taking a look.
Would Apple notarize an app using this?
I haven't seen any issues with notarising code that uses private APIs. Currently, Apple only seems to use notarisation for scanning for inclusion of known malware.
Would someone be willing to take a look at the foohid project and help me understand whether it is theoretically possible to include this functionality in an App Store compatible app?
Taking a quick glance at the code of that project, it's clear it implements a kernel extension (kext). Those are not allowed on the App Store.
However, since macOS 10.15 Catalina, there's a new way to write HID drivers, using DriverKit. The idea is that the APIs are very similar to the kernel APIs, although I suspect it'll be a rewrite of the kext as a DriverKit driver, rather than a simple port.
DriverKit drivers are permitted to be included in App Store apps.
I don't know if a DriverKit based HID driver will solve your specific power management issue.
If you go with a DriverKit solution, this will only work on 10.15+.
I suspect that AntiSleep may also be creating a virtual keyboard and mouse.
I haven't looked at AntiSleep, but I do know that in addition to writing an outright HID driver, it's possible to generate HID events using user space APIs such as IOHIDPostEvent(). I don't know if those are allowed on the App Store, but as far as I'm aware, IOKitLib is generally fine.
It's possible you might be able to implement your virtual input device using those.
I have an image application and I want to release it where unregistered users can view the files but cant save until they've registered.
I'm looking for a way to prevent the user from using the built in screenshot functionality so I don't have to watermark the images. How might I accomplish this?
-- Edit Below --
I decided to watermark the images. I had been trying to avoid watermarking since the images are stereoscopic but I'm rather happy about how the watermark looks now. I put a logo in the corner and offset it enough on each image so it appears in the foreground.
Whether people agree with it in practice or not, my question is still valid. Apple's DVD Player hides the video in its screenshots, which doesn't altogether stop the user from taking screenshots but accomplishes my original goal.
I would still very much like to know how to do this. (the DVD player way)
Based on a symbols search through DVD Player, it likely uses the private API CGSSetWindowCaptureExcludeShape. Richard Heard has been kind enough to reverse engineer it and wrap it for easy use.
Being private, it may stop working (or have already stopped working) at any time.
But ultimately the answer to your question is "yes, but not in any publicly documented way". Some other takeaways from this lengthy thread are:
Asking this question inevitably excites a lot of myopic moral outrage.
Given there's no public method, reverse engineering DVD Player is a useful path to pursue.
A request to Apple DTS might be the only reliable method to find an answer.
DVD Player does this (the user can still take the screenshot, but the player window doesn't appear in it), so I'm sure there's a way. Maybe setting the window's sharing type to NSWindowSharingNone?
One option that is very user hostile is to change the folder in which screen captures are stored to a /dev/null style directory by changing the com.apple.screencapture setting.
A huge downside of this is that you might mess up the users settings and not being able to restore them if the exit from your application isn't clean.
Another option is to keep track of what files that are created in the screen capture location, see if they match the pattern for name and then remove them.
This method is still quite hostile though.
I also investigated if it was possibility to kill the process that handle the screen capture, unfortunately the process that handles it, SystemUIServer just reboots after being killed.
SystemUIServer seems to refuse taking screenshots if DVD Player currently is playing a DVD. I have no idea how the DVD playback detection works though, but it might be a lead to prevent screenshots.
Links
Technical details about Screenshots in Mac OS X
com.apple.screencapture details
ScreenCapture.strings - List of error messages from ScreenCapture
Disclaimer before people start ranting: I have a legit reason to solve this problem, but won't use the com.apple.screencapture -> /dev/null method due to it's downsides.
You could try to run your application fullscreen and then capture all the keystrokes. But please listen to siride.
No; that's a system feature.
I want to develop an application for Mac OS X to record audio from one application.
I played around with Soundflower, but it only grabs the full system audio.
I know that I have to use a HAL plug-in. This plug-in is loaded from an application that uses Core Audio and then I can communicate with the plug-in to grab the audio.
My question is: How does such a plug-in look like? Are there examples on the internet? I have not found anything about this topic.
Now that you've decided that using Cocoa injection is a feasible solution to your problem, let's start there.
What you need to do is find out how the ObjC classes in the app are setting up to play audio, and hook in to set a different AU in place of the default system out.
There are two options (besides writing your own custom AU from scratch, which you don't need to do). You can use AUHAL as the AU, and capture the data from AUHAL. This is a bit easier from the point of view of hooking things up, but it means you have to write the code that renderers and saves the audio. Or you can just hook in a save-to-file AU, which is a bit harder to hook up, but once you do it takes care of rendering automatically.
So, how do you hook things in? Well, most of the higher-level CA calls are written to just write to the current output. If the app is doing things that way, you just need to hook in at startup to find your replacement AU and set it as the current output, in place of the default. On the other hand, if the app is writing directly to an AU that it stores in a variable, you have to hook it to store your AU as a variable. And if it's building a graph of AUs, you either replace the default output, or stick yours in front of it, in the graph.
See TN2091 for some sample code fragments for most of the hard parts for most of the possibilities. It doesn't show you how to put them together, and it's got a lot more about setting inputs than outputs (because that's harder), and the terminology can get confusing, but if you read it carefully, you should be able to find the parts you need.
If you haven't yet built a simple AU host and AU plugin before, you really should take the time to work through the whole Audio Unit Development Fundamentals guide. (And if you don't think you really need to know all that to do something simple, you're wrong. Why CoreAudio is Hard explains half of the reason; the changes between OS X versions versions are the other half of the reason.)
You probably also want to look at CocoaDev's CoreAudioAndAudioUnitsTutorial page for a placeholder page for a complete tutorial that nobody's ever written, with links to a lot of useful stuff.
Meanwhile, if injecting the whole MTCoreAudio framework into the app is feasible, it comes with a ton of nice, complete samples. In fact, even if you aren't going to use the framework, it's worth reading the Overview documentation, and possibly the source code.
What is the best way to record the mac screen with cocoa? I know there are many examples at the apple developer reference library. SonOfGrab explain how to capture the screen with quartz but also that it isn't enough fast to use it to grab many frames every second. OpenGLScreenSnapshot has same results but it isn't fast, too. OpenGLScreenCapture seems to be the best way to do it but XCode prompts me many errors because it's made for 10.4 and it requires old Quicktime commands I think they pushed into QTKit but I can't find a way to convert it. Could anyone send me to someone's site that converted the project or tell me if there are some other ways to do it. Thanks in advance.
OpenGL would be the way to go. You should still be able to use the OpenGLScreenCapture sample if your architecture is set to 32-bit. (QuickTime is not available in 64-bit.)
-Ken
We're in process of developing a desktop application which needs to record user's screen once he clicks a button. I read a tutorial about Adobe AIR, which says it is easy to do with AIR: http://www.adobe.com/devnet/air/flex/articles/air_screenrecording.html
But our preference is Titanium as we've explored it a little bit. So I want to know is that even possible? If yes, how can we get started with?
There's also an interesting solution which uses Java applet for recording, as demonstrated here: http://www.screencast-o-matic.com/create?step=info&sid=default&itype=choose
But again, we're not sure about JAVA and would like to know how can it be done? or if its even possible to run a JAVA applet in Titanium?
When you say "record screen", I'm assuming you mean video. Correct?
The only way to do this in Titanium Desktop right now is to take a bunch of screenshots and string them together (encoding would probably need to be done server-side).
Depending on how long your videos need to be, this probably won't work for you. I'm also not confident in how quickly you could capture screenshots, and if it would have a high enough frame rate to be usable.
Past that, a module could be developed for Desktop to support some native APIs to record video. That's not something I see on the horizon, though.
I hope this helps, albiet a rather dismal answer. -Dawson