2015-04-23 18 views
10

Prima di tutto, lasciami dire che capisco che l'utilizzo di PT_DENY_ATTACH come descritto a: Bugging Debuggers è piuttosto inutile.

Tuttavia, per capire come funziona iOS, mi piacerebbe comunque sapere: è possibile fare qualcosa di simile quando si lavora su un progetto Swift? Poiché Objective-C è basato su C, esiste una funzione main(int argc, char *argv[]) che può essere sfruttata per impedire a gdb di collegarsi al processo.

Come si farebbe in Swift? Sto principalmente cercando di capire il ciclo di vita dell'applicazione in Swift, tuttavia, la maggior parte delle spiegazioni che riesco a trovare sono per ObjC.iOS Antipirateria in Swift

+1

La risposta a [questa domanda] (http://stackoverflow.com/questions/24020000/subclass-uiapplication-with-swift/24021180#24021180) potrebbe essere utile. – ahruss

+0

Questa risposta è, in effetti, molto utile alla comprensione. Sembra che il ciclo di vita sia lo stesso. Tuttavia, Swift nasconde alcune delle implementazioni dietro la direttiva @UIApplicationMain. – Stephen

risposta

9

Grazie a utenti ahruss 's molto utile collegamento, ecco la soluzione che ho atterrato su:

ho usato il metodo di riferimento in this question per creare un file main.swift. Poi ho creato un file c (e intestazione) contenente questa definizione di metodo:

typedef int (*command_ptr_t)(int _request, pid_t _pid, caddr_t _addr, int _data); 

#if !defined(PT_DENY_ATTACH) 
#define PT_DENY_ATTACH 31 
#endif 

//Anti-debug method 
void disable_attach() { 
    void* handle = dlopen(0, RTLD_GLOBAL | RTLD_NOW); 
    command_ptr_t command_ptr = dlsym(handle, "ptrace"); 
    command_ptr(PT_DENY_ATTACH, 0, 0, 0); 
    dlclose(handle); 
} 

ho aggiunto il file di intestazione disableAttach.h nel mio header ponte, poi chiamato disable_attach() direttamente sopra la mia UIApplicationMain(Process.argc, Process.unsafeArgv, nil, NSStringFromClass(AppDelegate)) chiamata in main.swift. Si dovrebbe finire con un file main.swift simile a questo:

import Foundation 
import UIKit 

disable_attach() 
UIApplicationMain(
    CommandLine.argc, 
    UnsafeMutableRawPointer(CommandLine.unsafeArgv) 
     .bindMemory(
      to: UnsafeMutablePointer<Int8>.self, 
      capacity: Int(CommandLine.argc)), 
    nil, 
    NSStringFromClass(AppDelegate.self) 
) 

Come ho affermato in precedenza in un commento, sembra che il ciclo di vita è lo stesso, ma che la direttiva @UIApplicationMain nasconde la principale file di si.

+0

Se capisco cosa hai fatto correttamente, questo può ancora essere aggirato - una volta che l'attaccante scopre cosa sta succedendo, salterà semplicemente la chiamata di funzione. Puoi provare qualcosa di più sofisticato, come i percorsi accidentali non voluti (quando hai capito che stai eseguendo il debug e vuoi tenere l'attaccante al buio su * quando esattamente * è successo) combinato con il rilevamento di debugger non ovvio come misurare il tempo di esecuzione del codice o qualcosa di strano e inaspettato come l'auto-debugging. Il problema è che chiunque è tenace e abbastanza craccerà qualsiasi difesa ... Quindi assicurati di non andare troppo alto profilo =) – Mints97

+0

@ Mints97 Hai ragione. Il metodo PT_DENY_ATTACH non è più considerato utile ([questo collegamento] (http://iphonedevwiki.net/index.php/Crack_prevention) lo elenca come "Deprecato o non funzionante"), tuttavia, è stato concepito come un buon caso d'uso per capire le differenze tra un'applicazione iOS basata su Obec e Swift. – Stephen

+0

@Stephen C'è una soluzione che può sostituire PT_DENY_ATTACH? –