BHC (Batch Hide Compiler 2.2) by WHK [Proyecto para abril Negro]

[Karcrack]

De todas formas, no es posible ejecutar *.Bat's completos onthefly ... Al menos no de estas formas...

Ej:

Código (dos) [Seleccionar] Expandir

set /a valor=5
echo %valor%

Buen ejemplo Novlucker



No se... se me ocurre una forma de investigar... carga un BAT y mira que ocurre , luego simula cargar el BAT...
Todo esto, como no, son hipotesis... es cuestion de ponerse... y como muchos saben estoy castigado.... asi que se pongan otros!

Saludos

[Arkangel_0x7C5]

De todas formas, no es posible ejecutar *.Bat's completos onthefly ... Al menos no de estas formas...

Saludos

Porque no vas a poder ejecutarlos enteros. Si estas haciendo lo mismo que arias si le pasas un Batch. Mientras no llegues al limite de caracteres no hay problema

lpCommandLine [in, out, opcional]

   The command line to be executed. The maximum length of this string is 32,768 characters, including the Unicode terminating null character. La línea de comandos a ejecutar. La duración máxima de esta cadena es 32.768 caracteres, incluidos los caracteres Unicode de terminación nula. If lpApplicationName is NULL, the module name portion of lpCommandLine is limited to MAX_PATH characters. LpApplicationName Si es NULL, el nombre del módulo de lpCommandLine se limita a los caracteres MAX_PATH.

   The Unicode version of this function, La versión Unicode de esta función, CreateProcessW , can modify the contents of this string. CreateProcessW, puede modificar el contenido de esta cadena. Therefore, this parameter cannot be a pointer to read-only memory (such as a const variable or a literal string). Por lo tanto, este parámetro no puede ser un puntero a la memoria de sólo lectura (como un const variable o una cadena literal). If this parameter is a constant string, the function may cause an access violation. Si este parámetro es una cadena constante, la función puede provocar una violación de acceso.

   The lpCommandLine parameter can be NULL. El lpCommandLine parámetro puede ser NULL. In that case, the function uses the string pointed to by lpApplicationName as the command line. En ese caso, la función utiliza la cadena señaló que por lpApplicationName como la línea de comandos.

Saludos

PD:Lo mejor es que alguien lo prueve. Que no creo que se tarde tanto en implementar eso.

[Karcrack]

Cierto... estuve probando... y se puede!!! (aunque con limitaciones)

El problema esta por ejemplo en este code:

Código (dos) [Seleccionar] Expandir

@echo off

:cabeza
echo ###############
echo # Hecho por:  #
echo # sirdarckcat #
echo ###############
goto:EOF

:uso
echo uso:
echo %~nx0 Nombre
goto:EOF

:nombre
echo Hola %*
goto:EOF

Hay que buscar una alternativa viable...

Saludos

[Arkangel_0x7C5]

donde se produce el error?

[Karcrack]

donde se produce el error?

En los Goto:* ya que al no estar definida la etiqueta...

Puse ese code como ejemplo de goto:*

He estado mirando y este código sorprendentemente funciona:

Código (dos) [Seleccionar] Expandir

@echo off
tasklist | find "explorer.exe" >> NULL
if %errorlevel%==0 (
echo SI
  ) ELSE (
echo NO
)
goto:EOF

Aunque cuando lo vas poniendo linea por linea te pregunta... pero eso con Pipes o con WinExec no da problema

Lastima que por ahora no haya hecho funciona las etiquetas supongo que si que se puede

[WHK]

Le puse Highlighting al editor 



aunque estoy teniendo unos pequeños problemas con los scrollbars del richtextbox pero estoy solucionandolo.

eso de system no hace falta incluir dlls ni nada porque la api de win lo hace, también puedes reemplazar "\n" en vb6 por  vbCrLf, lo probaré.

echo %~nx0 Nombre

Tienes razón ya que como no habría .bat la variable que indica el mismo archivo se perdería aunque podría establecerse por defecto al inicio del script esas variables, por ejemplo con set a app.path & app.exename & ".exe"

[~~]

Ya te lo comenté por privado WHK, pero excelente trabajo

Si se me permite te daré algunas sugerencias que pueden resultar atractivas para la siguiente versión y alguna mejora que veo posible

He estado ojeando el código del stub y le veo algunas cosillas que podrías cambiar...

Usas un form, pero no lo utilizas, si lo quitas podrías ahorrarte unos pocos bytes  ya que no hace falta:
http://en.allexperts.com/q/Visual-Basic-1048/Applicaciones-Windows-sin-formulario.htm

Si cambias las firmas deja de funcionar o es que yo lo estoy haciendo mal?? Te aconsejo que utilices otro método, a mi parecer una buena idea sería esta:

-> Obtienes el final del stub gracias a sus datos en el PE, si quieres un ejemplo en VB aquí tienes uno mio: http://e0n-productions.blogspot.com/2008/11/obtener-el-inicio-del-eof.html A partir de la dirección devuelta ya por esa función se encontrarían todos los datos necesarios.

-> En vez de usar firmas fijas (fácilmente detectables por un AV y poco dinámicas) puedes poner en el inicio del EOF una estructura por ejemplo así:

Código (c) [Seleccionar] Expandir


struct datosEOF
{
   int NumeroCaracteresCuerpoMensaje; // Si es 0 pues no hay mensaje ;)
   int NumeroCaracteresTituloMensaje;   // Si es 0 lo mismo
}


Así leerías la estructura en modo binario desde el final de tu stub, con un CopyMemory te copiarías el título y el el cuerpo del mensaje de error y lo que sobrase sería el bat.

No se, me parece más dinámico y resultaría más fácil añadir datos en un futuro, de igual manera evita errores por firmas repetidas a lo largo del exe.


Pese a los bytes que te puedes ahorrar quitando el form del stub, VB no me parece un buen lenguaje para esto, hacerlo en C++ por ejemplo te resultaría igual de fácil y el stub pesaría un puñado de kb, claro eso siempre va a gusto del programador, si estás interesado no dudes en consultarme que te puedo hechar un cable.

Y bueno, no se me ocurre nada más, muy buien trabajo y el diseño gráfico elaboradísimo
Salu2

[YST]

-> Obtienes el final del stub gracias a sus datos en el PE, si quieres un ejemplo en VB aquí tienes uno mio: http://e0n-productions.blogspot.com/2008/11/obtener-el-inicio-del-eof.html A partir de la dirección devuelta ya por esa función se encontrarían todos los datos necesarios.

No me parece esta manera de obtener los datos ya que tu codigo al sacar el tamaño de el archivo mediante el PE si se modifica el PE(como ya le recomende a WHK por msn ) para que los datos queden dentro de este tu codigo no detectaria los otros datos logicamente .

Yo la manera que recomiendo guardar datos si no quieres usar el sistema de firmas al final de el archivo es mediante resource

[~~]

Está claro que si metes los datos dentro de una sección nueva por ejemplo o amplias la última sección eso no va a funcionar, ya que te dice donde empieza el EOF, pero él los tiene metidos en el EOF, no dentro del pe, por eso le di la idea

[WHK]

Lo de llamar con winexec a un contenido bat directamente no funciona, si lo paso por cmd /c tampoco (aunque no debería hacerlo tampoco)

Código (vb) [Seleccionar] Expandir

Private Declare Function WinExec Lib "kernel32" (ByVal lpCmdLine As String, ByVal nCmdShow As Long) As Long

Private Sub Command1_Click()
Call WinExec(Text1.Text, 0)
End Sub

asi que desde vb para ejecutarlo de esa forma no funciona a menos que pipeada si se pueda, trataré de hacer eso y lanzarle linea por linea aunque se que no funcionará.

Usas un form, pero no lo utilizas, si lo quitas podrías ahorrarte unos pocos bytes

Lo haré

Obtienes el final del stub gracias a sus datos en el PE

Alguien por msn me sopló que eso de poner datos después del binario a veces puede prestarse para la detección heuristica de algunos antivirus asi que estoy intentando de cambiar de estrategia. No es que no funcione pero quiero adelantarme un poco a su detección.

Lo de pasarlo a c++ es una opción pero me hize todo un desmadre cuando lo intenté jaja ya que no soy muy bueno con ese lenguaje aunque debo reconocer que intentandolo pude aprender muchas cosas pero aun así no pude y por eso lo hize en vb mejor.

Código (cpp) [Seleccionar] Expandir

struct datosEOF
{
    int NumeroCaracteresCuerpoMensaje; // Si es 0 pues no hay mensaje ;)
    int NumeroCaracteresTituloMensaje;   // Si es 0 lo mismo
}

Lo que pasa es que cuando insertas el ícono o comprimes el binario cambia totalmente el valor total del peso del binario asi que el numero de carácteres ya no sirve, en un comienzo el stub trabajaba de esa forma donde el bat se obtenía a partir desde el último carácter contado del stub y ese valor estaba en una global pero al ponerle el ícono tube que cambiar de estrategia y ponerle la fiorma, así por mas que se modifique el binario los datos siguen donde mismo.

Estaba pensando en el cifrado de los datos y al descifrarlos encontrar tags en formato xml como por ejemplo

Código (xml) [Seleccionar] Expandir

rc4('<msgbox>valor_en_base64</msgbox><bat>valor_en_base64</bat>', llave)
donde el contenido esté en base64 para evitar conflictos y todo eso en rc4 y ahi tener un único cuerpo donde pueda almacenar todo tipo de datos pero aun así estaría fuera del contenido total.

Yo la manera que recomiendo guardar datos si no quieres usar el sistema de firmas al final de el archivo es mediante resource

Eso en vb sería usar un OLE para cada recurso o simplemente un textbox y modificar binariamente el contenido por cada valor que quiera inyectarle.

Lo estoy viendo y en algún arreglo llegaré, eso si es seguro