Ho notato che Adobe Desktop Services monitora costantemente / etc / passwd.
Sarebbe il punto? Le password non sono memorizzate in / etc / passwd, quindi perché un monitor app / etc / passwd? Quali informazioni potrebbero provare a monitorare?
La libreria di sistema di Apple voleva conoscere il tuo nome utente in modo che possa trovare la tua home directory. Ha quindi deciso che il modo migliore per capire il tuo nome utente era cercarlo in /etc/passwd . Adobe Desktop Service voleva solo conoscere il percorso della directory home e (correttamente) utilizzare il framework CoreFoundation per questo. Ecco perché la chiamata appare sotto il processo di Adobe.
Nel tuo screenshot, la voce Caller dice qualcosa come _fsi_get_user . Questo è il simbolo di una subroutine privata in una delle librerie di sistema di macOS, libsystem_info.dylib , che si trova in /usr/lib/system .
Il codice sorgente pubblico della% la funzione_fsi_get_user rivela la seguente logica:
if (geteuid() == 0)
{
// […]
}
else
{
f = fopen(_PATH_PASSWD, "r");
_fsi_get_validation(si, VALIDATION_PASSWD, _PATH_PASSWD, f, &va, &vb);
fmt = 1;
}
Esaminando il codice decompilato in libsystem_info.dylib (ad esempio, utilizzando Hopper Disassembler) si conferma che _PATH_PASSWD è effettivamente il nome del file /etc/passwd . (Il codice sorgente più in basso in file_module.c spiega anche perché c'è una chiamata a fstat immediatamente dopo fopen : l'implementazione di _fsi_get_validation lo fa per calcolare l'ultima modifica del tuo /etc/passwd .)
In altre parole: Adobe non stava guardando il tuo file passwd; La libreria di sistema di Apple era.
Ci sono molti possibili stack di chiamate che possono collegare il codice di Adobe Desktop Service alla funzione _fsi_get_user . Un po 'di analisi statica suggerisce che il candidato più plausibile sarebbe NSHomeDirectory , una classe di utilità in Foundation.framework .
L'analisi del file binario di Adobe Desktop Service rivela che chiama effettivamente [NSHomeDirectory UTF8String] :
*100032ac4 call imp___stubs__NSHomeDirectory
*100032ac9 mov rsi, qword [0x10008a178] ; "UTF8String"
*100032ad0 mov rdi, rax
*100032ad3 call qword [_objc_msgSend_100088350]
L'implementazione di Apple di NSHomeDirectory ci condurrà quindi a /etc/passwd abbastanza rapidamente. La mia supposizione istruita sulla più probabile catena di chiamate di funzione sarebbe:
Adobe Desktop Service → [NSHomeDirectory UTF8String] (in Foundation.framework ) → NSHomeDirectoryForUser → CFCopyHomeDirectoryURLForUser (in CoreFoundation.framework ) → _CFCopyHomeDirURLForUser → getpwuid (in libsystem_info.dylib , riesportati tramite libSystem.B.dylib ) → si_user_byuid (è qui che Apple decide in fase di esecuzione quale fonte utilizzerà. Ad esempio, se l'ID utente è compreso tra 1 e 499, verrà consultato il /etc/passwd invece dei Servizi di directory. ) → file_user_byuid → _fsi_get_user .
Per essere più sicuro, ho ulteriormente analizzato il servizio binario Adobe Desktop e, come previsto, non contiene alcun riferimento a /etc/passwd . (Non ho controllato se Adobe Desktop Service fa altre cose losche, però.)
L'intera analisi sarebbe stata un po 'più semplice se avessi effettivamente fatto clic su una delle voci prima di aver creato lo screenshot. La tua app avrebbe quindi mostrato la traccia dello stack pertinente nell'angolo in basso a destra (sono le linee in cui è indicato Stack Trace ). Ma hey, mi sono divertito molto a capirlo, e ho imparato molto in questo modo!
Per confermare che la mia analisi è corretta, puoi fare clic su una delle voci /etc/passwd nell'app Strumenti e trovare i termini NSHomeDirectory e file_user_byuid da qualche parte nella traccia dello stack.
Dalle informazioni nel tuo screenshot, il programma non sta cercando di "monitorare" il contenuto del file. Richiede invece ripetutamente i metadati relativi al file (cioè il file esiste, quanto è grande, quando è stato creato, ecc.)
Solo Adobe può dirti perché hanno codificato il loro programma come hanno fatto.
Tuttavia, si noti che ci sono molte spiegazioni logiche sul perché hanno fatto quello che hanno fatto - che non comporta alcuna attività di "spionaggio" o "nefasto".
Ad esempio questo particolare programma daemon (cioè il servizio in background) potrebbe controllare costantemente l'esistenza di / etc / password per determinare che sia (a) non sandboxed, e (b) non sia privato delle sue autorizzazioni in modo che esso è vietato esaminare quel file.
Leggi altre domande sui tag applications adobe