Keygen para el Crackme Sweeet Dream 1.0 de 2Sweeet

por ·Sin comentarios

Intro

Hoy tenemos aquí un crackme del año 2000 empacado y con un algoritmo aunque no muy complicado largo de tracear. Está empacado varias veces, algo poco habitual pero recordemos que es un crackme antiguo. Tras el empacado se encuentra Delphi.

Herramientas

  • PEiD o similar.
  • OllyDbg con plugin OllyDumpEX.
  • Import REConstructor.
  • LordPE (Opcional).

Desempacado multicapa

VideoTutorial del desempacado disponible

Si lo pasamos por PEiD nos dice que Aspack 2.1, Exeinfo no está muy seguro y RDG packer detector en el escaneo avanzado nos encuentra Aspack, UPX y PE-Pack.

En principio nos enfrentamos a Aspack 2.1, abrimos el crackme con OllyDbg y vemos el típico PUSHAD.

01

Pulsamos F8 (Step Over) y a continuación click derecho sobre el registro ESP y Follow in DUMP.

02

Seleccionamos los primeros cuatro bytes útiles del dump y les ponemos un Breakpoint de Hardware, Access y Dword.

04

05

Pulsamos F9 y nos para aquí:

06

Ya tenemos a Aspack contra las cuerdas, pulsamos F8 hasta después del RETN para llegar al OEP (Original Entry Point).

07

Pero en el supuesto OEP vemos otro PUSHAD por lo que esto no ha terminado. Investigando un poco más vemos que la segunda capa se corresponde con PE-PACK 1.0. La estrategia a seguir es la misma, como ya tenemos el breakpoint puesto pulsamos F9 y nos para aquí:

08

Pulsamos F8 y nos llega a otro PUSHAD. Esta vez es UPX.

09

Pulsamos de nuevo F9 y paramos aquí:

10

Pulsamos F8 y esta vez si llegamos al OEP (4576EC).

11

A continuación vamos a dumpear el archivo en memoria. Vamos a plugins > OllyDumpEX, pulsamos sobre «Get EIP as OEP» y finalmente sobre «Dump«.

13

Minimizamos Olly (no cerrar), abrimos el programa ImportREC y seleccionamos el ejecutable «Sweeet1.exe».

14

Pegamos el OEP original (576EC), le damos a AutoSearch y a continuación a Get Imports.

15

Finalmente pulsamos Fix Dump y elegimos el ejecutable dumpeado anteriormente. Esto nos genera un ejecutable dumpeado que es el ejecutable válido.

Ahora PEiD nos dice que estamos tratando con un crackme hecho en Delphi.

Hemos pasado por tres capas de compresión casi idénticas, vamos a analizarlas.

triplecompresion

El algoritmo

Cuando abrimos el crackme nos fijamos en que genera una key. Esta key se genera en función del disco duro desde el que se ejecuta.

Como la secuencia de generación del serial válido es larga os pongo lo más importante muy resumido y con ejemplos como siempre.

El serial es del siguiente tipo:

Serial = 1ªParte-2ªParte-3ªParte
Serial = 0000XXXXX-SerialCalculado-xxxx000Z8

Comprobación del tamaño del nombre
----------------------------------
........
00456EAA    E8 01CCFAFF     CALL sweeet1_Fix_dump_rebuilded.00403AB0
00456EAF    83F8 04         CMP EAX,4    ------------------------------------------------; Nombre >=4                    
00456EB2    7D 13           JGE SHORT sweeet1_Fix_dump_rebuilded.00456EC7
00456EB4    A1 08954500     MOV EAX,DWORD PTR DS:[sweeet1_Fix_dump_rebuilded.459508]
00456EB9    8B00            MOV EAX,DWORD PTR DS:[EAX]
00456EBB    E8 0869FEFF     CALL sweeet1_Fix_dump_rebuilded.0043D7C8
00456EC0    BB 01000000     MOV EBX,1
00456EC5    EB 15           JMP SHORT sweeet1_Fix_dump_rebuilded.00456EDC
00456EC7    83FB 25         CMP EBX,25                                                                                                
00456ECA    7D 0E           JGE SHORT sweeet1_Fix_dump_rebuilded.00456EDA
00456ECC    83C3 32         ADD EBX,32
00456ECF    83C3 1E         ADD EBX,1E
00456ED2    83EB 4F         SUB EBX,4F
00456ED5    83FB 25         CMP EBX,25 -----------------------------------------------; Nombre <=25
00456ED8  ^ 7C F2           JL SHORT sweeet1_Fix_dump_rebuilded.00456ECC
00456EDA    33DB            XOR EBX,EBX
00456EDC    33C0            XOR EAX,EAX
........

1ºBucle - Nuestro nombre (A)
----------------------------
........
00456F55    BE 1B000000     MOV ESI,1B -------------------------------; ESI = 1B
00456F5A    EB 21           JMP SHORT sweeet1_dump_.00456F7D
00456F5C    8D55 D4         LEA EDX,[EBP-2C]
00456F5F    A1 34A84500     MOV EAX,DWORD PTR DS:[sweeet1_dump_.45A8
00456F64    8B80 C4020000   MOV EAX,DWORD PTR DS:[EAX+2C4]
00456F6A    E8 B5DAFCFF     CALL sweeet1_dump_.00424A24
00456F6F    8B45 D4         MOV EAX,DWORD PTR SS:[EBP-2C]
00456F72    0FB64418 FF     MOVZX EAX,BYTE PTR DS:[EBX+EAX-1]---------; Coje digito
00456F77    03F0            ADD ESI,EAX ------------------------------; digito + ESI
00456F79    43              INC EBX
00456F7A    0FAFF3          IMUL ESI,EBX  ----------------------------; multiplica por i (bucle)
00456F7D    8D55 D4         LEA EDX,[EBP-2C]
........

2ºBucle - La key (B)
--------------------
........
00456F9C         |.  BF 1A000000            MOV EDI,1A -------------------------;EDI = 1A
00456FA1         |.  BB 01000000            MOV EBX,1
00456FA6         |.  EB 1E                  JMP SHORT sweeet1_.00456FC6
00456FA8         |>  8D55 D4                /LEA EDX,[LOCAL.11]
00456FAB         |.  A1 34A84500            |MOV EAX,DWORD PTR DS:[45A834]
00456FB0         |.  8B80 D0020000          |MOV EAX,DWORD PTR DS:[EAX+2D0]
00456FB6         |.  E8 69DAFCFF            |CALL sweeet1_.00424A24
00456FBB         |.  8B45 D4                |MOV EAX,[LOCAL.11]
00456FBE         |.  0FB64418 FF            |MOVZX EAX,BYTE PTR DS:[EAX+EBX-1]--;Coje dígito
00456FC3         |.  03F8                   |ADD EDI,EAX -----------------------;Suma dígito a dígito
00456FC5         |.  43                     |INC EBX
00456FC6         |>  8D55 D4                 LEA EDX,[LOCAL.11]
00456FC9         |.  A1 34A84500            |MOV EAX,DWORD PTR DS:[45A834]
00456FCE         |.  8B80 D0020000          |MOV EAX,DWORD PTR DS:[EAX+2D0]
00456FD4         |.  E8 4BDAFCFF            |CALL sweeet1_.00424A24
00456FD9         |.  8B45 D4                |MOV EAX,[LOCAL.11]
00456FDC         |.  E8 CFCAFAFF            |CALL sweeet1_.00403AB0
00456FE1         |.  3BD8                   |CMP EBX,EAX
00456FE3         |.^ 7C C3                  \JL SHORT sweeet1_.00456FA8
........

Generación del serial central
-----------------------------
........
00456FE5         |.  B9 01000000            MOV ECX,1
00456FEA         |.  BB 01000000            MOV EBX,1
00456FEF         |.  8BC7                   MOV EAX,EDI
00456FF1         |.  F7EE                   IMUL ESI ----------; C = A * B
00456FF3         |.  99                     CDQ
........
00456FFD         |.  2345 E8                AND EAX,[LOCAL.6]--; D = A and C
00457000         |.  2355 EC                AND EDX,[LOCAL.5]
00457003         |.  8945 E8                MOV [LOCAL.6],EAX
00457006         |.  8955 EC                MOV [LOCAL.5],EDX
........
00457032         |.  8BC7                   MOV EAX,EDI
00457034         |.  99                     CDQ
00457035         |.  0345 E8                ADD EAX,[LOCAL.6]--; E = D + B
00457038         |.  1355 EC                ADC EDX,[LOCAL.5]
0045703B         |.  8945 E0                MOV [LOCAL.8],EAX
0045703E         |.  8955 E4                MOV [LOCAL.7],EDX
........
00405732           8B4424 10                MOV EAX,DWORD PTR SS:[ESP+10]
00405736           F72424                   MUL DWORD PTR SS:[ESP]
00405739           8BC8                     MOV ECX,EAX
0040573B           8B4424 04                MOV EAX,DWORD PTR SS:[ESP+4]
0040573F           F76424 0C                MUL DWORD PTR SS:[ESP+C]------; F = B * D
00405743           03C8                     ADD ECX,EAX
00405745           8B0424                   MOV EAX,DWORD PTR SS:[ESP]
00405748           F76424 0C                MUL DWORD PTR SS:[ESP+C]------; G = A * F
........
0045705E         |.  0B0424                 OR EAX,DWORD PTR SS:[ESP]-----; Serial central = G or A
........
00457077         |.  E8 FC07FBFF            CALL sweeet1_.00407878
0045707C         |.  8B45 F8                MOV EAX,[LOCAL.2]-------------; EAX = Serial central
........
004570D1         |.  E8 A207FBFF            CALL sweeet1_.00407878
004570D6         |.  8B45 D0                MOV EAX,[LOCAL.12]
004570D9         |.  E8 D2C9FAFF            CALL sweeet1_.00403AB0--------; Obtiene longitud del serial central en hexa
004570DE         |.  8BD8                   MOV EBX,EAX
........
004570D1         |.  E8 A207FBFF            CALL sweeet1_.00407878--------;*Nota

*Nota:
A partir de aquí genera la primera y tercera parte del serial de la siguiente manera:

Serial = 1ªParte-2ªParte-3ªParte
Serial = 0000XXXXX-SerialCalculado-xxxx000Z8

1ºParte = 3ºdigSerial+1ºdigSerial+2ºdigSerial+3ºdigSerial+4ºdigNombreMayu+2ºdigNombreMayu+5ºdigNombreMayu+1ºdigNombreMayu+3ºdigNombreMayu
3ºParte = 3ºdigNombreMin+1ºdigNombreMin+4ºdigNombreMin+2ºdigNombreMin+Tamaño Serial_2ªParte en Hex y de tres dígitos+Z8

 Ejemplo:

Nombre: deurus
Key:    C0C0A000
Serial: 6906REUDU-906297047918-udre00CZ8

1) A = 23A2A (Con nuestro nombre empezando por 1B se lo suma a ESI y se lo multiplica por i (la que toque cada vez))
2) B = 1A1 (Con nuestra Key empezando por 1A va sumando los digitos)
3) C = B * A = 3A0BE6A
4) D = A and C = 3A2A
5) E = D + B = 3BCB (Offset 457035)
6) F = B * D = 5EBE6A (Offset 48704A)
7) G = A * F = D303834164
8) Serial = G or A (Serial = D303834164 or 23A2A = D303837B6E (906297047918))

 A tener en cuenta:

  • 1ªParte del serial siempre mayúsculas.
  • 2ªParte siempre numérico. Usa el registro de 64 bits (Qword) con signo.**Nota
  • 3ªParte siempre minúsculas.

**Nota:

Nombre: deurus.info
Key:    E09FF000
Serial: 9169REUDU-16918236-udre008Z8

Fíjate que: -16918236 = FFFFFFFFFEFDD924

Nombre: deurus
Key:    C0C0A000
Serial: 6906REUDU-906297047918-udre00CZ8

906297047918 = 000000D303837B6E

Links

Reto Stego - Dos por Uno
El reto consiste en dos imágenes (v1.png y v2.png) que, a simple vista, parecen contener ruido aleatorio. Sin embargo, ambas
List of file signatures for file carving
File carving is the process of reassembling computer files from fragments in the absence of filesystem metadata. Wikipedia. "File carving", literalmente tallado
Reversing - Nosotros y ChatGPT contra un ELF desde Windows
Intro Antes que nada, es importante saber que un archivo ELF en Linux es equivalente a un archivo EXE en
ThisIsLegal.com - Realistic Challenge 2
Warning: This challenge is still active and therefore should not be resolved using this information. Aviso: Este reto sigue en

Reto Stego – Dos por Uno

por ·Sin comentarios
v1.png
v2.png

El reto consiste en dos imágenes (v1.png y v2.png) que, a simple vista, parecen contener ruido aleatorio. Sin embargo, ambas forman parte de un sistema de criptografía visual en la que cada imagen contiene información parcial que no es interpretable por separado, pero que al combinarse correctamente revelan información oculta.

La trampa está en que la combinación no se hace con operaciones normales como suma, resta o multiplicación. El autor del reto espera que el jugador use una herramienta como StegSolve y pruebe distintas operaciones tipo XOR, AND o MUL hasta encontrar una transformación en la que uno de los métodos muestre algo significativo. El truco está en llegar a la conclusión de que una de las imágenes hay que invertirla antes de combinar ambas imágenes. Todo esto se puede hacer con StegSolve sin necesidad de utilizar ninguna herramienta adicional, pero voy a aprovechar para hacerlo con python y así de paso entendemos como realiza las operaciones StegSolve. En resumen, para resolver el reto basta con:

  1. Invertir (Colour Inversion XOR) una de las imágenes.
  2. Combinar ambas imágenes mediante Analyse > Combine images.
  3. Operación MUL del combinador.

La operación MUL no es una multiplicación normalizada, sino una multiplicación de enteros de 24 bits (0xRRGGBB) con overflow, algo que la mayoría de herramientas no replican correctamente.

¿Por qué aparece la solución con esa combinación

Las imágenes están preparadas para que ciertos bits de color en una imagen sean el complemento de los de la otra. Por tanto:

  • Si se muestran tal cual → parecen ruido
  • Si se combinan mediante XOR → parte de la estructura aparece, pero no se ve el resultado correcto
  • Si se combinan mediante MUL «normal» → tampoco aparece
  • Si se aplica la multiplicación bitwise exacta usada por StegSolve → se alinean las partes ocultas

La operación MUL de StegSolve no es una multiplicación de píxeles, es decir, no hace:

R = (R1 * R2) / 255

sino:

c1 = 0xRRGGBB  (pixel 1)
c2 = 0xRRGGBB  (pixel 2)
resultado = (c1 * c2) & 0xFFFFFF

Con todo esto claro, he preparado un script para combinar las imágenes de forma automática.

import os
import numpy as np
from PIL import Image

# =========================================================
# UTILIDADES
# =========================================================

def ensure_output():
    if not os.path.exists("output"):
        os.makedirs("output")

def load_rgb(path):
    img = Image.open(path).convert("RGB")
    return np.array(img, dtype=np.uint32)

def save_rgb(arr, name):
    Image.fromarray(arr.astype(np.uint8), "RGB").save(os.path.join("output", name))

def invert_xor(arr):
    """Colour Inversion (Xor) de StegSolve."""
    out = arr.copy()
    out[..., :3] = 255 - out[..., :3]
    return out

# =========================================================
# FUNCIONES DE COMBINER EXACTAS DE STEGSOLVE
# =========================================================

def to24(arr):
    """Convierte RGB → entero 0xRRGGBB."""
    return ((arr[..., 0] << 16) |
            (arr[..., 1] << 8)  |
             arr[..., 2])

def from24(c):
    """Convierte entero 0xRRGGBB → RGB."""
    R = (c >> 16) & 0xFF
    G = (c >> 8)  & 0xFF
    B = c & 0xFF
    return np.stack([R, G, B], axis=-1).astype(np.uint8)

# ------------------------------
# Funciones auxiliares
# ------------------------------

def comb_xor(c1, c2):
    return from24((c1 ^ c2) & 0xFFFFFF)

def comb_or(c1, c2):
    return from24((c1 | c2) & 0xFFFFFF)

def comb_and(c1, c2):
    return from24((c1 & c2) & 0xFFFFFF)

def comb_add(c1, c2):
    return from24((c1 + c2) & 0xFFFFFF)

def comb_add_sep(c1, c2):
    R = (((c1 >> 16) & 0xFF) + ((c2 >> 16) & 0xFF)) & 0xFF
    G = (((c1 >> 8)  & 0xFF) + ((c2 >> 8)  & 0xFF)) & 0xFF
    B = ((c1 & 0xFF) + (c2 & 0xFF)) & 0xFF
    return from24((R << 16) | (G << 8) | B)

def comb_sub(c1, c2):
    return from24((c1 - c2) & 0xFFFFFF)

def comb_sub_sep(c1, c2):
    R = (((c1 >> 16) & 0xFF) - ((c2 >> 16) & 0xFF)) & 0xFF
    G = (((c1 >> 8)  & 0xFF) - ((c2 >> 8)  & 0xFF)) & 0xFF
    B = ((c1 & 0xFF) - (c2 & 0xFF)) & 0xFF
    return from24((R << 16) | (G << 8) | B)

def comb_mul(c1, c2):
    """MUL EXACTO StegSolve"""
    return from24((c1 * c2) & 0xFFFFFF)

def comb_mul_sep(c1, c2):
    R = (((c1 >> 16) & 0xFF) * ((c2 >> 16) & 0xFF)) & 0xFF
    G = (((c1 >> 8)  & 0xFF) * ((c2 >> 8)  & 0xFF)) & 0xFF
    B = ((c1 & 0xFF) * (c2 & 0xFF)) & 0xFF
    return from24((R << 16) | (G << 8) | B)

def comb_lightest(c1, c2):
    """Máximo por canal"""
    R = np.maximum((c1 >> 16) & 0xFF, (c2 >> 16) & 0xFF)
    G = np.maximum((c1 >> 8)  & 0xFF, (c2 >> 8)  & 0xFF)
    B = np.maximum(c1 & 0xFF, c2 & 0xFF)
    return from24((R << 16) | (G << 8) | B)

def comb_darkest(c1, c2):
    """Mínimo por canal"""
    R = np.minimum((c1 >> 16) & 0xFF, (c2 >> 16) & 0xFF)
    G = np.minimum((c1 >> 8)  & 0xFF, (c2 >> 8)  & 0xFF)
    B = np.minimum(c1 & 0xFF, c2 & 0xFF)
    return from24((R << 16) | (G << 8) | B)

# Lista de transformaciones
TRANSFORMS = {
    "xor": comb_xor,
    "or": comb_or,
    "and": comb_and,
    "add": comb_add,
    "add_sep": comb_add_sep,
    "sub": comb_sub,
    "sub_sep": comb_sub_sep,
    "mul": comb_mul,
    "mul_sep": comb_mul_sep,
    "lightest": comb_lightest,
    "darkest": comb_darkest,
}

# =========================================================
# GENERACIÓN DE TODAS LAS COMBINACIONES
# =========================================================

def generate_all(imA, imB, labelA, labelB):
    print(f"Generando combinaciones: {labelA} vs {labelB}")

    c1 = to24(imA)
    c2 = to24(imB)

    for name, fun in TRANSFORMS.items():
        out = fun(c1, c2)
        save_rgb(out, f"{labelA}__{labelB}__{name}.png")

    print(f"{labelA}-{labelB} completado.")

# =========================================================
# MAIN
# =========================================================

ensure_output()

print("Cargando imágenes v1.png y v2.png...")
im1 = load_rgb("v1.png")
im2 = load_rgb("v2.png")

print("Generando invertidas estilo StegSolve...")
im1_x = invert_xor(im1)
im2_x = invert_xor(im2)

save_rgb(im1_x, "v1_xored.png")
save_rgb(im2_x, "v2_xored.png")

# Generar las 52 combinaciones:
generate_all(im1,   im2,   "v1",   "v2")
generate_all(im1_x, im2,   "v1x",  "v2")
generate_all(im1,   im2_x, "v1",   "v2x")
generate_all(im1_x, im2_x, "v1x",  "v2x")

print("\nResultados en carpeta ./output/")

A continuación os muestro parte de las imágenes generadas por el script. El secreto oculto era un código QR que nos da la solución al reto.

v1__v2x__mul
v1__v2x__mul_sep
v1x__v2__mul
v1x__v2__mul_sep

List of file signatures for file carving

por ·Sin comentarios

File carving is the process of reassembling computer files from fragments in the absence of filesystem metadata. Wikipedia.

«File carving», literalmente tallado de archivos aunque lo traduciremos como extracción, es el proceso de re-ensamblado de archivos extraídos de un conjunto de mayor tamaño.

Índice

  1. Image files / Archivos de imagen
  2. Microsoft Office >2007
  3. Open Office
  4. Autocad
  5. Others / Otros
  6. Links / Enlaces

List of headers and tails / Lista de cabeceras y pies

Header = Cabecera

Footer or tail = Pie

Image files / Archivos de imagen

  • JPEG
    • Header: FFD8
    • Footer: FFD9
  • GIF87a
    • Header: 47 49 46 38 37 61
    • Footer: 00 3B
  • GIF89a
    • Header: 47 49 46 38 39 61
    • Footer: 00 3B
  • BMP
    • Header: 42 4D
    • Footer: Don’t have footer, but size is in bytes 2,3,4,5 in little-endian order (low byte first).
      • Example: 00 00 C0 38 == 49208 bytes

bmpsize

  • PNG
    • Header: 89 50 4E 47 0D 0A 1A 0A
    • Footer: 49 45 4E 44 AE 42 60 82

Microsoft Office >2007

All this documents have the same header and footer, because of this, we need search the middle bytes. This type uses a ZIP file package.

Los documentos de Microsoft Office >2007 tienen la misma cabecera y pie, por lo que necesitamos bytes intermedios para distinguirlos. Usan encapsulado ZIP.

  • DOCX
    • Header: 50 4B 03 04 14 00 06 00
      • Middle: 77 6F 72 64 (word)
    • Footer: 50 4B 05 06 (PK..) followed by 18 additional bytes at the end of the file.
  • XLSX
    • Header: 50 4B 03 04 14 00 06 00
      • Middle: 77 6F 72 6B 73 68 65 65 74 73 (worksheets)
    • Footer: 50 4B 05 06 (PK..) followed by 18 additional bytes at the end of the file.
  • PPTX
    • Header: 50 4B 03 04 14 00 06 00
      • Middle: 70 72 65 73 65 6E 74 61 74 69 6F 6E (presentation)
    • Footer: 50 4B 05 06 (PK..) followed by 18 additional bytes at the end of the file.
  • MDB / ACCDB
    • Header: 00 01 00 00 53 74 61 6E 64 61 72 64 20 4A 65 74 20 44 42 (….Standard Jet DB)
    • Footer: Don’t have footer.

Open Office

All this documents have the same header and footer, because of this, we need some bytes to differentiate them. In this case we can do this jumping 73 bytes from header. This type uses a ZIP file package.

Los documentos de OpenOffice tienen la misma cabecera y pie, por lo que necesitamos bytes intermedios para distinguirlos. Usan encapsulado ZIP.

  • ODS
    • Header: 50 4B 03 04 14 (PK..) jump +73 (0x49) bytes and 73 70 72 65 (spre)
    • Footer: 6D 61 6E 69 66 65 73 74 2E 78 6D 6C 50 4B 05 06 (manifest.xmlPK) followed by 18 additional bytes.
  • ODT
    • Header: 50 4B 03 04 14 (PK..) jump +73 (0x49) bytes and 74 65 78 64 (text)
    • Footer: 6D 61 6E 69 66 65 73 74 2E 78 6D 6C 50 4B 05 06 (manifest.xmlPK) followed by 18 additional bytes.
  • ODB
    • Header: 50 4B 03 04 14 (PK..) jump +73 (0x49) bytes and 62 61 73 65 (base)
    • Footer: 6D 61 6E 69 66 65 73 74 2E 78 6D 6C 50 4B 05 06 (manifest.xmlPK) followed by 18 additional bytes.
  • ODG
    • Header: 50 4B 03 04 14 (PK..) jump +73 (0x49) bytes and 67 72 61 70 (grap)
    • Footer: 6D 61 6E 69 66 65 73 74 2E 78 6D 6C 50 4B 05 06 (manifest.xmlPK) followed by 18 additional bytes.
  • ODF
    • Header: 50 4B 03 04 14 (PK..) jump +73 (0x49) bytes and 66 6F 72 6D (form)
    • Tail: 6D 61 6E 69 66 65 73 74 2E 78 6D 6C 50 4B 05 06 (manifest.xmlPK) followed by 18 additional bytes.
  • ODP
    • Header: 50 4B 03 04 14 (PK..) jump +73 (0x49) bytes and 70 72 65 73 (pres)
    • Footer: 6D 61 6E 69 66 65 73 74 2E 78 6D 6C 50 4B 05 06 (manifest.xmlPK) followed by 18 additional bytes.

Autocad

  • DWG (R11/R12 versions)
    • Header: 41 43 31 30 30 39
    • Footer: CD 06 B2 F5 1F E6
  • DWG (R14 version)
    • Header: 41 43 31 30 31 34
    • Footer: 62 A8 35 C0 62 BB EF D4
  • DWG (2000 version)
    • Header: 41 43 31 30 31 34
    • Footer: DB BF F6 ED C3 55 FE
  • DWG (>2007 versions)
    • Header: 41 43 31 30 XX XX
    • Footer: Don’t have

Note: >2007 versions have two patterns and the key is the position 0x80. If in this position we get the bytes «68 40 F8 F7 92», we need to search again for this bytes and displace 107 bytes to find the end of the file. If in the position 0x80 we get another different bytes, we need to search again this bytes and displace 1024 bytes to find the end of the file.

Nota: Las versiones >2007 siguen dos patrones y la clave está en la posición 0x80. Si en la posicion 0x80 obtenemos los bytes «68 40 F8 F7 92», los buscamos una segunda vez y ha 107 bytes encontramos el final del archivo. Si en la posición 0x80 obtenemos otros bytes diferentes a los del primer caso, los volvemos a buscar y a 1024 bytes hallaremos el final del archivo.

Others / Otros

  • PDF
    • Header: 25 50 44 46 (%PDF)
    • Footers:
      • 0A 25 25 45 4F 46 (.%%EOF) or
      • 0A 25 25 45 4F 46 0A (.%%EOF.) or
      • 0D 0A 25 25 45 4F 46 0D 0A (..%%EOF..) or
      • 0D 25 25 45 4F 46 0D (.%%EOF.)
  • ZIP
    • Header: 50 4B 03 04
    • Footer: 50 4B 05 06 (PK..) followed by 18 additional bytes at the end of the file.
  • RAR (< 4.x version)
    • Header: 52 61 72 21 1A 07 00
    • Tail: C4 3D 7B 00 40 07 00
  • 7ZIP
    • Header: 37 7A BC AF 27 1C 00 03  (7z¼¯’…)
    • Footer: 01 15 06 01 00 20 followed by 5 additional bytes at the end of the file.
  • RTF
    • Header: 7B 5C 72 74 66 31
    • Footer: 5C 70 61 72 20 7D

Links / Enlaces

Reversing – Nosotros y ChatGPT contra un ELF desde Windows

por ·Sin comentarios

Table of Contents

Intro

Antes que nada, es importante saber que un archivo ELF en Linux es equivalente a un archivo EXE en Windows. Dicho esto, es bastante común encontrarnos con ejecutables ELF en diversos CTFs (Capture The Flag), y a menudo representan un desafío para aquellos no familiarizados con el uso cotidiano de Linux. Sin embargo, tengo una buena noticia si no eres aficionado de Linux: existen herramientas que permiten realizar un análisis preliminar para determinar si es necesario abordar el problema desde Linux o si podemos resolverlo directamente desde Windows. Estas herramientas facilitan una transición más cómoda para los usuarios de Windows, permitiéndoles interactuar eficazmente con archivos ELF.

ELF

Un archivo ELF (Executable and Linkable Format) es un formato común de archivo para archivos ejecutables, código objeto, bibliotecas compartidas y volcados de memoria en sistemas basados en Unix, como Linux. Es el estándar de formato de archivo para programas compilados y enlazados en este tipo de sistemas operativos.

La cabecera de un archivo ELF es una estructura de datos al comienzo del archivo que proporciona información esencial sobre el contenido y la forma de procesar el archivo. Esta cabecera es fundamental para que el sistema operativo y otros programas puedan interpretar correctamente el archivo ELF. Aquí están los componentes clave de la cabecera de un archivo ELF:

  1. Identificación (e_ident): Esta sección incluye la magia del archivo ELF, representada por los primeros cuatro bytes 0x7F 'E' 'L' 'F'. También incluye información como la clase del archivo (32 o 64 bits), la codificación de datos (endianness), y la versión del formato ELF.
  2. Tipo (e_type): Indica el tipo de archivo ELF, como EXEC (ejecutable), DYN (biblioteca compartida), REL (relocalizable), entre otros.
  3. Máquina (e_machine): Especifica la arquitectura de hardware para la cual se diseñó el archivo, por ejemplo, x86, ARM.
  4. Versión (e_version): La versión del formato ELF, generalmente establecida en 1.
  5. Punto de Entrada (e_entry): La dirección de memoria virtual donde comienza la ejecución del proceso.
  6. Desplazamiento del Program Header (e_phoff): Indica dónde comienza el encabezado del programa en el archivo.
  7. Desplazamiento del Section Header (e_shoff): Indica dónde comienza el encabezado de la sección en el archivo.
  8. Flags (e_flags): Banderas específicas del procesador.
  9. Tamaño de esta cabecera (e_ehsize): El tamaño de la cabecera ELF.
  10. Tamaño del Program Header (e_phentsize): El tamaño de una entrada del encabezado del programa.
  11. Número de entradas del Program Header (e_phnum): El número total de entradas en el encabezado del programa.
  12. Tamaño del Section Header (e_shentsize): El tamaño de una entrada del encabezado de la sección.
  13. Número de entradas del Section Header (e_shnum): El número total de entradas en el encabezado de la sección.
  14. Índice del Section Header Table (e_shstrndx): El índice del encabezado de la sección que contiene los nombres de las secciones.

El reto

Se nos proporciona un fichero de 20KB que rápidamente catalogamos como ELF.

Para realizar un análisis preliminar siempre uso DogBolt, que no es más que un decompilador online con la ventaja de que usa varios motores y de esta forma casi siempre te da una decompilación aceptable. La versión actual tiene disponibles 11 motores y además es open source, ¿Qué más se puede pedir?

Echamos un vistazo y enseguida encontramos algo interesante.

La flag parece codificada de modo que vamos a indagar acerca de la función FUN_0010285d

Dentro de la función FUN_0010285d vemos que nuestra flag codificada la procesa la función FUN_00102752

Aquí os diría que depende de vuestra experiencia en programación veríais que se está procesando byte a byte la cadena de entrada (param_1) y haciendo a cada byte un XOR (^) con el param_3 (que es 1 según vemos en la llamada de la función FUN_00102752), pero en estos tiempos que corren vamos a preguntar a ChatGPT que opina.

ChatGPT

Le pido a ChapGPT que me analice el código y me responde:

Este código en C define una función llamada FUN_00102752 que realiza una operación de XOR (exclusivo OR) byte a byte sobre un bloque de memoria. La función toma tres parámetros:

  1. long param_1: Este parámetro es tratado como una dirección de memoria. Se utiliza como la base de un bloque de memoria sobre el que se realizará la operación.
  2. ulong param_2: Este parámetro especifica el tamaño del bloque de memoria que será afectado por la operación.
  3. byte param_3: Este es el valor de un solo byte que se utilizará en la operación XOR.

El cuerpo de la función consiste en un bucle for que itera sobre el bloque de memoria:

  • int local_c se declara como una variable local y se inicializa en 0. Esta variable actúa como un contador para el bucle.
  • La condición del bucle (ulong)(long)local_c < param_2 asegura que el bucle se ejecute sobre el rango completo del bloque de memoria especificado por param_2.
  • Dentro del bucle, *(byte *)(param_1 + local_c) = *(byte *)(param_1 + local_c) ^ param_3; realiza la operación XOR. Aquí, *(byte *)(param_1 + local_c) accede al byte actual en el bloque de memoria. Este byte se modifica aplicándole un XOR con param_3. La operación XOR se realiza entre el byte actual en la memoria y el valor de param_3, y el resultado se escribe de nuevo en la misma ubicación de memoria.

En resumen, la función FUN_00102752 modifica un bloque de memoria aplicando una operación XOR con un valor dado (param_3) a cada byte dentro del rango de memoria especificado desde param_1 hasta param_1 + param_2. Este tipo de operación es común en tareas como la manipulación de datos para cifrado/descifrado o para la generación de patrones específicos en un bloque de datos.

by ChatGPT

Ahora imaginad que no sois muy dados a programar o simplemente estáis vagos de modo que volvemos a recurrir a ChatGPT con el promt «Haz un XOR 1 con javascript a la cadena: gmfzuihr^vr^o^drx^nod^shfiu|» a lo que responde:

function xorString(str) {
return Array.from(str).map(char => String.fromCharCode(char.charCodeAt(0) ^ 1)).join(»);
}

console.log(xorString(‘gmfzuihr^vr^o^drx^nod^shfiu|’));

by ChatGPT

Copiamos el código y lo pegamos en un entorno online como por ejemplo playcode.io.

Este es un ejemplo simple, pero ¿percibís su potencial?

La imagen de portada de esta entrada ha sido generada con ChatGPT.

ThisIsLegal.com – Realistic Challenge 2

por ·Sin comentarios

Warning: This challenge is still active and therefore should not be resolved using this information.
Aviso: Este reto sigue en activo y por lo tanto no se debería resolver utilizando esta información.

Introducción

Realistic Challenge 2: You have heard about people being targeted by a new religion called Egitology. Another hacker infiltrated the group and discovered that the list of people they target is stored on the site but he doesn’t know where.

Break into the site, find the file and remove it. Also leave no evidence that you was ever there so they wont realise until its too late!

El enunciado del reto nos dice que tenemos que localizar la lista de objetivos y eliminarla sin dejar evidencias.

Analizando la seguridad de la víctima

Echamos un vistazo y vemos que tienen un Login para usuarios registrados, este será nuestro primer testeo.
Lo primero que se no viene a la cabeza con un formulario de este tipo es Inyección SQL, probamos varios métodos y tenemos suerte.
User: admin
Pass: ‘ or 1=1–‘;
 
 Vemos que hemos entrado como admin y enseguida nos llama la atención «Back up Database«. Pulsamos a ver que pasa.
 Obtenemos el hash de las claves de los usuarios Admin y SuperAdmin. Por suerte son hashes MD5. Obtenemos la clave de SuperAdmin y nos loguemos.

Solo nos queda borrar la lista de objetivos y nuestras huellas. Para ello borramos los siguientes archivos y reto superado.

Lista de objetivos: root/misc/targets
Logs: root/images/logs

Links