Sistemas basados en tiempo, a veces siguen funcionando simplemente cambiando la hora del equipo.
De funcionar... entonces es tan sencillo como iniciar dicho programa desde un script que antes de lanzarlo cambie la hora del sistema a la hora prefijada y no usarlo más de esas 4 horas de límite que ofrece. Para que sea cómodo y no haya que andar trastrando la hora cada vez, sería preciso:
1 - primero tomar y almacenar la hora actual
2 - Restar la hora de inicio de funcionamieto del programa de la hora actual y almacenar dicho dato, como diferencia horaria
3 - Establecer la hora de inicio que el programa acepta.
4 - lanzar el programa... el script debe esperar a su cierre.
5 - Tomar la hora de cierre
6 - restar a la hora de cierre la hora de inicio y almacenarla como tiempo transcurrido.
7 - Sumar a la hora actual el tiempo transcurrido y almacenarla como nueva hora actual
8 - Establecer la nueva hora actual (restablece la hora original).

Cuando no funciona es porque:
A - O bien, escribe algo en alguna parte que registra y comprueba (periódicamente)... Ver si escribe a algún fichero o registro, especialmente si requiere instalación.
B - O bien mantiene un reloj interno... abrir el ejecutbale y localizar el crono, donde establezca una suma o una diferencia, cambiar (como corresponda), para que sume 0, o para que la resta ofrezca el valor antes de resta (es decir que reste 0).
C - O bien mediante una función accese a internet para conocer la hora en tiempo real (reloj atómico, es lo más sensato).
D - Otros sistemas son más raros y menos fiables...

'HEX', no es ningún lenguaje, es un sistema de codificación... o si lo prefieres ver más racional 'un sistema de numeración en base 16'.
Cuando pulsas en una dirección (prácticamente en cualquier editor hexadecimal) en la sección de la izquierda, verás que decodifica el valor de 1,2,4,8 bytes (a partir del seleccionado) y ofrece varios valores de decodificación en decimal, en fecha (date time) e incluso algunos lo desensamblan (incluso cuando ni siquiera se trata de código ejecutable, por ejemplo si abres una imagen o un txt).

Respondiendo a tu cuestión: En general todo editor hexadecimal, sitúa a la derecha del texto en hexadecimal, su transcripción en texto.

Un editor hexadecimal, suele permitir buscar determinado valor, dando el valor como texto ASCII o en formato hexadecimal (solo hay que indicarle el caso)...

... si se trata de código compilado, necesitar usar un desensamblador. En realidad puede bastarte un editor hexadecimal (especialment si solo vas a cambiar muy pocos datos) a condición de que entiendas lo que estás haciendo y lo que tienes al frente... pero dadas las preguntas que haces, dudo que sea el caso.

Después de gatear, se aprende a andar antes de pretender correr y saltar. Tu todavía 'gateas', es decir: tu problema elemental es que te falta conocimiento y comprensión de lo que tratas de hacer, tu problema no son los programas señalados, ni otros programas...

No. Tu aprendiste antes español, desde niño. Java requiere aprendizaje, pseudocódigo, solo ordenar ideas en tu cabeza, el lenguaje e sí mismo es tu idioma natural.

Pseudocódigo, como tal, no es un lenguaje... la sintaxis es libre, pués en lo que hace incapié es en la semántica (el significado de las cosas, obviando precisamente el cómo se escriba).

En definitiva (el pseudocódigo) relaja la sintaxis en favor de la semántica... luego lejos de fastidiar simplifica las cosas.

Me suena a que impulsivo fuere win7, tratando de desviar la atención con eso de: ' porque mi hija no preguntaba en los hilos que correspondía'... 

...Desde cuándo un padre opera en el mismo foro que su hija????

Los prorusos, todavía seguirán emperrados en la 'desanzificación', porque la desnazificación, como es bien sabido implica:

- Robar el trigo y demás alimentos almacenados en los silos, que estaban listos para ser enviados a los clientes internacionales.

- Apoderarse del acero que igualmente esperaba en los puertos para ser enviado a los clientes internacionales.

- Sembrar el campo ucraniano de minas antipersonas.

- Llevar civiles a Rusia, sin conocimientoen lo sucesivo de qué es de la vida de ellos. Unos pocos aparecerán para las cámaras, por supuesto, para mantener el paripé de la preocupación por las vidas humanas ...del resto quién sabe, podrían haber acabado en Siberia, en campos de concentración (o re-educación como China lo llama), o directamente ejecutados...

- Destruir todo el país, incluído casas, industrias, hospitales, escuelas...

- Amenazar constantemente a todo el mundo con armas nuecleares.

A estas alturas, hasta el más recalcitrante tonto, debiera saber que los auténticos nazis están en el bando ruso.

Pero... si ha sido hackeado, ¿qué te hace pensar que mantengan las credenciales originales para el acceso?.

Si los servicios aludidos eran de pago, simplemente basta con decirles, "oye si no nos devolveis el control de los servicios contratados, se acabó el contrato" y dejais de pagar, por el servicio prestado si no atienden a razones.

Si en cambio es un servicio gratuito, ahí es más problemático, el alojamiento no tiene una 'razón de peso' para hacer más de lo que (supuestamente) ya hayan hecho... En casos así, es cuando se entiende esa frase tan gastada de: 'lo barato sale caro'.

Por otro lado, por muy ética que parezca ser tu petición, entiende que aquí (un foro de internet), nadie tiene porqué creer que sea verdad ni toda la verdad, lo que dices, aunque en principio se conceda como aceptado que es verdad, entre conceder y ceder hay una distancia insalvable.

En resumen, sería más provechoso que cifrarais el costo de los servicios perdidos (el valor de los mismos) y en base a ello contratar a un 'profesional' que os ayude, viendo si el precio que solicita es asequible con el costo estimado por vosotros.

Eso sí, recomiendo que el contrato sea por resultados, descartando cualquier pago sin ello, y ofreciendo pago parcial por resultados parciales... Para evitar suspicacias y dudas entre las partes, es preferible que el 'profesional' acuda en persona a vuestro centro de trabajo y en lo posible que realice su tarea desde el mismo. Si hay confianza mutua, podrá fluir mucho mejor.

Dudo que sea el caso...

Más bien la respuesta dada surge como lo apropiado dada la ambigüedad de su intención: (Les parece debatir sobre estas preguntas un tanto capciosas??: Sobre AES)

Si quiere preguntar que haga las preguntas pertienentes... preguntar si puede preguntar  es envolver el envoltorio en otro envoltorio estérilmente.

Tienes varios 'pequeños' errores... que incluyendo comentarios te señalo:

- Empezando por la declaración de la matriz. la declaras 'de 9, 9', pero luego la inicializas con: 0-9, 0-4

- Cuando solicitas la butaca, el limite en cambio es 0-5

- Inicializas la matriz 'asiento' (de tipo char), con valor char '0'. Que luego podría confundir... Es aceptable, si lueog eres consecuente con ello,  aunque hubiera sido preferible que se declarara como un valor numérico. Al efecto es más útil y además en conjunto sería más util declarar dos constantes (numericas): BUTACA_LIBRE = 0 y BUTACA_OCUPADA = 1

- Igualmente es aceptable que el máximo de filas y de butacas por fila fueren declaradas también como constantes... (cualquier cambio a posterior basta cambiar el valor en 1 solo sitio en todo el código, donde se declaran y asigna el valor de la constante).

- El conjunto 'si fila = letra', podrías meterlo mejor en un bloque switch (salvo que no lo hayais dado aún).

- Tu mayores errores aparecen en (y a lo largo de las siguientes líneas de código):


----- Primero por restar 1 a butaca. Si (el usuario) eligió la butaca 0, estás preguntando por la butaca -1 (0-1= -1, error que te saltará por que la matriz no lo contempla). Más preocupante aún... ocupada una butaca en la matriz asientos, como preguntas por la butaca anterior podría dar libre u ocupada, pués preguntas por una  que no es la solicitada (esto es un error semántico, no habrá ningún mensaje de error, pero el resultado final es incierto), nota como la última butaca de cada fila, jamás será ocupada.

----- Segundo, si la comparación señala que la butaca está ocupada, reinvocas recursivamente la función 'reserva'... no es adecuado invocar una función recursiva sin dos preceptos: Saber que pasará con las variables, invocar innecesariamente... en tu caso al no recibir parámetros, puede parecer que carece de importancia, pero, cuando regrese de una llamada, seguirá ejecutando lo que reste de la función, por lo que sigue afectando a las variables en curso (que se declararon a nivel de módulo y no de función) y por ello, se debe estar seguro que valor mantiene al regreso de cada llamada. No he revisado que sucederá ante tales llamadas, pero es muy fácil que radique ahí lo que parece ser para tí tu error principal...

Pero básicamente porque (la llamada recursiva) es innecesaria...
Es preferible una de dos situaciónes: O bien 'reserva' es una función que devuelve un buleano (en tes caso el nombre de la función no sería el adecuado), solicitando fila y butaca e indicando si el asiento está libre (y por referencia la fila y butaca), y al regreso reinvocar la función o hacer la reserva en función dle valor devuelto... (pero en realidad para un principante esto puede complicarte la cuestión, al tener que mover código entre una función y otra, etc...)

...o bien envuelves todo el código en otro bucle while (es lo más simple en tu caso presente), he aquí en pseudocódigo la adaptación:

Estudia y entiende bien, los cambios mostrados en esta esquematización...
  
- En la función 'mostrar', esto (lo que sigue) es redundante, solo se diferencia en 'un espacio'. es preferible  alterar el dato a presentar, que la diferencia sea más notable no un mero espacio.
         Es más sensato que la función mostrar señale fila a fila y butaca a butaca el estado del asiento: algo que se vea como (aunque usando un carácter, yo hubiera eligido como libre el carácter '-'):
 -: 123456789
 -----------------
 0: 000XX00XX
 1: XX00X0XXX
  ....

La primera línea es la numeración de cada butaca, y el primer carácter de cada fila, es la numeración de cada fila (sería aún mejor que fuera un carácter A-I, para coincidir con lo que está en uso en el ejercicio, por comodidad yo he puesto un número).


...y eso es todo, es tu turno.

El pseucocódigo te ayuda a pensar, a resolver problemas, pero al final la programación es código, luego necesitarás sí o sí, conocer como mínimo un lenguaje a fondo (y preferiblemente también varios a medias, que con el tiempo se irán mejorando (si antes no desaparecen de escena, que es algo que puede ocurrir)).

Además suele ser preciso, que del pseudocódigo se pase al código... es decir: uno (el pseudocódigo) debe ser la etapa previa del siguiente, no un fin en sí mismo, salvo cuando tiene fines didácticos.
Se aplica solo en el puesto de enseñar, no en el de aprender. El que aprende, teniendo esa primera fase a mano, debe valerse de ella para acometer esa segunda fase, así consolida el aprendizaje.

Sin práctica, sin convertir el pseudocódigo a código, el que aprende, se queda a medias, pués no ve los errores en los que puede incurrir (detalles mal concebidos o mal entendidos (o sobreentendidos y que por ello no se detallan más allá de cierto punto)) al pasar el pseudocódigo a código...

Esto era crítico en tiempos pretéritos, cuando la memoria estaba muy limitada.
En la medida en que la memoria ha crecido (a lo largo de los años, viendo nacer nuevos S.O.), esto es ya innecesario.

...desde que había solo disponible unos pocos kilobytes de memoria y necesitabas saber si tu 'programa' cabría en la memoria, ha llovido mucho.

En general el S.O. por tener funcionalidad para gestionar la memoria, podría totalizar tales valores, pero no tiene sentido que lo exponga al exterior. Incluso el propio S.O. no necesita totalizar lo que un programa consume en todo caso puntualmente la memoria ocupada en una llamada, etc... justamente para eso, gestionar la memoria lo más eficientemente posible.

Técnicamente un programador debe saber cuanta memoria consume su programa. Pués sabe en un momento dado cuantas variables están en uso y cuántos bytes consume cada variable. En general las variables sueltas de un programa son 'despreciables' (por que al final serán solo unas decenas o pocas centenas), lo que suele ocupar gran tamaño son los arrays, métodos recursivos (sobretodo si los parámetros no se pasan por referencia) y complejidades dependientes de herencia (objetos).
Sobre los arrays y métodos recursivos, también puede uno calcular el consumo de memoria pues sabe el tamaño de cada uno de ellos y la memoria consumida por cada variable unitaria, los objetos es ya mas complejo, pués además hay referencias ocultas para mantener enlazados los objetos y suelen ser valores desconocidos (con exactitud), por parte del programador... no obstante la experiencia, te enseña por 'aproxmación' la estimación de tales valores.

En definitiva, no es ninguna función primordial hoy día de ningún sistema de explotación en programación donde los recursos van sobrados, por ello no se implementa.

Si a pesar de todo precisas algo (no exhaustivo), investiga sobre procesos, suele aportar algo de info no precisa al respecto.

p.d.: En windows, por ejemplo debería valerte con el 'task manager'... pero verás como los valores fluctúan en el tiempo de modo instantáneo, especialmente si es un programa grande y complejo.