programmare in binario

[BlackCode]

non si vede il sorgente, ma il debug.

Cmq basta che provate da soli comparando source a debug

 

[imported_BlackLight]

si ma il più tipo gui e molte dll o servizi sono in c c++ no?

Non è affatto detto...tutto il codice C/C++ viene assemblato, ovvero tradotto in Assembly, e poi masticato da un normale linker a cui non frega nulla del linguaggio in cui è stato scritto in origine il codice. Ciò vuol dire che ovviamente tutto ciò che è richiamabile in C/C++ lo è anche in Assembly. Esempio, una cosa del genere in Assembly è perfettamente ammissibile:

msg:  .string  "Ciao by BlackLight\n"

push   $msg
call   printf@plt
addl   $4,%esp

xorl   %edx,%edx
push   %edx
call   exit@plt
addl   $4,%esp

leave
ret

Ovviamente se prendi quel "sorgente" e lo incolli nel compilatore non andrà.

Questa frase è perfettamente sensata...un codice non è fatto di solo code segment, ovvero solo segmento di codice. È fatto anche di segmento dati, eventuale segmento di stack ecc., e tutte queste sezioni nel file eseguibile sono situate in precise posizioni stabilite dagli header stessi dell'eseguibile. Se prendo solo il codice e lo incollo da qualche parte, ignorando data segment e stack segment, mi ritroverò con delle call, delle jmp o delle mov in/dalla memoria che non portano da nessuna parte, e il codice non andrà.

 

[The Massakretor]

differenza tra windows e distro linux? ha detto preddy che windows è fatto con un insieme di linguaggi e unix è un sistema operativo...

 

[imported_BlackLight]

ha detto preddy che windows è fatto con un insieme di linguaggi e unix è un sistema operativo...

Uhm sicuro che preddy ha detto questo? Ora non mi va di andare indietro a cercare il messaggio, ma come frase questa non sta né in cielo né in terra...sono entrambi sistemi operativi, che consistono in un kernel che gestisce l'interfaccia fra l'hardware sottostante e l'utente che è a un livello di astrazione superiore, e intorno al kernel (scritto in C e Assembly, c'è poco da fare) ci sono tutti i vari applicativi e servizi di sistema.

 

[The Massakretor]

windows è un insieme di linguaggi, le cose più a basso livello sono scritte in assembly.
mmm unix è un sistema operativo non un linguaggio.
...

ecco volevo sapere proprio ciò che hai detto black... kernel, scritto in C e assembly..

forse mi sono espresso male " in che linguaggio è fatto windows? assembly? unix? " dovevo scrivere: e unix?

 

[Predator]

la punteggiatura è importante
cmq stessa cosa per unix

 

[Sc0rp10n]

scusate se riprendo questo vecchio post ma a questo punto mi sfugge qualcosa... ma allora è totalmente inutile saper usare il binario?? cioè a parte sapere cos'è e sapere al massimo tradurlo... non possiamo utilizzarlo per niente??? che ne so integrarlo in qualche codice o bo... o è solo una perdita di tempo e di spazio?

 

[Mr_x]

scusate se riprendo questo vecchio post ma a questo punto mi sfugge qualcosa... ma allora è totalmente inutile saper usare il binario?? cioè a parte sapere cos'è e sapere al massimo tradurlo... non possiamo utilizzarlo per niente??? che ne so integrarlo in qualche codice o bo... o è solo una perdita di tempo e di spazio?

per esempio nella guida:
http://www.infernet-x.com/introduzione-alla-steganografia-t-10791.html

c'è un esempio su come il codice binario venga usato per nascondere delle informazioni!!!!

poi sicuramente si potrà usare per fare 1000 altre cose di cui il purtroppo non sono al corrente ma comunque sia allargare le proprie conoscenze più solo fare bene

 

[imported_BlackLight]

Oddio che domande......
Programmare in binario così come si programmerebbe in C o Perl è inutile, e per un semplice motivo. L'Assembly già di suo rappresenta un'interfacciamento diretto con il binario, in quanto ogni statement del linguaggio viene direttamente tradotto dall'assemblatore nel corrispondente opcode binario. Esiste quindi una corrispondenza praticamente 1 a 1 fra l'Assembly e il binario, in quanto un

int 21h

ad esempio viene automaticamente interpretato dall'assemblatore come

CD 21  [in esadecimale]

Ora, si fa prima a sapere come usare un interrupt in Assembly, o uno spostamento di dati registro->memoria e viceversa, o un salto condizionato, oppure perdere tempo per impararsi a memoria tutti e 255 (si, sono 255) gli opcode binari previsti da un processore Intel con relative varianti, e magari anche tutti gli opcode usati per identificare i registri? Sapendo che appena si cambia processore gli opcode che si è con fatica imparato a memoria non saranno più validi, mentre invece la struttura di un linguaggio Assembly rimane grosso modo quella? Se proprio volete del codice binario associato ad un vostro frammento di codice, scrivete quel pezzo di codice in Assembly, date l'eseguibile in pasto a un debugger o ad un objdump ed avrete, statement per statement Assembly, i corrispondenti opcode binari. È l'approccio che uso sempre io per tirar fuori degli shellcode binari a partire da righe di codice che ho scritto. C'è già la macchina a fare queste cose, per questo reputo che impararsi a memoria tutti gli opcode del linguaggio macchina (che poi sono sempre specifici per l'architettura della CPU che si usa, o meglio per la sua ISA) è solo una perdita di tempo che non accresce sicuramente il proprio bagagliaio di conoscenze informatiche..

 

[fojeaf]

oltre al fatto che è umanamente impossibile, in quanto sbagliare la posizione di un 1 darebbe un risultato molto diverso, mentre normalmente si usano simboli e parole che il cervello umano può memorizzare....

 

[imported_BlackLight]

Mah a parte che di editor che ti consentono di programmare in binario bit per bit nemmeno esistono, dato che la quantità minima di informazione trasferibile è il byte non il bit...casomai se proprio si vuol fare i masochisti si può scrivere gli opcode in esadecimale, in binario non ha senso...

 

[DGXstyle]

Anche per questo mi piacerebbe imparare l'Assembly, ma se non lo studio su un libro proprio non ci riesco...