However, released versions of apps had no way to inspect dynamic web content or scripts, leaving developers and users to have to resort to more complicated workflows to get information that would otherwise be made available by Web Inspector.

From iOS 16.4 (and MacOS 13.3) Apple introduced isInspectable flag on WKWebView and on JSContext

How to enable inspection?

According to webkit.org:

let webConfiguration = WKWebViewConfiguration()
let webView = WKWebView(frame: .zero, configuration: webConfiguration)
webView.isInspectable = true

Or:

let jsContext = JSContext()
jsContext?.isInspectable = true

And from a desktop Safari's Develop menu you can access now the inspection.

(For iOS and iPadOS, you must also have enabled Web Inspector in the Settings app under Safari > Advanced > Web Inspector. For simulators it is always enabled.)

The caveat

If you start your iOS development journey after iOS 16.4 you will rely on the current state of Web inspection.

As webkit.org also mentions, the isInspectable flag

defaults to false, and you can set it to true to opt-in to content being inspectable. This decision is made for each individual WKWebView and JSContext to prevent unintentionally making it enabled for a view or context you don’t intend to be inspectable

This will make you think that disabling the isInspectable flag is enough to restrict the access to your Webview/JSContext for 3rd-parties.

This assumption can make you lazy and you forget to obfuscate your sensitive Javascript code.

This is specially important if you develop (and distribute) a framework that has its business logic in Javascript (and even contains some sensitive data)

Before iOS 16.4 (as mentioned earlier) Web inspection was by default enabled for development-signed builds, so you were alerted immediately once you opened Safari's Develop menu. You had to make precautions against disassembling your code.

This is not the case anymore and your false assumption of safety can cause some pain later.

What's going on?

In a previous article I already talked about hooking into (aka. swizzling) methods.

From the moment isInspectable is a property on a class, we can use the same technique to override the “hardcoded” value by the 3rd-party framework (or even by an app on a jailbroken device).

We need to find a hooking point (preferable as late as possible, so our new value can not be overridden by the framework/app anymore), e.g. when the Webview loads an HTML string. (But this can be anything. Setting a certain value, calling a constructor, etc…)

extension WKWebView {

    @objc dynamic func _swizzled_loadHTMLString(_ string: String, baseURL: URL?) -> WKNavigation? {
        //this will do the magic
        if #available(iOS 16.4, *) {
            print("[SWIZZLING] Overriding isInspectable from loadHTML")
            self.isInspectable = true
        } else {
            // No flag on earlier version
        }
        
        // call the original method. Looks like an infinite loop, but the implementations are exchanged!
        return _swizzled_loadHTMLString(string, baseURL: baseURL)
    }
}

After we found the right method, we can exchange the implementations.

extension WKWebView {
    static func applySwizzling() {
        print("[SWIZZLING] applySwizzling")
        
        //original method
        let selector1 = #selector(WKWebView.loadHTMLString(_:baseURL:))
        //new method
        let selector2 = #selector(WKWebView._swizzled_loadHTMLString(_:baseURL:))
        
        let originalMethod = class_getInstanceMethod(WKWebView.self, selector1)!
        let swizzleMethod = class_getInstanceMethod(WKWebView.self, selector2)!
        //exchange implementations
        method_exchangeImplementations(originalMethod, swizzleMethod)
        
    }
}

We can call WKWebView.applySwizzling() to enable hooking as early as possible in the application life-cycle (e.g. in AppDelegate)

After applying the hooking, we are able to see the Web inspection in Safari again for all the Webview within our app. We can see all of ours, but also all the 3rd-party ones which were not meant to be seen by us.

Why is this a problem?

1. Hidden parts can be discovered of any 3rd-party SDK while using them.
2. On a jailbroken device we can open up all the Webviews (in any app) by applying the snippet above via a Jailbreak tweak.
3. isInspectable is a public API, so swizzling it is not against the Apple Store guidelines. (So if we find a valid use-case for it, we are free to do it in release apps)

Can we avoid our secrets being exposed?

There are few tricks we can try. I am going to touch up on few of these.

Always obfuscate the Javascript code

This is the first and most important defense line. If the business logic is obfuscated and hard to read we can already make the bad actor's life difficult.

Also, don't store any secret inside Javascript.

Swizzle the swizzling

Unfortunately, we can not be faster within a framework than someone who is using our library within an app and can put hooking around application life-cycle methods.

However, if we are lucky we can hook into the right method in the right time, so every call to that method will arrive to us and we can decide how to continue.

    @objc dynamic func _swizzleSetter(_ val: Bool) {
        print("[INTERNAL SWIZZLING] isInspectable setter ", val)
        _swizzleSetter(val)
    }
    
    static func applySwizzling() {
        print("[INTERNAL SWIZZLING] applySwizzling")

        if #available(iOS 16.4, *) {
            let selector11 = #selector(setter: WKWebView.isInspectable)
            let selector21 = #selector(WKWebView._swizzleSetter(_:))
            let originalMethod = class_getInstanceMethod(WKWebView.self, selector11)!
            let swizzleMethod = class_getInstanceMethod(WKWebView.self, selector21)!
            method_exchangeImplementations(originalMethod, swizzleMethod)
        } else {
            // Fallback on earlier versions
        }
    }

In the sample code above we hook into the setter of isInspectable, so whenever an app-level hooking would try to set isInspectable to TRUE we can just reject it.

So in the first hooking sample snippet, whenever _swizzled_loadHTMLString hook calls self.isInspectable = true, that call will be delivered to _swizzleSetter and there we can decide what to do.

Devirtualizing Objective-C calls

When calling a method on a class in Objective-C, under the hood it uses objc_msgSend which will call (dispatch a message) the selected function via a selector on a specific object (with specific parameters).

Because of this technique the Obj-C methods are called “virtual” and they are dynamically resolved during runtime.

And this way of communication makes method swizzling work.

With bitcode manipulation we can bypass objc_msgSend and call the required function directly. This is called devirtualization.

There is a brilliant article from GuardSquare on the topic that explains how it works.

Note: Don't try this at home 🙂… Try to use tools that make your life easier.

Conclusion

Obfuscate and keep challenging the conventional wisdom!

Support

Did you enjoy my story? There is more in the pipeline… 😉

Do you want to know more insights? Would you like to discuss the used techniques, or would you like to see some part of the code? Then consider becoming a monthly supporter on Patreon via my Tweaked.Tech initiative.

Become a Patron

Why?

• The articles are published on Patreon first.
• There is a follow-up article that shares insights, used techniques, architecture, infrastructure.
• You can get early access to projects in the Beta phase.
• We can discuss your ideas, your doubts, and the current issues you face in your project.
• You keep me going, it is a big boost to my motivation!

I really appreciate a one time support too, you can do it via Buy Me A Coffee.

Buy me a coffee

Thanks for reading my story, I am grateful that you were here until the end.
Stay tuned for the next one!

The Story

Usually, every product story starts with a pain, a problem that needs to be solved. A problem that bothers you, annoys you, you face it frequently and probably you are not alone with it.
This case was not different either.

A few months ago we started to use a new HR system that has a lot of advantages compared to the old one. But it had disadvantages too… Missing functionality, missing information… or the information is there, but hard to get it out from the system.

That's when the idea of Pandoo (the holiday planner) was born.

The Problem

The new tool did lack some features that we got used to.

A nice(r) and clean(er) way to see all of your holidays, your team's holidays (and type of those holidays), and book them in a bunch.

Disclaimer: Maybe some of these problems are manageable with admin configurations or with educating the users.. but usually, when people switch tools they just expect that “it works” and they have all the things they had previously plus nice extras.

The goal of this article is not to blame the tool, it is about the solution and the key learnings.

The Solution

I wanted to bring back the functionalities from the old tool. I wanted to see my holidays as I was used to, I wanted to book my holidays as I used to. And I was not alone with this.

The Requirements

• I don't want to waste too much time on the MVP, just get it to work with the basic functionality and make me happy.
• There is no way that I will build multiple apps using multiple programming languages.
• Mobile-first, but bigger screen support would be nice where I can see more data.
• Challenge myself.

The Choice

Flutter

Why?

• Flutter's promise

Flutter is a cross-platform tool made by Google, that helps you build native mobile apps from a single codebase.
(Edit (19/09/2020): This has been changed a bit as you will see it later. )

• I had some experiences already.

I have built Edengreen, a tool that helps you check your available meal vouchers.
It is a really basic app, but it taught me the basics of how Flutter works. At this time Flutter was still in beta.

One of my other projects was CoronaVirus Alert, a tool that monitors the infections country by country and sends you push notifications.
In this project, I have played with Firebase, serverless functions, and custom scripts here and there. I have learned that there is a big pool of third-party libraries for Flutter and the community is growing rapidly too.

• Web support

I have never tried, but apparently, there was rudimentary Web support too.

• The challenge

My previous projects helped me to understand the basics but I wanted to achieve more and the Web support was sounded interesting too.

Know Your Stuff

I needed a giant scrollable table view where horizontally I can show the days of the year and vertically all of my colleagues and their holidays.
This sounds easy, but in reality, it never is. Weird, annoying edge-cases when you are almost done, lack of Flutter knowledge from my side, unforeseen platform limitations, etc…

I wanted to see what is available already by the community, maybe there is something that is similar and it can fit my needs (with minimal tweaking). Luckily I have found the horizontal_data_table package, that provided 90% of what I have needed… I have forked the package and did some fine-tuning for my needs on the way.

Getting the data from the HR tool was pretty easy, they provide a nice REST API to interact with the back-end.

When you connect the dots you have to be cautious. You need to know what you expect from your tool, how it is going to work. How does it get the data? Do we need to store the data locally? Do we need an extra server-side logic too? Do we plan to use any exotic UI elements?

These are important questions, because when you pick a library/package in Flutter and e.g. if it works on Android it does not mean automatically that it works on iOS too… or even on the Web. You need to pick libraries that rely on the default native support and no additional native third-party libraries. (Or the reliance on those libraries needs to be complete on every side.)

For example, if you would like to use Firebase services in your app, you need to check which platforms are supported. If your target is not, probably you will face a runtime crash when Flutter tries to access the non-existent APIs.

When you search for a Flutter package in the official Dart/Flutter package repository, you can also see which platforms are supported.

3 Apps at Once

Based on past experiences in the MVP I did not choose any special external library (except the horizontal_data_table) because I wanted to limit the compatibility issues between iOS, Android, and Web.

After I was done with the minimal version, I tested the implementation on Android and iOS.
It worked and looked nice! (Sure, it had some performance issues here and there while scrolling through the holidays of the whole company… but on a limited dataset it was good.)

So now we have two apps ready to use!

Let's see how it works on the Web.
Of course, it crashed in a few places 😀. But nothing serious that a good old “if-else” could not solve. I have still used some APIs that were not available on the Web, so I needed to use kIsWeb constant to differ the logic between Web and native mobile.

It also had some UI quirks due to unsupported/buggy UI elements (with gradients), but it was good enough for the current phase.

We have the third app too, and you could say “Ok, you are done, you have it all, Web runs on all platforms”.

But wait, there is more!

The Meetup and The Extra 3 Apps

I really like Meetups. I can meet with like-minded people, listen to good and interesting presentations, and sometimes I give a talk too 😊.

There was a promising Meetup from GDG Brussels on Flutter topic. Based on the presentation summary, it intended to be a basic Flutter intro and the experiences of the author.
So it could be nothing interesting for me, I am kinda done with the basics… but I always like to repeat similar things, because maybe I can discover a new bit of information that can change my perspective and start me thinking. For the same reason, I read/listen to books on similar topics too… even the 95% is the same as a previous book, the remaining 5% is worth the time.

Luckily this case was not different either.
The presenter walked through their app development challenges and how quickly they have re-implemented the apps from scratch in Flutter.

Then he showed something interesting. His app was in a weird-looking window. It looked like a browser or a bezel-less iOS simulator. Apparently, it was his application compiled into a native MacOS app. It turned out that Flutter added support for Desktop platforms. Obviously, this was even in an earlier stage than the Web support, but it is worth a try.

The next day I tried it, it worked! I had Pandoo as a native MacOS app. Meanwhile, I have discovered that there is also really basic support for Linux and Windows… After the initial setup of the environments in VirtualBox, I could compile Pandoo as a native Windows and Linux app too! 🎉

Sure, there were some extra limitations on Windows and Linux, I had to do some extra “if-else” conditions. E.g. there was no persistent storage API available on these platforms, so I could not save any data to the disk.
(Edit (19/09/2020): Later I did polyfill these missing features by using the default Dart file reading and writing APIs.)

Extra three apps are done. Sounds good, doesn't it?

+1

We can argue on this if it counts as the seventh app or not. But it was such a nice surprise to me, so please allow me to count it as +1.

While I was testing Pandoo in the Chrome Browser on my phone, I got a popup that asked me if I would like to add Pandoo to my home screen. Sure, why not. But this icon on my home screen looked different from another page link. And… it also appeared between my apps in the Launcher. What?

It turned out that the Web apps built by Flutter are PWA applications too. So even if the device is offline, you can open and use the web apps. Or, you could… if a webpage is made for that. In my case I don't cache any data from the HR tool, I fetch all the data from the API every time. That means when Pandoo is loaded inside the browser and you try to use it without an Internet connection, it shows an API error (just like all the other versions of the app). I could save the last fetched data locally and load it immediately at app start (while the new is loading)… but for now, it is ok as it is.

Conclusion

I think Flutter is a strong candidate in the app development era. Not only for mobile but in general.

I did not write a single line of code to have a Mac OSX app. Although I have some experiences with Mac OSX apps (Mike) so I would have an idea where to start, it is not a copy/paste from an iOS app, you need to put some work there. Hopefully Mac Catalyst will help with this in the future.

Write an app for Windows and Linux? I would not even think about it.

The additional Web support is really nice, and it can be really useful. For example, if you have a Revolut and TransferWise account you probably noticed that the mobile apps are very similar to each other, and they also provide a Web version too with a limited feature set. I don't know what technologies they use, but (if not Flutter already) I can imagine in the future these kinds of services will consider Flutter for their apps.

Definition of ‘One Day’

Probably at this point, you think “How on Earth was this possible in one day”?

My definition of one day: 14-16 hours.

In this timeframe, I was able to develop the most important part of the app, the giant table view with all the data in it, the holiday balance view, and the way of requesting holidays one by one.
I don't count the extra menus, extra functionalities, going to the Meetup 😀.
For the additional basic Desktop support, I don't count any minute. Basically, there was no code change done, except when I saw a crash I did put an “if-else” around the problematic part and it was “fixed”. Also, the later polyfill changes were not taken into account.

Key learnings

In general:

• To build a prototype, Flutter is one of the best tools now on the market.
• You don't have to over-engineer an MVP.
• Better to know the limitations of your tool upfront than being surprised later.
• Meetups are great to meet interesting people and gather new information.

About Flutter:

• It supports Android, iOS, Web, Windows, MacOS, Linux (and Fuchsia).
• If a native third-party library exists, but there is no Flutter support yet, you can make it Flutter compatible.
• The core Dart libraries are available on all platforms, so in the worst case, you can fall-back on them.
• The community is huge.

Support

Did you enjoy my story? There is more in the pipeline… 😉

Do you want to know more insights? Would you like to discuss the used techniques, or would you like to see some part of the code? Then consider becoming a monthly supporter on Patreon via my Tweaked.Tech initiative.

Become a Patron

Why?

• The articles are published on Patreon first.
• There is a follow-up article that shares insights, used techniques, architecture, infrastructure.
• You can get early access to projects in the Beta phase.
• We can discuss your ideas, your doubts, and the current issues you face in your project.
• You keep me going, it is a big boost to my motivation!

I really appreciate a one time support too, you can do it via Buy Me A Coffee.

Buy me a coffee

Thanks for reading my story, I am grateful that you were here until the end.
Stay tuned for the next one!

I think everyone remembers the scandal (around November 2019) about an app in which the camera was activated in the “background” due to a bug. If you missed it, quickly Google it. The online media was full of these kinds of articles at that time.

Then my mind did not let me sleep…

Camera Permission on iOS

Description from Apple:

In iOS, the user must explicitly grant permission for each app to access cameras and microphones. Before your app can use the capture system for the first time, iOS shows an alert asking the user to grant your app access to the camera, as shown below. iOS remembers the user’s response to this alert, so subsequent uses of the capture system don’t cause it to appear again. The user can change permission settings for your app in Settings > Privacy.

Camera API

The Camera API usage is pretty straightforward. You define which camera hardware you would like to use, how to show a preview, and where to save the files.

The Problem

As you see from the documentation above, once the user grants the Camera Permission for an app, it is granted. Forever.

Anyone can make an application that asks for Camera Permission. e.g. taking a photo, uploading an image, setting profile picture, “scanning” document, etc. You can find many use-cases that can justify camera usage. The application can ask it for a valid reason, but after that, you don't know what can happen.

And do you know if the app is still using your camera while you are in the app? Probably not.

Let your imagination fly a bit and think about what you could do if you could have access to the user's camera anytime in the app.

You have a home decor online shop. While the user is searching for a certain item in your app you could look around in his/her house, see the colors, furniture, and your app could start suggesting extra items in matching style.

Or:

Your main revenue stream is displaying ads in your app. What if you could monitor the user's reaction to an ad? Then you could offer to your advertiser more insights about what kind of ads a certain type of user likes.

This information would be pretty valuable, right? Ethical? I don't think so.

Proof of Concept

The Good

Note: If you would like to go straight to the code, here you are: HiddenCamera app on GitHub.

As a first step, you have to define the NSCameraUsageDescription key Info.plist file of your application. You have to define a purpose string for this key why your app needs this permission. Obviously, taking pictures… right?

This description will be part of the alert message that will be shown to the users the first time when they use your app.

So, let's take a look at our CameraViewController.

We need to initialize an AVCaptureSession.

let session = AVCaptureSession()

This session is the base of everything. Here we can attach our input/output elements.

var deviceInput: AVCaptureDeviceInput!

session.sessionPreset = AVCaptureSession.Preset.vga640x480

// acquire the camera device
guard let device = AVCaptureDevice
    .default(AVCaptureDevice.DeviceType.builtInWideAngleCamera,
             for: .video,
             position: AVCaptureDevice.Position.front) else {
                return
}

do {
    deviceInput = try AVCaptureDeviceInput(device: device)
    guard deviceInput != nil else {
        print("error: can't get deviceInput")
        return
    }
    
    // add the Input device to the session
    if self.session.canAddInput(deviceInput){
        self.session.addInput(deviceInput)
    }
    
    // define a Video output device to capture video frames from the camera
    videoDataOutput = AVCaptureVideoDataOutput()
    videoDataOutput.alwaysDiscardsLateVideoFrames = true
    videoDataOutputQueue = DispatchQueue(label: "VideoDataOutputQueue")
    videoDataOutput.setSampleBufferDelegate(self, queue:self.videoDataOutputQueue)
    
    if session.canAddOutput(self.videoDataOutput){
        session.addOutput(self.videoDataOutput)
    }
    
    //define a Picture output device to capture still images from the camera
    stillImageOutput = AVCapturePhotoOutput()
    
    if session.canAddOutput(stillImageOutput) {
        session.addOutput(self.stillImageOutput)
    }
    
    videoDataOutput.connection(with: .video)?.isEnabled = true
    
    // define the camera preview view
    previewLayer = AVCaptureVideoPreviewLayer(session: self.session)
    previewLayer.videoGravity = AVLayerVideoGravity.resizeAspect
    
  	// ...
    
    // and start running the capture session
    session.startRunning()
} catch let error as NSError {
    deviceInput = nil
    print("error: \(error.localizedDescription)")
}

The startRunning() method kicks in the whole capturing process. (This will be important later!)

Now we can listen to the video delegate callbacks:

func captureOutput(_ output: AVCaptureOutput, didOutput sampleBuffer: CMSampleBuffer, from connection: AVCaptureConnection) {
    // do stuff here with the video
}

Then to the photo delegate callbacks:

func photoOutput(_ output: AVCapturePhotoOutput, didFinishProcessingPhoto photo: AVCapturePhoto, error: Error?) {
    //process single image
    guard let imageData = photo.fileDataRepresentation()
        else { return }
    
    let captureImageView = UIImageView(frame: CGRect(x: 50, y: 50, width: 100, height: 100))
    let image = UIImage(data: imageData)
    captureImageView.image = image
    
    //show the captured image
    let centerView = UIView(frame: CGRect(x: UIScreen.main.bounds.size.width / 2 - 100,
                                          y: UIScreen.main.bounds.size.height / 2 - 100,
                                          width: 200,
                                          height: 200))
    centerView.backgroundColor = UIColor.red
    centerView.addSubview(captureImageView)
    
    self.view.addSubview(centerView)
    
}

As you can see, nothing evil. We ask for permission, the user grants it, we show the video preview and the captured photo.

Let's see how it works:

The Bad

We can take a look on the CameraViewControllerHidden class. Same thing as above, but unfortunately by mistake we forgot to attach our video preview to the view.

// ...
do {
    deviceInput = try AVCaptureDeviceInput(device: captureDevice)
    guard deviceInput != nil else {
        print("error: can't get deviceInput")
        return
    }
    
    if self.session.canAddInput(deviceInput){
        self.session.addInput(deviceInput)
    }
    
    stillImageOutput = AVCapturePhotoOutput()
    
    if session.canAddOutput(stillImageOutput) {
        session.addOutput(self.stillImageOutput)
    }
    
    // we can also attach videoDataOutput from the previous example to get all the video frames
    // but for now image capturing is enough

    // and whoopsie, we forgot the preview :(
    
    session.startRunning()
}
// ...

What do we see now?

No permission was asked (previously it was granted forever), no video preview. So we think everything is alright, we are browsing our feed, watching ads, liking/disliking photos… meanwhile someone is spying on us:

Just to give you a little peace of mind: at least the camera stream is blocked while the app is in the background.

Jailbreak to the Rescue

What is Jailbreaking?

Jailbreaking is the privilege escalation of an Apple device for the purpose of removing software restrictions imposed by Apple on iOS, iPadOS, tvOS and watchOS operating systems. This is typically done by using a series of kernel patches. Jailbreaking permits root access in Apple's mobile operating system, allowing the installation of software that is unavailable through the official Apple App Store. Many types of jailbreaking are available, for different versions.

Apple publicly disapproves of jailbreaking.

There are a lot of pros and cons of jailbreaking. You can find some of these on the above-mentioned links.

Jailbreaking is for users who know what they are doing. And these people like to jailbreak for tweaking their devices. Just take a look at all the magic you can do on your iOS device once it is jailbroken.

The Tweak

The tweaks are iOS applications, however

…many of them are not typical self-contained apps but instead are extensions and customization options for iOS and its features and other apps (commonly called tweaks). Users install these programs for purposes including personalization and customization of the interface by tweaks developed by developers and designers, adding desired features and fixing annoyances…

PrivacyGuard - iOS

Note: This post is not elaborating how to develop a Jailbreak tweak. That's for a future post. If you want to hear more about it, please subscribe to the content notifications.

As you read above, most of the Jailbreak tweaks are extending the functionality of already existing apps. How? In a nutshell, they hook into existing methods in the app and react when the method is called. They can completely override it, alter its behavior, or just trigger a jailbreak code and call the original method after it.

This is exactly what we will do.

Note: If you would like to go straight to the code, here you are: PrivacyGuard-iOS tweak on GitHub.

As we saw above in the camera app examples, everything starts with the startRunning() method on AVCaptureSession.

It's time to hook!

#import <UIKit/UIKit.h>

%hook SpringBoard
-(void) applicationDidFinishLaunching:(id)arg {
	%orig(arg);
	UIAlertView *lookWhatWorks = [[UIAlertView alloc] initWithTitle:@"PrivacyGuard Tweak"
		message:@"Your privacy guard is running 😎"
		delegate:self
		cancelButtonTitle:@"OK"
		otherButtonTitles:nil];
	[lookWhatWorks show];
}
%end

%hook AVCaptureSession

// Hooking an instance method with no arguments.
-(void) startRunning {
	NSString *appName = [[NSBundle mainBundle] objectForInfoDictionaryKey:@"CFBundleIdentifier"];
	NSLog(@"PrivacyGuard startRunning: %@", appName);

	UIView *statusBar = [[UIApplication sharedApplication] valueForKey:@"statusBar"];
	statusBar.backgroundColor = [UIColor greenColor];

	%orig;

}

-(void) stopRunning {
	NSLog(@"PrivacyGuard stopRunning");

	UIView *statusBar = [[UIApplication sharedApplication] valueForKey:@"statusBar"];
	statusBar.backgroundColor = [UIColor clearColor]; // or we could save and restore the original one

	%orig;
}

// Always make sure you clean up after yourself; Not doing so could have grave consequences!
%end

Easy (for now) and beautiful!

(The first part, hooking into Springboard, just a helper notification to show the tweak is initialized.)

We hook directly into AVCaptureSession's startRunning() method. Whenever this method is called we log to the console the current app that is using the camera (initiated the capturing) and change the status bar color to green to visually notify ourselves. After this is done we just call the original (%orig) method and let the flow continue. Hooking into the stopRunning() method is useful to revert our changes after the camera is not in use anymore.

How does it look while using the example apps above?

When you have the preview visible:

And when we are in evil mode:

Also, in the logs we can see the relevant app info:

And no hidden surprises anymore.

You can go further. Showing a popup, notification, or a little icon in the status bar while the camera is in use. It is all up to you!

Note: PrivacyGuard-iOS is not available in any Jailbreak repository (yet). If you have the urge to try it, please let me know. But also feel free to compile it and tweak it for yourself.

Note: If there are other ways of accessing the camera stream those were not part of this investigation. Probably there you can use the same approach.

Conclusions

Jailbreak Tweaks

The tweaks made by the Jailbreak community are amazing. Lot of smart ideas, solutions for daily annoyances.

Having the possibility to use a jailbroken device and develop your own tweaks for your development work can be really interesting. It opens your possibilities, you have more access to the system, you can debug more things, private APIs.

It is brilliant.

Camera API

I think you can draw your own conclusion.

Be aware of your apps and used services. Maybe you don't even need those apps, just try to use the web version of those services. Check the granted permissions of your apps, maybe for your use-case it does not need extra permission.

Sensitive permissions should not be granted forever. Hopefully, Apple will fix this issue soon like Google is doing it on Android 11 now.

Disclaimer

I don't say that any of these things are happening in any apps on the market and I don't encourage you to jailbreak your iOS device.

But better to be prepared and be more privacy-conscious. Having these kinds of data collected about a user/content/ad could be valuable for certain parties.

Support

Did you enjoy my story? There is more in the pipeline… 😉

Do you want to know more insights? Would you like to discuss the used techniques, or would you like to see some part of the code? Then consider becoming a monthly supporter on Patreon via my Tweaked.Tech initiative.

Become a Patron

Why?

• The articles are published on Patreon first.
• There is a follow-up article that shares insights, used techniques, architecture, infrastructure.
• You can get early access to projects in the Beta phase.
• We can discuss your ideas, your doubts, and the current issues you face in your project.
• You keep me going, it is a big boost to my motivation!

I really appreciate a one time support too, you can do it via Buy Me A Coffee.

Buy me a coffee

Thanks for reading my story, I am grateful that you were here until the end.
Stay tuned for the next one!