Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Basic Security Testing / Reverse Engineering and Tampering" Chapters Restructuring #970

Closed
cpholguera opened this issue Aug 13, 2018 · 12 comments

Comments

@cpholguera
Copy link
Collaborator

commented Aug 13, 2018

As I was reviewing the chapters on Android and iOS Basic Security Testing / Reverse Engineering and Tampering (0x5b/5c and 0x6b/6c), I found that sometimes they are a bit mixed-up. In addition, if you read one and then go to the other you will find a completely different structure.

owasp_mstg_issues6b_6c 002
owasp_mstg_issues6b_6c 003
owasp_mstg_issues6b_6c 004
owasp_mstg_issues6b_6c 005

Of course the way we perform the testing on the different platforms is completely different but at the end, what we want to do is the same. The proposed unified structure for both chapters should:

  • Be consistent by
    • Avoiding repetition of some specific content (e.g. Installing Frida, Setting up the Android SDK)
    • Avoiding mixing of general content like Static/Dynamic Analysis (present on both sections)
    • Adding missing content (e.g. "app folder structure", "copying app data files" are only present in the iOS chapters)
  • Provide a clear methodology / way-to-go for both platforms that will facilitate the first reading and the further reading of the other platform (e.g. I already learn the organized approach in 0x5b/5c and I want to start with iOS by reading 0x6b/6c. With the new structure I directly find what I may expect, i.e. the same structured way-to-go, after reading 0x5b/5c).
  • Revise tools that might be outdated, (e.g. ipainstaller) and add new tools or techniques (e.g. r2frida).
  • Relate to 0x4b (Mobile App Security Testing) and 0x4c (Tampering and Rev.Eng.)

At the end, as a mobile security tester, I normally want to do the same: work on a device with root access, get a shell, install apps, reverse apps, patch, debug, inject code, trace/dump stuff, access files, ...

Based on all of the previous points I have crafted the structure as a first draft that I would like to discuss with you. This could be implemented in several steps / tickets one per chapter, that would re-structure and re-organize them keeping all the current content, removing duplicates and adding the new stuff.

Here are the proposed outlines for the four chapters:

0x5b/6b Basic Security Testing

Setting up a Testing Environment

Host Device

Testing Device

Real Device vs Emulator
Getting Privileged Access
Recommended Setup

Basic Testing Operations

Accessing the Device Shell

On-device Shell App
Remote Shell

Information Gathering

Installed Apps
App Basic Information
Permissions
Native Libs
...
Accessing App Data (what to expect, where, sandbox structure)
Monitoring System Logs

Obtaining and Extracting Apps

App Store
App Decryption (iOS only)
App Thinning (iOS only)
Recovering the App Package from the Device
From Rooted / Jailbroken Devices
From Non-Rooted / Non-Jailbroken Devices

Installing Apps

Host-Device Data Transfer

0x5c/6c Reverse Engineering and Tampering

Reverse Engineering

Disassembling and Decompiling

Tooling (radare2, IDA, Hopper, Bin. Ninja)
Java / Objective-C and Swift
Native Libraries

Static Analysis

Manual (Reversed) Code Review

Java / Objective-C and Swift
Native Libraries

Basic Information Gathering

Strings
Call Diagrams and Cross References
API Usage (Bluetooth, NFC, Crypto ...) -> just refer to 0x05d-j/0x06d-j
Check Secure Connections (HTTPS, TLS, cert. pinning, ATS) -> just refer to 0x05g/0x06g

Automatic Code Analysis

Dynamic Analysis

Basic Information Gathering

Opened Files
Opened Connections
Loaded Native Libraries
Sandbox Inspection (Files and Permissions)

Debugging

Debugging Release Apps
Debugging Native Libraries

Dynamic Analysis on Non-Rooted/Non-Jailbroken Devices

Tracing

Execution Tracing (calls)
Method Tracing (parameters and returns)
Native Libraries Tracing

Emulation-based Analysis (Android only)

Binary Analysis

Angr
Symbolic Execution

Tampering and Runtime Instrumentation

Patching

Patching Release Apps
Patching Native Libraries

Re-Packaging

Library Injection

Re-Signing

Dynamic Instrumentation

Tooling (Xposed (Android only), Frida)
Information Gathering
Getting Loaded Libraries
Getting Loaded Classes and their Methods
Getting Runtime Dependencies
Method Hooking
Process Exploration (r2frida)
Memory Maps and Inspection
In-Memory Search
Memory Dump
Runtime Reverse Engineering

OS-specific customization (Android only)

Customizing the RAMDisk

Customizing the Android Kernel

Booting the Custom Environment

System Call Hooking with Kernel Modules

@commjoen

This comment has been minimized.

Copy link
Collaborator

commented Aug 14, 2018

Thank you for the wonderful description of the issue! Is it ok if can can have a call first about it? Because changing the structure is quiet impactful at this point in time.

@commjoen

This comment has been minimized.

Copy link
Collaborator

commented Dec 30, 2018

Scheduled to be taken care of during the OSS2019! https://open-security-summit.org/working-sessions/mobile/restructure/

@commjoen

This comment has been minimized.

Copy link
Collaborator

commented Jan 11, 2019

Don't forget to update the excel after this :)

@TheDauntless

This comment has been minimized.

Copy link
Collaborator

commented Apr 23, 2019

Will we move to make a direct link between MASVS and MSTG? Just like ASVS and the security testing guide?

For a very large part of the content, this would make good sense.

@commjoen commjoen added this to the 1.3 Release milestone May 13, 2019

@commjoen commjoen added this to To do in OWASP MSTG May 13, 2019

@commjoen commjoen moved this from To do to In progress in OWASP MSTG May 13, 2019

@commjoen

This comment has been minimized.

Copy link
Collaborator

commented May 16, 2019

I think having direct links (excel file? and masvs?) will make sense. Moreover, some of the stuff is still os-dependent, while it might make more sense to say that these items can be written for both os's as well. The challenge is still a bit for some of the content: where should it go to (for instance: teh static analysis which should be moved out: where to?)

@commjoen

This comment has been minimized.

Copy link
Collaborator

commented May 17, 2019

what i think is still pretty important, is to keep the restructuring as fast and as painless as possible: let's first reuse existing content and restructure BEFORE we are going to write a lot of new content :),. this way other people adding content will not introduce a lot of merging conflicts.

@commjoen

This comment has been minimized.

Copy link
Collaborator

commented May 31, 2019

Can we close this?

@cpholguera

This comment has been minimized.

Copy link
Collaborator Author

commented May 31, 2019

@TheDauntless

This comment has been minimized.

Copy link
Collaborator

commented Jun 4, 2019

I'm aligning iOS and Android from a structure point of view

@commjoen commjoen moved this from In progress to Ready for review in OWASP MSTG Jul 23, 2019

@commjoen

This comment has been minimized.

Copy link
Collaborator

commented Jul 24, 2019

@cpholguera : can we now close this issue :D ?

@cpholguera

This comment has been minimized.

Copy link
Collaborator Author

commented Jul 24, 2019

Yes! We finally made it :D

@commjoen

This comment has been minimized.

Copy link
Collaborator

commented Jul 24, 2019

Congratulations!!! YOU and the team worked hard on this one! Finally!!!!! Whooohoooo!

@commjoen commjoen closed this Jul 24, 2019

OWASP MSTG automation moved this from Ready for review to Done Jul 24, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
4 participants
You can’t perform that action at this time.