Spørgsmål:
Porting Linux eksekverbar fra 32bit til 64bit
Mellowcandle
2013-04-10 12:50:29 UTC
view on stackexchange narkive permalink

Som du måske forestiller dig, er kildekoden ikke tilgængelig. Den eksekverbare fil blev skrevet ved hjælp af C / C ++ og kompileret ved hjælp af gcc.

Dette er hvad -fil kode> har at sige om filen 

  ELF 32-bit LSB eksekverbar, Intel 80386, version 1 (SYSV), dynamisk linket (bruger delte libs) til GNU / Linux 2.6.24, ikke fjernet

Ifølge ldd er dette de biblioteker, som programmet bruger: 

  libssl.so.1.0.0 = > /lib/i386-linux-gnu/libssl.so.1.0.0 (0xf7700000) libcrypto.so.1.0.0 = > /lib/i386-linux-gnu/libcrypto.so.1.0.0 (0xf7554000) libm .so.6 = > /lib/i386-linux-gnu/libm.so.6 (0xf7528000) libc.so.6 = > /lib/i386-linux-gnu/libc.so.6 (0xf737e000) libpthread.so .0 = > /lib/i386-linux-gnu/libpthread.so.0 (0xf7363000) librt.so.1 = > /lib/i386-linux-gnu/librt.so.1 (0xf7359000) libstdc ++. So.6 = > /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xf7270000) li bdl.so.2 = > /lib/i386-linux-gnu/libdl.so.2 (0xf726b000) libz.so.1 = > /lib/i386-linux-gnu/libz.so.1 (0xf7252000) / lib /ld-linux.so.2 (0xf7789000) libgcc_s.so.1 = > /lib/i386-linux-gnu/libgcc_s.so.1 (0xf7234000)

Alle disse biblioteker er også tilgængelig i 64-bit version.

Spørgsmålene:

  1. Er det muligt at samle applikationen igen som 64-bit-applikation?
  2. Hvilke værktøjer findes der til at hjælpe med sådan en ting ? (hvis det er muligt)
To svar:
Ange
2013-04-10 12:59:08 UTC
view on stackexchange narkive permalink

Selvom det ikke er i spørgsmålet, da det ville være ret svært at samle det igen, håber jeg, du kan prøve noget andet end at samle det igen, eller at det i det mindste er en lille og ikke-tilsløret fil.

lavt niveau

Genmontering ville være meget vanskeligt: ​​

Værktøjer : Jeg kan ikke tænke på et specifikt værktøj til at hjælpe ud over IDA og normale reverse engineering-metoder (jeg får en lignende anmodning til port DOS / NE-filer til PE)

Opkaldskonventioner : Portering fra 32b til 64b vil være vanskelig som opkaldskonventioner er forskellige, så de skal omskrives på forsamlingsniveau. ELF-strukturer er i det mindste meget ens.

højt niveau

Din bedste chance er at prøve at dekompilere via Hex-Rays Decompiler for at redde besværet, men det vil stadig kræve meget kedeligt arbejde, før den dekompilerede kode kan fungere som forventet.

Hvad mener du med at 'kaldekonventioner er forskellige'. Jeg troede, at dette i sidste ende var på anmodning af operativsystemet / det eksekverbare format?
[videregive funktionsparametre i registre og ikke på stakken] (http://stackoverflow.com/questions/5022744/x64-bit-assembly)
Jeg kan se, er det for visse ekser stadig ikke det samme? Jeg tror, ​​at to ting generelt sendes i registre, og resten på stakken i Windows's "standard" -opkaldskonvention? Hvorfor er disse opkaldskonventioner (udover registerstørrelse) forskellige?
(exe som i PE, ikke?) Jeg skrev [dette] (https://code.google.com/p/corkami/wiki/CallingConventioner) som en påmindelse om PE-opkaldskonventioner.
Jeg forstår, jeg troede, at Microsoft kaldte det "Standard", nu ved jeg, at det hedder FastCall - Du og corkami flipper forresten. Jeg fortæller alle, jeg møder, der vil lytte om jer.
@angealbertini: men kunne du ikke bare bruge oldstyle-opkaldskonventioner i din nye 64b-eksekverbare?
Du kunne - teknisk set - men standardcompilere genererer ikke kompatibel kode, så du ville ikke være i stand til let at bruge biblioteker.
Markørstørrelsesændringen er den bit, der skræmmer mig ... hvert indeks i en struktur eller stabelramme skal vide, om der er en markør, der ændrede størrelse overalt i hukommelsen. Du har sandsynligvis brug for noget næsten lige så kraftigt som en dekompilator. På emnet for opkaldskonventionen skal de konverteres, uanset hvor biblioteksfunktioner bruges, selvom du teknisk set måske kan skrive omslag til dem i stedet.
0xC0000022L
2013-04-12 19:39:41 UTC
view on stackexchange narkive permalink

Spørgsmålet her er, hvad har du brug for? Har du brug for for at kunne køre denne ting på 64bit og interagere med den eller er målet faktisk at porte den ?

Kør den

Hvis du kun havde brug for at køre det, og vi kan antage kompatibilitetsbibliotekerne (dem, der tillader at køre 32bit-programmer på 64bit) som en given, kan du sandsynligvis opfange al slags funktionalitet ved hjælp af standard ld.so -metoder ( LD_PRELOAD og venner) som også beskrevet i svar på Hvordan tilføjer jeg funktionalitet til en eksisterende binær eksekverbar fil? der ville du være i stand til at grænseflade med det eksisterende og uændrede 32bit-program ved hjælp af hukommelseskortede filer eller stikkontakter eller virkelig enhver form for IPC-mekanisme, som du finder egnet til formålet.

Helt ærligt er dette sandsynligt den bedste metode med mindst mulig indsats.

På Debian 5 findes kompatibilitetslaget i følgende to pakker: 

  libc6-dev-i386 - Embedded GNU C Bibliotek: 32-bit udviklingsbiblioteker til AMD64libc6-i386 - Indbygget GNU C-bibliotek: 32-bit delte biblioteker til AMD64

Det samme navn bruges på Ubuntu 10.04 til 12.04. Dette er de eneste versioner, jeg kunne kontrollere i øjeblikket, men jeg er opmærksom på lignende ting i RHEL / CentOS / ScientificLinux.

Port det

Ellers løber du ind i en hele overflod af problemer, hvoraf de største allerede blev skitseret af ange albertini her.

Generelt, hvis du er heldig, og det ser sådan ud, skal fejlretningsoplysningerne ( ikke strippet står der) giver dig mulighed for at sortere navne på kildefiler, så du kan muligvis sætte puslespil som biblioteker sammen og derefter kan koncentrere sig om den "faktiske" kode. Dette er måske ikke en stor fordel, men for reverse engineer hjælper hvert lille halm.

Dekompilere som Hex-Rays-plugin'et eller den der følger med Hopper kan være en god måde at få en mere højt forestående idé om koden. Stadig vil dette være en masse arbejde, medmindre du fokuserer på de funktionelle dele, du har brug for - det er derfor, jeg (er doven og alt) altid vil gå med ovenstående mulighed, dvs. køre det i kompatibilitetstilstand.



ⓘ
Denne spørgsmål og svar blev automatisk oversat fra det engelske sprog.Det originale indhold er tilgængeligt på stackexchange, som vi takker for den cc by-sa 3.0-licens, den distribueres under.
Loading...