Tema destacado: Nueva página de elhacker.net en Google+ 
 Autor
|
Tema: [Solucionado] Obtener la ruta de todos los procesos en ejecución (Leído 2,742 veces)
|
Krähne
 Desconectado
Mensajes: 51
It can't rain all the time...
|
es que "el proceso inactivo del sistema" no es un proceso en si, es un simple hilo del kernel que calcula el uso de la cpu, para que quede claro aca te dejo una explicación de internet:
PD:yo no usaria apis en .NET, lo podes hacer con la clase Process o hasta con WMI muy facilmente sin recurrir a las apis para obtener el path.
Interesante, no se me había dado por buscarle en google. Gracias por esa información. Y... ¿Cómo lo harías sin el uso de APIS obteniéndo los mismos resultados que yo con el uso de las mismas?. De todos modos, creo que la ayuda quedó solventada ya hace 2 respuestas.
|
|
|
|
|
En línea
|
Yo soy más sabio que este hombre; es posible que ninguno de los dos sepamos cosa que valga la pena, pero él cree que sabe algo, pese a no saberlo, mientras que yo, así como no sé nada, tampoco creo saberlo. Yo no tengo conciencia de saber nada.
|
|
|
|
seba123neo
|
aca te paso 2 formas, una con Process y la otra con WMI: Imports System.Management
Public Class Form1
Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
Call ObtenerProcesos1()
Call ObtenerProcesos2()
End Sub
Private Sub ObtenerProcesos1()
Dim machineName As String = "localhost"
Dim myQuery As String = "select * from win32_process"
Dim mScope As New ManagementScope(String.Format("\\{0}\root\cimv2", machineName), Nothing)
mScope.Connect()
If mScope.IsConnected Then
Dim objQuery As New ObjectQuery(myQuery)
Using objSearcher As New ManagementObjectSearcher(mScope, objQuery)
Using result As ManagementObjectCollection = objSearcher.Get
For Each item As ManagementObject In result
Debug.WriteLine(String.Format("---->> Nombre Proceso: {0}. ID Proceso: {1}. Path: {2}.", item("Name"), item("ProcessId"), item("ExecutablePath")))
Next
End Using
End Using
End If
End Sub
Private Sub ObtenerProcesos2()
For Each p As Process In Process.GetProcesses()
Try
Debug.WriteLine(p.Modules(0).FileName)
Catch ex As Exception
End Try
Next
End Sub
End Class
saludos.
|
|
|
|
|
En línea
|
Mucha gente, especialmente la ignorante desea castigarte por decir la verdad, por ser correcto, por ser tú. Nunca te disculpes por ser correcto, o por estar años delante de tu tiempo.
Si estas en lo cierto, y lo sabes, que hable tu razón. Incluso si eres una minoria de uno solo, la verdad sigue siendo la verdad. M. Gandhi
|
|
|
Krähne
Desconectado
Mensajes: 51
It can't rain all the time...
|
@seba123neo: Hola... he revisado tus ejemplos y me he tomado la libertad de depurarlos para saber cómo funcionaban, y como lo supuse habrían más limitaciones que con el uso de APIS. Si bien tus códigos aprovechan lo que la plataforma .NET nos ofrece, pero... resulta que dicha plataforma no es tan "potente" como quisiéramos, por tal tenemos limitaciones al momento de realizar operaciones como las que hemos estado tratando en el tema, de lo cual ya debes estar al tanto. Como te puedes dar cuenta, con tu ejemplo tenemos limitaciones en más de 2 procesos al momento de obtener su ruta, esto con WMI, ahora al momento de hacerlo con Process es aún peor, las limitaciones son mayores ya que no se puede tener acceso a los módulos de algunos procesos, sí... ya veo el Try-Catch pero de nada sirve porque no nos devuelve entonces las rutas de " Todos los procesos" como dice el enunciado de la pregunta original. Un ejemplo de lo que te digo con WMI es el siguiente:  Como notas la ruta de los procesos nombrados, más uno además del ya nombrado no son obtenidos. Una pena eh, parece que el uso de APIS nos da un poco más de ventajas. Por supuesto, yo tampoco logré obtener la ruta de esos dos procesos, pero como has traído la información podemos entender que System es un hilo del kernel así que ubicación física no existe, ya el System Idle Process sí se le puede obtener su ruta (creo) ya que revisando algunas aplicaciones por allí en C veo que obtienen esa ruta sin problemas algunos y si mi memoria no falla, es un archivo en C:\WINDOWS\System32. De todos modos no estamos aquí para probar quién ha hecho el mejor código, tan sólo estamos para dar ayuda y claro, explorar otras soluciones, por ahora sigo firme en mi opinión que el uso de APIS para puntos como los tratados, es mejor en .NET. Gruß. |
|
|
|
|
En línea
|
Yo soy más sabio que este hombre; es posible que ninguno de los dos sepamos cosa que valga la pena, pero él cree que sabe algo, pese a no saberlo, mientras que yo, así como no sé nada, tampoco creo saberlo. Yo no tengo conciencia de saber nada.
|
|
|
|
[D4N93R]
|
"resulta que dicha plataforma no es tan "potente" como quisiéramos" Demuéstralo.. Cualquier lenguaje puede usar APIs. Y cuando cambias del lenguaje no cambias de API por lo que no cambia en nada el comportamiento de la llamada. Todo acá (en entornos administrados) es cuestión de permisologías. Y esa es la verdadera potencia que nos ofrece la plataforma.. Un saludo  |
|
|
|
|
En línea
|
|
|
|
Krähne
Desconectado
Mensajes: 51
It can't rain all the time...
|
"resulta que dicha plataforma no es tan "potente" como quisiéramos" Demuéstralo.. Cualquier lenguaje puede usar APIs. Y cuando cambias del lenguaje no cambias de API por lo que no cambia en nada el comportamiento de la llamada. Todo acá (en entornos administrados) es cuestión de permisologías. Y esa es la verdadera potencia que nos ofrece la plataforma.. Un saludo Venga, estás haciéndome un especie de reto en base a lo que he demostrado. ¿Qué pasa [D4N93R] me vas a trollear ahora?. Ostia que me gusta C# tanto como a ti, pero no hay que negar sus defectos. Tu mismo te contradices porque, en contraposición con lo que he dicho SÍ tenemos limitaciones de privilegios, y esas limitaciones nos las da misma .NET, ¿¡¡¡QUÉ!!!? ¿¡¡¡CÓMO!!!?... Venga calma, revisa con APIS lo que he hecho y luego con las clases de .NET y verás que tenemos más privilegios o acceso (Debe ser por haber abierto el handle del proceso con permisos específicos, no con los que .NET debe darles para las clases que usa) al momento de usar APIS como he dicho anteriormente, con la clase Process no podemos acceder a los módulos de X Procesos, como svchost.exe (Específicamente uno de todos los svchost.exe), entre otros procesos como winlogon.exe, etc. Con WMI también tenemos limitaciones, y aunque prefiero usar WMI antes que Process, el uso de APIS va a ser un tema indiscutible, siempre tendríamos que trabajar sobre código administrado, seguiré firme en mi opinión sobre el uso de APIS nativas para obtener informaciones de esta talla. No busco pelear contigo, vamos que hasta te respeto por ser programador de esta plataforma, pero tampoco pienso rebajarme sólo porque no te gustó una crítica que ni si quiera a ti mismo hice; Si gustas comprueba por ti mismo, depura los códigos, prueba paso a paso lo que he dicho. Eso sí, espero haber entendido lo que me dijiste en tal respuesta, porque... si no ya me extendí en vano  . Gruß.
|
|
|
|
« Última modificación: 29 Mayo 2011, 01:07 por Krähne »
|
En línea
|
Yo soy más sabio que este hombre; es posible que ninguno de los dos sepamos cosa que valga la pena, pero él cree que sabe algo, pese a no saberlo, mientras que yo, así como no sé nada, tampoco creo saberlo. Yo no tengo conciencia de saber nada.
|
|
|
Segurida
Desconectado
Mensajes: 61
|
Yo no sé mucho de APIS, pero sé que sin utilizarlas, hay "algunas limitaciones" en cuanto a "acceder fuera de la propia aplicación" es decir, al acceder al registro, o como en este caso a otros procesos, más aun a los del sistema o antivirus, sin APIS, supongo que se podrán conseguir (con las limitaciones que eso conlleva), pero con APIS en más sencillo (para quién lo entienda) y más rápido (código más ligero en la mayoría de los casos), como ya dije no sé mucho de APIS ni de bases de datos, pero sé que la mayoría de los problemas que he tenido con mis aplicaciones, he encontrado códigos en los que utilizaban APIS, y con eso se me solucionaron los problemas.
Muchas gracias a tod@s, saludos!
|
|
|
|
|
En línea
|
|
|
|
|
[D4N93R]
|
@Krähne: Creo que te extendiste en vano. Todos conocemos la diferencia entre nativo y administrado, no se porque resaltas estas cosas. Si es un beneficio para la plataforma que te limite en ciertos aspectos. Sino comprueba el rate de bugs de una aplicación nativa a una app administrada. Y te explico: Si yo llamo al método A en la librería X.dll desde .net, voy a tener los mismos resultados que si la llamara desde C++. Siempre y cuando ambas llamdas se hagan con el mismo usuario. Cuando no tienes acceso a algo es por una razón. No hay nada aleatorio ni nada por el estilo. Si usas WMI desde .net o desde Python, vas a tener el mismo resultado. En verdad no entiendo bien lo que dices. Ahora, si estás hablando de que una aplicación corra en otro Ring, ahí estás equivocado, porque ni .Net ni cualquier otra plataforma administrada se creó con ese fin. De todos modos, si crees que .Net sigue siendo así de perezoso en cuanto a privilegios, te recomiendo que le eches un ojo a: http://www.mosa-project.org/Y si estás interesado en el tema: http://channel9.msdn.com/blogs/charles/peter-wieland-user-mode-driver-frameworkUn saludo. PD: Lo de troll está de más.. |
|
|
|
|
En línea
|
|
|
|
Krähne
Desconectado
Mensajes: 51
It can't rain all the time...
|
@[D4N93R]: Parece que has desarrollado una especie de fobia/rabia hacia mis respuestas pues a todas las que puedes/quieres les vas sacando una contraposición cuando éstas ya solventaron el problema principal. Creo que para el usuario Segurida, fue más que satisfactoria la respuesta que le he dado, y mucho más funcional que usar WMI o Process, si no te has dado cuenta EN LOS EJEMPLOS DE seba123neo NO PUEDES ACCEDER A X INFORMACIÓN EN X PROCESOS (En rojo, negrita y mayúsculas a ver si lo lees de una vez por todas) que con el uso de APIS ¡SÍ PUEDES! (Y ya se que no es un tema de rings, joder que con tal API tienes más acceso a un proceso (Modo usuario igual, ¡¡¡Pero revisa los parámetros que le doy a OpenProcess!!!) ¡Que con las que .net nos ofrece!). ¿Será que te cuesta mucho entenderlo o qué pasa?... Yo vengo a tratar de ayudar (No a discutir con X o Y persona si X o Y método es más ético/viable/obligatorio mientras que otro hace lo mismo y lo hace mejor sin tanto protocolo) satisfactoriamente en éste caso, al igual que los demás también desean ayudar pero... como que no te gustó/gusta la idea de que eligieran/elijan mi solución como la más viable en el caso de él/otros.
Sinceramente no pienso seguir discutiendo un tema que ya está resuelto, más si sin embargo quieres seguir la -sin sentido- disputa existen los MP, alguien debería cerrar el tema, o creo que tú mismo ya que eres moderador.
Gruß.
P.D.: Si vas a volver con protocolos de cómo usar .net, qué es más recomendable, qué no, o si vienes de nuevo a hablarme de APIS cuando el tema está bastante claro, me temo que preferiré ignorarte, pues sigo sin entender el porqué saltaste de la nada a discutir algo que estaba solventado.
|
|
|
|
« Última modificación: 30 Mayo 2011, 00:13 por Krähne »
|
En línea
|
Yo soy más sabio que este hombre; es posible que ninguno de los dos sepamos cosa que valga la pena, pero él cree que sabe algo, pese a no saberlo, mientras que yo, así como no sé nada, tampoco creo saberlo. Yo no tengo conciencia de saber nada.
|
|
|
|
seba123neo
|
@[D4N93R]: Parece que has desarrollado una especie de fobia/rabia hacia mis respuestas pues a todas las que puedes/quieres les vas sacando una contraposición cuando éstas ya solventaron el problema principal. Creo que para el usuario Segurida, fue más que satisfactoria la respuesta que le he dado, y mucho más funcional que usar WMI o Process, si no te has dado cuenta EN LOS EJEMPLOS DE seba123neo NO PUEDES ACCEDER A X INFORMACIÓN EN X PROCESOS (En rojo, negrita y mayúsculas a ver si lo lees de una vez por todas) que con el uso de APIS ¡SÍ PUEDES! (Y ya se que no es un tema de rings, joder que con tal API tienes más acceso a un proceso (Modo usuario igual, ¡¡¡Pero revisa los parámetros que le doy a OpenProcess!!!) ¡Que con las que .net nos ofrece!). ¿Será que te cuesta mucho entenderlo o qué pasa?... Yo vengo a tratar de ayudar (No a discutir con X o Y persona si X o Y método es más ético/viable/obligatorio mientras que otro hace lo mismo y lo hace mejor sin tanto protocolo) satisfactoriamente en éste caso, al igual que los demás también desean ayudar pero... como que no te gustó/gusta la idea de que eligieran/elijan mi solución como la más viable en el caso de él/otros.
Sinceramente no pienso seguir discutiendo un tema que ya está resuelto, más si sin embargo quieres seguir la -sin sentido- disputa existen los MP, alguien debería cerrar el tema, o creo que tú mismo ya que eres moderador.
Gruß.
P.D.: Si vas a volver con protocolos de cómo usar .net, qué es más recomendable, qué no, o si vienes de nuevo a hablarme de APIS cuando el tema está bastante claro, me temo que preferiré ignorarte, pues sigo sin entender el porqué saltaste de la nada a discutir algo que estaba solventado.
che no era para tanto, pense que ya habia terminado el tema. este mensaje de [D4N93R]"resulta que dicha plataforma no es tan "potente" como quisiéramos" Demuéstralo.. Cualquier lenguaje puede usar APIs. Y cuando cambias del lenguaje no cambias de API por lo que no cambia en nada el comportamiento de la llamada. Todo acá (en entornos administrados) es cuestión de permisologías. Y esa es la verdadera potencia que nos ofrece la plataforma.. Un saludo no le veo nada de arrogancia, pelea o de tratar de hacer peleas...no se porque siguieron. ---------------------- perdona Krähne pero vos mismo ya te respondiste cuando me dijiste en el otro post esto:
con tu ejemplo tenemos limitaciones en más de 2 procesos al momento de obtener su ruta, esto con WMI, ahora al momento de hacerlo con Process es aún peor, las limitaciones son mayores ya que no se puede tener acceso a los módulos de algunos procesos, sí... ya veo el Try-Catch pero de nada sirve porque no nos devuelve entonces las rutas de "Todos los procesos" como dice el enunciado de la pregunta original.
yo tampoco logré obtener la ruta de esos dos procesos
entonces en que quedamos? es lo mismo usar api que wmi ?, si total las 2 formas dan el mismo resultado... mostrame un ejemplo que se pueda hacer exclusivamente con apis y no con wmi, solo asi te voy a decir que estas en lo cierto, pero sino no hay nada mas que hablar. y creo que no es discutir en mala forma, discutamos pero en buena forma para asi aprender a mas y aprender, o acaso no somos capaces de discutir algo civilizadamente ? si no te has dado cuenta EN LOS EJEMPLOS DE seba123neo NO PUEDES ACCEDER A X INFORMACIÓN EN X PROCESOS (En rojo, negrita y mayúsculas a ver si lo lees de una vez por todas) que con el uso de APIS ¡SÍ PUEDES!
ahi no entendi, que es lo que se puede hacer con apis y no con wmi. saludos.
|
|
|
|
|
En línea
|
Mucha gente, especialmente la ignorante desea castigarte por decir la verdad, por ser correcto, por ser tú. Nunca te disculpes por ser correcto, o por estar años delante de tu tiempo.
Si estas en lo cierto, y lo sabes, que hable tu razón. Incluso si eres una minoria de uno solo, la verdad sigue siendo la verdad. M. Gandhi
|
|
|
|
 |
