Loading from memory
Building shellcode and playing with assembly is my idea of fun. In this article I introduce shellcode that executes to download a dynamic library from a TCP connection and loads it without ever touching the disk. On MacOS, there are several methods of doing that , but I would like to show another alternative which possibly requires less code to implement.
Some folks lost their touch
In an earlier post, I introduced CHAOTICMARCH - simple tool for simulating a user’s interaction with an App for blackbox testing. The tool worked well and has helped me a lot with testing. However, all was not well. Every now and then, too often for my comfort, the tool’s requests for touch were getting ignored. For example, CHAOTICMARCH would find a button and try to click it. The event would get logged and the little circle would show up on the screen. However, the App would ignore the request as if nothing happened. This become very frustrating to me and I was determined to find the root cause. Investigating this behavior took me down a deep rabbit hole. To find my way out, I built LLDB scripts, learned about iOS IPC and read lots of code. With this post, I would like to share my insights, lessons and scripts.
A little something for your reversing habits.
I’m a big fan of binary reverse engineering. I think it’s a unique skill to have and it creates an interesting way of thinking. The way of thinking that forces you to figure out how things work, even if you’re trying to enjoy some iced tea on the beach. Most of my reversing life has been spent on either x86_64 or ARM64 architectures. I would even go as far as to claim that I know those instruction sets well. However, every now and then I come across a strange looking instruction - like
UNPCKLPS, I have to break my flow open the Intel Reference manual and look up the instruction’s meaning. Same for when I’m trying to understand semantics of a very common instruction. For example,
SUB can be used atomically if it has the LOCK prefix set - not a detail that comes up often.
Automating the UI for blackbox testing
During blackbox security testing, it is often the case that you need to explore the application. Mostly to understand what it does and what sort of interactions it has with the outside world. It is also a good way to determine what code a user might end up exercising during their use of the application. In case of iOS, most of the App activity will be user triggered and the other parts will be things like polling of the web api for changes. Either way, the App’s activity and any potential vulnerabilities are largely triggered by the user.