Autorun ya no funciona en Windows 8 para arriba, mejor dicho, esta deshabilitado. Hay un link que puede servirte, aunque si dijiste que sos 'noob' y no te llevas con el ingles mucho, puede que te cueste, pero digamos que no es muy dificil ya que cuenta con screenshots. Es 'amigable': You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login

Si no recuerdo mal se puede lograr bypassear la seguridad mediante dos particiones, y se logra confundir al Windows..
No lo he probado a dia de hoy, pero no hace mucho, funcionaba.

Saludos.

Personalmente, Linux Debian. Y claro tengo un Windows en esa particion juntando polvo.. nunca esta de mas.

Lastima que no lei esto antes. Como cada año, menos el anterior que fue el unico que falte, estuve presente.

Saludos a todos. Espero hayan disfrutado de la Eko.

Gracias!. Si soy ese mismo. Espero sea de utilidad, o al menos resuelva mas dudas de las que pueda traer.

Este es el cuarto paper que escribo sobre como encaminar los conocimientos de assembler, gdb, etc, hasta llegar y ver de lleno explotaciones, caza de bugs, etc. No se queden con este paper porque intento que NO sea un texto de programacion o assembler (es por eso que les pido que no lo muevan a programacion etc, porque careceria de ser un tutorial de programacion, esta orientado a familiarizarse con cosas necesarias para poder meternos de lleno en el reversing y exploting. Escribire un poco de definiciones necesarias y luego un codigo para verlo en la practica via GDB. GNU/Debugger. Los primeros papers los pueden encontrar aca:
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login O en mi humilde blog You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login.



Sin dudas algo fundamental que no se puede pasar por alto es saber como se divide la memoria de un programa compilado, y es algo que voy a tratar de explicar para que se entienda bien, SI NO SE TIENE CLARO ESTO, se va a complicar bastante el recorrido hacia explotar vulnerabilidades o realizar reversing a software. Es como caminar a ciegas.. Tratare de que sea lo menos aburrido posible. Trataré...

La memoria de un programa compilado se divide en 5 segmentos que son fundamentales y cada uno tiene un propósito especial:

Codigo (o texto)
Datos
Bss
Heap
Stack


- Codigo (o texto): Llamada de ambas maneras, en esta seccion no tendremos ningun permiso de escritura. Esto es intencional para asi poder evitar que se modifique el codigo del programa.
Tampoco es el lugar donde se almacenan las variables, por ende lo unico que encontraremos es 'codigo'. Si por alguna razon nosotros intentaramos escribir alli, el programa colgaria, o alertaria de que esta out-of-band y finalizaria. Tambien suele referirse al contenido de esa parte de memoria como 'static values' por lo que explique recien, y como 'global values' ya que esa zona al ser read-only los valores estan disponibles para cualquier parte del programa que lo necesite.

- Datos y Bss: En esta seccion como se ve en la imagen, es donde se almacenan las variables tanto estaticas como globales. Una vez mas si vemos la imagen, en el campo DATOS vemos que se almacenan las variables estaticas y globales 'inicializadas'. Mientras que en Bss, vemos que se encontraran las variables 'no inicializadas'

Heap: (Seguramente hayan leido en algun lado sobre.. 'heap overflow'), en esta seccion de memoria, el programador tiene total permiso de escritura, es usada como memoria dinamica durante la ejecucion del programa para asignar (allocate) o liberar (free) valores que el programa necesite/no necesite. Es llamado dynamic memory por la frecuencia en que puede cambiar su contenido mientras el programa esta corriendo. No posee un tamaño 'fijo'. Por ende la altitud de la pila crecera o decrecera en base a la cantidad de memoria reservada para su uso. El crecimiento del heap es de abajo.. hacia arriba.

Stack (o pila): Esta zona tambien tiene un tamaño dinamico de memoria, se usa como memoria temporal para almacenar variables de funcion locales y argumentos de llamadas a funcion.
Imaginenlo de esta manera, cuando un programa llama a una determinada funcion, esta funcion va a poseer su propio conjunto de variables locales, y el codigo de esta funcion estara en otra posicion de memoria como habiamos explicado anteriormente en Codigo (o Texto).
Como el contexto y el EIP deben cambiar una vez que se invoca a una funcion, se utiliza la stack para recordar todas las variables pasadas, la posicion a la que debe volver el puntero EIP una vez finalice la funcion y todas las variables locales usadas por esa funcion. (Recuerden, EIP es el puntero de instruccion, imaginenlo como el dedo indice de nuestra mano cuando vamos leyendo un libro, y vamos siguiendo la lectura con el dedo para no perdernos..).

La stack, es un conjunto ordenado de elementos que se agregan o se quitan. Las direcciones altas de memorias 'estan ABAJO' y las direcciones bajas de memoria 'estan ARRIBA'.

La cima de la pila, es conocida como TOP OF THE STACK o tope de la pila. Lo interesante que tiene la pila, es que como dijimos es un conjunto donde se agregan o quitan elementos (imaginenlo como un mazo de cartas), y la manera en que los elementos se apilan o desapilan es por: ULTIMO elemento apilado es el PRIMERO en salir. (Conocido en ingles como LIFO, Last In, First Out). Dos de las funciones basicas que veremos seguido sobre la pila, son "push" y "pop", push inserta un nuevo elemento al 'tope' de la pila, y pop hara lo contrario, lo eliminara del tope.




Marcos de Pila, o stack frame (Sacado de Google, editado por mi, me gusto la definicion):
Cuando se invoca a una funcion, se apilan varias cosas juntas, en un marco de pila. En principio el registro "EBP" al cual llamaremos: Puntero de Marco, Frame Point. Se usa para hacer referencia a las variables de funcion local en el marco de pila actual. Cada marco de pila contiene los parametros de la funcion, las variables locales, dos punteros que son necesarios para volver a dejar las cosas como estaban: el puntero de marco anterior (SPF) y la direccion de retorno que se usa para devolver el EIP a la siguiente instruccion despues de la llamada de funcion. Esto restauraria el contexto de funcion del anterior marco de pila...



A continuacion vamos a hacer una practica de esto, adjunto un codigo basico que va a ayudar a entender mejor todo esto, y luego lo analizaremos con GDB.

#include <stdio.h>
void SoyUnaFuncion(int a, int b, int c, int d, int e) {
   int variableLocal1; // Se declaran variables LOCALES de esta funcion.
   int variableLocal2; 
   variableLocal1 = 99;
   variableLocal2 = 999;
}

int main() {
   SoyUnaFuncion(1,2,3,4,5); // Invocamos a una funcion "SoyUnaFuncion".
}

Se declaran dos funciones, la clasica main() que es donde iniciara el programa, y luego esta llamara a la funcion "SoyUnaFuncion" (que imaginacion la mia eh xD), y se le pasaran 5 argumentos..

Dentro de la funcion 'SoyUnaFuncion' se declaran dos variables locales. Llamadas: variableLocal1, y variableLocal2 (estoy hecho una luz de imaginacion xD), con sus respectivos valores, 99 y 999.
Como habiamos aclarado al principio, en la zona de la STACK/PILA, se almacenaran estas variables locales de funcion.. Vamos a ver esto con atencion desde el debugger.

Compilamos el archivo con el flag -g. Y lo debuggeamos con gdb:



Presten atencion a lo que resalte en amarillo. Se lo llama "Prologo de procedimiento" o en su ingles "Procedure Prologue", estas primeras instrucciones "configuran el Marco de la Pila".
Reservan el puntero de marco en la pila, y reservan memoria de pila para las variables de funcion locales.

Siguiendo con el codigo de la funcion main(), vimos que lo unico que hacia este basico programa era invocar a la funcion "SoyUnaFuncion" y pasarle 5 argumentos -> "SoyUnaFuncion(1,2,3,4,5)". Estos argumentos seran apilados en la pila, y habiamos comentado que la manera de apilar y desapilar era mediante LIFO -last in first out- osea, ultimo entrado, primero salido.
Veamos la parte resaltada ahora como podemos observar estos 5 numeros enteros pasados a la funcion "SoyUnaFuncion":



Luego vemos que al pie del ultimo argumento, hay un "CALL [0x80483ed]", donde empezara nuestra funcion invocada "SoyUnaFuncion".. Luego de ese CALL tenemos la instruccion LEAVE que es la direccion de retorno que EIP seguira una vez que ese CALL finalice.
Bien, aca es donde el contexto cambia, y hay que prestar atencion..

Cuando ese CALL se ejecute, la direccion de regreso sera agregada a la pila y el rumbo de la ejecucion pasara al principio de la funcion "SoyUnaFuncion" como lo muestra la imagen siguiente:




Observamos el prologo nuevamente de instrucciones que crearan el otro Marco de Pila.

Vemos como con el "PUSH ebp", se apila el valor actual que tiene EBP. Se le da el nombre de SFP (Saved Frame Pointer). Puntero de Marco Anterior, y luego se utilizara para devolver a EBP a su estado anterior.

Vemos la siguiente instruccion "MOV ebp, esp" esto copia el contenido del registro ESP a EBP.
De esta manera se creara el nuevo puntero de marco, y referenciara a las 'VARIABLES LOCALES' de la funcion. (recordemos el codigo "variableLocal1, y variableLocal2").

Por ultimo el "sub esp, 0x10" reservara memoria para estas dos variables dichas, restandole 10 a ESP en este caso.

En la imagen vemos claramente las dos variablesLocales que declaramos. Por sino se dieron cuenta 0x63, y 0x3e7, corresponden a 99 y 999. Los valores que les asignamos a las variables, rapidamente con pcalc vemos los valores de cada uno en Decimal - Hex - Binario:



Ahora vamos a poner algunos breakpoints, para que el debugger se detenga y nos muestre con claridad todo esto..



(1) Como vemos, el gdb se detiene donde se lo pedimos.. en el primer breakpoint de la funcion main().
(2) El valor de ESP esta en 0xbffff0d4. Y el valor de EBP esta en 0xbffff0e8 (Recuerden este valor).

Este breakpoint se encuentra antes de crearse el marco de pila para el CALL a la funcion 'SoyUnaFuncion'.

Si continuamos hasta el segundo breakpoint, ya habremos llegado a la segunda funcion, despues del prologo de procedimiento, donde ya se habrá creado el marco de pila..



Bien, para concluir con esto.. paso a explicar la imagen.

(1) El segundo breakpoint nos deja luego de la creacion del marco de pila, justo en el momento que se asigna la variableLocal1 que tiene 99 de valor. Y se mueve a la direccion de memoria [ebp-0x8] y la segunda variable local a [ebp-0x4]. En el punto (3) imprimimos la direccion destino en dos variables, para recordar esas direcciones.

El punto (2) nos muestra info de EBP y ESP. Vemos como la stack esta al tope en [0xbffff0bc].
Tipearemos 'nexti' dos veces para que el breakpoint donde habiamos parado avance dos instrucciones mas que era donde las variablesLocales estaban insertandose en la pila.. Una vez hecho esto Si examinamos esta zona de la pila entenderemos todo mejor..



En el punto (1) al final del marco de la pila vemos los 5 argumentos de la funcion que habiamos pasado, 5,4,3,2,1. En el punto (2) seguido a los argumentos, vemos la direccion 0x8048435, esa es la direccion de retorno, luego del CALL a la funcion!!..



En el punto (3), se encuentra el puntero de marco anterior, que era el EBP en el anterior marco de pila, (les dije que se lo recuerden ese valor mas arriba). En el punto (4) vemos ambas variablesLocales asignadas en la funcion, las cuales tenian valor 99 y 999..en hexa como vimos arriba, 0x63 y 0x3e7 .

Para finalizar, el programar terminara concluyendo su trabajo, y todo el marco se desapilara de la stack.. Pronto el 5to y ya metiendonos cada vez mas a fondo para explotar cosas.. tiempo al tiempo

You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login - c0nfused.

Welcome! Enjoy ur stay
Disfruta tu estadia.

Saludos.

Buen aporte, para aquellos 'despistados' y usuarios normales.. que le dan click sin leer a todo jaja..
Vaya paradoja que Firefox lance un un addon-update y el autor 'no sea verificado' no?. Seria el colmo
Pero asi y todo caen.

Saludos!

Veremos de que trata, lo voy a testear

Salu2.

Bienvenido! que disfrutes tu estadia.

De nada che, me alegra que haya funcionado, era la idea.
Saludos.

Bueno, algo desprolijo como lo posteastes... pero estoy de humor y creo que puedo ayudarte jej.
(No aclaraste de que manera reversearlo asi que lo hice desde mi gdb bajo linux).

En principio el codigo, recibe en main 2 argumentos. Un entero, y un 'vector de argumentos' argv.
En la linea donde declara "contador = atoi(argv[2]);"
Invoca a la funcion "Ascii to integer". (ATOI), y toma como argumento el segundo (2), para transformarlo en entero ya que cuando se declaro, se declaro como 'char'.

Osea que el programa se ejecutaria ./a.out <mensaje> <veces>.
Si se ejecuta haciendo esto: ./a.out x
Da Segmentation Fault.

La manera de fixearlo es poniendo un Condicional IF y una salida en la funcion funcRepetir.
Lo testie y queda 'corregido' y funcionando de la siguiente manera:

En la funcion funcRepetir, terminala con un exit(1); (y ademas inclui <stdlib.h).
Luego en el main, justo despues de declarar los enteros 'x' y 'contador';
Aplica un condicional if:

   if (argc < 3)
   funcRepetir(argv[0]);

(Si hay menos de 3 argumentos sale..) (el primer argumento siempre es el del programa path/a.out).

Resuelto esto, vamos con la segunda pregunta. Como te dije lo reversie con el gdb de linux, previamente lo recompile con gcc y el flag -g. Como muestra la imagen corri el debugger y le inyecte una cadena 'soyhax0r' asi buscamos el segmentatio fault:



Vemos el sentido de la pila a la inversa, y ponemos un breakpoint justo antes de que haga el segmentation fault, en 'main'. Como la matriz 'argv[]' es un puntero en realidad.. Este apunta a la cadena de strings que son tomadas como argumentos.. lo confirmamos en esta imagen y listo.



- Para en el breakpoint que puse en main.
- Examino el valor antes del segmentation fault que arroja 'argv=0xbffff1b4'.
- Examino las 4 primeras direcciones que tiene almacenada la direccion de la matriz argv..
- Compruebo que son los argumentos enviados antes del segmentation fault, el path, el soyhax0r que inyecte, y el segmentation fault........ 0x00000000 <es una direccion out-of-band>. Es decir que se encuentra fuera de los limites de memoria, cuando un programa intenta acceder a esa direccion de memoria se cuelga y falla.

Espero te haya servido.
Saludos.

Muchas gracias ambos!.
Es un placer..

Saludos!

You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
Por lo que veo copiaste mal el código a los include les hace falta

#include <netdb .h="">
#include <stdio .h="">
#include <stdlib .h="">
#include <string .h="">
#include <errno .h="">

Juraría que los había puesto, creo que ANTRAX me edito el post y agrego esa imagen arriba.. y seguramente el "code" :p..
Ya esta corregido de todos modos, gracias por la aclaración Stuxnet. Saludos.

Estos últimos días estuve trabajando en unos análisis de Malware, y sin dudas un software que me ayuda bastante para la etapa Dinámica del análisis es INetSim. (Internet Services Simulation Suite).

Este software lo que hace es simular servicios de internet. Entre otras cosas como se le conocería en términos de ingles: "Faking Network". Muchas veces, cuando se intenta analizar un malware mediante análisis dinámicos, con un poco de experiencia es suficiente para darnos cuenta mediante librerias y funciones que importa o strings que sale a buscar a internet o reportar información, y a veces preferimos realmente estudiar su funcionalidad y su comportamiento de manera controlada y bajo nuestro dominio.

A veces no queremos que el malware realmente salga a internet, o reporte a sus creadores de nosotros, es por eso que en ciertas circunstancias optamos por 'hacer una faking network' y menos ruido con sus creadores.. Una tool excelente es sin dudas InetSim, la cual permite ejecutar el malware y hacerle creer que esta conectandose a el mundo exterior cuando en realidad no hace otra cosa que interactuar con nosotros mismos, o mejor dicho con nuestro amigo inetsim y sus servicios.

Dejare una breve reseña de como funciona, y como puede sernos util, a la hora de realizar como dije un analisis dinamico de malware.
Mi red para esta ocasion esta compuesta de la siguiente manera, 2 SO's:

A - 192.168.0.102 -> PC Linux con Debian/Ubuntu donde estara corriendo el InetSim.
B - 192.168.0.107 -> VMWARE corriendo un Windows XP.. (Nuestro entorno con malware). Este es un entorno controlado, y el malware a ejecutar no es realmente maligno, es solo para simularlo, así que asegurense de tener un entorno controlado y seguro siempre que hagan pruebas.

> Instalando INetSim (Linux):

# Para usuarios Debian/Ubuntu Linux: You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
# Para el resto de mortales:  You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login

Una vez instalado, usarlo es demasiado facil. Pero antes hay que revisar y editar algunas cosas de configuracion. Ustedes luego podran editar e ir metiendo mano y modificar a su gusto sin romper nada. Iniciar mas o menos servicios, etc. Pero en este caso edito estas lineas para la prueba:

$> sudo nano /etc/default/inetsim

Buscamos la siguiente linea y ponemos el ENABLED en '1', salvamos el cambio y salimos:
# Whether or not to run the internet simulation suite; set to 0 to disable.
ENABLED=1

Lo siguiente sera ir al archivo de configuracion:

$> sudo nano /etc/inetsim/inetsim.conf

Buscamos la siguiente linea, la descomentamos y asignamos la IP del Linux donde corre InetSim, mi caso era la siguiente IP:
service_bind_address    192.168.0.102

Luego buscamos la siguiente linea y si bien dice 127.0.0.1, que seria la del linux mismo, descomentamos y editamos por la IP que tiene asignada:
dns_default_ip          192.168.0.102

Con esto ya podria funcionar tranquilamente para la prueba.
Lo iniciamos:

$> sudo /etc/init.d/inetsim start

Abrimos otra terminal, verificamos con nmap que esto es asi..

$> nmap 192.168.0.102 -vv

Y como resultado se darán cuenta si todo funciona bien que ya tenemos como 20 puertos y servicios abiertos corriendo :O.. no se asusten, solo 'simulan' muy bien serlo .

Nos dirigimos ahora a la maquina virtual que corre Windows XP y antes de 'ejecutar el malware' editamos su configuracion de red, para que apunte a nuestra ip con inetsim. Le decimos que su gateway a internet vamos a ser Nosotros (inetsim) y que su DNS por ende tambien .



Una vez que configuramos esto, optamos por ejecutar el malware.. y veremos que pasa. Los reportes que genera inetsim se guardan en /var/log/inetsim/report.

Una vez que se ejecuta el malware luego de pasado unos minutos, detenemos el inetsim y vemos el reporte que nos genero. En mi caso quedo algo así:



1) Vemos como en el primer recuadro de la imagen, se realiza una consulta DNS bastante rara..
"You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login"...

2) En el segundo resaltado vemos como dos minutos después realiza una petición via HTTP GET para descargar de un dominio bastante raro "You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login". ¿que sera? ;p

3) Y en el 3 resaltado, vemos como realiza una similar petición pero ahora baja una librería llamada ashid.dll.

Como ultimo comentario, me gustaría resaltar como ven en la imagen el InetSim "responde" ante la petición del malware (GET) y le envía un 'fake file'.

Esto es demasiado útil, ya que supongamos si un Malware que estamos analizando del cual no tenemos mucho conocimiento de su comportamiento sale a internet a buscar algún tipo de archivo ya sea un .exe o .dll o cualquier otro, y no lo logra, posiblemente el malware quede inoperativo, o quizás no demuestre mas comportamientos hasta que su tarea de bajar otro archivo le permita poder completar todos los pasos de su infección y explotación. (No siempre tiene que ser asi, hay malwares realmente sofisticados pero sin dudas que es de una gran utilidad..).

Espero sea útil, personalmente, cumple un rol fundamental como tool en mis primeras etapas de análisis dinámico de malware en mis trabajos.

Saludos.

Bienvenido!, en lo que se pueda ayudar, con gusto.

Saludos.

Muchas Gracias Antrax.

Saludos!

Bueno, me ha sorprendido no encontrar nada con el buscador del foro sobre esta vulnerabilidad, si se trata de un error y trataron ya este tema, pido disculpas, y borren el tema. Estaba en dudas si ponerlo en seguridad o hacking, pero como es algo temprana la vulnerabilidad 'publicamente', y hay tantos sistemas vulnerables por ahi, lo considere correcto aca.

Sin dudas una de las noticias de estos dias es el descubrimiento de la vulnerabilidad CVE-2015-0235.
Afecta a la libreria "glibc". La gente de Qualys descubrio un interesante desbordamiento de buffer en una funcion de glibc llamada "the_nss_hostname_digits_dots()". Se puede tomar ventaja remotamente de esta vulnerabilidad desde la funcion gethostbyname() de glibc.

Al parecer de glibc-2.17 a glibc-2.18 se encuentra parcheado. De hecho lo estaban desde el 2013 pero no se considero de mayor prioridad y se paso por alto en muchos desarrolladores, por ende los modulos de ciertas distribuciones siguen siendo aun vulnerables.

Algunas app conocidas que dependen de esta libreria son Apache, GnuPG, OpenSSH, entre otras.

A continuacion adjunto un PoC hecho por vpetkov, para que puedan testear la vulnerabilidad localmente.  Primero dense una idea de que libreria tienen instalada con el siguiente comando, desde mi debian/ubuntu (sistemas derivados de estos):

$> ldd --version

Desde Redhat y CentOS:

$> rpm -q glibc

El PoC para verificar si es vulnerable o no el sistema, peguenlo en un editor de texto, guardenlo con como ghost.c y luego lo deben compilar con gcc de la siguiente manera

$> gcc ghost.c -o ghost (compilan)

$> chmod +x ghost (le dan permisos de ejecucion).

$> ./ghost (ejecutan)

#include <netdb.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h> 
 
#define CANARY "in_the_coal_mine"
 
struct {
  char buffer[1024];
  char canary[sizeof(CANARY)];
} temp = { "buffer", CANARY };
 
int main(void) {
  struct hostent resbuf;
  struct hostent *result;
  int herrno;
  int retval;
 
  /*** strlen (name) = size_needed - sizeof (*host_addr) - sizeof (*h_addr_ptrs) - 1; ***/
  size_t len = sizeof(temp.buffer) - 16*sizeof(unsigned char) - 2*sizeof(char *) - 1;
  char name[sizeof(temp.buffer)];
  memset(name, '0', len);
  name[len] = '\0';
 
  retval = gethostbyname_r(name, &resbuf, temp.buffer, sizeof(temp.buffer), &result, &herrno);
 
  if (strcmp(temp.canary, CANARY) != 0) {
    puts("vulnerable");
    exit(EXIT_SUCCESS);
  }
  if (retval == ERANGE) {
    puts("not vulnerable");
    exit(EXIT_SUCCESS);
  }
  puts("should not happen");
  exit(EXIT_FAILURE);
}

Si es vulnerable, saldria "vulnerable" je je.
Sino, lo contrario.

Para fixear esto desde Debian/Ubuntu vamos a enfocar solamente en actualizar la libc.

$> apt-get update
$> apt-get install --only-upgrade libc6 -y

(Reiniciemos, y luego volver a verificar con el PoC si sigue siendo vulnerable).
El resto de distribuciones, favor de verificar y tratar de actualizar el modulo a la ultima version, y no seria mala idea el kernel tambien.

Mas informacion detallada directo desde Qualys Community:
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login

Super interesante, ya estuve leyendo a este tipo el otro dia.
(El nombre del asunto se contradice un poco, ya que no encuentran un backdoor/puerta trasera en el Drone, encuentran una vulnerabilidad que permite ser manipulado remotamente, al principio pense que el fabricante de manera silenciosa tenia un sector en el codigo de programacion ofuscado que funcionaba como backdoor jeje).

Saludos.

Bienvenido! espero sea grata tu estadía acá.
Saludos.

Alternativo a lo que puso ANTRAX, creo que si en ese caso tendrías mas de un file (60 por ejemplo), escribirias lineas de codigo al pepe, imaginate 1000 files. De acuerdo a tu posteo tenes una cantidad de archivos que queres enviarlos a una cantidad de carpetas que 'ya existen', y estas tienen el mismo nombre de los archivos, de esta manera envia automaticamente en masa cada file a sus carpetas respectivas, te dejo masomenos como seria, (funciona asi tal cual esta y acordate de ponerle %% a la variable en el for):

@echo off
for /f %%v in ('dir /b /ad') do move %%v*.* %%v\

Lo que haria eso seria pasar todos los archivos que tengas como vos decis: 01.pdf - 02.pdf - 03.pdf, etc.. a sus respectivas carpetas 01/ 02/ 03/

PD: El caso es tal cual como lo planteaste vos, pone el bat donde esten los files y las carpetas y lo corres desde ahi. Si la situacion cambiase, habría que modificar el bat de acuerdo a la situacion real.

Saludos.