Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Malimite – iOS and macOS Decompiler

github.com

Post reply on HN
Print view View original

11–20 of 39 posts

Re: Malimite – iOS and macOS Decompiler

#11

Post by adeon »

Starting this year I started learning bunch of security topics and Ghidra is something I started learning. I decompiled some games and getting comfortable how to work a project, teach Ghidra structures etc.

Am I right in looking at Malimite here and reading "Built on top of Ghidra decompilation to offer direct support for Swift, Objective-C, and Apple resources." that this is not a Ghidra extension but rather it is using a piece of Ghidra (the decompilation) like a backend? Malimite here is presented as its own piece of software.

Asking as a Ghidra noob who doesn't know all the ways Ghidra can be used: Would it make sense for something like this to be a Ghidra extension instead? I.e. give Ghidra some tooling/plugin to understand iOS apps or their languages better, instead of a new app that just uses parts of Ghidra. Also the Malimite screenshot in the page looks similar to Ghidra CodeBrowser tool.

Asking because it feels like it could be: from the little I've used Ghidra so far, looks like it is designed to be extendable, scriptable, usable by a team collaborating, etc. And Ghidra seems more holistic than just focusing on decompiling code.

Re: Malimite – iOS and macOS Decompiler

#13

Post by judge2020 »

surlyville wrote: post #9
commandersaki wrote: post #7

This is all well and good, but at least for iOS my understanding is you cannot decompile unless you have a jailbroken iPhone or security research device. Makes things a bit difficult.

Jailbreak not required. I use TrollStore/TrollDecrypt but I'm sure there are other methods.

For reference, it's possible because of a AMFI/CoreTrust bug in older iOS:

https://github.com/opa334/TrollStore/blob/main/README.md

> It works because of an AMFI/CoreTrust bug where iOS does not correctly verify code signatures of binaries in which there are multiple signers.

> Supported versions: 14.0 beta 2 - 16.6.1, 16.7 RC (20H18), 17.0

This seemed to happen because they didn't have time to release 17 with the bug fixed, which is why 16.7 Final is not supported; per https://x.com/MasterMike88/status/1743974453459956209

Re: Malimite – iOS and macOS Decompiler

#14

Post by lauriewired »

Hi everyone, I'm the creator of Malimite. I actually released this as part of a conference talk at Objective By the Sea, which you can see here:

https://youtu.be/vWdKjVCZtTI

It gives a good overview of the development process as well as my motivations for creating it. The tool will also be on homebrew shortly :)

Re: Malimite – iOS and macOS Decompiler

#15

Post by lauriewired »

adeon wrote: post #11

Starting this year I started learning bunch of security topics and Ghidra is something I started learning. I decompiled some games and getting comfortable how to work a project, teach Ghidra structures etc. Am I right in looking at Malimite here and reading "Built on top of Ghidra decompilation to offer direct support for Swift, Objective-C, and Apple resources." that this is not a Ghidra extension but rather it is u…

It might be better to think of Malimite as "JADX but for iOS/Mac".

(JADX is a very popular Android decompiler)

Ghidra is quite limiting, and the workflow makes iOS reverse engineering quite cumbersome.

Malimite is intended to have a swappable back-end, so theoretically compilers other than Ghidra can be used in the future.

Re: Malimite – iOS and macOS Decompiler

#16

Post by lauriewired »

saagarjha wrote: post #2

(This is LLM-powered and based on Ghidra, fwiw)

It’s more like LLM-optional.

Malimite is first and foremost intended to be a tool to help Reverse Engineer iOS/Mac binaries, much like JADX for Android.

As it turns out, LLMs are quite good at “converting” C-Pseudocode into an approximation of the original Swift or Objective-C code. Therefore, you can optionally use the LLM extension to help analysis.

Of course, it’s not 100% accurate, but significantly easier to read, and I find it to save hours of manual research.

Re: Malimite – iOS and macOS Decompiler

#17

Post by ghostpepper »

lauriewired wrote: post #15
adeon wrote: post #11

Starting this year I started learning bunch of security topics and Ghidra is something I started learning. I decompiled some games and getting comfortable how to work a project, teach Ghidra structures etc. Am I right in looking at Malimite here and reading "Built on top of Ghidra decompilation to offer direct support for Swift, Objective-C, and Apple resources." that this is not a Ghidra extension but rather it is u…

It might be better to think of Malimite as "JADX but for iOS/Mac". (JADX is a very popular Android decompiler) Ghidra is quite limiting, and the workflow makes iOS reverse engineering quite cumbersome. Malimite is intended to have a swappable back-end, so theoretically compilers other than Ghidra can be used in the future.

What parts of ghidra do you find most limiting? I thought it was supposed to be "almost as good" as IDA in terms of features, if not UX polish.

Re: Malimite – iOS and macOS Decompiler

#19

Post by lauriewired »

ghostpepper wrote: post #17
lauriewired wrote: post #15

Earlier quoted context omitted.

It might be better to think of Malimite as "JADX but for iOS/Mac". (JADX is a very popular Android decompiler) Ghidra is quite limiting, and the workflow makes iOS reverse engineering quite cumbersome. Malimite is intended to have a swappable back-end, so theoretically compilers other than Ghidra can be used in the future.

What parts of ghidra do you find most limiting? I thought it was supposed to be "almost as good" as IDA in terms of features, if not UX polish.

Ghidra is very feature-rich for code decompilation, however it doesn't handle dropping in an entire application bundle; only single executables.

Apple application files are special, bundling up resources and (potentially multiple) executables into the same package.

Many of these resource files are important for analysis, but have custom encodings by Apple. Malimite "digests" this information into a logical way.

Re: Malimite – iOS and macOS Decompiler

#20

Post by jhbadger »

LeoPanthera wrote: post #8
rgovostes wrote: post #3

Earlier quoted context omitted.

The prompts used are in this file: https://github.com/LaurieWired/Malimite/blob/main/src/main/j...

Who would have guessed just a few years ago that the final programming language would be English.

In the 1980s/early 1990s when HyperCard was king, that would have made sense. And in the late 1990s/early 2000s when Applescript was a thing people cared about, too. But yes, for the last twenty years or so, English-like programming languages weren't the thing.
Post reply on HN