Adobe Desktop Service no estaba mirando su / etc / passwd. La biblioteca del sistema de Apple era.
La biblioteca del sistema de Apple quería saber su nombre de usuario para poder encontrar su directorio de inicio. Luego decidió que la mejor manera de averiguar su nombre de usuario era buscarlo /etc/passwd. Adobe Desktop Service solo quería saber la ruta de acceso a su directorio de inicio y ¿(correctamente) lo usó? el marco de CoreFoundation para eso. Es por eso que la llamada aparece bajo el proceso de Adobe.
Detalles
En su captura de pantalla, la entrada de la persona que llama dice algo así _fsi_get_user. Este es el símbolo de una subrutina privada en una de las bibliotecas del sistema macOS libsystem_info.dylib, ubicada en /usr/lib/system.
El código fuente público de la _fsi_get_userfunción revela la siguiente lógica:
if (geteuid() == 0)
{
// […]
}
else
{
f = fopen(_PATH_PASSWD, "r");
_fsi_get_validation(si, VALIDATION_PASSWD, _PATH_PASSWD, f, &va, &vb);
fmt = 1;
}
Mirando el código descompilado en libsystem_info.dylib(por ejemplo, usando Hopper Disassembler) confirma que ese _PATH_PASSWDes realmente el nombre del archivo /etc/passwd. (El código fuente más abajo file_module.ctambién explica por qué hay una llamada a fstatinmediatamente después de fopen: la implementación de _fsi_get_validation? Hace eso para averiguar el último tiempo de modificación de su /etc/passwd).
En otras palabras: Adobe no estaba mirando su archivo passwd; La biblioteca del sistema de Apple era.
Conectando los puntos
Hay muchas pilas de llamadas posibles que pueden conectar el código de Adobe Desktop Service a la _fsi_get_userfunción. ¿Un poco de análisis estático sugiere lo más plausible? candidato sería NSHomeDirectory, una clase de utilidad en Foundation.framework.
Mirando el binario de Adobe Desktop Service revela que efectivamente llama [NSHomeDirectory UTF8String]:
*100032ac4 call imp___stubs__NSHomeDirectory
*100032ac9 mov rsi, qword [0x10008a178] ; "UTF8String"
*100032ad0 mov rdi, rax
*100032ad3 call qword [_objc_msgSend_100088350]
La implementación de Apple NSHomeDirectorynos llevará a /etc/passwdbastante rápido. Mi suposición educada sobre la cadena más probable de llamadas a funciones sería:
Adobe Desktop Service → [NSHomeDirectory UTF8String](en Foundation.framework) → NSHomeDirectoryForUser→ CFCopyHomeDirectoryURLForUser(en CoreFoundation.framework) → _CFCopyHomeDirURLForUser→ getpwuid(en libsystem_info.dylib, reexportado a través de libSystem.B.dylib) → si_user_byuid(aquí es donde Apple decide en tiempo de ejecución qué fuente va a utilizar. Por ejemplo, si su ID de usuario está entre 1 y 499 , /etc/passwdse le consultará en lugar de Servicios de directorio. ) → file_user_byuid→ _fsi_get_user.
Para estar más seguro, analicé el servicio binario de escritorio de Adobe y, como era de esperar, no contiene ninguna referencia única /etc/passwd. (Sin embargo, no he comprobado si Adobe Desktop Service hace o no otras cosas sospechosas).
Todo el análisis hubiera sido un poco más fácil si hubiera hecho clic en una de las entradas antes de crear la captura de pantalla. Su aplicación habría mostrado el seguimiento de pila relevante en la esquina inferior derecha (son las líneas donde dice Seguimiento de pila ). Pero bueno, me divertí mucho descubriéndolo, ¡y aprendí mucho de esa manera!
Verificación
Para confirmar que mi análisis es correcto, es posible que desee hacer clic en una de las /etc/passwdentradas en su aplicación de instrumentos y encontrar los términos NSHomeDirectoryy file_user_byuiden algún lugar del seguimiento de la pila.
fstat(). Pero esto puede ser solo un efecto secundario de los instrumentos.