Newsgroup: it.comp.programmare
Titolo: Programmare in Bin e in Hex

Ciao a tutti,
tempo fa mi dissero che se ad es. scrivo un programma in binario con il 
notepad e lo salvo come exe funziona. Io ho provato con un Hex e non 
funziona. Forse deve essere per forza Bin? 
Inoltre con un editor Hex ho aperto un exe e ho trasformato il sorgente 
Hex in un sorgente C che aveva la seguente struttura:
unsigned char [DIMENSIONE_ARRAY] = {0x00, 0xA2, .... 0x3b,};
Insomma era solo un'array enorme con tutti i valori in esadecimale. Non 
cera nemmeno il main. Cosa si deve fare per compilare tale sorgente ed 
ottenere l'exe? Aggiungere solo il main? Siccome attualmente non ho la 
possibilità di usare un compilatore C qualcuno potrebbe provarci e 
farmi sapere?
Grazie
--
Noixe
Inviato da 
www.mynewsgate.net

 farmi sapere?
questo non e' il sorgente C di nulla...
solo il contenuto pari pari dell'exe messo in un vettore stile C...
--
Ciao!
Skunkguru

 solo il contenuto pari pari dell'exe messo in un vettore stile C...
Il sorgente era unsigned char rawData[Dimensione] etc... avevo 
dimenticato il nome. Cmq, è C perchè il compilatore per C dovrebbe 
compilarlo. Il vettore è scritto in C.
Ciao


 compilarlo. Il vettore è scritto in C.
e' quello che ho detto....
quello E' un vettore in C... ma il contenuto di quel vettore
(ne tantomeno il vettore) NON e' il codice sorgente del
programma che hai aperto... ma semplicemente un
vettore in C che CONTIENE il programma che hai aperto...
e cmq credo sia meglio se spieghi cosa vuoi ottenere esattamente
e perche' questi giri...
--
Ciao!
Skunkguru

 compilarlo. Il vettore è scritto in C.
int main(void)
{
   unsigned char rawData[DIM_ARR] = {inizializzazione di rawData};
   return 0;
}
Produce un codice perfettamente inutile, indipendentemente dal
contenuto di rawData.
HTH
C:\>iao Angelo
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 e perche' questi giri...
Infilare SofICE in una smartcard per debuggare il decoder e vedersi
XXX Channel? :-)


 e perche' questi giri...
Voglio fare un virus potentissimo...
Ma che! E' solo per provare a scrivere un exe direttamente senza compilare.
Io per fare una cosa non mi baso sulla sua utilità ma sulla mia curiosità.


 contenuto di rawData.
Ma cosa hai messo come inizializzazione? Io avevo messo qualcosa tanto per 
rendere l'idea... dovresti provarlo con la vera inizializzazione. La post nel 
NG?


 vedere come!
quando neanche l'assembler basta piů ... ti rendi conto di quello che hai
scritto?
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (
http://www.grisoft.com
).
Version: 6.0.560 / Virus Database: 352 - Release Date: 08/01/2004

 scritto?
Io ho voglia di sperimentare ciò e vi ho chiesto alcune informazioni. Se voi 
non vedete l'utilità non è un mio problema. Io non ragiono in termini di 
utilità.



non era di utilità che parlavo ma di fattibilità ;-)


 non era di utilità che parlavo ma di fattibilità ;-)
Il fatto è che tempo fa mi dissero (su questo NG se non sbaglio) che salvando 
direttamente un binario in exe il programma funzionava (io però adesso sto 
lavorando con gli Hex perchè l'editor non mi da il Bin. Forse non trovo io la 
funzione che lo fa...). Cmq, attualmente mi interessa vedere il risultato della 
compilazione in C di quel sorgente. E' il notepad stesso aperto in Hex e poi 
esportato in un vettore C. E' circa 323 Kb. Se te lo invio lo compili e mi dici 
se l'output è un exe uguale al notepad?


 NG?
Nel caso ti fosse sfuggito, te lo ripeto
<autoCite>
   Produce un codice perfettamente inutile, indipendentemente dal
   contenuto di rawData.
</autoCite>


 direttamente un binario in exe il programma funzionava
certo ma non puoi programmare in binario è una cosa assurda!


 </autoCite>
Perchè?
Cmq invece mi pare che dovrebbe funzionare... infatti anche il traduttore 
Python C genera un sorgente simile (array di esadecimali).
Dove trovo in rete un compilatore leggero per windows? Mi basta un Gcc anche 
vecchio (deve solo compilare un'array...)


 certo ma non puoi programmare in binario è una cosa assurda!
Ma io voglio solo fare una prova, non devo mica fare software commerciale per 
lavoro!


 Ciao
L'unica cosa possibile è che tu impari l'assembly a menadito. Solo allora
(forse) riuscirai a fare quello che stai chiedendo.
M.

 
Tu non hai mai visto il sorgente di un programma in C e hai scambiato 
l'opzione che genera una dichiarazione in C (che puň essere utilizzata 
per includere dei dati che hai in un file dentro un programma C senza 
doverli caricare ogni volta dal file) con la generazione dei sorgenti 
in C del programma stesso.
Prova a eseguire la stessa funzione su un file di dati (magari un jpg 
di Pamela Anderson), vedrai che tira fuori la stessa dichiarazione 
(contenuto dell'array a parte). 
Pensi che compilando quel codice con un compilatore C ti troverai 
l'immagine di Pamela Anderson a video?
-- 
Valter Minute
vmi...@inwind.it
 (the reply address of this message is invalid)

 l'immagine di Pamela Anderson a video?
Pensavo di si, visto che in fondo tutto è byte.
Ma allora come si può creare una semplice applicazione (magari che stampi 
solo "hello world") soltando scrivendo codice e salvando in exe?



Per quanto riguarda cosa ne penso sul programmare
scrivendosi direttamente tutti i bytes a manina con
un editor esadecimale, Angelo Paolitto ha riassunto
il concetto in maniera mirabile: tu invece del martello
hai preso un editor esadecimale, vabbè...
De gustibus ecc. ecc. :-)
Comunque: devi sapere che i file di programma
(gli .EXE) possono essere in tre formati diversi
(sotto Windows; con altri OS ce ne sono altri
ancora): il NE di Win16/OS/2, il PE di Windows
95/98/ME/NT/2000/XP, ed il vecchio formato DOS
eseguibile.
In tutti questi tre casi, il file NON inizia con
le istruzioni ma con degli header che contengono
una serie di informazioni sul programma, su chi
l'ha creato, quando, come, dove e perchè: inoltre
sono presenti anche delle sezioni dati e degli
array di rilocazioni per modificare il codice al
momento di caricarlo in RAM (sennò sarebbe
eseguibile solo se caricato ad una ben precisa
locazione di memoria... e questo è MALE :-)
Per non parlare dei simboli di debugging e delle
directory di importazione (per linkare le funzioni
nelle DLL esterne)...
Praticamente, se tu compili un vettore statico
come quello che hai creato, otterrai un nuovo file
.EXE lungo 323 + (da 1 a 8) KB che una volta
lanciato terminerà immediatamente, visto che
l'array è un DATO e il compilatore l'avrà
incorporato nel file come tale, senza generare
una sola istruzione a parte il codice di
prologo/epilogo comune a tutti i programmi. :-)
Se comunque intendi perseverare nella tua pazzia,
io ti consiglierei di scrivere programmi .COM:
è il più vecchio formato (DOS) esistente, e non ha
header di nessun genere: uniche limitazioni, un file
.COM non può essere più lungo di 64Kb e la prima
istruzione del codice deve stare all'offset 0x100
esadecimale dall'inizio del file. A parte questo,
hai carta bianca... oddio non so se puoi usare
codice a 32 bit oppure no in un programma .COM,
ma ti basterà fare qualche prova per scoprirlo :-)
Buon martell... ehm... Buon lavoro! ;-)

 Buon martell... ehm... Buon lavoro! ;-)
Grazie per le info, finalmente uno che mi ha chiarito il perchè il copia 
e incolla non potesse funzionare... comunque la mia era solo curiosità, 
niente di più...
Ciao


 unsigned char [DIMENSIONE_ARRAY] = {0x00, 0xA2, .... 0x3b,};
un tale amico mio aveva fatto cosi': aveva creato un array (o un 
puntatore ad array?) e l'aveva riempito del codice di una tale funzione 
che gli interessava eseguire - non riusciva ad usare l'assembly inline 
di gcc perche' gli faceva pieta' l'implementazione e anche a me, ad 
essere sincero). cmq poi castava l'array in un puntatore a funzione ed 
eseguiva cosi' il codice contenuto nell'array. ora, di qui a produrre 
un'intero binario penso che sia dura ma il procedimento e' piu' o meno 
questo. non ho l'email dell'amico sotto mano, al limite lo invito qui e 
gli chiedo di postare la sua soluzione.
-- 
Morpheu5 (cast-away =)

 stare all'offset 0x100 esadecimale dall'inizio del file.
Una qualche utilità nello scrivere questo tipo di programmi c'e'. Giusto per
dare un idea date un'occhiate a questo comando:
ECHO XPYP[*'CC-\1P\QX,=P,APZ5O!PQ2O~5aaI~}Ksx>
E.COM
che crea un versione di echo (
E.COM
) che non aggiunge il CR/LF alla fine
della linea.
(Il comando è tutto su una riga, se il programma che usate per leggere le
news ve lo ha spezzato non funzionerà)
La stringa dopo ECHO altro non è che un programma in assembler in cui tutti
i byte sono compresi tra 0x21 e 0x7F e possono essere rappresentati come
caratteri ASCII!!!
Per vedere il sorgente basta eseguire il comando, lanciare debug, caricare
il programma 
E.COM
 e disassemblarlo.
Non lo inventato io (anche se mi sarebbe piaciuto), e' una tecnica
utilizzata nella programmazione di file batch per DOS e la spiegazione la
trovate a questo indirizzo:  
http://lf.8k.com/BAT/FVAR.HTM
.
Ciao,
                        /RD/
PS: Io non esegurei MAI del codice senza prima aver verificato di cosa si
tratta, leggete la spiegazione sul sito PRIMA e poi, a vostro rischio e
pericolo, eseguite il suddetto comando ed il programma 
E.COM
.

 Perchč?
Te l'hanno spiegato e contiui ad insistere.
Hai detto che il file e' di 300K. Spediscimelo che te lo copilo
e ti mando eseguibile e disassemblato.


 Te l'hanno spiegato e contiui ad insistere.
Me lo hanno spiegato dopo la mia richiesta. Se tu mi avessi detto subito che un 
binario inizia con delle info aggiuntive come mi ha detto Tin Toy non avrei più 
pensato che il sorgente C potesse essere sufficiente a generare un exe 
funzionante e non avrei fatto altre richieste.


 funzionante e non avrei fatto altre richieste.
Non per essere stupidamente polemico, ma la spiegazione corretta
te l'ha data Valter Minute: un compilatore "C" che trova un programma
del tipo
int main(void)
{
   unsigned char rawData[];
   return 0;
}
genera del codice che avvia il programma ed esce immediatamente senza
prendere minimamente in considerazione il contenuto di rawData (se
ottimizza anche il codice, rawData potrebbe persino non esserci nel
programma generato in quanto inutile alla sua esecuzione).
Quanto detto da Tin Toy e' sicuramente corretto (e se ti ha aiutato
a capire il problema tanto meglio), ma il comportamento del programma
risulta lo stesso sia se compilato da un compilatore che genera codice
rilocabile (ovvero genera anche l'intestazione letta dal S.O. al
momento del caricamento del programma) sia se compilato da uno che
genera codice non rilocabile (tipicamente per sistemi "embedded").
HTH


 compilare.
i principi basilari prima di tutto: gli eseguibili li genera il linker, 
il compilatore genera solo l'input per il linker. Gli informatici amano 
risolvere i problemi impilando astrazioni, e il caso compilatori/linker 
non fa eccezione: si tratta di trasformazioni messe in sequenza. Per la 
precisione, la sequenza è:
 - programmatore (input: documento di specifica)
 - compilatore (input: sorgente in un linguaggio di alto livello)
 - assemblatore (input: sequenza di opcode specifici della piattaforma)
 - linker (input: codice binario indipendente dal sistema operativo)
L'output finale è codice binario specifico della piattaforma formattato 
in modo che un particolare sistema operativo possa caricarlo. Tanto per 
non smentirsi mai, ogni singolo livello può essere composto da numerosi 
altri livelli: il programmatore può aiutarsi nella produzione di codice 
con strumenti detti di "modellazione", che possono andare dal wizard al 
sorgente UML; il compilatore, quasi sempre, è diviso in due parti dette 
"front-end" e "back-end", dove il front-end è specifico del linguaggio, 
e il back-end specifico della piattaforma, e in mezzo c'è un linguaggio 
detto "linguaggio intermedio", una specie di assembler ad alto livello. 
Non paghi di tanta astrazione, aggiungiamo che la piattaforma va, a sua 
volta, divisa in instruction set e hardware (esempio: una Playstation e 
una workstation Silicon Graphics hanno un instruction set identico, ma, 
ovviamente, l'hardware è molto diverso), e normalmente l'hardware è una 
cosa secondaria, di cui si occupa solo un piccolo componente del kernel 
(hardware abstraction layer, o HAL); e che il linker, in molti casi, si 
divide in due fasi: una che produce un eseguibile su disco indipendente 
dal sistema operativo e l'altra, detta "dynamic linker" o "loader", che 
legge questo eseguibile in memoria adattandolo ai parametri sconosciuti 
nelle fasi precedenti, come l'indirizzo effettivo in memoria
-- 
  < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
      Don't stand, REACT!      version 0.1.5. C, C++ and ASM developers
                               and beta testers are welcome!

 sia se compilato da un compilatore che genera codice
Si, infatti mi sembrava strano che un prog C di quel tipo potesse funzionare, 
ma quello che mi ha fatto persistere nel pensare che ciò potesse accadere è il 
fatto che vidi tempo quel sorgente Python->C generato da frozen di cui ho 
scritto prima.


 
Ho fatto anche io un programmino con 
la stessa funzione:
http://8008.8k.com/scripts.htm
-- 
Marco

 notepad e lo salvo come exe funziona. 
Solo se lo scrivi in formato ascii,e per fare questo devi conoscere
a fondo l'Assembly e sfruttare solo quei comandi e istruzioni che te
lo permettono.E' molto difficile,te lo assicuro.In genere si usa
un file eseguibile e lo si converte in formato ascii con un 
programma apposito in cui la prima o le prime due rige sono
il decodificatore e le restanti la parte codificata.
Qui trovi qualche mio esempio (fra l'altro)
http://8008.8k.com/scripts.htm
--
Marco

 
http://8008.8k.com/scripts.htm
Visto! Il tuo "echo senza \n" è anche più breve di questo.
In effetti anche la tecnica di rappresentare il codice in hex ed usare debug
per convertirli in un .COM è assimilabile a quello che voleva fare il nostro
amico.
.RD.

 caratteri ASCII!!!
Ma se il programma che devo scrivere ha bisogno di usare byte che non 
sono compresi nell' intervallo [0x21; 0x7F] devo necessariamente scrivere 
in Hex giusto?




No,puoi fare in modo di ottenerli con le poche istruzioni e comandi
a disposizione.Ogni programma a bisogno di un ret o int 21h
finale e non sono ottenibili direttamente in ascii.Se ad esempio
l'utimo byte e' caricato ad offset 200 e si vuole che diventi un ret
biogna far in modo che i comandi precedenti lo trasformino in CD21.
-- 
Marco

 trasformino in CD21.
In pratica scrivi un programma che si automodifica. C'era da stare attenti
sui vecchi computer (486? 386? Non mi ricordo) che per via del prefetch
rischiavano di mandare tutto all'aria non ho idea di come sia la situazione
con i nuovi processori.
Comunqe mi associo al discorso che alcuni avevano fatto inizialmente: se
vuoi scrivere in ASM prenditi un bell'assembler free (ce ne sono parecchi
che generano anche direttamente dei .com) e con il tuo editor invece di
metterti a scrivere:
XPYP[*'CC
o
58 50 59 50 5B 2A 27 43 43
scrivi direttamente:
POP     AX
PUSH    AX
POP     CX
PUSH    AX
POP     BX
SUB     AH,[BX]
INC     BX
INC     BX
Che mi sembra molto piu' comprensibile.
Se poi non trovi un assembler che fa al caso tuo puoi usare il vecchio e
caro DEBUG che trovi in tutte le evoluzioni del DOS (incluso WinXP)
.RD.

> a disposizione.Ogni programma a bisogno di un ret o int 21h
Cioe' "ha" bisogno, scusate!

 Cioe' "ha" bisogno, scusate!
"Quando l'Agnello sciolse il primo dei sette sigilli, vidi
e udii il primo dei quattro esseri viventi che gridava come
con voce di tuono: "Vieni". ^2 Ed ecco mi apparve la grande
Rete estesa su tutta la terra, e in tutte le mail era scritta
la a senz'acca"
Nuovo Testamento, Giovanni, Apocalisse 6:1
:-)