Archiv der Kategorie: Allgemein

SwiftAlyzer is progressing

In April I talked about my newest projekt, SwiftAlyzer, a tool to analyze the quality of software projects written in the Swift programming language. There’s now a clear milestone plan for the closed alpha and public beta releases. Right now, we’re heading for the alpha release and it looks pretty neat already. If you’re interested in joining the closed alpha programming, just drop me a line on Twitter pm or here:
In the last few days worked on these little loading animation. I’ll shortly write a little tutorial on how to create this image layer masking effect. Stay tuned ✌️

Smartified Garage Door

Making the best out of Corona-wise cancelled sports evenings, there was suddenly enough time to smartify my garade door. It already has connectors on the garage door hardware. That way, I could connect a button to the board that is used to open and close the garage. But what was missing is a way to control it remotely. Since the remote went missing it was nearby to integrate the button into my smart home setup: Homematic actuators and a raspberry pie transferring all traffic via MQTT.
As there’s already the possibility to control radio-relays via MQTT, the next move was to replace the connection from the button to board with a circuit integrating the relay HM-LC-Sw1-FM.
But there was one problem. The relay works with an input and output voltage of 230V. That’s too much to control the board on the garage opener. So I had to integrate another relay that could switch an arbitrary input voltage but works with a rated Control Supply Voltage of 230V. I finally came up with an relay by Entrelec.

Now to the fun part. Connecting all parts together according to the wiring on the left. The Entrelec relay is directly connected to the garage opener board. The control supply is provided by the Homematic relay. The switch input of the Homematic relay is provided by the hardware button and finally some 230V to feed the relay. That’s it.

In order to test it, there’s no faster prototyping than to use Node-Red. It enables visually wiring up a control that either automates a workflow or provides a rudimentary GUI. In this case, it’s a simple UI consisting of one toggle labeled „Garage“ sending out a message to the MQTT broker to fire up the Homematic relay.
Since that’s quite a boring interface, the next step was to write a control app, fooling around with Combine and SwiftUI. But that’s a story for another time 😉

If your iOS code signing fails today

If your iOS code signing fails today, it may be due to an expired Apple Intermediate Certificate.

What you need for code signing beside your valid developer or distribution certificate is the
Apple Worldwide Developer Relations Certification Authority. It expired yesterday and there’s probably already a new one side by side in your keychain. (If not, download and install the new one here: WWDR Certificate (Expiring 02/07/23)) Alas, the expired one interferes with the chain of trust and as a result you get a

„This certificate has an invalid issuer.“

To get rid of this error, you simply have to delete the expired one
in three easy steps:

  1. Open the Keychain Access utility
  2. In the menu, select View -> Show Expired Certificates
    Screen Shot 2016-02-15 at 10.50.14
  3. Make sure to delete the expired “Apple Worldwide Developer Relations*” certificates from all keychains (probably login and system).
    Screen Shot 2016-02-15 at 10.50.06 copy

Now everything should work like a charm again 😉

Find out iOS SDK version from IPA

Recently I updated xcode on our CI server and additionally provide the option to use older xcode versions per project.
To verify that the option works I wanted to find out the iOS SDK version from the provided ipa.

Here we go:
Assuming the app is named APPNAME and the ipa my-app.ipa.

  1. rename my-app.ipa to
  2. unzip (Now we’ve got a folder named Payload)
  3. execute the following bash command:
    otool -l Payload/ | fgrep --after-context=3 LC_VERSION_MIN_IPHONEOS
  4. (Alternative)
    plutil -p Payload/ | grep DTSDKName

The output is something similar to:

cmdsize 16
version 7.0
sdk 8.4
cmdsize 16
version 7.0
sdk 8.4

UIWebView Cross Site Scripting Vulnerability

When integrating UIWebViews you have to pay attention to how the desired webpage is being loaded.
That’s why Apple lately added the following lines to the documentation of UIWebView:

To help you avoid being vulnerable to security attacks, be sure to use this method [-loadHTMLString:baseURL:] to load local HTML files; don’t use loadRequest:.

Loading a website via loadRequest: bears the risk of Cross Site Scripting, since it does not enforce the Same Origin Policy, i.e., access to resources of other websites or within the bundle container of the app is possible.

When installing an app on iOS, the following containers are being generated:

  • Bundle container
  • Data container
  • possibly an iCloud container

Without enforcing the Same Origin Policy a HTML file running inside a UIWebView can access resources within the bundle container of the app.

Example Attack Scenario

Screen Shot 2015-08-04 at 13.22.40
Hacking an app’s imprint webview with the aid of Charles.

Applying a Man-in-the-middle attack I could pass a primed website off as the desired app’s imprint website. An attacker could now prompt for sensitive data and capture it.

Furthermore, the attacker could access sqlite cache files or other sensitive resources inside the bundle container. But since this attack requires guessing the id of the sandbox, which is part of the required URL, this is not very likely to happen.


A solution is to use the methodsloadData:baseURL:orloadData:MIMEType:textEncodingName:baseURL: to load external websites and specifying the baseURL property to point to the host of the desired website, preventing access to resources on different hosts.

Alternatively you could implement webView:shouldStartLoadWithRequest:navigationType: of the UIWebViewDelegate protocol, inspecting every request’s host address and whitelisting which to allow.