L'impedenza è la versione "dinamica" ossia applicata a segnali variabili nel tempo, della "resistenza" che si trova nella legge di Ohm.

In questa viene definita come Resistenza (Ohm) il rapporto tra tensione (V, Volt) e corrente (I, Ampere) >>> R=V/I

In pratica la tensione è quella che viene chiamata una Differenza Di Potenziale (ddp) e la corrente è l'elemento che tende ad azzerare questa differenza. La resistenza è quello che si oppone all'azzeramento..

Un esempio che faccio sempre è: il lago di montagna, rispetto alla valle ha una sua energia potenziale.
Se si apre il lago, l'acqua scorre a valle fino a svuotare il lago.
Le dimensioni dell'apertura sono la resistenza, ossia quello che limita lo svuotamento immediato..

La versione dinamica ossia con tensioni e correnti alternate, si chiama appunto Impedenza ed è la somma (vettoriale...) di più componenti "resistive" caratteristiche di alcuni componenti.

Le bobine ed i condensatori ad esempio hanno delle caratteristiche particolari differenti da una resistenza "semplice" e il loro valore "resistivo" ha sia un nome particolare che un utilizzo specifico.
Entrambi variano al variare della frequenza ma in maniera praticamente opposta..
>Le bobine alle basse frequenze sono dei cortocircuiti ma non alle alte in cui aumenta la loro "reattanza induttiva".
>I condensatori alle basse frequenze sono dei circuiti aperti ma alle alte tendono a ridurre il loro valore di "reattanza capacitiva"

Si fa presto a capire che un pickup da chitarra è una bobina ma che al suo interno tra spira e spira si formano delle capacità parassite ed il tutto è come fosse un circuito composto da resistenza-condensatore-induttanza (bobina) e quindi una sua caratteristica sarà "l'impedenza".

Poichè questa varia al variare della frequenza, di solito si indica un valore di riferimento che generalmente nell'audio è 1000Hz..
Quidni quando vedete "impedenza 8 ohm", vuol dire che è il valore a 1KHz ma che può essere ben diverso ad esempio a 5KHz..

L'adattamento di impedenza di solito si basa sulla relazione tra l'impedenza di uscita del circuito "fonte" e quella di ingresso del "ricevitore".
Generalmente dovrebbero essere in rapporto 1:2 - 1:4 o più..
Un microfono dinamico, generalmente 150ohm viene accoppiato ad almeno 600ohm se non più alto..

Ad esempio il discorso degli ingressi Hi-Z si basa sul fatto che i pickup non hanno mai impedenze basse ed anzi hanno grosse variazioni nello spettro audio (anche rapporti 1:10) per cui il "ricevitore" ideale dovrebbe avere impedenza molto più elevata del massimo valore.

Il termine HiZ intende valori superiori ai 500Kohm (di solito)...


Con Circuit Bending si indica l'arte di modificare in maniera creativa, attraverso semplici cortocircuiti, apparecchi elettronici a bassa tensione o strumenti elettronici alimentati a pile, come giocattoli (il più famoso tra questi è lo Speak & Spell della Texas Instruments, commercializzato in Italia come Grillo Parlante dalla Clementoni), tastiere, batterie elettroniche e effetti per chitarra, allo scopo di generare suoni inediti e curiosi, creare nuovi strumenti musicali e generici generatori di suono.

Generalmente il Circuit Bending viene associato alla musica elettronica sperimentale, al noise e a musicisti alla ricerca di nuovi suoni e di nuove strumentazioni "aleatorie". I suoni generati da tali apparecchiature sono, infatti, per lo più casuali, caotici o comunque non canonicamente collegabili all'idea di suono emesso da uno strumento musicale.

























Articolo Punto Informatico









2 Timer 555
1 Condesatore ceramico 0.1 uF
1 Condesatore ceramico 0.01 uF
1 Condesantore elettrolitico 100 uF
1 Resistenza 1K Ohm


Il chip CD4093 è composto da quattro porte NAND identiche. Ci sono due porte su ciascun lato del chip, ma a differenza del 74C14, sono disposte in modo simmetrico, specularmente : l'uscita di ciascuna porta fronteggia l'uscita della successiva, piuttosto che essere nella stessa direzione.

Ho giocato con le fotoresistenze, una tra l'uscita e l'ingresso verso il condensatore e la massa della prima porta NAND va a modulare il Gate della seconda porta NAND da cui viene perlevata l'uscita audio; poi ho fatto un po di cambiamenti a caso per arrivare a effetti audio particolari modulando le fotoresistenze con delle luci intermittenti;











L'interferenza dei fili sul sensore ad ultrasuoni ha prodotto questa melodia impazzita di suoni, dovuta alla presenza dei fili e al mio corpo che si avvicinava e allontanava dal sensore;

I sensori ad ultrasuoni non forniscono direttamente la misura della distanza dell’oggetto più vicino, ma misurano il tempo impiegato da un segnale sonoro a raggiungere l’oggetto e ritornare al sensore. L’impulso ad ultrasuoni inviato dal HC-SR04 è di circa 40KHz il tempo viene misurato in microsecondi, la tensione di funzionamento è di 5V

Il sensore HC-SR04 dispone di 4 pin: Vcc (+5V), Trigger, Echo, GND. Si invia un impulso alto sul pin Trigger per almeno 10 microsecondi, a questo punto il sensore invierà il ping sonoro e aspetterà il ritorno delle onde riflesse, il sensore risponderà sul pin Echo con un impulso alto della durata corrispondente a quella di viaggio delle onde sonore, dopo 38 millisecondi si considera che non sia stato incontrato alcun ostacolo. Per sicurezza si aspettano in genere 50-60 millisec per far si che non vi siano interferenze con la misura successiva.

Progetto originale : link

Hardware

330Ω Resistor
470Ω Resistor
Solderless Breadboard
Ultrasonic Distance Sensor
3 x Male to Male Jumper Leads
4 x Male to Female Jumper Leads

Software

sudo apt update && sudo apt upgrade -y
sudo pip3 install python-osc

Python :

from gpiozero import DistanceSensor
from time import sleep

from pythonosc import osc_message_builder
from pythonosc import udp_client

sensor = DistanceSensor(echo=17, trigger=4)
sender = udp_client.SimpleUDPClient('127.0.0.1', 4559)

while True:
        pitch = round(sensor.distance * 100 + 30)
        sender.send_message('/play_this', pitch)
        sleep(0.1)


------

Sonic Pi :


live_loop :listen do
       message = sync "/play_this"
       note = message[:args][0]
       play note
end

























Il CD4049 Hex Inverter.
Il resistore di ingresso, RI, generalmente di 10kOhm.
Il resistore di retroazione, RF, generalmente più grande di RI.
Il condensatore di ingresso, CI, generalmente intorno a 0.1uf.
Il condensatore di uscita, CO, generalmente intorno a 10uf.

Il guadagno, ovvero quanto il circuito amplifica il segnale in ingresso, è determinato dal rapporto RF/RI. Quindi, se RF = 100kOhms e RI = 10kOhms, il guadagno è di 10, il che significa che qualsiasi segnale in input al circuito viene amplificato di 10 volte. Se RF = 10mOhms e RI = 10kOhms il guadagno è di 1000, il che rende il segnale MOLTO più forte. Sostituendo i resistori fissi con un potenziometro (tipo da 1 megOhm) possiamo variare il guadagno del circuito. Per un tipico preamplificatore (come quello che si potrebbe usare per un microfono) si potrebbe desiderare di collegare una resistenza da 10k in serie al potenziometro da 1 megOhm: ciò consente di regolare l'amplificazione in modo fluido dal guadagno unitario (segnale in uscita uguale al segnale in ingresso) a un guadagno di 100 (output = 100 volte l'ingresso).

I condensatori all'ingresso e all'uscita (CI e CO) bloccano le tensioni continue presente nel circuito.  Sono necessari per la stabilità del circuito, e di solito non influenzano molto il suono.




















Inserisci un chiodo o una graffetta in un limone. Poi un pezzo di filo di rame. Assicurati che il filo e il chiodo siano vicini, ma che si non tocchino. Il chiodo è diventato l'elettrodo negativo della batteria e il filo di rame l'elettrodo positivo. Il succo di limone, che è acido, agisce come l'elettrolita. È possibile utilizzare altre cose oltre alla graffetta, al chiodo e al filo di rame, purché costituite da metalli diversi. La batteria al limone fornirà circa un quarto a un terzo di un Volt. Per utilizzare una batteria al limone per alimentare un piccolo dispositivo elettrico, come un LED, è necessario collegarne diverse in serie;



















al posto del Fotoresistore nel simulatore ho messo uno Switch, quando è buio la resistenza è altissima, il valore del Fotoresistore in assenza di luce tende a pochi Ohm, ed è come se lo Switch fosse aperto e quindi il LED si accende; quando invece è giorno, la resistenza è praticamente nulla ed è come se lo Switch fosse chiuso; quando lo Switch è chiuso la base del BJT è a 0 Volt quindi il Transistor è interdetto; quando è aperto la base di trova a circa 0.7 Volt e quindi il Transistor conduce;




Nel multivibratore astabile nessuno dei due stati è stabile ed il circuito passa continuamente da uno stato all'altro. Il circuito si comporta pertanto come un particolare oscillatore a rilassamento, in grado di produrre onde quadre.

Si supponga che nel circuito in figura inizialmente il transistor T1 conduca. La tensione sul collettore è praticamente zero e si ha la carica di C1 attraverso R2. Quando il potenziale nel punto tra C1, R2 e la base di T2 raggiunge 0,6V, T2 entra in conduzione, portando il potenziale sul suo collettore a zero. C2 inizia a caricarsi provocando l'interdizione di T1 e C1 si scarica. Nel nuovo stato C2 si carica attraverso R3 fino a che la tensione raggiunge 0,6V, al che T1 ritorna a condurre, caricando C1 e provocando l'interdizione di T2. C2 si scarica. Il ciclo si ripete indefinitamente, con un periodo determinato dai valori delle resistenze e dei condensatori. Se i valori di R2/C1 e R3/C2 non sono simmetrici, è possibile variare il duty cycle del segnale.

Esempio Componenti: 2 R da 470 ohm
2 R da 47K
2 C da 22uF
2 T tipo 2n3904
2 Led






















quando l'uscita è 0 il condensatore si scarica attraverso la resistenza, l'input diventa 0 e l'Inverter genera 1 sull' uscita, e l'1 va a caricare il condensatore attraverso la resistenza che quindi porta a 1 l'ingresso e si ripete l'oscillazione;

if a binary “1,” represented by 9 volts, is applied to the input, then a “0” (0 volts) is sent to the output. Th at 0 fl ows through the resistor back to the input. When the 0 appears at the input the output goes to 1, which fl ows back to the input and the whole process begins again, causing the circuit to fl ip back and forth between two states, generating a square wave. Th e speed of the fl ip-fl opping (the pitch we hear) depends on the values of the resistor and capacitor—just like in our earlier clock experiments, the smaller the values the higher the pitch. It’s like the Monty Python argument sketch, or a dispute in a bar: I disagree with everything you say, so our output keeps fl ipping between yes and no according to how fast each of us can reply. Th e resistor and capacitor act like booze—the more you add the slower the argument goes, ergo the lower the pitch. Having brushed you off earlier, I will now confi de that the Schmitt Trigger part of the Inverter prevents indecisiveness in the argument: the inverter snaps completely from one state to the other, from 0 to 1 and back, and never vacillates in between.


Il connettore jack, noto anche come spinotto jack o semplicemente jack, è un connettore elettrico usato per trasportare segnali (per lo più audio in forma analogica) in bassissima tensione. È stato inventato nel XIX secolo (1878) per l'uso in centralini telefonici, ed è uno degli standard più vecchi di connettore elettrico ancora in uso





TS mono (Tip, Sleeve = punta e manicotto): per il collegamento audio sbilanciato mono si usano prese, cavi e spine con collegamento TS. Il cablaggio TS è il seguente :

Punta del connettore (Tip): terminale per il canale mono.
Manicotto del connettore (Sleeve): massa.

Diametri standard:
6,3 mm (1/4 di pollice);
3,5 mm (1/8 di pollice);
2,5 mm (3/32 di pollice).

TRS stereo (Tip, Ring, Sleeve = punta, anello e manicotto): per il collegamento audio stereo sbilanciato o bilanciato si usano prese, cavi e spine con collegamento TRS. Il cablaggio del connettore TRS è il seguente :

Punta del connettore (Tip): terminale per il canale sinistro.
Anello del connettore (Ring): terminale per il canale destro.
Manica del connettore (Sleeve): massa.

Diametri standard:
6,3 mm (1/4 di pollice);
3,5 mm (1/8 di pollice);
2,5 mm (3/32 di pollice);










Le Regole dell'Hacking
(tratte dal libro Handmade Electronic Music. The Art of Hardware Hacking)

Regola 1: non avere paura!
Regola 2: non smontare niente che sia collegato direttamente alla presa sul muro.
Regola 3: è più facile smontare qualcosa che rimontarla.
Regola 4: prendi nota di ciò che stai facendo mentre vai avanti, non dopo.
Regola 6: molti hack sono come farfalle: belle ma di breve durata.
Regola 7: In generale cerca di evitare i cortocircuiti.
Regola 8: Nell'elettronica alcune cose sono reversibili con risultati interessanti, ma altre sono reversibili solo con risultati irreversibili.
Regola 9: utilizza un cavo schermato per tutte le connessioni audio più lunghe di 20 cm, a meno passino per un amplificatore e un altoparlante.
Regola 10: ogni connessione audio è composta da due parti: il segnale e un riferimento a terra.
Regola 11: non saldare quando hai bevuto.
Regola 12: dopo un arresto anomalo di un circuito compromesso potrebbe essere necessario disconnettere e riconnettere le batterie prima che il circuito funzioni di nuovo.
Regola 13: il valore netto di due resistori collegati in parallelo è leggermente inferiore al valore più piccolo dei due resistori; il valore netto di due resistori collegati in serie è la somma dei due resistori.
Regola 14: stai lontano dalla corrente alternata.
Regola 15: è sempre possibile sostituire una batteria da 1,5 V più grande con una più piccola, basta essere sicuri di utilizzare lo stesso numero di batterie, nella stessa configurazione.
Regola 16: è sempre più sicuro usare batterie separate per circuiti separati.
Regola 17: Se suona bene e non fuma, va bene cosi e non ti preoccupare se non capisci cosa hai fatto.
Regola 18: inizia con cose semplici e verifica che il circuito funzioni ancora dopo ogni tua modifica.
Regola 19: lascia sempre intatto e funzionante il tuo progetto sulla breadboard fino a quando la versione saldata funziona.
Regola 20: tutti i chip possono apparire simili all'esterno senza essere uguali all'interno, leggi la documentazione relativa.
Regola 21: tutti i chip aspettano connessioni positive e negative alla giusta potenza; se queste tensioni sono collegate ad altri pin per altre ragioni, mantenetele collegate a vostro rischio o intrattenimento.
Regola 22: utilizzare sempre un resistore quando si accende un LED, altrimenti il ​​circuito e/o Il LED potrebbero bruciarsi.
Regola 23: la distorsione è la verità.
Regola 24: è più facile praticare fori tondi che slot rettangolari.
Regola 25: Non fidarti mai di quello che è scritto sui trasformatori.



























#include <IRremote.h>

#define POWER         0xE0E040BF
#define UNO           0xE0E0906F
#define TVKEY         0xE0E0D827
#define ZERO          0xE0E08877  
#define CHPIU         0xE0E048B7
#define CHMENO        0xE0E008F7
#define SAMSUNG_BITS  32

IRsend irsend;

void setup()
{
  pinMode (3, OUTPUT);  //output as used in library
}

void loop() {
  

irsend.sendSAMSUNG(REPEAT, 32); // Some receivers seem to respond a lot faster when a repeat is sent before the actual command.
delay(35); //This delay is needed for optimal response.
irsend.sendSAMSUNG(ZERO, 32); // hex value, 32 bits
delayMicroseconds(50);

}

 
http://lirc.sourceforge.net/remotes/samsung/BN59-00940A 








1 CMOS Hex Schmitt Trigger CD40106BE;
3 fotoresistori;
3 Condensatori 1 uF;
3 diodi 1N914;




1 CMOS Hex Schmitt Trigger CD40106BE
1 fotoresistore
1 Condensatore 1 uF

Schmitt Trigger Oscillator
Spiegazione
Talking Electronics

NFC


NFC Reader
NFC Tools

https://arxiv.org/pdf/1705.02081.pdf

Lack of security protection of communication. Most NFC communications do not include encryption mechanisms during its data exchange, it relies on the short range (i.e., less than 4 cm) to guarantee absence of eavesdropping attacks. However, the attacker can still place the device (i.e., NFC tag or NFC reader/writer) between client and NFC provider (i.e., NFC contactless point-of-sale) to trigger a specific attack such as eavesdrop, URL/URI spoofing. This vulnerability can also be exploited to jam the data exchange between two parties by sending out specific packet at the right timing, which can lead to a deny-of-service (DoS) attack toward the NFC- service provider.

URL/URI spoofing. The authors show that spoofing attacks can be performed to trick the user to see the false information as a valid one. In example, the attacker will design an exactly copy of a user’s trusted website with an almost equal URL so the user does not see the difference if she is not cautious. In addition, to uniform resource identifier (URI) and uniform/universal resource locater (URL) spoofing the research shows that phone call and text-message spoofing using the NFC protocol are also applicable. Furthermore, URI and URL spoofing are specially useful in combination with other attacks (i.e., cross-site request forgery).

Lack of authentication mechanism of NFC device. When the NFC reader reads information from another NFC-enabled device, there is not any authentication mechanisms available. Therefore, there is a potential risk of tag replacement and tag hiding (TRTH) attack. In the TRTH scenario, the NFC tags are overwritten by an attacker with malicious information or the physical tag is replace with another tag prepared by the attacker.

Automatic and non-user intervention URL/URI connection. The proposed attack takes advantage of the non-user inter- vention when the device detects another NFC device in its proximity. The malicious NFC provides an URL/URI to attack the user’s device, as the Android system does not request any user intervention, the device will automatically open the provided link by either other smartphone or NFC-tag. This situation opens security and privacy threads for the device’s owner. Once, the device opens the link, it can be attacked by fingerprinting mechanisms or share the user’s location for example (see more details in Section IV. The URI can also open application services such as contacts to automatically add malicious contacts without user permission request.

The attack can be achieved placing NFC-tags that unlocked Android devices will read in several locations: (1) public transport: in areas where the public transport uses NFC reader we can track user’s movement from one station to another, collect the user’s routine information (i.e., when the user goes to work and back home, where does he work); (2) coffee shop, poster at shopping mall : placing NFC-tags under coffee tables or in locations where users tend to leave the device unlocked, we can collect not only device’s information but also the geo-location as we know where the tag is located. For both situations, we can also collect the mentioned social network profiles or leverage more complex attacks in combination with other documented browser vulnerabilities.
the term “hacker” has evolved quite dramatically over the years as the public’s awareness of technology has increased and as a sensationalist mass media continues to color the public’s opinion of hackers. In the beginning, a hacker was someone who worked passionately for the sake of curiosity and exploration. There were hardware hackers who took it upon themselves to remove the covers from computers to optimize their design (early computers were built out of discrete components, so they could be modified in meaningful ways with simple tools), and there were software hackers who labored to make the most compact and elegant code, since computational resources were scarce and slow. There were hackers who explored the ins and outs of the phone system, and those who explored the roofs and tunnels of buildings of university campuses. Quite often, early hackers engaged in all of these activities. Hackers would share their findings or results (hacks) with each other freely, as their rewards were not financial, but came from satisfying their intellectual curiosity and from the enthusiasm of their peers. As a result, hackers tended to form into meritocratic groups where member- ship and advancement were based entirely upon a person’s ability to hack.

As technology evolved and computers became faster and more inte- grated, hackers found that the effort involved in hardware hacking was not worth the benefits. The interesting pieces of computers were quickly becoming buried deep within hermetically sealed ceramic packages, etched into silicon structures that were difficult to see even with a good microscope. A difficult hardware hack that might double the perfor- mance of a computer was made moot within months by Moore’s Law. On the other hand, software hacking was beginning to focus more on applications and less on algorithms or optimization. The compactness or elegance of a program was no longer directly important as memory and processor power became cheap and plentiful. Besides, compiler technol- ogy had also improved to the point where compiled code ran almost as fast as hand assembly. By the late 80’s, the term “hacker” had grown to imply someone who could write volumes of C code in their sleep and create brilliant applications overnight. The old hardware hackers were either converting to software hackers, or retreating to university labs and corporations that could afford to support their expensive hobbies.

The term “hacker” at that time was increasingly associated with people who cracked passwords and programs to gain access to machines and software that was otherwise off limits. Hollywood was partly responsible for this stereotype, with a slew of movies that portrayed teenagers bringing the world to the brink of nuclear annihilation with a few keystrokes, or closet geniuses creating artificially intelligent cyber- monsters in their basement. 4 Unfortunately, the hyberbole of these movie plots was lost on the general public, and this dark impression of hackers eventually became a dominant part of the hacker stereotype. The inaccuracy of this stereotype contributed to the creation of a term for hackers that focuses primarily upon cracking systems and programs “crackers.”

Linux-RE-101 documenti sul mondo del Reverse Engineering di Linux; RE 101

linux-re-101
============

Work in progress as I am actively collecting these.

#### Keep these handy

- Describes how all syscalls for all architectures work (what registers are for input, output, error, ..) http://man7.org/linux/man-pages/man2/syscall.2.html
- "Executable and Linkable Format (ELF)" http://www.skyfree.org/linux/references/ELF_Format.pdf or http://www.muppetlabs.com/~breadbox/software/ELF.txt (I like .txt more)
- "Linux Cross Reference" http://lxr.free-electrons.com/
- "Syscall table reference" https://w3challs.com/syscalls/
- "System V ABI x86-64 Linux" https://web-beta.archive.org/web/20160801075139/http://www.x86-64.org/documentation/abi.pdf
- "MIPS documentation" http://www.linux-mips.org/pub/linux/mips/doc/ABI/
- "ELF for the ARM" http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044e/IHI0044E_aaelf.pdf
- "ELF for the ARM64" http://infocenter.arm.com/help/topic/com.arm.doc.ihi0056b/IHI0056B_aaelf64.pdf
- "How to write shared libraries" by Ulrich Drepper http://www.akkadia.org/drepper/dsohowto.pdf  

#### Must read

- "The 101 of ELF Binaries on Linux: Understanding and Analysis" https://linux-audit.com/elf-binaries-on-linux-understanding-and-analysis/
- ELF101 from Corkami (Ange Albertini) http://imgur.com/a/JEObT
- "How programs get run: ELF binaries" https://lwn.net/Articles/631631/
- "How statically linked programs run on Linux" http://eli.thegreenplace.net/2012/08/13/how-statically-linked-programs-run-on-linux
- "A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux" http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html
- "The Definitive Guide to Linux System Calls" https://blog.packagecloud.io/eng/2016/04/05/the-definitive-guide-to-linux-system-calls/
- "LINUX ANTI-DEBUGGING TECHNIQUES (FOOLING THE DEBUGGER)" http://www.ouah.org/linux-anti-debugging.txt
- "UNIX ELF PARASITES AND VIRUS" http://ouah.org/elf-pv.txt
- "Linux on the Half-ELF" http://mammon.github.io/tales/linux_re.txt
- "Learning Linux Binary Analysis" by Ryan O'Neill
- https://www.cs.stevens.edu/~jschauma/631/elf.html
- "LD_NOT_PRELOADED_FOR_REAL" http://haxelion.eu/article/LD_NOT_PRELOADED_FOR_REAL/

#### 101

- *Optional*: "Guide to x86 assembly" http://www.cs.virginia.edu/~evans/cs216/guides/x86.html
- *Optional*: "Assembly x86_64 programming for Linux" http://0xax.blogspot.sk/p/assembly-x8664-programming-for-linux.html
- *Optional*: x64 assembly http://rayseyfarth.com/asm/pdf/index.html
- *Optional*: "Step by step to MIPS assembly" http://winfred-lu.blogspot.sk/2010/06/step-by-step-to-mips-assembly.html
- *Optional*: FreeBSD Assembly Language Programming http://www.int80h.org/bsdasm/
- *Optional*: "Linux MIPS ELF reverse engineering tips" https://www.cr0.org/paper/mips.elf.external.resolution.txt
- "The dissection of a simple hello world ELF file" https://github.com/mewrev/dissection and "ELF101" http://imgur.com/a/JEObT
- https://www.cs.stevens.edu/~jschauma/631/elf.html
- "The 101 of ELF Binaries on Linux: Understanding and Analysis" http://linux-audit.com/elf-binaries-on-linux-understanding-and-analysis/
- "A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux" http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html
- "The definitive guide to linux system calls" http://blog.packagecloud.io/eng/2016/04/05/the-definitive-guide-to-linux-system-calls/
- "Anatomy of a system call, part 1" http://lwn.net/Articles/604287/
- "Anatomy of a system call, part 2" http://lwn.net/SubscriberLink/604515
- "About ELF auxiliary vectors" http://articles.manugarg.com/aboutelfauxiliaryvectors.html
- "How programs get run: ELF binaries" https://lwn.net/Articles/631631/
- "Linux x86 Program Start Up" http://dbp-consulting.com/tutorials/debugging/linuxProgramStartup.html
- "How statically linked programs run on Linux" http://eli.thegreenplace.net/2012/08/13/how-statically-linked-programs-run-on-linux
- "Startup state of a Linux/i386 ELF binary" http://asm.sourceforge.net/articles/startup.html and http://dbp-consulting.com/tutorials/debugging/linuxProgramStartup.html
- "Stack frame layout on x86-64" http://eli.thegreenplace.net/2011/09/06/stack-frame-layout-on-x86-64
- "What is linux-gate.so.1?" http://www.trilithium.com/johan/2005/08/linux-gate/
- "Understanding ld-linux.so.2 " http://www.cs.virginia.edu/~dww4s/articles/ld_linux.html
- "Linux process states" https://idea.popcount.org/2012-12-11-linux-process-states/

#### 201

- *Optional*: "Linkers - 20 parts" http://www.airs.com/blog/page/4?s=linkers
- "Static linking (x86) internals" http://sploitfun.blogspot.sk/2013/02/linking-with-static-library-internals.html
- "Static linking (x86_64) internals" http://sploitfun.blogspot.sk/2013/07/static-linking-x8664-internals.html
- "Dynamic linking and x86_64 internals" http://sploitfun.blogspot.sk/2013/07/dynamic-linking-x8664-internals.html
- "Dynamic linking (x86) internals" http://sploitfun.blogspot.sk/2013/06/dynamic-linking-internals.html
- "PLT and GOT - they key to code sharing and dynamic libraries" https://www.technovelty.org//linux/plt-and-got-the-key-to-code-sharing-and-dynamic-libraries.html
- "Understanding x64 code models" http://eli.thegreenplace.net/2012/01/03/understanding-the-x64-code-models/
- "Load-time relocation of shared libraries " http://eli.thegreenplace.net/2011/08/25/load-time-relocation-of-shared-libraries
- "Position Independent Code (PIC) in shared libraries " http://eli.thegreenplace.net/2011/11/03/position-independent-code-pic-in-shared-libraries/
- "Position Independent Code (PIC) in shared libraries x64" http://eli.thegreenplace.net/2011/11/11/position-independent-code-pic-in-shared-libraries-on-x64/
- "Relocations, relocations" http://www.mindfruit.co.uk/2012/06/relocations-relocations.html
- *Good night reading*: "Linux on the Half-ELF" http://mammon.github.io/tales/linux_re.txt

#### Packers, obfuscation, and encryption

- "Runtime binary encryption" http://phrack.org/issues/58/5.html
- "Next-Gen Runtime Binary Encryption" http://phrack.org/issues/63/13.html
- "Binary Protection Schemes" http://indra.linuxstudy.pe.kr/study/Binary%20Protection%20Schemes.pdf
- "Shiva - Advances in ELF Binary Encryption" https://www.blackhat.com/presentations/bh-usa-03/bh-us-03-mehta/bh-us-03-mehta.pdf
- "Burneye protector" http://packetstormsecurity.com/files/30648/burneye-1.0.1-src.tar.bz2.html
- "ELF Encrypter" http://elf-encrypter.sourceforge.net/
- "midgetpack is a multiplatform secure ELF packer" https://github.com/arisada/midgetpack
- "ELF Binary Code Injection, Loader/'Decrypter'" http://www.pinkstyle.org/elfcrypt.html

#### Exploitation

- "Linux x86 Reverse Engineering - Shellcode Disassembling and XOR decryption" https://www.exploit-db.com/docs/33429.pdf
- "Shellcoding in Linux" https://www.exploit-db.com/docs/21013.pdf
- "Linux (x86) Exploit Development Series" https://sploitfun.wordpress.com/2015/06/26/linux-x86-exploit-development-tutorial-series/
- "Linux 64-bit Return Oriented Programming" https://crypto.stanford.edu/~blynn/rop/
- "Introduction to Return Oriented Programming (ROP)" https://ketansingh.net/Introduction-to-Return-Oriented-Programming-ROP/
- "Linux x64 Infection for Lamers (by a Lamer)" http://vxheaven.org/lib/vjp01.html
- "Linux Kernel ROP - Ropping your way to # (Part 1) "https://www.trustwave.com/Resources/SpiderLabs-Blog/Linux-Kernel-ROP---Ropping-your-way-to---(Part-1)/
- "Linux Kernel ROP - Ropping your way to # (Part 2)" https://www.trustwave.com/Resources/SpiderLabs-Blog/Linux-Kernel-ROP---Ropping-your-way-to---(Part-2)/
- "Practice and learning in the world of C RE and exploit analysis" https://github.com/211217613/C-Hacking
- "Modern Binary Exploitation" http://security.cs.rpi.edu/courses/binexp-spring2015/ (not strictly related to Linux)
- "Advanced exploitation on Linux: ROP and infoleaks" https://speakerdeck.com/milkmix/advanced-exploitation-on-linux-rop-and-infoleaks

#### Anti techniques

- "LINUX ANTI-DEBUGGING TECHNIQUES (FOOLING THE DEBUGGER)" http://www.ouah.org/linux-anti-debugging.txt
- "Beginners guide to basic Linux anti anti debugging techniques" http://www.stonedcoder.org/~kd/lib/14-61-1-PB.pdf
- "Kickers of ELF" http://www.muppetlabs.com/~breadbox/software/elfkickers.html
- "ELF header abuse" https://github.com/strazzere/IDAnt-wanna
- "Toolkit to detect/crash/attack GNU debugging-related tools" https://github.com/jvoisin/pangu
- "ELF: dynamic struggles" "http://michalmalik.github.io/elf-dynamic-segment-struggles"
- "ptrace() tutorial" http://mikecvet.wordpress.com/2010/08/14/ptrace-tutorial/
- "ptrace() on 64-bit system" http://theantway.com/2013/01/notes-for-playing-with-ptrace-on-64-bits-ubuntu-12-10/
- "Linux x86 run-time process manipulation" http://hick.org/code/skape/papers/needle.txt
- "Cheating the ELF Subversive Dynamic Linking to Libraries" http://www.ouah.org/subversiveld.pdf
- "LD_NOT_PRELOADED_FOR_REAL" http://haxelion.eu/article/LD_NOT_PRELOADED_FOR_REAL/
- https://github.com/antire-book/dont_panic
- "gdb leaves file descriptors open in debugee" https://silviocesare.wordpress.com/2008/05/13/gdb-leaves-file-descriptors-open-in-debugee/
- "More GDB Anti-Debugging" https://xorl.wordpress.com/2009/01/05/more-gdb-anti-debugging/
- "How to detect virtualization on Linux" http://www.dmo.ca/blog/detecting-virtualization-on-linux/
- "Mechanisms to determine VMWare VM" http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1009458

#### Viruses & infection techniques

- "UNIX VIRUSES" http://ouah.org/unix-viruses.txt
- "UNIX ELF PARASITES AND VIRUS" http://ouah.org/elf-pv.txt
- "Linux viruses - ELF file format" by Marius Van Oers http://www.mcafee.com/us/resources/white-papers/wp-linux-viruses-elf-file-format.pdf
- "Abusing .CTORS and .DTORS for fun 'n profit" http://vxer.org/lib/viz00.html
- "The WIT virus" http://vanilla47.com/PDFs/Viruses In Linux PDFs/The WIT Virus.pdf
- "Caveat virus" http://vxer.org/herm1t/caveat_en.html
- "Reverse of a coin: A short note on segment alignment" http://vxheavens.com/lib/vhe04.html
- "INT 0x80? No, thank you! aka Pilot" http://vxer.org/herm1t/pilot_en.html
- "Infecting ELF-files using function padding for Linux" http://vxer.org/lib/vhe00.html
- "Injected Evil (executable files infection)" http://vxheaven.org/lib/vzo08.html
- "An unofficial analysis of the Retaliation Virus (Authored by JPanic)" http://vxer.org/lib/vrn01.html or http://www.bitlackeys.org/papers/retaliation.txt
- "Skeksi virus" https://github.com/elfmaster/skeksi_virus
- "Modern Day ELF Runtime infection via GOT poisoning" http://vxheaven.org/lib/vrn00.html
- "From position-independent to self-relocatable viral code" http://vxer.org/lib/vhe08.html
- "The Cerberus ELF interface" http://phrack.org/issues/61/8.html#article
- "Malicious Code Injection via /dev/mem" http://www.blackhat.com/presentations/bh-europe-09/Lineberry/BlackHat-Europe-2009-Lineberry-code-injection-via-dev-mem.pdf
- VX Heaven collection of viruses http://vxer.org/vl.php?dir=Virus.Linux
- http://vxer.org/herm1t/
- Source code of infection techniques http://vxer.org/herm1t/examples.tar.gz by herm1t

#### Linux kernel, rootkits, and LKM development

- *Optional*: "A series of posts about the linux kernel and its insides." http://0xax.gitbooks.io/linux-insides/content/index.html
- *Optional*: "Kernel hacking HOWTO" http://kernelnewbies.org/New_Kernel_Hacking_HOWTO
- "Anatomy of the Linux kernel" http://www.ibm.com/developerworks/linux/library/l-linux-kernel/index.html
- "Linux process management" http://www.ibm.com/developerworks/linux/library/l-linux-process-management/index.html
- "Linux processes" http://www.cs.columbia.edu/~junfeng/10sp-w4118/lectures/l07-proc-linux.pdf
- "Kernel hacking" http://info.fs.tum.de/images/2/21/2011-01-19-kernel-hacking.pdf
- "Be a kernel hacker" http://www.linuxvoice.com/be-a-kernel-hacker/?pk_campaign=hn&pk_kwd=3
- "Day 5: I wrote a kernel module" http://jvns.ca/blog/2013/10/07/day-5-i-wrote-a-kernel-module/
- "Linux Rootkits 101" http://turbochaos.blogspot.sk/2013/09/linux-rootkits-101-1-of-3.html
- "Linux Rootkits 201" http://turbochaos.blogspot.sk/2013/10/writing-linux-rootkits-201-23.html
- "Linux Rootkits 301" http://turbochaos.blogspot.sk/2013/10/writing-linux-rootkits-301_31.html
- "Handling Interrupt Descriptor Table for fun and profit" http://www.phrack.org/issues.html?issue=59&id=4
- "Intercepting System Calls and Dispatchers – Linux" https://ruinedsec.wordpress.com/2013/04/04/modifying-system-calls-dispatching-linux/
- "Linux Kernel Rootkits" http://www.la-samhna.de/library/rootkits/index.html
- "Linux Kernel Debugging using KGDB/GDB" http://sploitfun.blogspot.sk/2013/06/linux-kernel-debugging-using-kgdbgdb.html
- "Kernel instrumentation using kprobes" http://phrack.org/issues.html?issue=67&id=6#article
- "Infecting loadable kernel modules versions 2.6.x/3.0.x" http://phrack.org/issues/68/11.html#article
- "(nearly) Complete Linux Loadable Kernel Modules" https://www.thc.org/papers/LKM_HACKING.html
- Check the README for more https://github.com/citypw/citypw-SCFE/tree/master/security/rootkit/hide_file
- "UNIX and Linux based rootkits" http://www.kernelhacking.com/rodrigo/docs/StMichael/BuntenSlides.pdf
- "Sample rootkit for linux" https://github.com/ivyl/rootkit/
- "Writing a LKM rootkit that uses LSM hooks" http://vladz.devzero.fr/015_lsm-backdoor.html
- "TCP/UDP symmetric encryption tunnel wrapper" https://github.com/chokepoint/CryptHook
- "Userland rootkit based off of the original LD_PRELOAD technique from Jynx rootkit" https://github.com/chokepoint/azazel
- "an experimental linux kernel module (rootkit) with a keylogger and built-in IRC bot" https://github.com/bones-codes/the_colonel
- "An LKM rootkit targeting Linux 2.6/3.x on x86(_64), and ARM" https://github.com/mncoppola/suterusu
- "Linux rootkit adapted for 2.6 and 3.x" https://github.com/trimpsyw/adore-ng
- https://github.com/mfontanini/Programs-Scripts/blob/master/rootkit/rootkit.c
- "Linux: Creating an entry in /proc file system (Part 1: The hello_proc pseudo file)" http://pointer-overloading.blogspot.in/2013/09/linux-creating-entry-in-proc-file.html
- Answer to "Ripping out the hidden kernel module by reading kernel memory directly?" http://stackoverflow.com/a/18464599
- "User space memory access from the Linux kernel" http://www.ibm.com/developerworks/library/l-kernel-memory-access/
- "get_user_pages example" http://krishnamohanlinux.blogspot.sk/2015/02/getuserpages-example.html
- "Horse Pill: A New Type Of Linux Rootkit" https://www.blackhat.com/docs/us-16/materials/us-16-Leibowitz-Horse-Pill-A-New-Type-Of-Linux-Rootkit.pdf
- "vlany, Linux (LD_PRELOAD) rootkit" https://github.com/mempodippy/vlany
- "Hacking the wholism of GNU/Linux net*" http://kernelnewbies.org/Networking?action=AttachFile&do=get&target=hacking_the_wholism_of_linux_net.txt
- "Linux Device Drivers" https://lwn.net/Kernel/LDD3/
- "Linux Data Structures" http://tldp.org/LDP/tlk/ds/ds.html
- "Status of the Kernel Self Protection Project" https://outflux.net/slides/2016/lss/kspp.pdf

#### Crackmes and challenges

- "Exercises for learning Reverse Engineering and Exploitation." https://github.com/wapiflapi/exrs
- "IOLI crackme" http://dustri.org/b/files/IOLI-crackme.tar.gz
- http://security.cs.rpi.edu/courses/binexp-spring2015/lectures/2/challenges.zip from "Modern Binary Exploitation"
- "Exercises" section in http://beginners.re/Reverse_Engineering_for_Beginners-en.pdf

#### Analyzes, "hands-on", analysis techniques

- "100 GDB tips" https://github.com/hellogcc/100-gdb-tips/tree/master/src
- "Defeating IOLI with Radare2" http://dustri.org/b/defeating-ioli-with-radare2.html
- "Using radare2 to pwn things" http://radare.today/using-radare2/
- "Pwning With Radare2" http://crowell.github.io/blog/2014/11/23/pwning-with-radare2/
- "At Gunpoint Hacklu 2014 With Radare2" http://crowell.github.io/blog/2014/11/23/at-gunpoint-hacklu-2014-with-radare2/
- "manual binary mangling with radare" http://phrack.org/issues/66/14.html#article
- "Analysis of an unknown binary, for the HoneyNet Reverse Challenge" http://old.honeynet.org/reverse/results/sol/sol-06/analysis.html
- "Reversing GO binaries like a pro" http://rednaga.io/2016/09/21/reversing_go_binaries_like_a_pro/
- "Reversing Golang" https://2016.zeronights.ru/wp-content/uploads/2016/12/GO_Zaytsev.pdf
- "Reversing Linux Malware" https://github.com/radareorg/r2con/blob/master/2016/talks/11-ReversingLinuxMalware/r2con_SergiMartinez_ReversingLinuxMalware.pdf (includes Golang reversing with radare2)
- https://samsymons.com/blog/reverse-engineering-with-radare2-part-1/
- "Reverse Engineering With Radare2 – Part 2" https://insinuator.net/2016/08/reverse-engineering-with-radare2-part-2/
- "Reverse Engineering With Radare2 – Part 3" https://insinuator.net/2016/10/reverse-engineering-with-radare2-part-3/

#### Research and development
- binary samples for testing https://github.com/JonathanSalwan
- "ELF Eccentricities - Julian Bangert, Sergey Bratus" https://www.youtube.com/watch?v=4LU6N6THh2U
- "ELF-Miner: Using structural knowledge and data mining methods to detect new (Linux) malicious executables" http://www.genetic-programming.org/hc2011/05-Farooq/Farooq-Paper.pdf
- "Fuzzing the ELF file format with Melkor" https://www.blackhat.com/docs/us-14/materials/arsenal/us-14-Hernandez-Melkor-Slides.pdf
- http://www.bitlackeys.org (all of it)
- "Effective file format fuzzing" https://www.blackhat.com/docs/eu-16/materials/eu-16-Jurczyk-Effective-File-Format-Fuzzing-Thoughts-Techniques-And-Results.pdf (not related to Linux directly, but it's pretty great)
- "Linux kernel sanitizers and syscall fuzzer" https://www.linuxplumbersconf.org/2016/ocw//system/presentations/3471/original/Sanitizers.pdf
- "ElfParser blog" http://www.blog.elfparser.com/
- "ELF vs. Mach-O" http://timetobleed.com/dynamic-linking-elf-vs-mach-o/
- "ELF vs. Mach-O 2" http://timetobleed.com/dynamic-symbol-table-duel-elf-vs-mach-o-round-2/
- "Where did the fork go?" http://thorstenball.com/blog/2014/06/13/where-did-fork-go/
- "Playing with ptrace, part II" http://www.linuxjournal.com/article/6210
- "Write Yourself an Strace in 70 Lines of Code" https://blog.nelhage.com/2010/08/write-yourself-an-strace-in-70-lines-of-code/
- "Writing a Linux Debugger Part 1: Setup" http://blog.tartanllama.xyz/c++/2017/03/21/writing-a-linux-debugger-setup/
- "Writing a Linux Debugger Part 2: Breakpoints" http://blog.tartanllama.xyz/c++/2017/03/24/writing-a-linux-debugger-breakpoints/
- "Writing a Linux Debugger Part 3: Registers and memory" http://blog.tartanllama.xyz/c++/2017/03/31/writing-a-linux-debugger-registers/
- "Writing a Linux Debugger Part 4: Elves and dwarves" http://blog.tartanllama.xyz/c++/2017/04/05/writing-a-linux-debugger-elf-dwarf/

#### Tools

- "Quickly determine the capabilities of an ELF binary through static analysis" http://elfparser.com/
- "LIEF (Library to Instrument Executable Formats) https://lief.quarkslab.com/"
- "[shmcat] Dumps the contents of a SysV shared memory segment" https://github.com/niklata/shmcat
- "ld-linux code injector" https://github.com/sduverger/ld-shatner
- "Measuring Linux at Runtime" http://www.unixist.com/security/measuring-linux-at-runtime/index.html coupled with https://github.com/unixist/camb
- "Linux Rootkit Scanner" https://github.com/dgoulet/kjackal
- "tool to locally check for signs of a rootkit" http://www.chkrootkit.org/
- "a Unix-based tool that scans for rootkits, backdoors and possible local exploits" http://rkhunter.sourceforge.net/
- "MoVP 1.5 KBeast Rootkit, Detecting Hidden Modules, and sysfs " http://volatility-labs.blogspot.sk/2012/09/movp-15-kbeast-rootkit-detecting-hidden.html
- https://github.com/detuxsandbox/detux

#### Other

- "Building a concrete alternative to IDA - Radare2 to the rescue!" https://recon.cx/2015/slides/recon2015-04-jeffrey-crowell-julien-voisin-Radare2-building-a-new-IDA.pdf
- "Introduction to Reverse Engineering Software in Linux" http://ouah.org/RevEng/
- "Radare2 book" http://radare.gitbooks.io/radare2book/content/
- "Intro to Radare2" http://rada.re/get/condret-r2talk.pdf
- "Radare2 baby steps" http://maijin.fr/slides.pdf
- "Radare A to Z" http://radare.org/get/RadareAZ-NN2015.pdf
- https://github.com/citypw/citypw-SCFE/tree/master/security
- http://mammon.github.io/
- https://code.google.com/p/corkami/downloads/list & https://code.google.com/p/corkami/source/browse/#svn/trunk/wip/elf
- https://github.com/jbangert/mithril
- http://0x90909090.blogspot.fr/2015/07/no-one-expect-command-execution.html
- "Emulating Linux MIPS in Perl" http://schplog.schmorp.de/2015-06-08-emulating-linux-mips-in-perl-1.html
- "Crypto 101" https://www.crypto101.io/
- "REMnux 6" https://zeltser.com/remnux-v6-release-for-malware-analysis/
- https://people.debian.org/~aurel32/qemu/
- "Why is the ELF execution entry point virtual address of the form 0x80xxxxx and not zero 0x0?" http://stackoverflow.com/questions/2187484/why-is-the-elf-execution-entry-point-virtual-address-of-the-form-0x80xxxxx-and-n
- "Why do virtual memory addresses for linux binaries start at 0x8048000?" http://stackoverflow.com/questions/2966426/why-do-virtual-memory-addresses-for-linux-binaries-start-at-0x8048000

#### Books
- "Malware Forensics Field Guide for Linux Systems" by Cameron H. Malin, Eoghan Casey, James M. Aquilina
- "Linux (Bezpečnosť a exploity)" by Miroslav Dobšíček and Radim Ballner
- "Hacking: The Art of Exploitation" by Jon Erickson
- "The Shellcoder's Handbook: Discovering and Exploiting Security Holes" by Chris Anley, John Heasman, Felix Lindner
- "The Linux Programming Interface" by Michael Kerrisk
- "Learning Linux Binary Analysis" by Ryan O'Neill
SECTION  .data
my_str:
    db     'The pool on the roof must have a leak.', 0
SECTION  .text
GLOBAL _start
_start:
    nop
    push byte 'x'      ; second function parameter
    push dword my_str  ; first function parameter
    call black_out     ; call function
    add esp, 8         ; cleaning out the stack
    mov  ebx,0         ; parameter for exit call (return value)
    mov  eax,1         ; exit system call
    int 080h           ; run system call, see page 79 pal

black_out:
    push ebp           ; function prologue, save stack base pointer
    mov ebp, esp       ; point base pointer to ESP  
    ; ------------ start code from book ---------

    mov edi, [ebp+8]  
;  mette in edi l'indirizzo del primo parametro della funzione
   
    mov edx, edi        
; backup dell'indirizzo
   
    xor eax, eax          
; azzera eax
   
   or ecx, 0FFFFFFFFh
; mette a -1 ecx

   repne scasb              
;  scansiona tutta la stringa fino al byte null 0 presente in eax  
   
   add ecx, 2              
   neg ecx                     ; nega ecx, 38

   mov al, [ebp+0Ch]  
; copia il carattere presente in ebp+12
   mov edi, edx            
; rimette in edi l'indirizzo dell'inizio della stringa

   rep stosb                  
; riempie la stringa di x        
   mov eax, edx          
; copia l'indirizzo della stringa in eax che ritorna il valore della funzione    


   ; ------------ end code from book -----------
   mov esp, ebp       ; restore stack pointer
   pop ebp            ; restore stack base pointer
   ret

























Playing a very basic level of a known wargame the other day I was trying to solve the following problem:
Given an executable (ELF, Linux) which accepts a password as an argument and verifies if this is correct, find this string. As most of the problems, it’s quite easy if you have the right tools (and knowledge of course).
Anyway, I thought the solution(s) would make a nice blog entry, so here it is!
In order to play around with it in my own Ubuntu, I wrote a very simple C program, named pass_cli.c

carlos@dell:~/Dropbox/hacking/wargames$ cat pass_cli.c
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
int
main(int argc, char **argv)
{
char password[] = “yomama”;
if(argc < 2)
{
printf(“Usage: %s <password>\n”, argv[0]);
exit(1);
}
if(strncmp(argv[1], password, strlen(password)))
{
printf(“FAIL\n”);
exit(1);
} else {
printf(“WIN\n”);
return(0);
}
return(0); // never reached :)
}
I compiled the program with no special options.
carlos@dell:~/Dropbox/hacking/wargames$ file pass_cli
pass_cli: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, not stripped
A first tool of the trade when you are looking for strings in a binary is strings, which will look for strings of printable characters inside the binary.
carlos@dell:~/Dropbox/hacking/wargames$ strings pass_cli
/lib/ld-linux.so.2
`:6K*
__gmon_start__
libc.so.6
_IO_stdin_used
exit
strncmp
puts
printf
strlen
__libc_start_main
GLIBC_2.0
PTRh`
yomaf
[^_]
Usage: %s <password>
FAIL
Well, we cannot find the password here (and even if it were displayed here, how could you identify it?) but that gave us some preliminar information about the program. We can see some familiar libc functions (printf, strlen, strncmp, etc.), strncmp will be of interest a bit later.
Another method you could have tried is for example to dump the contents of the .text section inside the binary. This is actually the same idea behind the use of strings, just a lot messier ;)
Remember that the .text section of a binary contains the machine instructions (the compiled code) but that doesn’t mean the strings are neccesarily stored in a readable way. Anyway we could check the contents of this section with the help of objdump.
carlos@dell:~/Dropbox/hacking/wargames$ objdump

-h, –[section-]headers  Display the contents of the section headers

-T, –dynamic-syms       Display the contents of the dynamic symbol table

carlos@dell:~/Dropbox/hacking/wargames$ objdump -h pass_cli

CONTENTS, ALLOC, LOAD, READONLY, CODE
13 .text         000001fc  08048400  08048400  00000400  2**4   <—- here

This section starts at the address 0x08048400, that is, the offset is 0x400 (the start virtual address is 0x08048000)
Armed with this knowledge we could hexdump this section and manually inspect it
carlos@dell:~/Dropbox/hacking/wargames$ hexdump -C -s 0x400 pass_cli | less

000004c0  19 79 6f 6d 61 66 c7 44  24 1d 6d 61 c6 44 24 1f  |.yomaf.D$.ma.D$.| <—   :(
As we can see, the string isn’t stored in a readable format, as expected :(
A very useful tool in this case is “ltrace” for we can monitor every system call (with the corresponding arguments!)
carlos@dell:~/Dropbox/hacking/wargames$ ltrace ./pass_cli AAAAA
__libc_start_main(0x80484b4, 2, 0xbf952854, 0x8048570, 0x8048560 <unfinished …>
strlen(“yomama”)                                                   = 6
strncmp(“AAAAA”, “yomama”, 6)                                      = -1      <— TA-DA!!!! :)
puts(“FAIL”FAIL
)                                                       = 5
exit(1 <unfinished …>
+++ exited (status 1) +++
But what if our system doesn’t have this tool? Then we have to take the heavy weapons and perform some elegant debugging :)
carlos@dell:~/Dropbox/hacking/wargames$ objdump -T pass_cli
pass_cli:     file format elf32-i386
DYNAMIC SYMBOL TABLE:
00000000  w   D  *UND*  00000000              __gmon_start__
00000000      DF *UND*  00000000  GLIBC_2.0   __libc_start_main
00000000      DF *UND*  00000000  GLIBC_2.0   strlen
00000000      DF *UND*  00000000  GLIBC_2.0   printf
00000000      DF *UND*  00000000  GLIBC_2.0   puts
00000000      DF *UND*  00000000  GLIBC_2.0   strncmp     <—- idea!
00000000      DF *UND*  00000000  GLIBC_2.0   exit
0804861c g    DO .rodata        00000004  Base        _IO_stdin_used
We have very good reasons to suspect that strncmp is being used to check our input against the password so let’s start the program in gdb and quickly disassemble it in order to localize the call to strncmp.
carlos@dell:~/Dropbox/hacking/wargames$ gdb -q ./pass_cli
Reading symbols from /home/carlos/Dropbox/hacking/wargames/pass_cli…(no debugging symbols found)…done.
(gdb) set disassembly-flavor intel <—- PLEASE ;)
(gdb) disass main
Dump of assembler code for function main:
0x080484b4 <+0>: push ebp
0x080484b5 <+1>: mov ebp,esp
0x080484b7 <+3>: and esp,0xfffffff0
0x080484ba <+6>: sub esp,0x20
0x080484bd <+9>: mov DWORD PTR [esp+0x19],0x616d6f79
0x080484c5 <+17>: mov WORD PTR [esp+0x1d],0x616d
0x080484cc <+24>: mov BYTE PTR [esp+0x1f],0x0
0x080484d1 <+29>: cmp DWORD PTR [ebp+0x8],0x1
0x080484d5 <+33>: jg 0x80484f9
0x080484d7 <+35>: mov eax,DWORD PTR [ebp+0xc]
0x080484da <+38>: mov edx,DWORD PTR [eax]
0x080484dc <+40>: mov eax,0x8048620
0x080484e1 <+45>: mov DWORD PTR [esp+0x4],edx
0x080484e5 <+49>: mov DWORD PTR [esp],eax
0x080484e8 <+52>: call 0x80483bc
0x080484ed <+57>: mov DWORD PTR [esp],0x1
0x080484f4 <+64>: call 0x80483ec
0x080484f9 <+69>: lea eax,[esp+0x19]
0x080484fd <+73>: mov DWORD PTR [esp],eax
0x08048500 <+76>: call 0x80483ac
0x08048505 <+81>: mov edx,eax
0x08048507 <+83>: mov eax,DWORD PTR [ebp+0xc]
0x0804850a <+86>: add eax,0x4
0x0804850d <+89>: mov eax,DWORD PTR [eax]
0x0804850f <+91>: mov DWORD PTR [esp+0x8],edx
0x08048513 <+95>: lea edx,[esp+0x19]
0x08048517 <+99>: mov DWORD PTR [esp+0x4],edx
0x0804851b <+103>: mov DWORD PTR [esp],eax
0x0804851e <+106>: call 0x80483dc
0x08048523 <+111>: test eax,eax
0x08048525 <+113>: je 0x804853f
0x08048527 <+115>: mov DWORD PTR [esp],0x8048636
[…]
Now I will place a breakpoint exactly on the address of this call instruction.
(gdb) b *0x0804851e
Breakpoint 1 at 0x804851e
Remember to use the asterisk (*) right in front of the address, so gdb understands what follows isn’t a literal.
Why did I do it this way? Think about it the other way. What happens when the call instruction is executed? The whole stack frame stup parafernalia, namely
EIP is pushed to the stack (by the call itself)
The function prologue is executed, that is
the current value of EBP is pushed to the stack (from now on, known as SFP)
the current value of ESP passes to be the new EBP (“a new stack frame starts here”)
a value is subtracted from ESP (to allocate space for local variables)
That is too messy to keep track of, so if we stop the execution flow right before the call instruction, what we have is the stack right before all this stuff… the function arguments at the top of the stack ;)
(gdb) run AAAAAA
Starting program: /home/carlos/Dropbox/hacking/wargames/pass_cli AAAAAA
Breakpoint 1, 0x0804851e in main () <— breakpoint is hit
(gdb) info reg
eax 0xbffff620 -1073744352
ecx 0x6 6
edx 0xbffff3c9 -1073744951
ebx 0x283ff4 2637812
esp 0xbffff3b0 0xbffff3b0 <— “top” of the stack
ebp 0xbffff3d8 0xbffff3d8
esi 0x0 0
edi 0x0 0
eip 0x804851e 0x804851e
eflags 0x286 [ PF SF IF ]
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0 0
gs 0x33 51
Let’s examine the top of the stack. We are actually interested in the first three words.
(gdb) x/12x $esp
0xbffff3b0: 0xbffff620 0xbffff3c9 0x00000006 0xbffff3d8
0xbffff3c0: 0x0015d4a5 0x0011e0c0 0x6d6f797b 0x00616d61
0xbffff3d0: 0x08048570 0x00000000 0xbffff458 0x00144bd6
Without further inspection we can see a 6, the number of char the function has to compare. It looks good at least ;) Let’s remember the exact syntaxis of strncmp()
carlos@dell:~/Dropbox/hacking/wargames$ man 3 strncmp
[…]
SYNOPSIS
#include
int strcmp(const char *s1, const char *s2);
int strncmp(const char *s1, const char *s2, size_t n); <— allright, three arguments…
[…]
Also one of the first two words must be a pointer to the hardcoded password, the other a pointer to the user input (argv[1] in this case)
(gdb) x/4x 0xbffff620
0xbffff620: 0x41414141 0x4f004141 0x54494252 0x434f535f
Well, this is pretty clearly our string of 6 “A’s” null-terminated. The other address must be the location of our password!
(gdb) x/4x 0xbffff3c9
0xbffff3c9: 0x616d6f79 0x7000616d 0x00080485 0x58000000
OK, another string of 6 characters, null-terminated. The ASCII char  associated to these values can be displayed in gdb as follows:
(gdb) p/c *0xbffff3c9
$16 = 121 ‘y‘
(gdb) p/c *0xbffff3ca
$17 = 111 ‘o‘
(gdb) p/c *0xbffff3cb
$18 = 109 ‘m‘
(gdb) p/c *0xbffff3cc
$19 = 97 ‘a‘
(gdb) p/c *0xbffff3cd
$20 = 109 ‘m‘
(gdb) p/c *0xbffff3ce
$21 = 97 ‘a‘
(gdb) p/c *0xbffff3cf
$22 = 0 ‘00‘

So here’s the magic password! YOMAMA! ;)