mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/mobile-pentesting/android-app-pentesting/reversing-nati
This commit is contained in:
Translator
parent
eb5801b8f5
commit
62f1040ba8
@ -1,8 +1,8 @@
|
||||
# Malware विश्लेषण
|
||||
# Malware Analysis
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Forensics CheatSheets
|
||||
## Forensics चीटशीट्स
|
||||
|
||||
[https://www.jaiminton.com/cheatsheet/DFIR/#](https://www.jaiminton.com/cheatsheet/DFIR/)
|
||||
|
||||
@ -24,8 +24,8 @@ sudo apt-get install -y yara
|
||||
```
|
||||
#### नियम तैयार करें
|
||||
|
||||
इस स्क्रिप्ट का उपयोग github से सभी yara malware rules को डाउनलोड और मर्ज करने के लिए करें: [https://gist.github.com/andreafortuna/29c6ea48adf3d45a979a78763cdc7ce9](https://gist.github.com/andreafortuna/29c6ea48adf3d45a979a78763cdc7ce9)\
|
||||
Create the _**rules**_ directory and execute it. यह _**malware_rules.yar**_ नाम की एक फ़ाइल बनाएगा जिसमें malware के लिए सभी yara rules शामिल होंगे।
|
||||
इस स्क्रिप्ट का उपयोग करके github से सभी yara malware rules डाउनलोड और मर्ज करें: [https://gist.github.com/andreafortuna/29c6ea48adf3d45a979a78763cdc7ce9](https://gist.github.com/andreafortuna/29c6ea48adf3d45a979a78763cdc7ce9)\
|
||||
Create the _**rules**_ directory and execute it. This will create a file called _**malware_rules.yar**_ which contains all the yara rules for malware.
|
||||
```bash
|
||||
wget https://gist.githubusercontent.com/andreafortuna/29c6ea48adf3d45a979a78763cdc7ce9/raw/4ec711d37f1b428b63bed1f786b26a0654aa2f31/malware_yara_rules.py
|
||||
mkdir rules
|
||||
@ -36,9 +36,9 @@ python malware_yara_rules.py
|
||||
yara -w malware_rules.yar image #Scan 1 file
|
||||
yara -w malware_rules.yar folder #Scan the whole folder
|
||||
```
|
||||
#### YaraGen: malware के लिए जांच करें और नियम बनाएं
|
||||
#### YaraGen: malware की जाँच और नियम बनाएँ
|
||||
|
||||
आप [**YaraGen**](https://github.com/Neo23x0/yarGen) टूल का उपयोग करके किसी binary से yara rules जनरेट कर सकते हैं। इन ट्यूटोरियल्स को देखें: [**Part 1**](https://www.nextron-systems.com/2015/02/16/write-simple-sound-yara-rules/), [**Part 2**](https://www.nextron-systems.com/2015/10/17/how-to-write-simple-but-sound-yara-rules-part-2/), [**Part 3**](https://www.nextron-systems.com/2016/04/15/how-to-write-simple-but-sound-yara-rules-part-3/)
|
||||
आप बाइनरी से yara rules जनरेट करने के लिए टूल [**YaraGen**](https://github.com/Neo23x0/yarGen) का उपयोग कर सकते हैं। इन ट्यूटोरियल्स को देखें: [**Part 1**](https://www.nextron-systems.com/2015/02/16/write-simple-sound-yara-rules/), [**Part 2**](https://www.nextron-systems.com/2015/10/17/how-to-write-simple-but-sound-yara-rules-part-2/), [**Part 3**](https://www.nextron-systems.com/2016/04/15/how-to-write-simple-but-sound-yara-rules-part-3/)
|
||||
```bash
|
||||
python3 yarGen.py --update
|
||||
python3.exe yarGen.py --excludegood -m ../../mals/
|
||||
@ -49,7 +49,7 @@ python3.exe yarGen.py --excludegood -m ../../mals/
|
||||
```
|
||||
sudo apt-get install -y clamav
|
||||
```
|
||||
#### स्कैन
|
||||
#### Scan
|
||||
```bash
|
||||
sudo freshclam #Update rules
|
||||
clamscan filepath #Scan 1 file
|
||||
@ -57,26 +57,27 @@ clamscan folderpath #Scan the whole folder
|
||||
```
|
||||
### [Capa](https://github.com/mandiant/capa)
|
||||
|
||||
**Capa** executables में संभावित malicious **capabilities** का पता लगाती है: PE, ELF, .NET. इसलिए यह Att\&ck tactics जैसी चीज़ें, या निम्नलिखित suspicious capabilities जैसी चीज़ें खोजेगी:
|
||||
**Capa** संभावित रूप से दुर्भावनापूर्ण **capabilities** को executables: PE, ELF, .NET में पहचानता है। इसलिए यह Att\&ck tactics जैसी चीज़ें या निम्नलिखित संदिग्ध क्षमताओं को ढूँढेगा:
|
||||
|
||||
- check for OutputDebugString error
|
||||
- run as a service
|
||||
- create process
|
||||
- OutputDebugString error की जाँच
|
||||
- सेवा के रूप में चलना
|
||||
- process बनाना
|
||||
|
||||
इसे [**Github repo**](https://github.com/mandiant/capa) में प्राप्त करें।
|
||||
Get it int he [**Github repo**](https://github.com/mandiant/capa).
|
||||
|
||||
### IOCs
|
||||
|
||||
IOC का मतलब Indicator Of Compromise है। एक IOC उन शर्तों का सेट है जो किसी संभावित unwanted software या confirmed **malware** को पहचानती हैं। Blue Teams इस तरह की परिभाषा का उपयोग अपने **systems** और **networks** में इस तरह की malicious files को खोजने के लिए करते हैं।\
|
||||
इन परिभाषाओं को share करना बहुत उपयोगी है क्योंकि जब किसी कंप्यूटर में malware पहचाना जाता है और उस malware के लिए एक IOC बनाया जाता है, तो अन्य Blue Teams उसे तेजी से पहचानने के लिए इसका उपयोग कर सकती हैं।
|
||||
IOC means Indicator Of Compromise. एक IOC उन **conditions that identify** की एक सेट होती है जो कुछ संभावित अनचाहे सॉफ़्टवेयर या पुष्ट **malware** की पहचान करती है। Blue Teams इस प्रकार की परिभाषा का उपयोग अपने **systems** और **networks** में इस प्रकार की दुर्भावनापूर्ण फ़ाइलों की **search for this kind of malicious files** के लिए करते हैं.\
|
||||
|
||||
IOC बनाने या संशोधित करने के लिए एक tool है [**IOC Editor**](https://www.fireeye.com/services/freeware/ioc-editor.html)**.**\
|
||||
आप ऐसे tools उपयोग कर सकते हैं जैसे [**Redline**](https://www.fireeye.com/services/freeware/redline.html) जो किसी device में defined IOCs को खोजने के लिए हैं।
|
||||
इन परिभाषाओं को साझा करना बहुत उपयोगी होता है क्योंकि जब किसी कंप्यूटर में malware की पहचान होती है और उस malware के लिए IOC बनाया जाता है, तो अन्य Blue Teams इसका उपयोग करके malware को तेज़ी से पहचान सकती हैं।
|
||||
|
||||
IOC बनाने या संशोधित करने के लिए एक टूल [**IOC Editor**](https://www.fireeye.com/services/freeware/ioc-editor.html)**.**\
|
||||
आप [**Redline**](https://www.fireeye.com/services/freeware/redline.html) जैसे टूल का उपयोग **परिभाषित IOCs को किसी डिवाइस में खोजने के लिए** कर सकते हैं।
|
||||
|
||||
### Loki
|
||||
|
||||
[**Loki**](https://github.com/Neo23x0/Loki) Simple Indicators of Compromise के लिए एक scanner है।\
|
||||
Detection निम्न चार detection methods पर आधारित है:
|
||||
[**Loki**](https://github.com/Neo23x0/Loki) is a scanner for Simple Indicators of Compromise.\
|
||||
Detection is based on four detection methods:
|
||||
```
|
||||
1. File Name IOC
|
||||
Regex match on full file path/name
|
||||
@ -92,41 +93,41 @@ Compares process connection endpoints with C2 IOCs (new since version v.10)
|
||||
```
|
||||
### Linux Malware Detect
|
||||
|
||||
[**Linux Malware Detect (LMD)**](https://www.rfxn.com/projects/linux-malware-detect/) एक Linux के लिए malware स्कैनर है जो GNU GPLv2 license के अंतर्गत जारी किया गया है, और इसे shared hosted environments में आने वाले threats के मद्देनज़र डिज़ाइन किया गया है। यह network edge intrusion detection systems से threat data का उपयोग करके उन malware को पहचानता और निकालता है जो सक्रिय रूप से हमलों में उपयोग हो रहे हैं और detection के लिए signatures बनाता है। इसके अलावा, threat data LMD checkout feature के जरिए user submissions और malware community resources से भी लिया जाता है।
|
||||
[**Linux Malware Detect (LMD)**](https://www.rfxn.com/projects/linux-malware-detect/) एक Linux के लिए malware स्कैनर है जो GNU GPLv2 license के तहत जारी किया गया है, और यह साझा होस्टेड वातावरणों में सामना किए जाने वाले खतरों को ध्यान में रखकर डिज़ाइन किया गया है। यह network edge intrusion detection systems से threat data का उपयोग करके सक्रिय रूप से हमलों में उपयोग हो रहे malware को extract करता है और detection के लिए signatures जनरेट करता है। इसके अतिरिक्त, threat data LMD checkout feature के माध्यम से user submissions और malware community resources से भी प्राप्त किया जाता है।
|
||||
|
||||
### rkhunter
|
||||
|
||||
Tools like [**rkhunter**](http://rkhunter.sourceforge.net) का उपयोग फ़ाइल सिस्टम की जाँच करने के लिए किया जा सकता है ताकि संभावित **rootkits** और malware का पता लगाया जा सके।
|
||||
Tools like [**rkhunter**](http://rkhunter.sourceforge.net) filesystem को संभावित **rootkits** और malware के लिए जांचने में उपयोग किए जा सकते हैं।
|
||||
```bash
|
||||
sudo ./rkhunter --check -r / -l /tmp/rkhunter.log [--report-warnings-only] [--skip-keypress]
|
||||
```
|
||||
### FLOSS
|
||||
|
||||
[**FLOSS**](https://github.com/mandiant/flare-floss) एक टूल है जो विभिन्न तकनीकों का उपयोग करके executables के अंदर obfuscated strings खोजने की कोशिश करता है।
|
||||
[**FLOSS**](https://github.com/mandiant/flare-floss) एक टूल है जो अलग‑अलग तकनीकों का उपयोग करके executables के अंदर obfuscated strings खोजने की कोशिश करेगा।
|
||||
|
||||
### PEpper
|
||||
|
||||
[PEpper ](https://github.com/Th3Hurrican3/PEpper) executable के अंदर कुछ बुनियादी चीज़ें चेक करता है (binary data, entropy, URLs and IPs, कुछ yara rules)।
|
||||
[PEpper ](https://github.com/Th3Hurrican3/PEpper) executable के अंदर कुछ बुनियादी चीज़ें चेक करता है (binary data, entropy, URLs and IPs, some yara rules)।
|
||||
|
||||
### PEstudio
|
||||
|
||||
[PEstudio](https://www.winitor.com/download) एक टूल है जो Windows executables की जानकारी देता है जैसे imports, exports, headers; साथ ही यह virus total को भी चेक करेगा और संभावित Att\&ck techniques खोजेगा।
|
||||
[PEstudio](https://www.winitor.com/download) एक टूल है जो Windows executables की जानकारी प्राप्त करने की अनुमति देता है जैसे imports, exports, headers, और साथ ही virus total की जाँच करता है और संभावित Att\&ck techniques ढूँढता है।
|
||||
|
||||
### Detect It Easy(DiE)
|
||||
|
||||
[**DiE**](https://github.com/horsicq/Detect-It-Easy/) एक टूल है जो पता लगाने के लिए कि कोई फ़ाइल **encrypted** है या नहीं और साथ ही **packers** भी खोजता है।
|
||||
[**DiE**](https://github.com/horsicq/Detect-It-Easy/) एक टूल है जो यह पता लगाने के लिए कि कोई फ़ाइल **encrypted** है या नहीं और साथ ही **packers** भी ढूँढता है।
|
||||
|
||||
### NeoPI
|
||||
|
||||
[**NeoPI** ](https://github.com/CiscoCXSecurity/NeoPI) एक Python स्क्रिप्ट है जो text/script files के भीतर छिपे हुए **obfuscated** और **encrypted** कंटेंट का पता लगाने के लिए विभिन्न **statistical methods** का उपयोग करती है। NeoPI का उद्देश्य छिपे हुए web shell code के **detection** में मदद करना है।
|
||||
[**NeoPI** ](https://github.com/CiscoCXSecurity/NeoPI) एक Python script है जो text/script files के भीतर **statistical methods** की विविधता का उपयोग करके **obfuscated** और **encrypted** content का पता लगाती है। NeoPI का उद्देश्य **detection of hidden web shell code** में सहायता करना है।
|
||||
|
||||
### **php-malware-finder**
|
||||
|
||||
[**PHP-malware-finder**](https://github.com/nbs-system/php-malware-finder) obfuscated/**dodgy code** के साथ-साथ उन फाइलों का पता लगाने की पूरी कोशिश करता है जो **PHP** functions का उपयोग करती हैं जो अक्सर **malwares**/webshells में इस्तेमाल होते हैं।
|
||||
[**PHP-malware-finder**](https://github.com/nbs-system/php-malware-finder) अपनी पूरी कोशिश करता है ताकि **obfuscated**/**dodgy code** के साथ-साथ उन फ़ाइलों का भी पता चल सके जो अक्सर **PHP** functions का उपयोग करती हैं जो **malwares**/webshells में दिखाई देते हैं।
|
||||
|
||||
### Apple Binary Signatures
|
||||
|
||||
जब आप किसी **malware sample** की जांच कर रहे हों तो हमेशा binary के **signature** की जांच करनी चाहिए क्योंकि जिस **developer** ने उसे sign किया है वह पहले से ही **related** हो सकता है **malware** से।
|
||||
जब आप किसी **malware sample** की जाँच कर रहे हों तो हमेशा बाइनरी के **check the signature** को देखें क्योंकि जिसने इसे साइन किया है वह **developer** पहले से ही **related** with **malware** हो सकता है।
|
||||
```bash
|
||||
#Get signer
|
||||
codesign -vv -d /bin/ls 2>&1 | grep -E "Authority|TeamIdentifier"
|
||||
@ -141,21 +142,21 @@ spctl --assess --verbose /Applications/Safari.app
|
||||
|
||||
### File Stacking
|
||||
|
||||
यदि आप जानते हैं कि किसी फ़ोल्डर जिसमें **files** वाले web server को किसी विशेष तिथि पर **last updated on some date** किया गया था, तो उस स्थिति में आप वे सभी **files** की **date** जाँचें कि वे कब **created** और **modified** हुए थे; अगर कोई **date** **suspicious** दिखे तो उस file की जाँच करें।
|
||||
यदि आप जानते हैं कि किसी फ़ोल्डर में web server के **files** थे जिन्हें **last updated on some date** किया गया था। **Check** करें कि web server के सभी **files** किस **date** पर created और modified हुए थे, और अगर कोई date **suspicious** लगे, तो उस file की जाँच करें।
|
||||
|
||||
### Baselines
|
||||
|
||||
यदि किसी फ़ोल्डर के **files** को **shouldn't have been modified** होना चाहिए था, तो आप उस फ़ोल्डर के **original files** का **hash** निकालकर उन्हें **current** वाले से **compare** कर सकते हैं। जो भी संशोधित होगा वह **suspicious** होगा।
|
||||
यदि किसी फ़ोल्डर के **files** को **shouldn't have been modified** होना चाहिए था, तो आप फ़ोल्डर के **original files** का **hash** निकालकर उन्हें **current** वाले से **compare** कर सकते हैं। जो कुछ भी modified होगा वह **suspicious** माना जाएगा।
|
||||
|
||||
### Statistical Analysis
|
||||
|
||||
जब जानकारी logs में सेव होती है, आप ऐसे **statistics** चेक कर सकते हैं जैसे कि web server के प्रत्येक file को कितनी बार एक्सेस किया गया — क्योंकि web shell संभवतः सबसे अधिक एक्सेस किए गए में से एक हो सकता है।
|
||||
जब जानकारी logs में सेव होती है तो आप **check statistics like how many times each file of a web server was accessed as a web shell might be one of the most** कर सकते हैं — यानी यह देख सकते हैं कि web server के किस **file** तक कितनी बार access हुआ, क्योंकि एक web shell संभवतः सबसे ज़्यादा access किए जाने वाले में से एक हो सकता है।
|
||||
|
||||
---
|
||||
|
||||
### Android in-app native telemetry (no root)
|
||||
|
||||
On Android, आप target app process के अंदर native code में instrumentation कर सकते हैं एक छोटे logger library को प्रीलोड करके, इससे पहले कि अन्य JNI libs initialize हों। इससे system-wide hooks या root के बिना ही native व्यवहार की शुरुआती visibility मिलती है। एक लोकप्रिय तरीका SoTap है: सही ABI के लिए libsotap.so को APK में डालें और शुरुआती चरण में System.loadLibrary("sotap") कॉल inject करें (उदाहरण के लिए, static initializer या Application.onCreate), फिर logs को internal/external paths या Logcat fallback से इकट्ठा करें।
|
||||
Android पर आप target app process के अंदर native code को instrument कर सकते हैं एक छोटा logger library पहले preload करके, इससे पहले कि अन्य JNI libs initialize हों। इससे system-wide hooks या root के बिना native व्यवहार की early visibility मिलती है। एक लोकप्रिय तरीका SoTap है: सही ABI के लिए libsotap.so को APK में drop करें और early में System.loadLibrary("sotap") call inject करें (उदा., static initializer या Application.onCreate), फिर internal/external paths से logs collect करें या Logcat fallback का उपयोग करें।
|
||||
|
||||
See the Android native reversing page for setup details and log paths:
|
||||
|
||||
@ -165,11 +166,11 @@ See the Android native reversing page for setup details and log paths:
|
||||
|
||||
---
|
||||
|
||||
## डायनामिक Control-Flow का Deobfuscation (JMP/CALL RAX Dispatchers)
|
||||
## Deobfuscating Dynamic Control-Flow (JMP/CALL RAX Dispatchers)
|
||||
|
||||
आधुनिक malware परिवार Control-Flow Graph (CFG) obfuscation का भारी दुरुपयोग करते हैं: सीधे jump/call की जगह वे destination को run-time पर compute करते हैं और `jmp rax` या `call rax` execute करते हैं। एक छोटा *dispatcher* (आम तौर पर नौ निर्देश) CPU के `ZF`/`CF` flags के आधार पर final target सेट करता है, जिससे static CFG recovery पूरी तरह टूट जाती है।
|
||||
आधुनिक malware परिवार Control-Flow Graph (CFG) obfuscation का भारी उपयोग करते हैं: सीधे jump/call के बजाय वे destination को run-time पर compute करते हैं और `jmp rax` या `call rax` execute करते हैं। एक छोटा *dispatcher* (आम तौर पर नौ instructions) CPU के `ZF`/`CF` flags पर निर्भर करके final target सेट करता है, जिससे static CFG recovery पूरी तरह टूट जाती है।
|
||||
|
||||
The technique – showcased by the SLOW#TEMPEST loader – can be defeated with a three-step workflow that only relies on IDAPython and the Unicorn CPU emulator.
|
||||
यह technique — SLOW#TEMPEST loader द्वारा प्रदर्शित — IDAPython और Unicorn CPU emulator पर ही निर्भर तीन-स्टेप workflow से bypass की जा सकती है।
|
||||
|
||||
### 1. Locate every indirect jump / call
|
||||
```python
|
||||
@ -180,7 +181,7 @@ mnem = idc.print_insn_mnem(ea)
|
||||
if mnem in ("jmp", "call") and idc.print_operand(ea, 0) == "rax":
|
||||
print(f"[+] Dispatcher found @ {ea:X}")
|
||||
```
|
||||
### 2. डिस्पैचर बाइट-कोड निकालें
|
||||
### 2. डिस्पैचर का बाइट-कोड निकालें
|
||||
```python
|
||||
import idc
|
||||
|
||||
@ -195,7 +196,7 @@ size = jmp_ea + idc.get_item_size(jmp_ea) - start
|
||||
code = idc.get_bytes(start, size)
|
||||
open(f"{start:X}.bin", "wb").write(code)
|
||||
```
|
||||
### 3. Unicorn के साथ इसे दो बार Emulate करें
|
||||
### 3. इसे Unicorn के साथ दो बार अनुकरण करें
|
||||
```python
|
||||
from unicorn import *
|
||||
from unicorn.x86_const import *
|
||||
@ -211,9 +212,9 @@ mu.reg_write(UC_X86_REG_RAX, 0)
|
||||
mu.emu_start(BASE, BASE+len(code))
|
||||
return mu.reg_read(UC_X86_REG_RAX)
|
||||
```
|
||||
`run(code,0,0)` और `run(code,1,1)` चलाएँ ताकि *false* और *true* branch targets प्राप्त किए जा सकें।
|
||||
`run(code,0,0)` और `run(code,1,1)` चलाएँ ताकि आप *false* और *true* ब्रांच टार्गेट प्राप्त कर सकें।
|
||||
|
||||
### 4. direct jump / call को वापस patch करें
|
||||
### 4. एक direct jump / call को वापस पैच करें
|
||||
```python
|
||||
import struct, ida_bytes
|
||||
|
||||
@ -222,22 +223,22 @@ op = 0xE8 if is_call else 0xE9 # CALL rel32 or JMP rel32
|
||||
disp = target - (ea + 5) & 0xFFFFFFFF
|
||||
ida_bytes.patch_bytes(ea, bytes([op]) + struct.pack('<I', disp))
|
||||
```
|
||||
पैच करने के बाद, पूरी CFG और Hex-Rays आउटपुट को बहाल करने के लिए IDA को function का पुनः विश्लेषण करने के लिए मजबूर करें:
|
||||
पैच करने के बाद, IDA को फ़ंक्शन का पुनः विश्लेषण करने के लिए मजबूर करें ताकि पूरा CFG और Hex-Rays आउटपुट बहाल हो:
|
||||
```python
|
||||
import ida_auto, idaapi
|
||||
idaapi.reanalyze_function(idc.get_func_attr(ea, idc.FUNCATTR_START))
|
||||
```
|
||||
### 5. अप्रत्यक्ष API calls को लेबल करें
|
||||
### 5. अप्रत्यक्ष API कॉल्स को लेबल करें
|
||||
|
||||
एक बार जब हर `call rax` का असली गंतव्य पता चल जाए, आप IDA को बता सकते हैं कि वह क्या है, ताकि parameter types & variable names अपने आप पुनर्प्राप्त हो जाएँ:
|
||||
एक बार जब हर `call rax` का वास्तविक गंतव्य ज्ञात हो जाता है, तो आप IDA को बता सकते हैं कि वह क्या है ताकि पैरामीटर प्रकार और वेरिएबल नाम स्वचालित रूप से पुनर्प्राप्त हो जाएँ:
|
||||
```python
|
||||
idc.set_callee_name(call_ea, resolved_addr, 0) # IDA 8.3+
|
||||
```
|
||||
### व्यावहारिक लाभ
|
||||
|
||||
* वास्तविक CFG को पुनर्स्थापित करता है → decompilation *10* लाइनों से हजारों तक चली जाती है।
|
||||
* string-cross-reference & xrefs सक्षम करता है, जिससे behaviour reconstruction सरल हो जाती है।
|
||||
* Scripts पुन:उपयोगी हैं: उन्हें किसी भी loader में डालें जो उसी trick से सुरक्षित हो।
|
||||
* वास्तविक CFG को बहाल करता है → decompilation *10* लाइनों से हजारों तक पहुँच जाता है।
|
||||
* string-cross-reference & xrefs सक्षम होते हैं, जिससे behaviour reconstruction सरल हो जाता है।
|
||||
* Scripts पुनः उपयोग योग्य हैं: इन्हें उसी trick द्वारा सुरक्षित किसी भी loader में डालें।
|
||||
|
||||
---
|
||||
|
||||
|
||||
@ -1,50 +1,50 @@
|
||||
# रिवर्सिंग नेटीव लाइब्रेरीज़
|
||||
# नेटिव लाइब्रेरीज़ को रिवर्स करना
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
**अधिक जानकारी के लिए देखें:** [**https://maddiestone.github.io/AndroidAppRE/reversing_native_libs.html**](https://maddiestone.github.io/AndroidAppRE/reversing_native_libs.html)
|
||||
|
||||
Android ऐप्स performance-critical कार्यों के लिए आम तौर पर C या C++ में लिखी गई native libraries का उपयोग कर सकते हैं। मैलवेयर रचयिता भी इन लाइब्रेरीज़ का दुरुपयोग करते हैं क्योंकि ELF shared objects अभी भी DEX/OAT byte-code की तुलना में decompile करने में कठिन होते हैं।
|
||||
यह पेज *प्रैक्टिकल* वर्कफ़्लोज़ और *हालिया* tooling सुधारों (2023-2025) पर केंद्रित है जो Android `.so` फ़ाइलों को रिवर्स करना आसान बनाते हैं।
|
||||
Android apps प्रदर्शन-सम्बन्धी कार्यों के लिए आमतौर पर C या C++ में लिखी गई नेटिव लाइब्रेरीज़ का उपयोग कर सकते हैं। Malware रचनाकार भी इन लाइब्रेरीज़ का दुरुपयोग करते हैं क्योंकि ELF shared objects को DEX/OAT byte-code की तुलना में अभी भी decompile करना कठिन होता है।
|
||||
यह पृष्ठ *व्यावहारिक* workflows और *हाल के* tooling सुधारों (2023-2025) पर केंद्रित है जो Android `.so` फ़ाइलों को रिवर्स करना आसान बनाते हैं।
|
||||
|
||||
---
|
||||
|
||||
### ताजा निकाली गई `libfoo.so` के लिए त्वरित ट्रायेज-वर्कफ़्लो
|
||||
### एक नए निकाले गए `libfoo.so` के लिए त्वरित ट्रायेज-वर्कफ़्लो
|
||||
|
||||
1. **लाइब्रेरी निकालें**
|
||||
1. **लाइब्रेरी निकालना**
|
||||
```bash
|
||||
# From an installed application
|
||||
adb shell "run-as <pkg> cat lib/arm64-v8a/libfoo.so" > libfoo.so
|
||||
# Or from the APK (zip)
|
||||
unzip -j target.apk "lib/*/libfoo.so" -d extracted_libs/
|
||||
```
|
||||
2. **आर्किटेक्चर और प्रोटेक्शंस पहचानें**
|
||||
2. **आर्किटेक्चर और सुरक्षा पहचानें**
|
||||
```bash
|
||||
file libfoo.so # arm64 or arm32 / x86
|
||||
readelf -h libfoo.so # OS ABI, PIE, NX, RELRO, etc.
|
||||
checksec --file libfoo.so # (peda/pwntools)
|
||||
```
|
||||
3. **exported symbols और JNI bindings सूचीबद्ध करें**
|
||||
3. **Exported symbols और JNI bindings सूचीबद्ध करें**
|
||||
```bash
|
||||
readelf -s libfoo.so | grep ' Java_' # dynamic-linked JNI
|
||||
strings libfoo.so | grep -i "RegisterNatives" -n # static-registered JNI
|
||||
```
|
||||
4. **Decompiler में लोड करें** (Ghidra ≥ 11.0, IDA Pro, Binary Ninja, Hopper or Cutter/Rizin) और auto-analysis चलाएँ।
|
||||
नयी Ghidra versions ने एक AArch64 decompiler पेश किया है जो PAC/BTI stubs और MTE tags को पहचानता है, जिससे Android 14 NDK से बनी libraries का analysis काफी बेहतर हुआ है।
|
||||
5. **static vs dynamic reversing पर निर्णय लें:** stripped, obfuscated code अक्सर *instrumentation* (Frida, ptrace/gdbserver, LLDB) की मांग करता है।
|
||||
4. **किसी decompiler में लोड करें** (Ghidra ≥ 11.0, IDA Pro, Binary Ninja, Hopper or Cutter/Rizin) और auto-analysis चलाएँ।
|
||||
नवीन Ghidra संस्करणों में एक AArch64 decompiler शामिल है जो PAC/BTI stubs और MTE tags को पहचानता है, जिससे Android 14 NDK से बनी लाइब्रेरीज़ के विश्लेषण में काफी सुधार हुआ है।
|
||||
5. **static बनाम dynamic reversing तय करें:** stripped, obfuscated code अक्सर *instrumentation* की जरूरत होती है (Frida, ptrace/gdbserver, LLDB).
|
||||
|
||||
---
|
||||
|
||||
### डायनामिक इंस्ट्रूमेंटेशन (Frida ≥ 16)
|
||||
### डायनामिक Instrumentation (Frida ≥ 16)
|
||||
|
||||
Frida की 16-सीरीज़ ने कई Android-specific सुधार लाए हैं जो तब मदद करते हैं जब टार्गेट आधुनिक Clang/LLD optimisations का उपयोग करता है:
|
||||
Frida के 16-series ने कई Android-विशिष्ट सुधार लाए हैं जो तब मदद करते हैं जब target आधुनिक Clang/LLD optimisations का उपयोग करता है:
|
||||
|
||||
* `thumb-relocator` अब LLD की aggressive alignment (`--icf=all`) द्वारा जनरेट की गई छोटे ARM/Thumb functions को *hook* कर सकता है।
|
||||
* Android पर *ELF import slots* को enumerate और rebind करना काम करता है, जिससे inline hooks reject होने पर per-module `dlopen()`/`dlsym()` patching सक्षम होता है।
|
||||
* जब ऐप्स Android 14 पर `--enable-optimizations` के साथ compiled होते हैं तब उपयोग किए जाने वाले नए **ART quick-entrypoint** के लिए Java hooking ठीक किया गया है।
|
||||
* `thumb-relocator` अब LLD की aggressive alignment (`--icf=all`) द्वारा जनरेट की गई छोटी ARM/Thumb functions को *hook* कर सकता है।
|
||||
* `ELF import slots` की enumerating और rebinding Android पर काम करती है, जिससे inline hooks अस्वीकार होने पर per-module `dlopen()`/`dlsym()` patching संभव होता है।
|
||||
* Java hooking को नए **ART quick-entrypoint** के लिए फिक्स किया गया जो तब इस्तेमाल होता है जब apps Android 14 पर `--enable-optimizations` के साथ compiled होते हैं।
|
||||
|
||||
उदाहरण: `RegisterNatives` के माध्यम से रजिस्टर किए गए सभी functions को सूचीबद्ध करना और runtime पर उनके addresses dump करना:
|
||||
Example: enumerating all functions registered through `RegisterNatives` and dumping their addresses at runtime:
|
||||
```javascript
|
||||
Java.perform(function () {
|
||||
var Runtime = Java.use('java.lang.Runtime');
|
||||
@ -61,29 +61,29 @@ console.log('[+] RegisterNatives on ' + clazz.getName() + ' -> ' + count + ' met
|
||||
});
|
||||
});
|
||||
```
|
||||
Frida बिना अतिरिक्त कॉन्फ़िगरेशन के PAC/BTI-enabled devices (Pixel 8/Android 14+) पर तब तक काम करेगा जब तक आप frida-server 16.2 या बाद का उपयोग कर रहे हैं – पुराने संस्करण inline hooks के लिए padding locate करने में विफल थे।
|
||||
Frida PAC/BTI-enabled डिवाइसों (Pixel 8/Android 14+) पर सीधे काम करेगा, बशर्ते आप frida-server 16.2 या बाद का उपयोग करें — पुराने वर्शन inline hooks के लिए padding ढूँढने में विफल होते थे।
|
||||
|
||||
### Process-local JNI telemetry via preloaded .so (SoTap)
|
||||
### Preloaded .so (SoTap) के माध्यम से Process-local JNI telemetry
|
||||
|
||||
जब full-featured instrumentation ओवरकिल हो या ब्लॉक हो, तब भी आप target process के भीतर एक छोटा logger प्री-लोड करके native-स्तरीय visibility हासिल कर सकते हैं। SoTap एक lightweight Android native (.so) library है जो उसी app process के भीतर अन्य JNI (.so) libraries के runtime व्यवहार को लॉग करता है (no root required)।
|
||||
जब full-featured instrumentation ज़रूरत से ज़्यादा हो या blocked हो, तब भी आप target process के अंदर एक छोटा logger preload करके native-level visibility हासिल कर सकते हैं। SoTap एक lightweight Android native (.so) लाइब्रेरी है जो उसी app process के भीतर अन्य JNI (.so) लाइब्रेरियों के runtime व्यवहार को log करती है (no root required).
|
||||
|
||||
मुख्य विशेषताएँ:
|
||||
- प्रारंभ में इनिशियलाइज़ होता है और उस process के अंदर JNI/native interactions को observe करता है जो इसे लोड करता है।
|
||||
- कई writable paths का उपयोग करके लॉग्स को स्थायी रूप से सहेजता है और जब storage restricted हो तो सुव्यवस्थित तरीके से Logcat पर fallback कर जाता है।
|
||||
- Source-customizable: sotap.c को एडिट करके लॉग किए जाने वाले तत्वों को बढ़ाएँ/समायोजित करें और प्रत्येक ABI के लिए रीबिल्ड करें।
|
||||
Key properties:
|
||||
- जल्दी initialize होता है और उस process के अंदर JNI/native interactions को observe करता है जो इसे लोड करता है।
|
||||
- Logs को कई writable paths में persist करता है और जब storage restricted हो तो graceful fallback के तौर पर Logcat का उपयोग करता है।
|
||||
- Source-customizable: sotap.c को edit करके जो log होता है उसे extend/adjust करें और प्रत्येक ABI के लिए rebuild करें।
|
||||
|
||||
सेटअप (repack the APK):
|
||||
1) सही ABI build को APK में डालें ताकि loader libsotap.so को resolve कर सके:
|
||||
- lib/arm64-v8a/libsotap.so (arm64 के लिए)
|
||||
- lib/armeabi-v7a/libsotap.so (arm32 के लिए)
|
||||
2) सुनिश्चित करें कि SoTap अन्य JNI लाइब्स से पहले लोड हो। शुरुआती चरण में एक call inject करें (उदा., Application subclass के static initializer या onCreate) ताकि logger पहले initialize हो। Smali snippet उदाहरण:
|
||||
Setup (repack the APK):
|
||||
1) Drop the proper ABI build into the APK so the loader can resolve libsotap.so:
|
||||
- lib/arm64-v8a/libsotap.so (for arm64)
|
||||
- lib/armeabi-v7a/libsotap.so (for arm32)
|
||||
2) Ensure SoTap loads before other JNI libs. Inject a call early (e.g., Application subclass static initializer or onCreate) so the logger is initialized first. Smali snippet example:
|
||||
```smali
|
||||
const-string v0, "sotap"
|
||||
invoke-static {v0}, Ljava/lang/System;->loadLibrary(Ljava/lang/String;)V
|
||||
```
|
||||
3) Rebuild/sign/install करें, ऐप चलाएँ, और फिर लॉग्स एकत्रित करें।
|
||||
3) Rebuild/sign/install करें, ऐप चलाएँ, फिर logs इकट्ठा करें।
|
||||
|
||||
लॉग पाथ (क्रम में जाँचे जाते हैं):
|
||||
Log paths (checked in order):
|
||||
```
|
||||
/data/user/0/%s/files/sotap.log
|
||||
/data/data/%s/files/sotap.log
|
||||
@ -92,30 +92,30 @@ invoke-static {v0}, Ljava/lang/System;->loadLibrary(Ljava/lang/String;)V
|
||||
# If all fail: fallback to Logcat only
|
||||
```
|
||||
नोट्स और समस्या निवारण:
|
||||
- ABI alignment अनिवार्य है। mismatch होने पर UnsatisfiedLinkError उठेगा और logger लोड नहीं होगा।
|
||||
- Storage constraints आधुनिक Android पर सामान्य हैं; अगर फाइल लिखने में विफलता हो तो SoTap फिर भी Logcat के जरिए emit करेगा।
|
||||
- व्यवहार/verbosity को अनुकूलित करने के लिए उद्देश्यपूर्ण रखा गया है; sotap.c संपादित करने के बाद स्रोत से फिर से build करें।
|
||||
- ABI alignment अनिवार्य है। किसी असंगति से UnsatisfiedLinkError होगी और logger लोड नहीं होगा।
|
||||
- आधुनिक Android पर स्टोरेज सीमाएँ आम हैं; यदि फ़ाइल लिखना विफल होता है, तो SoTap फिर भी Logcat के माध्यम से लॉग भेजेगा।
|
||||
- व्यवहार/verbosity को अनुकूलित करने के लिए बनाया गया है; sotap.c संपादित करने के बाद स्रोत से पुनर्निर्माण करें।
|
||||
|
||||
यह तरीका malware triage और JNI debugging के लिए उपयोगी है जहाँ process start से native call flows का अवलोकन κρίतिक होता है लेकिन root/system-wide hooks उपलब्ध नहीं होते।
|
||||
यह तरीका मैलवेयर ट्रायज और JNI डिबगिंग के लिए उपयोगी है जहाँ process की शुरुआत से native call flows का अवलोकन महत्वपूर्ण हो पर root/system-wide hooks उपलब्ध नहीं होते।
|
||||
|
||||
---
|
||||
|
||||
### Recent vulnerabilities worth hunting for in APKs
|
||||
### APKs में खोजने योग्य हालिया कमजोरियाँ
|
||||
|
||||
| Year | CVE | Affected library | Notes |
|
||||
| साल | CVE | प्रभावित लाइब्रेरी | नोट्स |
|
||||
|------|-----|------------------|-------|
|
||||
|2023|CVE-2023-4863|`libwebp` ≤ 1.3.1|नेटिव कोड जो WebP इमेजेस को डिकोड करता है उसमें पहुँच योग्य heap buffer overflow। कई Android apps कमजोर संस्करण bundle करते हैं। जब आप किसी APK में `libwebp.so` देखें, तो उसकी version चेक करें और exploit या patch करने का प्रयास करें.| |
|
||||
|2024|Multiple|OpenSSL 3.x series|कई memory-safety और padding-oracle समस्याएँ। कई Flutter & ReactNative bundles अपना खुद का `libcrypto.so` ship करते हैं।|
|
||||
|2023|CVE-2023-4863|`libwebp` ≤ 1.3.1|हीप बफर ओवरफ़्लो जो WebP इमेजेस को डिकोड करने वाले native कोड से पहुँच योग्य है। कई Android ऐप्स कमजोर वर्जन बंडल करते हैं। जब आप किसी APK के भीतर `libwebp.so` देखें, तो उसकी वर्जन जांचें और exploit या patch करने का प्रयास करें.| |
|
||||
|2024|Multiple|OpenSSL 3.x series|कई memory-safety और padding-oracle समस्याएँ। कई Flutter & ReactNative बंडल अपने स्वयं के `libcrypto.so` के साथ शिप करते हैं।|
|
||||
|
||||
जब आप किसी APK के अंदर third-party `.so` फाइलें देखें, तो हमेशा उनका hash upstream advisories के साथ cross-check करें। SCA (Software Composition Analysis) mobile पर आम नहीं है, इसलिए outdated vulnerable builds प्रचुर मात्रा में मिलते हैं।
|
||||
जब आप किसी APK के अंदर *third-party* `.so` फ़ाइलें देखें, तो हमेशा उनका हैश upstream advisories से cross-check करें। मोबाइल पर SCA (Software Composition Analysis) आम नहीं है, इसलिए पुराने कमजोर बिल्ड व्यापक हैं।
|
||||
|
||||
---
|
||||
|
||||
### Anti-Reversing & Hardening trends (Android 13-15)
|
||||
### Anti-Reversing & Hardening प्रवृत्तियाँ (Android 13-15)
|
||||
|
||||
* **Pointer Authentication (PAC) & Branch Target Identification (BTI):** Android 14 system libraries में PAC/BTI सक्षम करता है जब ARMv8.3+ silicon समर्थित हो। Decompilers अब PAC‑संबंधित pseudo-instructions दिखाते हैं; dynamic analysis के लिए Frida PAC strip करने के बाद trampolines inject करता है, लेकिन आपके custom trampolines को जहाँ आवश्यक हो वहां `pacda`/`autibsp` कॉल करना चाहिए।
|
||||
* **MTE & Scudo hardened allocator:** memory-tagging opt-in है लेकिन कई Play-Integrity aware apps `-fsanitize=memtag` के साथ build होते हैं; tag faults कैप्चर करने के लिए `setprop arm64.memtag.dump 1` और फिर `adb shell am start ...` का उपयोग करें।
|
||||
* **LLVM Obfuscator (opaque predicates, control-flow flattening):** commercial packers (e.g., Bangcle, SecNeo) बढ़ती मात्रा में सिर्फ Java ही नहीं बल्कि *native* कोड की भी रक्षा करते हैं; `.rodata` में bogus control-flow और encrypted string blobs की उम्मीद रखें।
|
||||
* **Pointer Authentication (PAC) & Branch Target Identification (BTI):** Android 14 समर्थित ARMv8.3+ सिलिकॉन पर system libraries में PAC/BTI सक्षम करता है। Decompilers अब PAC‐संबंधित pseudo-instructions दिखाते हैं; dynamic analysis के लिए Frida PAC हटाने के बाद trampolines inject करता है, लेकिन आपके कस्टम trampolines जहां आवश्यक हों वहां `pacda`/`autibsp` कॉल करना चाहिए।
|
||||
* **MTE & Scudo hardened allocator:** memory-tagging ऑप्ट-इन है पर कई Play-Integrity aware ऐप्स `-fsanitize=memtag` के साथ बिल्ड करते हैं; tag faults पकड़ने के लिए `setprop arm64.memtag.dump 1` और `adb shell am start ...` का उपयोग करें।
|
||||
* **LLVM Obfuscator (opaque predicates, control-flow flattening):** commercial packers (e.g., Bangcle, SecNeo) तेजी से *native* कोड की सुरक्षा करते हैं, सिर्फ Java नहीं; `.rodata` में नकली control-flow और encrypted string ब्लॉब्स की उम्मीद रखें।
|
||||
|
||||
---
|
||||
|
||||
|
||||
@ -3,15 +3,15 @@
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
कभी-कभी application code को modify करके आपके लिए hidden information तक पहुँच बनाना दिलचस्प होता है (शायद अच्छी तरह obfuscated passwords या flags)। ऐसे में apk को decompile करना, code में बदलाव करना और इसे recompile करना उपयोगी हो सकता है।
|
||||
कभी-कभी एप्लिकेशन कोड में बदलाव करके आपके लिए छिपी जानकारी तक पहुंचना दिलचस्प होता है (शायद अच्छी तरह से ऑबफ़्यूस्केट किए गए पासवर्ड या flags)। ऐसे में apk को decompile करना, कोड संशोधित करना और फिर से recompile करना उपयोगी हो सकता है।
|
||||
|
||||
**Opcodes संदर्भ:** [http://pallergabor.uw.hu/androidblog/dalvik_opcodes.html](http://pallergabor.uw.hu/androidblog/dalvik_opcodes.html)
|
||||
**Opcodes reference:** [http://pallergabor.uw.hu/androidblog/dalvik_opcodes.html](http://pallergabor.uw.hu/androidblog/dalvik_opcodes.html)
|
||||
|
||||
## तेज़ तरीका
|
||||
|
||||
Visual Studio Code और [APKLab](https://github.com/APKLab/APKLab) extension का उपयोग करके, आप बिना किसी कमांड को चलाए application को **automatically decompile**, modify, **recompile**, sign & install कर सकते हैं।
|
||||
Using **Visual Studio Code** और [APKLab](https://github.com/APKLab/APKLab) extension का उपयोग करके, आप बिना किसी कमांड को चलाए एप्लिकेशन को **automatically decompile**, संशोधित, **recompile**, sign और install कर सकते हैं।
|
||||
|
||||
एक और **script** जो इस कार्य को बहुत आसान बनाती है वह है [**https://github.com/ax/apk.sh**](https://github.com/ax/apk.sh)
|
||||
इस काम को काफी आसान बनाने वाला एक और **script** है [**https://github.com/ax/apk.sh**](https://github.com/ax/apk.sh)
|
||||
|
||||
## APK को Decompile करना
|
||||
|
||||
@ -19,70 +19,68 @@ APKTool का उपयोग करके आप **smali code and resources**
|
||||
```bash
|
||||
apktool d APP.apk
|
||||
```
|
||||
यदि **apktool** कोई त्रुटि देता है, तो कोशिश करें[ installing the **latest version**](https://ibotpeaches.github.io/Apktool/install/)
|
||||
यदि **apktool** आपको कोई त्रुटि देता है, तो [installing the **latest version**](https://ibotpeaches.github.io/Apktool/install/) आज़माएँ
|
||||
|
||||
कुछ **दिलचस्प फ़ाइलें जिन्हें आपको देखना चाहिए**:
|
||||
कुछ **रोचक फ़ाइलें जिन्हें आपको देखना चाहिए**:
|
||||
|
||||
- _res/values/strings.xml_ (and all xmls inside res/values/*)
|
||||
- _AndroidManifest.xml_
|
||||
- Any file with extension _.sqlite_ or _.db_
|
||||
|
||||
यदि `apktool` को **problems decoding the application** हैं, तो देखें [https://ibotpeaches.github.io/Apktool/documentation/#framework-files](https://ibotpeaches.github.io/Apktool/documentation/#framework-files) या तर्क **`-r`** का उपयोग करने की कोशिश करें (Resources को decode न करें)। फिर, यदि समस्या resource में थी और source code में नहीं, तो आपको यह समस्या नहीं होगी (आप resources को भी decompile नहीं करेंगे)।
|
||||
यदि `apktool` को एप्लिकेशन को डिकोड करने में **समस्याएँ** हो रही हैं तो [https://ibotpeaches.github.io/Apktool/documentation/#framework-files](https://ibotpeaches.github.io/Apktool/documentation/#framework-files) देखें या तर्क **`-r`** (संसाधनों को डिकोड न करें) का उपयोग करके कोशिश करें। फिर, यदि समस्या किसी resource में थी न कि source code में, तो आपकी समस्या समाप्त हो जाएगी (आप संसाधनों को भी डिकम्पाइल नहीं करेंगे)।
|
||||
|
||||
## Smali कोड बदलें
|
||||
|
||||
आप **instructions** बदल सकते हैं, कुछ variables का **value** बदल सकते हैं या नए instructions **add** कर सकते हैं। मैं Smali code को [**VS Code**](https://code.visualstudio.com) का उपयोग करके बदलता/बदलती हूँ, उसके बाद आप **smalise extension** इंस्टॉल करें और editor बताएगा यदि कोई **instruction गलत** है.\
|
||||
कुछ **examples** यहाँ मिल सकते हैं:
|
||||
आप **निर्देश** बदल सकते हैं, कुछ वेरिएबल्स के **मान** बदल सकते हैं या नए **निर्देश** जोड़ सकते हैं। मैं Smali कोड को [**VS Code**](https://code.visualstudio.com) का उपयोग करके बदलता/बदलती हूँ, फिर आप **smalise extension** इंस्टॉल करें और एडिटर बताएगा अगर कोई **निर्देश गलत** है.\
|
||||
कुछ **उदाहरण** यहाँ मिल सकते हैं:
|
||||
|
||||
- [Smali changes examples](smali-changes.md)
|
||||
- [Google CTF 2018 - Shall We Play a Game?](google-ctf-2018-shall-we-play-a-game.md)
|
||||
|
||||
Or you can [**check below some Smali changes explained**](smali-changes.md#modifying-smali).
|
||||
या आप [**check below some Smali changes explained**](smali-changes.md#modifying-smali) देख सकते हैं।
|
||||
|
||||
## APK को पुनः संकलित करें
|
||||
|
||||
कोड में संशोधन करने के बाद आप निम्न का उपयोग करके कोड को **पुनः संकलित** कर सकते हैं:
|
||||
कोड में बदलाव करने के बाद आप निम्न का उपयोग करके कोड को **पुनः संकलित** कर सकते हैं:
|
||||
```bash
|
||||
apktool b . #In the folder generated when you decompiled the application
|
||||
```
|
||||
यह नए APK को _**dist**_ फ़ोल्डर के अंदर **कम्पाइल** करेगा।
|
||||
यह नया APK _**dist**_ फ़ोल्डर के **inside** में **compile** करेगा।
|
||||
|
||||
यदि **apktool** कोई **error** फेंकता है, तो [ installing the **latest version**](https://ibotpeaches.github.io/Apktool/install/) इंस्टॉल करने की कोशिश करें
|
||||
यदि **apktool** कोई **error** फेंकता है, तो try [installing the **latest version**](https://ibotpeaches.github.io/Apktool/install/) करें।
|
||||
|
||||
### **नए APK पर हस्ताक्षर करें**
|
||||
### **नए APK को Sign करें**
|
||||
|
||||
फिर, आपको **generate a key** बनानी होगी (आपसे password और कुछ जानकारी मांगी जाएगी जिसे आप यादृच्छिक रूप से भर सकते हैं):
|
||||
फिर, आपको **generate a key** करने की ज़रूरत होगी (आपसे एक password और कुछ जानकारी के बारे में पूछा जाएगा जिन्हें आप randomly भर सकते हैं):
|
||||
```bash
|
||||
keytool -genkey -v -keystore key.jks -keyalg RSA -keysize 2048 -validity 10000 -alias <your-alias>
|
||||
```
|
||||
अंत में, नए APK को **साइन** करें:
|
||||
अंत में, नए APK को **sign** करें:
|
||||
```bash
|
||||
jarsigner -keystore key.jks path/to/dist/* <your-alias>
|
||||
```
|
||||
### नए एप्लिकेशन का अनुकूलन
|
||||
### नई एप्लिकेशन को अनुकूलित करें
|
||||
|
||||
zipalign एक आर्काइव अलाइनमेंट टूल है जो Android एप्लिकेशन (APK) फ़ाइलों के लिए महत्वपूर्ण अनुकूलन प्रदान करता है। [More information here](https://developer.android.com/studio/command-line/zipalign).
|
||||
**zipalign** एक आर्काइव संरेखण उपकरण है जो Android एप्लिकेशन (APK) फ़ाइलों के लिए महत्वपूर्ण अनुकूलन प्रदान करता है। [More information here](https://developer.android.com/studio/command-line/zipalign).
|
||||
```bash
|
||||
zipalign [-f] [-v] <alignment> infile.apk outfile.apk
|
||||
zipalign -v 4 infile.apk
|
||||
```
|
||||
### **नए APK पर साइन करें (फिर से?)**
|
||||
### **Sign the new APK (again?)**
|
||||
|
||||
यदि आप jarsigner की बजाय [**apksigner**](https://developer.android.com/studio/command-line/) का उपयोग करना **पसंद** करते हैं, तो zipaling के साथ ऑप्टिमाइज़ेशन लागू करने के बाद आपको **APK पर साइन करना चाहिए**।
|
||||
|
||||
लेकिन ध्यान दें कि आपको केवल एक बार ही **एप्लिकेशन को साइन करना होगा**: jarsigner के साथ (zipalign से पहले) या aspsigner के साथ (zipaling के बाद)।
|
||||
अगर आप [**apksigner**](https://developer.android.com/studio/command-line/) का उपयोग jarsigner की जगह करना पसंद करते हैं, तो zipaling के साथ optimization लागू करने के बाद आपको **apk को sign करना चाहिए**। लेकिन ध्यान दें कि आपको केवल एक बार ही jarsigner के साथ (zipalign से पहले) या aspsigner के साथ (zipaling के बाद) **APPLICATION को SIGN करना होता है**।
|
||||
```bash
|
||||
apksigner sign --ks key.jks ./dist/mycompiled.apk
|
||||
```
|
||||
## Smali संशोधित करना
|
||||
## Smali को संशोधित करना
|
||||
|
||||
निम्नलिखित Hello World Java code के लिए:
|
||||
निम्नलिखित Hello World Java कोड के लिए:
|
||||
```java
|
||||
public static void printHelloWorld() {
|
||||
System.out.println("Hello World")
|
||||
}
|
||||
```
|
||||
Smali code होगा:
|
||||
Smali कोड इस प्रकार होगा:
|
||||
```java
|
||||
.method public static printHelloWorld()V
|
||||
.registers 2
|
||||
@ -92,13 +90,13 @@ invoke-virtual {v0,v1}, Ljava/io/PrintStream;->println(Ljava/lang/String;)V
|
||||
return-void
|
||||
.end method
|
||||
```
|
||||
Smali instruction set उपलब्ध है [here](https://source.android.com/devices/tech/dalvik/dalvik-bytecode#instructions).
|
||||
Smali instruction set इस लिंक पर उपलब्ध है [here](https://source.android.com/devices/tech/dalvik/dalvik-bytecode#instructions).
|
||||
|
||||
### हल्के बदलाव
|
||||
|
||||
### फ़ंक्शन के अंदर किसी वेरिएबल के प्रारंभिक मान बदलें
|
||||
### फ़ंक्शन के अंदर एक वेरिएबल के प्रारम्भिक मान बदलें
|
||||
|
||||
कुछ वेरिएबल फंक्शन की शुरुआत में opcode _const_ का उपयोग करके परिभाषित किए जाते हैं, आप इनके मान बदल सकते हैं, या नए वेरिएबल परिभाषित कर सकते हैं:
|
||||
कुछ वेरिएबल फ़ंक्शन की शुरुआत में opcode _const_ का उपयोग करके परिभाषित होते हैं, आप उनके मानों को संशोधित कर सकते हैं, या आप नए मान परिभाषित कर सकते हैं:
|
||||
```bash
|
||||
#Number
|
||||
const v9, 0xf4240
|
||||
@ -131,7 +129,7 @@ goto :goto_6 #Always go to: :goto_6
|
||||
```
|
||||
### बड़े परिवर्तन
|
||||
|
||||
### Logging
|
||||
### लॉगिंग
|
||||
```bash
|
||||
#Log win: <number>
|
||||
iget v5, p0, Lcom/google/ctf/shallweplayagame/GameActivity;->o:I #Get this.o inside v5
|
||||
@ -140,19 +138,19 @@ move-result-object v1 #Move to v1
|
||||
const-string v5, "wins" #Save "win" inside v5
|
||||
invoke-static {v5, v1}, Landroid/util/Log;->d(Ljava/lang/String;Ljava/lang/String;)I #Logging "Wins: <num>"
|
||||
```
|
||||
Recommendations:
|
||||
सिफारिशें:
|
||||
|
||||
- यदि आप फ़ंक्शन के अंदर घोषित वेरिएबल्स का उपयोग करने जा रहे हैं (घोषित v0,v1,v2...) तो ये पंक्तियाँ _.local <number>_ और वेरिएबल्स की घोषणाओं (_const v0, 0x1_) के बीच रखें
|
||||
- यदि आप लॉगिंग कोड को फ़ंक्शन के कोड के बीच में डालना चाहते हैं:
|
||||
- यदि आप फ़ंक्शन के अंदर घोषित वेरिएबल्स (v0, v1, v2...) का उपयोग करने जा रहे हैं, तो इन लाइनों को _.local <number>_ और वेरिएबल्स की घोषणाओं (_const v0, 0x1_) के बीच रखें।
|
||||
- यदि आप फ़ंक्शन के कोड के बीच में logging code रखना चाहते हैं:
|
||||
- घोषित वेरिएबल्स की संख्या में 2 जोड़ें: उदाहरण: _.locals 10_ से _.locals 12_
|
||||
- नए वेरिएबल्स पहले से घोषित वेरिएबल्स के अगले नंबर होने चाहिए (इस उदाहरण में यह _v10_ और _v11_ होने चाहिए, याद रखें कि यह v0 से शुरू होता है)।
|
||||
- लॉगिंग फ़ंक्शन के कोड को बदलें और _v10_ और _v11_ का उपयोग _v5_ और _v1_ के स्थान पर करें।
|
||||
- नए वेरिएबल्स पहले से घोषित वेरिएबल्स की अगली संख्याएँ होने चाहिए (इस उदाहरण में ये _v10_ और _v11_ होने चाहिए, याद रखें कि यह v0 से शुरू होता है)।
|
||||
- logging function के कोड को बदलें और _v10_ और _v11_ का उपयोग _v5_ और _v1_ की जगह करें।
|
||||
|
||||
### टोस्टिंग
|
||||
### Toast दिखाना
|
||||
|
||||
याद रखें कि फ़ंक्शन की शुरुआत में _.locals_ की संख्या में 3 जोड़ें।
|
||||
|
||||
यह कोड **एक फ़ंक्शन के बीच** में डालने के लिए तैयार किया गया है (**आवश्यकतानुसार** **वेरिएबल्स** की संख्या बदलें)। यह **this.o** का **value** लेगा, उसे **String** में **transform** करेगा और फिर उसके मान के साथ एक **toast** बनाएगा।
|
||||
यह कोड **फ़ंक्शन के बीच** में डालने के लिए तैयार किया गया है (ज़रूरत अनुसार **variables** की संख्या **change** करें)। यह **this.o के value** को लेगा, उसे **String** में **transform** करेगा और उसके मान के साथ एक **toast** बनाएगा।
|
||||
```bash
|
||||
const/4 v10, 0x1
|
||||
const/4 v11, 0x1
|
||||
@ -164,9 +162,9 @@ invoke-static {p0, v11, v12}, Landroid/widget/Toast;->makeText(Landroid/content/
|
||||
move-result-object v12
|
||||
invoke-virtual {v12}, Landroid/widget/Toast;->show()V
|
||||
```
|
||||
### स्टार्टअप पर एक native लाइब्रेरी लोड करना (System.loadLibrary)
|
||||
### स्टार्टअप पर Native Library लोड करना (System.loadLibrary)
|
||||
|
||||
कभी-कभी आपको एक native लाइब्रेरी को preload करना पड़ता है ताकि यह अन्य JNI libs से पहले initialize हो जाए (उदा., process-local telemetry/logging सक्षम करने के लिए)। आप System.loadLibrary() कॉल को किसी static initializer में या Application.onCreate() की शुरुआत में inject कर सकते हैं। static class initializer (<clinit>) के लिए उदाहरण smali:
|
||||
कभी-कभी आपको एक native लाइब्रेरी को पहले से लोड करना पड़ता है ताकि यह अन्य JNI लाइब्रेरीज़ से पहले इनिशियलाइज़ हो जाए (उदा., प्रोसेस-लोकल telemetry/logging सक्षम करने के लिए)। आप static initializer में या Application.onCreate() में जल्दी System.loadLibrary() कॉल इंजेक्ट कर सकते हैं। static class initializer (<clinit>) के लिए उदाहरण smali:
|
||||
```smali
|
||||
.class public Lcom/example/App;
|
||||
.super Landroid/app/Application;
|
||||
@ -178,7 +176,7 @@ invoke-static {v0}, Ljava/lang/System;->loadLibrary(Ljava/lang/String;)V
|
||||
return-void
|
||||
.end method
|
||||
```
|
||||
वैकल्पिक रूप से, लाइब्रेरी को यथासंभव जल्दी लोड कराने के लिए अपने Application.onCreate() की शुरुआत में वही दो निर्देश रखें:
|
||||
वैकल्पिक रूप से, लाइब्रेरी जितनी जल्दी संभव हो लोड हो यह सुनिश्चित करने के लिए अपने Application.onCreate() की शुरुआत में वही दो निर्देश रखें:
|
||||
```smali
|
||||
.method public onCreate()V
|
||||
.locals 1
|
||||
@ -191,10 +189,10 @@ return-void
|
||||
.end method
|
||||
```
|
||||
नोट्स:
|
||||
- सुनिश्चित करें कि लाइब्रेरी का सही ABI संस्करण lib/<abi>/ के अंतर्गत मौजूद हो (उदा., arm64-v8a/armeabi-v7a) ताकि UnsatisfiedLinkError से बचा जा सके।
|
||||
- बहुत जल्दी लोड करने पर (class static initializer) यह सुनिश्चित होता है कि native logger बाद की JNI गतिविधियों का निरीक्षण कर सके।
|
||||
- सुनिश्चित करें कि लाइब्रेरी का सही ABI वेरिएंट lib/<abi>/ (उदा., arm64-v8a/armeabi-v7a) के अंतर्गत मौजूद हो ताकि UnsatisfiedLinkError से बचा जा सके।
|
||||
- बहुत जल्दी लोड करने पर (class static initializer) यह सुनिश्चित होता है कि native logger बाद की JNI गतिविधि को देख सके।
|
||||
|
||||
## References
|
||||
## संदर्भ
|
||||
|
||||
- SoTap: हल्का-फुल्का इन-ऐप JNI (.so) व्यवहार लॉगर – [github.com/RezaArbabBot/SoTap](https://github.com/RezaArbabBot/SoTap)
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user