trueseeing - Non-decompiling iOS/Android app vulnerability scan

项目说明

README

!Last release
!Last release date
!Main branch deploy status
!Main branch last commit

trueseeing is a fast, accurate and resillient scanner for iOS/Android apps. We operate on the Dalvik for Android -- i.e. we don't care if the target app is obfuscated or not.

Capability

Currently we can:

* Automatically scan app for , reporting in HTML/JSON/text format (see below)
* Manipulate app for easier analysis: e.g. enabling debug bit, enabling full backup, disabling TLS pinning, manipulating target API level, injecting frida-gadget, etc.
* Examine app for general information
* Copy in/out app data through debug interface
* Search for certain calls/consts/sput/iput
* Deduce constants/typesets for args of op
* Scan API/private calls for nati (NB: you need ts2-disasm-ghidra)
* Scan iOS apps for basic (NB: you need ts2-disasm-ghidra)
* Attach frida scripts
* Provide frida interati
* Tracing calls
* etc.

Installation

Containers

NOTE:
* As of 2.1.9, we are on ghcr.io. (Docker Hub is somewhat deprecated)
* Requires adbd in the host to control devices.

We provide containers so you can use right away as follows; now this is also the recommended way, and the only way if you are on Windows, to run:

$ docker run --rm -v $(pwd):/out -v ts2:/cache ghcr.io/alterakey/trueseeing

If you want to run statelessly you omit mounting onto /cache (not recommended for day-to-day use though; also see #254):

$ docker run --rm -v $(pwd):/out ghcr.io/alterakey/trueseeing

Install with uv

Alternatively, you can install our package with uv as follows. Especially the uv tool install form of installation might be useful for extensions (see below), as it grants them the greatest freedom. Just remember you need a JRE and Android SDK (optionally; to mess with devices):

$ u

$ uv tool install trueseeing
$ trueseeing

Install with pip (deprecated)

Of course you can always use the good old pip if you must:

$ pip install trueseeing

Usage

Interactive mode

You can interactively scan/analyze/patch/etc. apps -- making it the ideal choice for manual analysis:

$ trueseeing target.apk
[+] trueseeing x.y.z
ts[target.apk]> ?
...
ts[target.apk]> i # show generic information
...
ts[target.apk]> pf AndroidManifest.xml # show manifest file
...
ts[target.apk]> a # analyze resources too
...
ts[target.apk]> /s something # search text
...
ts[target.apk]> as # scan
...
[+] done, found 6403 issues (174.94 sec.)
ts[target.apk]> gh report.html

Batch mode

We accept an inline command (-c) or script file (-i) to run before giving you prompt, as well as quitting right away instead of prompting (-q; we don't require a tty in this mode!).

You can use the features to conduct a batch scan, as follows e.g. to dump findings right onto the stderr:

$ trueseeing -eqc 'as' target.apk

To generate a report file in HTML format:

$ trueseeing -eqc 'as;gh report.html' target.apk

To generate a report file in JSON format:

$ trueseeing -eqc 'as;gj report.json' target.apk

To get report generated in stdout, omit filename from final g* command:

$ trueseeing -eqc 'as;gh' target.apk > report.html
$ trueseeing -eqc 'as;gj' target.apk > report.json

Non-interactive scan mode (deprecated)

Traditionally, you can scan apps with the following command line to get findings listed in stderr:

$ trueseeing --scan target.apk

To generate a report in HTML format:

$ trueseeing --scan --scan-output report.html target.apk
$ trueseeing --scan --scan-report=html --scan-output report.html target.apk

To generate a report in JSON format:

$ trueseeing --scan --scan-report=json --scan-output report.json target.apk

To get report generated in stdout, specify '-' as filename:

$ trueseeing --scan --scan-output - target.apk > report.html
$ trueseeing --scan --scan-report=html --scan-output - target.apk > report.html
$ trueseeing --scan --scan-report=json --scan-output - target.apk > report.json

Ad Usages

Extensions

You can write your own commands and signatures as extensions. Extensions are placed under /ext (containers) or ~/.trueseeing2/extensions/ (uv/pip) . Alternatively you can distribute your extensions as wheels. We provide type information so you can not only type-check your extensions with zuban but also get a decent assist from IDEs. See the details section for details.

Build

You can build it as follows:

$ docker build -t trueseeing

To build wheels you can do with flit, as follows:

$ flit build

To hack it, you need to create a proper build en. With uv you could just do:

$ git clone wc
$ uv sync --locked --dev
$ (... hack ...)
$ uv run trueseeing ... # to run
$ uv run zuban check trueseeing && uv run ruff trueseeing # to
Success: no issues found in XX source files
$ uv run flit build # to build (wheel)
$ docker build -t trueseeing . # to build (container)

With pip, to create one, firstly set up a ven flit and toolchains (zuban and ruff) in there, and have flit pull dependencies. In short, do something like this:

$ git clone wc
$ python3 -m venv wc/.venv
$ source wc/.venv/bin/activate
(.venv) $ pip install flit zuban ruff
(.venv) $ flit install --deps=develop -s
(.venv) $ (... hack ...)
(.venv) $ trueseeing ... # to run
(.venv) $ zuban check trueseeing && ruff check trueseeing # to
Success: no issues found in XX source files
(.venv) $ flit build # to build (wheel)
(.venv) $ docker build -t trueseeing . # to build (container)

Details

Classes

Currently we can detect the following class of , largely ones covered in OWASP Mobile Top 10 - 2016:

* Improper Platform Usage (M1)

* Debuggable
* Inadvent publishing of Acti, Services, ContentPro, BroadcastReceivers

* Insecure Data (M2)

* Backupable (i.e. suspectible to the backup attack)
* Insecure file permissions
* Logging

* Insecure Commnications (M3)

* Lack of pinning (i.e. suspictible to the TLS interception attack)
* Use of cleartext HTTP
* Tamperable WebViews

* Insufficient Cryptography (M5)

* Hardcoded passphrase/secret keys
* ciphers with static keys
* Use of the ECB mode

* Client Code Quality Issues (M7)

* Reflectable WebViews (i.e. XSSs in such views should be escalatable to remote code executions via JS reflection)
* Usage of insecure policy on mixed contents

* Code Tampering (M8)

* Hardcoded certificates

* Reverse Engineering (M9)

* Lack of obfuscation

Extension API

Our extension API lays under the trueseeing.api package. As we provide type information with it, your IDE will assist you when writing your extensions. Just make sure its (or its language server's) PYTHONPATH covers the venv in where our package; see uv tool list --show-paths if you installed it with uv tool install. If you installed with uvx, consider re-install it with u. If you installed with pip, you' know where it is.

#### Commands

To define new commands, implement trueseeing.api.Command and ad them.

The following class will provide a sample command as t, for example:

#### Signatures

To define new signatures, implement trueseeing.api.Signature and ad them.

The following class will provide a sample detector as my-sig, for example:

#### File Formats

To define new file formats, firstly implement Contexts (ABC) for your formats, then implement trueseeing.api.FileFormatHandler to create and return their instances, and ad them.

The following class will provide APK file support under the type named apk2, for example:

Then make sure you check for the type of the context in your signatures, making them ignored on unsupported contexts:

Upon successful check, require_type(...) will try to downcast them to appropriate types for your con.

But by design it works only for known types (currently, the apk). So if you are defining some detailed interface in your new context classes as we do for the apk type, you need to do a downcast here i.e.:

It is possible to define multiple formats matching the same pattern. We e patterns in the order of from the most stringent (i.e. long) to the least. You use the -F switch to force some format to use with the target file, e.g.:

#### Package requirements

Extensions can be either: a) any package placed under /ext (container) or ~/.trueseeing2/extensions (pip), or b) any installed module named with the prefix of trueseeing_ext0_.

Origin of Project Name?

The D&D spell, True Seeing.

项目信息

开发语言：Python

Star 数：72

技术要点

该项目属于安全软件方向的开源资源，代码结构清晰，适合安全研究人员学习参考。项目围绕Non-decompiling iOS/Android app vulnerability scanner (DC25 demo lab, CB17)展开，提供了可运行的实现，对理解相关安全机制、工具原理与攻防技术具有较高的研究价值。

从技术实现角度看，此类项目的核心在于对底层原理的深入理解与工程化落地。开发者在研究过程中可以结合官方文档与社区讨论，梳理项目的初始化流程、核心模块职责与数据流转，逐步掌握其中的技术细节与设计思路。

使用与学习建议

1. 下载源码压缩包，解压到本地环境。

2. 根据项目类型准备对应的运行环境与依赖。

3. 按照 README 中的步骤完成配置与部署。

4. 在隔离的测试环境中运行验证，避免影响生产系统。

免责声明

本资源来源于开源社区，仅供安全研究、技术学习与合法授权范围内的攻防演练使用，请勿用于任何非法或侵害他人权益的用途。使用本项目产生的一切后果由使用者自行承担。