Hola, se que se puede pero nose hacerlo soy un poco nuevo en el lenguaje de c# lo que quiero hacer es esto:

quiero convertir el archivo asi 0x72, 0x6F, 0x67, 0x72, 0x61, 0x6D, 0x20, 0x63, 0x61, 0x6E, 0x6E, 0x6F(ya lo hice) y quiero crear un form capaz de leer esos numeros y ejecutarse tal cual como si tuviera el codigo fuente

Si es por conversión, simplemente crea un array de 256 valores de tipo string.
Al cargar el programa, genera el array...básicamente es un byte en formato
byteHex = "0x" Hex(valor)  // un literal de byte en formato hexadecimal...
Esto es, cada valor del array es un byte (el mismo cuyo orden ocupa), convertido en hexadecimal, precedido por el prefijo "0x".

Luego cuando cargues un fichero, lo lees (tu ya ves si entero o en tramos según lo largo que sea), y en un bucle vas traduciendo la salida...


Con esto ya conviertes un fichero cualquiera sea su contenido (parece que te interesan solo ejecutables) en ese formato de texto legible sin separación entre unidades.

Respecto de la segunda parte:
 Es harina de otro costal... básicamente tendrías que hacer un lenguaje intepretado, para poder 'colar' y ejecutar lo que tú pretendes... (camuflado)...
Para que no te quedes con las ganas pensando que uno no quiere colaborar, te diré que un ejecutable, no se ejecuta al vuelo JAMÁS, primero debe cargarse en memoria, y debe reasignarse las direcciones de memoria REALEs, mientras es fichero, las direcciones dentro del fichero son relativas al propio fichero, solo cuando se carga en memoria, el cargador se encarga de sumar a todas esas direcciones la direccioón real, además, no tod se queda ahí, la reserva de memoria dinámica, tampoco queda incluída en el fichero, esta se asigna solo cuando se solicita y la dirección real es que el S.O. encuentre libre (no la dirección de carga del ejecutable o librería, esto es del código). Luego una conversión de un formato, no puede luego ejecutarse tal cual, con solo 'devolverlo' a su formato original... otra cosa es convertirlo todo de una vez a fichero y mandarlo ejecutar, pero es lo mismo que no haberlo convertido... o bien el método que ofrece Elektro...
Sin embargo recuerda que los antivirus prestan especial atención a los ficheros recién creados, o que abren y ejecutan... ...luego la ocultación (única razón para ese cambio de formato) sería solo 'eficaz' hasta el momento de ejecutarlo... la otra opción es como te dije interpretarlo...

p.d.:
Obviamente huelga decir que esto último no se explica en dos párrafos... y mucho menos si no tienes ni P4J0L354 idea de por dónde empezar algo tan simple como una mera conversión de formato:
valor = cualquier byte
byteHex = "0x" Hex(valor)
Si esa es la primera producción que te expongo (la que se encarga de la traducción), no te cuento todo lo que supone la compilación completa de un lenguaje, que puede llevar algunos cientos de producciones la mayoría más complejas que esa...
 

Si eso es explicarse mejor, apaga y vámonos. Vamos a ver, tienes estos números enteros (o bytes, como prefieras llamarlo): 0x64 y 0x00, o 100 y 0, bien, ¿a qué dices que hacen referencia esos números?, ¿y qué quieres hacer con ellos?.

De verdad, yo sigo sin entenderlo. Dices que esos bytes son un mensaje de texto, no entiendo, el valor 100 en la tabla ASCII es una "d" minúscula, y el 0 es un caracter no imprimible. Y dices que quieres "convertir el mensaje en una aplicación" y "sin ver el codigo fuente verdadero de la aplicacion 1", no entiendo nada.

Intenta especificar mejor las cosas usando las palabras/términos adecuados, ya en serio, por favor, de lo contrario lo único que consigues es malgastar el tiempo de los usuarios dispuestos a ayudarte, escribiendo cosas que no te sirven para nada, como lo que escribí en mi primer comentario, o como el compañero NEBIRE, puesto que se supone que eso no es lo que andas buscando...

---

NEBIRE, sabes que apoyo y nunca me he quejado de que compartas pseudo-codigos, pero en esta ocasión me parece realmente excesivo viendo lo que sugieres hacer en dicho pseudo-codígo...

No siempre es algo bueno ni inteligente querer hacer las cosas con búcles y redimensionando arrays y etc. para aprender a hacer las cosas "sin ayuda" y defenderse con cualquier lenguaje, ni enseñar a que la gente lo haga de esa manera, más que nada por que el lenguaje (bueno, el framework) ya provee las herramientas necesarias para ayudarnos a hacer las cosas de forma simplificada (y casi siempre resulta la forma más óptima), y sería de tontos no aprovechar dichas herramientas, de lo contrario el programador que haga las cosas así realmente debería plantearse seriamente por que está usando .NET ...si no es para sacarle provecho y hacer las cosas simples, no complicadas.

Si se trata de abrir un fichero executable para leer los bytes, y convertir ese array de bytes para construir ese formato específico de texto delimitado por comas, bastaría con hacer lo siguiente:

Dim rawBytes As Byte() = File.ReadAllBytes("C:\Program.exe")
Dim converter As Converter(Of Byte, String) = Function(value As Byte) String.Format("0x{0}", value.ToString("X2"))
 
Dim hexValues As String() = Array.ConvertAll(rawBytes, converter)
Dim hexString As String = String.Join(", ", hexValues)
 
Console.WriteLine(hexString)

Fin.

El tema de leer los bytes del archivo de entrada y escribir el archivo de salida pausadamente mediante un buffer de "X" tamaño sería innecesario dado el caso, ya que no hay modo de colapsar la memoria ni afectar negativamente al rendimiento de operaciones I/O del disco por leer de una todos los bytes de un archivo executable, al menos yo nunca he visto executables de 1 gigabyte o más tamaño como para que haya que plantearse hacer las cosas de otra forma más sofisticada, vaya. Ahora, ya se que tu pseudo-codigo está escrito para usos más... universales, archivos de todo tipo cuyo tamaño sea desconocido y puedan pesar bastante, y entonces sí se aplicaría la idea (sería lo mejor hacerlo, por supuesto), pero aun así lo veo totálmente excesivo ya que muchas cosas se pueden "omitir" por los miembros de .NET.

Lo siento por esta extensa critica constructiva, de verdad, casi preferiría haberme callado y no decir nada, por que es lo que suelo hacer cuando alguien me cae bien y no quiero molestar a esa persona, pero es que por otro lado me duele un poco ver ese tipo de cosas, ya que considero que la forma correcta de ilustrar con pseudo-códigos para que otros aprendan, y teniendo en cuenta que son pseudo-codigos para programadores de .NET, es enseñando/indicando como utilizar los miembros de .NET Framework, por que están ahí para aprender a usarlos, no para ignorarlos y hacer las cosas como se hacia en los años 90 o como se hace en otros lenguajes que no permitan hacerlo de forma más simple / abstracta...

Un saludo.

Bueno, aunque Elektro se queja (no sin motivo), yo alcanzo a comprender que necesitas justo lo opuesto a lo que te señale... es decir tener de vuelta los bytes desde el formato literal hexadecimal que muestras.

Supongo que no es más que un simple ejercicio... (porque la otra opción es intentar colar algún virus)...

Y para que Elektro no se manifieste protestón, lo pondré en código (por esta vez)...
Cuando alguna funcionalidad la usas con cierta frecuencia (no creo que este vaya a ser el caso, vaya contradición, ¿no?), resulta muy útil, utilizar las extensiones de tipos, y como la gente no acostumbra a usar extensiones, he preferido hacer una versión al caso...

Es una alternativa a la solución que propone Elektro, al caso no he probado (ni voy a perder tiempo en ello), sobre cual ofrece mejor rendimiento...

Omito todo el detalle de leer y guardar a fichero... básicamente he recurrido a un split...

namespace EjemploConversion{
    //Import the extension method namespace.
    using CustomExtensions;
    class Program {
        // en vez de 'main' puede ser el evento 'validate' de un textbox, por ejemplo... yo he tirado de consola para algo rápido...
        static void Main(string[] args) {    
            string kod = " 0x34 0x22 0x4B 0xB2 0xED 0xAB";  // nota el espacio delante del primero...
 
             //aqui tienes el array de bytes. Haz con ello luego lo que precises (cargarlo a memoria, guardarlo a fichero, etc...).
            byte[] by = kod.FromLitHex() ;
}}}
 
namespace CustomExtensions{
    public static class StringExtension{
        // Convierte una cadena de literales en hexadecimal, a  un array de bytes.
        public static byte[] FromLitHex(this string litHex){                     
            string[] sep = {" 0x"};
            // Split, Replace... realmente son funciones costosas en tiempo, acceder al array de caracteres y saltar entre ellos es más eficiente si lo que buscas es velocidad (pero para pequeños ficheros, no se precisa).
            string[] sBytes = litHex.Split(sep, StringSplitOptions.RemoveEmptyEntries );                  
            Int32 j = sBytes.Length;
            Int32 k = 0;
            byte[] gBytes = new byte[j];
            // NOTA: Si no dejaste el espacio delante del primero (es costoso en tiempo de procesado hacerlo después si no se empezó así), no importa, basta que lo trates (suelto) antes del bucle y luego el bucle comience ya en el índice 1.
            for (k = 0; k < j; k++){
                gBytes[k] = Convert.ToByte(sBytes[k], 16);
            }
            return gBytes;
        }
    }
}    
 

Créeme que convertir ese pseudocódigo en código NET, es mucho más breve, precisamente por los métodos que ya posee (NET).

La cuestión del bucle, es porque a priori, habla de "quiero convertir el archivo", en general sin especificar tamaños... yo he deducido que pueda referirse a ejecutables por que dice "leer esos numeros y ejecutarse", eso de ejecutarse, parece delimitar de alguna manera, pero tal como se explicó podría ser cualquier cosa... Por otro lado el propio Microsoft, tiene librerías de 10Mb. y me he encontrado con empresas donde pululan tochos de algún que otro ciento de Mb. luego sugerir una posibilidad, no implica llevarla a cabo, solo tenerla en cuenta, cuando proceda.

También, te señalo que pseudocódigo, no es la forma de los 80, ni los 90, ni de ninguna década, simplemente es la manera universal... de enseñar y comprender las cosas. El lenguaje en realidad es algo por lo que nadie debeiera preguntar en los foros, porque la especificación de cada uno de ellos está recogida en la web de la corporación que mantiene dicho lenguaje.

Los problemas de la gente (lo normal), son dos: Falta de comprensión de como resolver un problema y falta de comprensión de qué usar en un lenguaje para aplicar los conocimientos del problema. Lo primero se resuelve con pseudocódigo, lo segundo con la especificación del lenguaje.

Tranquilo, no hay ningún problema...
Cada uno tiene su forma de ver las cosas y en definitiva, nadie y todos a la vez tenemos razón. En defnitiva nos une buscar soluciones, aunque sea desde distintas perspectivas, es un "problema" del intelecto inquieto que no para...