No se hacen tareas. Te podemos ayudar en temas puntuales, la parte donde te hayas estancado, pero no vamos a resolver todo el problema.
Muestra lo que tengas hecho o la parte donde no sabes seguir. Así sí que te podremos ayudar.

---

Lo digo, más que nada, porqué esto contraviene las reglas del foro y el moderador te puede cerrar el post y así no se te podrá ayudar en nada.

Moverse en la pila local es restar un literal a base pointer, un acceso al montón es cargar la dirección de memoria y despues hay que calcular el offset.

---

Dos programas que hacen casi lo mismo. El primero crea un array normal, en la pila; el segundo lo crea en el motón mediante malloc.
Código en C del array en pila:

#include <stdio.h>
 
int main( void ){
    int array[5];
 
    array[3] = 3;    
    printf("%i", array[3]);
 
    return 0;
}

Código en C del array en el montón:

#include <stdio.h>
#include <stdlib.h>
 
int main( void ){
    int *array = malloc(sizeof(int) * 5);
 
    array[3] = 3;    
    printf("%i", array[3]);
 
    return 0;
}

Código ensamblador generado, sin optimización y en sintaxis INTEL, por GCC para el array en la pila:

	.file	"c.c"
	.intel_syntax noprefix
	.section	.rodata
.LC0:
	.string	"%i"
	.text
	.globl	main
	.type	main, @function
main:
.LFB0:
	.cfi_startproc
	push	rbp
	.cfi_def_cfa_offset 16
	.cfi_offset 6, -16
	mov	rbp, rsp
	.cfi_def_cfa_register 6
	sub	rsp, 32
	mov	DWORD PTR [rbp-20], 3
	mov	eax, DWORD PTR [rbp-20]
	mov	esi, eax
	mov	edi, OFFSET FLAT:.LC0
	mov	eax, 0
	call	printf
	mov	eax, 0
	leave
	.cfi_def_cfa 7, 8
	ret
	.cfi_endproc
.LFE0:
	.size	main, .-main
	.ident	"GCC: (Ubuntu 4.8.4-2ubuntu1~14.04.1) 4.8.4"
	.section	.note.GNU-stack,"",@progbits

Código ensamblador generado, sin optimización y en sintaxis INTEL, por GCC para el array en el montón:

	.file	"d.c"
	.intel_syntax noprefix
	.section	.rodata
.LC0:
	.string	"%i"
	.text
	.globl	main
	.type	main, @function
main:
.LFB2:
	.cfi_startproc
	push	rbp
	.cfi_def_cfa_offset 16
	.cfi_offset 6, -16
	mov	rbp, rsp
	.cfi_def_cfa_register 6
	sub	rsp, 16
	mov	edi, 20
	call	malloc
	mov	QWORD PTR [rbp-8], rax
	mov	rax, QWORD PTR [rbp-8]
	add	rax, 12
	mov	DWORD PTR [rax], 3
	mov	rax, QWORD PTR [rbp-8]
	add	rax, 12
	mov	eax, DWORD PTR [rax]
	mov	esi, eax
	mov	edi, OFFSET FLAT:.LC0
	mov	eax, 0
	call	printf
	mov	eax, 0
	leave
	.cfi_def_cfa 7, 8
	ret
	.cfi_endproc
.LFE2:
	.size	main, .-main
	.ident	"GCC: (Ubuntu 4.8.4-2ubuntu1~14.04.1) 4.8.4"
	.section	.note.GNU-stack,"",@progbits

Como se puede ver la escritura y la lectura en el montón, mediante puntero necesita de muchas más instrucciones que el acceso a un elemento el array.

Los arrays y las tablas són siempre más eficientes, pues son datos que se guardan en la pila y el código que se genera para acceder a ellos es más rápido que acceder el montón. Por otra parte la memoria de la pila es bastante más limitada, en tamaño que la del montón y para un gran número de elementos te podrías quedar sin pila de programa rápidamente.
También está el tema de pasar arrays a funciones como argumentos: como es un puntero se pierde totalmente la ventaja de un array propio ya que hay que tratarlo como si estuviera en el montón.
Por último la función realloc es una de las más lentas pues debe acceder al montón, comprobar si hay memoria suficiente para la nueva asignación,  copiar todos los datos que le son posible a la nueva asignación y liberar la memoria del puntero original.

Correcto.

Sí, la POO y los genéricos quitan mucha carga al programador y tal, pero la sintaxys de C++ me sigue preciendo muy engorrosa. Hace años microsoft tenía un proyecto de un C# que compilaba directamente a código nativo. Desconozco si ha tenido continuidad, pero es una lástima que no se haya hechi de dominio público. Me gustaba mucho C# y podría haberse convertido en el lenguaje de mi preferencia. No hubo suerte.

Yo soy de C. Allá por el 2005 - 2008 estuve tocando C# y me gustaba como lenguaje POO. Lo he intentado con otros lenguajes pero me siento incómodo por la falta de expresividad y control que obtengo con C. Y considero C++ un lenguaje muy sucio, hecho de parche, sobre parche, sobre parche.

En cuánto al estilo de código, siempre que éste sea coherente, claro y agradable a la vista, no tengo objeción.

En este caso, cuándo haces realloc, string1 deja de tener memoria asignada. Hay que verlo como si realloc hiciera internamente un free al puntero que se le pasa. El que veas string1 después del realloc es porqué los datos persisten en la memoria (no se pone a 0), aunque hay que recordar que el sistema ya no la tiene en cuenta por tanto en cualquier momento se puede reescribir.

Y la clave de descifrado es?

Bueno, vamos a hacer una cosa. Empieza poniendo el código que sepas y vamos montando el programa a partir de aquí.

Ahora le puedes explicar el porqué de cada línea del programa.