Názory k článku Nástroj objdump: švýcarský nožík pro vývojáře

Skvělý článek, díky moc.

Díky, rádo se stalo

Taky jsem si rad pocetl, asembler jsem uz nevidel fakt dlouho.

jj objdump je uzitecnej tool. Jinak FYI pro Go se primo moc neda pouzit (tedy da, ale vysledky nejsou ono), ale ve standardnim toolingu je `go tool objdump` (nahodicka)

U disassemblování by bylo dobré zmínit, že pokud se objdump používá na object file nebo soubor, u kterého se některé relokace budou provádět až později (např. dynamicky linkovaná knihovna nebo modul), je vhodné použít parametr -r, aby bylo vidět, kam externí volání opravdu vedou:

...> objdump -d vmnet.o
...
0000000000000120 <init_module>:
     120:       e8 00 00 00 00          call   125 <init_module+0x5>
     125:       41 54                   push   %r12
     127:       e8 00 00 00 00          call   12c <init_module+0xc>
     12c:       85 c0                   test   %eax,%eax
...

vs.

...> objdump -r -d vmnet.o
...
0000000000000120 <init_module>:
     120:       e8 00 00 00 00          call   125 <init_module+0x5>
                        121: R_X86_64_PC32      __fentry__-0x4
     125:       41 54                   push   %r12
     127:       e8 00 00 00 00          call   12c <init_module+0xc>
                        128: R_X86_64_PC32      VNetProc_Init-0x4
     12c:       85 c0                   test   %eax,%eax
...

To je pravda, diky moc za doplneni. Ja se k teto problematice jeste vratim u popisu toho, jak se pracuje (nejenom v objdumpu) s dyn. knihovnami

Diky - super clanek jako vzdy!

Btw neplanujete take udelat nejake lehke info k radare2 ? :)

Díky.

Neplánoval jsem, ale dívám se na ten projekt a vypadá to, že to dělají lidi mé krevní skupiny :-) Takže článek bude, ale musím si to pořádně ošahat. Díky za připomenutí.

Hodilo by se ;-). Prave se pro nej v potu tvare snazim napsat podporu jednoho MCU.
Protoze devkit od japoncu uz neni, strejc umrel i s podporou ( tak to v japonsku chodi) a neofiko se nikde neda sehnat. Ani pres tchana. Propalil jsem uz 5 mcu (jsou OTP) abych testnul kde se startuje program sekce.

Díky za článek.

Jak moc je dnes s klidným svědomím použitelný objdump na "rizikové" binárky (malware, reverse engineering)? Pamatuji si že na ručně dělaných lehce nekorektních binárkách mi coredumpoval, a viděl jsem nějaká CVEčka - ale nevím zda se řešily jen náhodně nalezená zjištění, nebo došlo k nějakému auditu.

Man stránka se drží při zdi a říká "mostly useful to programmers who are working on the compilation tools".

Neni. Worst case zbehnout to na jine platforme nebo virtualu jine platformy + user prava. To by mohlo stacit.
Jinak ja treba v korporatu pouzivam BinaryNinju. Ale tam je dost omezena podpora platforem.

Obecně to není dobrý nápad. Na druhou stranu se objdump nesnaží například načítat dynamické knihovny té binárky (na rozdíl od ldd). V tomho ohledu je ldd o dost více problematická, ale stejně bych objdump na "vešky" používal v hodně izolovaném prostředí, jistota je kulomet :-)

Je az s podivem kolik C programatoru tento zakladni tool nezna.
Celkem rad tyto tooly pouzivam na aplikaci metod Doc. Ing. Zla na vyvojare.
Predstavte si ze vam dodaji tool prelozeny uplne jinym compilerem, nepouziji spravne knihovny atd. A v tom tymu nesmite mit ke zdrojakum pristup ( EU/US ).

Ja este pridam pre mna takmer nevyhnutny parameter"-w", teda wide display alebo v praxi nech nezalamuje riadky. Bez toho mam v tom gulas.
Ako priklad z clanku pri pouziti s -h, teda objdump -wh ./file
Pre readelf je to -W.

S tym att vs intel je to celkom zaujimave. Ked som zacal pouzivat x86 asm tak som bol jednoznacne tim intel. Od zobrazovania (objdump,gdb, IDA...) az po samotne pisanie. Dokonca aj pri gcc v inline asm som pouzival intel syntax. A nechapal som ako moze niekto pouzivat att.
Len prakticky kazdy v opensource komunite (Linux, BSD..) pouziva att. Tak som si povedal, ze to skusim. Na moje prekvapenie som celkom rychlo nasiel v tom logiku. Napr. to obratenie parametrov. V hlave si drzim co idem ulozit, kam to idem ulozit. A teda movl $0xdecafe, %eax mi zrazu davalo zmysel. Suffix pri instrukciach je tiez fajn vec, je to taky double-check ci robim to co mam. Ja este davam premennym prefix ich velkosti. Lahsie sa mi potom prechadza kod.
Napr.

movw %ax, (w_small_int)

w_small_int: .word 0 

Co je trosku komicke je fakt, ze stale na zobrazovanie pouzivam intel. att syntax ma strasne vela balastu (imm ma $, % pri reg, a aj tie () sa mi citaju horsie ako []).
Len potom pridem na instrukciu cmp a mam v hlave misung, ze co sa vlastne porovnava. :)

Problem mam hlavne s tim adresovanim. U Intel syntaxe je to v podstate cecko, u AT&T je to docela umele konstruovana adresa. Ale je fakt, ze jsem vyrostl na Intel syntaxi, ktera byla vsude, i u mikroradicu,

Ja tak isto, Borland C++, masm/tasm, vsetko intel. Tak isto arm/mips asm sa v podstate podoba na intel syntax.
Len fakt je, ze je to teraz u mna trosku komicke lebo pisem att a citam intel. A to je taky trosku bf.

Pořadí je opravdu otázka zvyku. Když jsem se ještě v minulém století poprvé potkal s assemblerem 8080, přišlo mi pořadí kam-co postavené na hlavu a nechápal jsem, kdo to takhle mohl vymyslet. Když jsem pak o dost později začal trochu víc pracovat s assemblerem na Linuxu, byl zase nezvyk, že to je obráceně. Dnes už bych měl asi zase problémy s Intel mnemonikou.

Ale souhlasím, že pořadí kam-co vs co-kam je oproti složitějším adresovacím modům prkotina. Moje soukromá pomůcka je, že když vidím velká písmena a registry bez procent, je to Intel, když malá a procenta, je to AT&T. :-) Pak ale člověk jednoho dne poprvé narazí na něco jako

925:       48 8d 54 ca 02          lea    0x2(%rdx,%rcx,8),%rdx
9da:       48 8d 74 fe 02          lea    0x2(%rsi,%rdi,8),%rsi
b27:       48 8d 04 c2             lea    (%rdx,%rax,8),%rax
b2b:       4d 8d 04 c6             lea    (%r14,%rax,8),%r8
bf7:       49 8d 54 d7 02          lea    0x2(%r15,%rdx,8),%rdx

...a včil mudruj. :-)