Hoe krijg ik een lijst met functies binnen een EXE file?

[PageFault]

Mijn vraag:

Hoe krijg ik een lijst met functies binnen een EXE file? Liefst met argumenten.


Relevante software en hardware die ik gebruik:

Windows Server 2008 R2 64 bits


Wat ik al gevonden of geprobeerd heb:

Ik heb een aantal tools geprobeerd, waaronder DDLExplorer, PE Explorer, Boomerang en ook .NET Reflector 9.0. Geen van allen laat iets zien van de EXE file waar ik tegenaan wil praten.

Iemand een tip?

[chaoscontrol]

.\naamvan.exe /?

[downtime]

PageFault schreef op zondag 12 februari 2017 @ 12:16:
Mijn vraag:

Hoe krijg ik een lijst met functies binnen een EXE file? Liefst met argumenten.


Relevante software en hardware die ik gebruik:

Windows Server 2008 R2 64 bits


Wat ik al gevonden of geprobeerd heb:

Ik heb een aantal tools geprobeerd, waaronder DDLExplorer, PE Explorer, Boomerang en ook .NET Reflector 9.0. Geen van allen laat iets zien van de EXE file waar ik tegenaan wil praten.

Iemand een tip?

Een exe kun je alleen gebruiken als je de parameters kent. Die vraag je normaal met /?, /h, -h of -help op. Soms gewoon door de exe zonder parameters te starten. Als dat allemaal niet helpt dan zul je de maker moeten vragen. Een exe is nu eenmaal geen dll.

[PageFault]

De exe is geregistreerd als object of beter: als service, ik weet enkele functies, maar ik zoek nu naar additionele functies met argumenten.

Commandline parameters accepteert de service niet, dus daar heb ik in dit geval heel weinig aan.

De maker gaat het ons niet vertellen

[nescafe]

Kijk eens met strings naar de leesbare stukken in de exe.

Als het een ActiveX EXE is kun je het proberen met OLE Viewer.

Een obfuscated .NET assembly kun je de-obfuscaten met de4dot voor je hem door Reflector haalt.

[jip_86]

Wat is het doel hiervan dan? Een service zal werken volgens een bepaald patroon, maar kan je niet ineens iets anders laten doen oid.

[Squ1zZy]

Je bent opzoek naar de import table denk ik. Met PE Explorer kan je dit zien. Dependency Walker is ook een goede tool en gratis:

http://www.dependencywalker.com

Is de executable te delen?

[Marco1994]

Je zou de .EXE kunnen decompilen en vanuit daar verder kijken

[TRON]

Hoe heet het bestand en/of waar is het onderdeel van? Wellicht heeft iemand hier meer informatie over.

[Swedish Clown]

PageFault schreef op zondag 12 februari 2017 @ 12:53:
[...]
De maker gaat het ons niet vertellen

Dan zou ik zeggen dat het ook niet ok is om te gaan decompilen en andere ongein. Je zal vast een contract met die lui hebben. Op deze wijze begeef je jezelf en het bedrijf waar je voor werkt op een pad waar je niet wil zijn

[mr_taipan]

Je zou IDA Pro kunnen proberen?

[PageFault]

Dank voor alle tips so far.

De status so far:

PE Explorer:

Ik zie wel gegevens van de DLL dependencies met eterne (leesbare) functies
EXE file zelf is in assembler taal met nutteloze naamgevingen (letter+cijferreeks)
Strings van de variabelen wel in de string view, functions niet

Dependency Walker:

Wel structuur van de DLL dependencies
Krijg de melding "Errors were detected when processing EXE. In de event viewer staat niks, ondanks dat de tool daar naar verwijst.

Ik heb geen Visual Studio. Kan de OLE/COM object viewer ook stand-alone draaien? En zo ja, is deze ook zo te downloaden?

De EXE zou ik kunnen delen met diegene die interesse hebben. Ik vermoed dat de EXE alleen de service registreert en dat daarna de functies beschikbaar zijn.

De EXE file heet DsPcSrv.exe en is onderdeel van een scan/print oplossing "uniFLOW".

[.oisyn]

Ik mis de meest belangrijke vraag: waaróm wil je dit weten? Wat probeer je te bewerkstelligen?

[PageFault]

Ik kan aardig wat gegeven in en uit het systeem krijgen. Ik mis voor het exporteren nog wat gegevens en ik vermoed dat er functions zijn om de ontbrekendr gegevens uit te lepelen.

De rest kan ik al via javascript of vbscript eruit trekken. Nu dat laatste stukje nog.

Er loopt een change bij de leverancier om data selectief eruit te krijgen, maar zij hebben dit jaar andere prioriteiten, heel begrijpelijk, maar wij willen ook door.

[EfBe]

.oisyn schreef op dinsdag 14 februari 2017 @ 17:04:
Ik mis de meest belangrijke vraag: waaróm wil je dit weten? Wat probeer je te bewerkstelligen?

inderdaad. Zonder de reden is het slecht antwoordgeven. Reverse engineering is niet simpel, je bent er echt wel even mee zoet en het vergt veel kennis van bv assembler en tools. Ik heb niet het idee dat je die hebt, no offense.

[PageFault]

EfBe schreef op woensdag 15 februari 2017 @ 09:13:
[...]

inderdaad. Zonder de reden is het slecht antwoordgeven. Reverse engineering is niet simpel, je bent er echt wel even mee zoet en het vergt veel kennis van bv assembler en tools. Ik heb niet het idee dat je die hebt, no offense.

Hierboven beschreef ik de reden: ik wil gegevens via de kernel opvragen. Een hele boel zaken kan ik al opvragen, een aantal niet. Een heleboel kan ik ook via de omgekeerde weg het systeem in krijgen. Via een XML import gaat de rest van de gegevens ook.

Assembler ben ik na BASIC (ja ik ben zo oud) mee begonnen, maar wel in het begin van het pentium tijd mee gestopt.

Maar ik ben niet op zoek naar WAT de functies doen, maar WELKE er zijn met welke parameters. Ik wil ze alleen aanroepen. Ik heb geen interesse in het reverse engineeren van de code zelf. Dat kost teveel tijd en ik hoef de code niet te snappen.

[Gomez12]

PageFault schreef op dinsdag 14 februari 2017 @ 20:55:
Ik kan aardig wat gegeven in en uit het systeem krijgen. Ik mis voor het exporteren nog wat gegevens en ik vermoed dat er functions zijn om de ontbrekendr gegevens uit te lepelen.

De rest kan ik al via javascript of vbscript eruit trekken. Nu dat laatste stukje nog.

Er loopt een change bij de leverancier om data selectief eruit te krijgen, maar zij hebben dit jaar andere prioriteiten, heel begrijpelijk, maar wij willen ook door.

Waarom niet gewoon bij de leverancier je vraag stellen dan? Hun zullen dat echt wel intern gedocumenteerd hebben. Kopietje van die pagina's van de interne documentatie moet toch zo te maken zijn mits je leverancier wel mee wilt werken maar het echt te druk heeft.

En dat ze in Februari al kunnen zeggen dat ze dit jaar andere prioriteiten hebben neigt bij mij ernaar dat ze het of zien als een gigantisch project of ze hebben er gewoon geen zin in, of je betaalt simpelweg niet genoeg.

Als ik 1 ding geleerd heb in het zakenleven is het dat elke prioriteit te veranderen is met geld. Er zit een beetje een apart luchtje aan het feit dat ze nu al weten dat ze er in de komende 10 maanden geen tijd voor hebben.

[MSalters]

Een EXE hoeft niet eens functies te hebben. 't Is gebruikelijk, maar het zou een Finite State Machine implementatie kunnen zijn. Maar zelfs als er functies in zitten, dan is het onwaarschijnlijk dat er een lijst is.

@chaoscontrol suggereert command-line parameters. Die zijn ongerelateerd.

@Squ1zZy suggereert een import tabel. Dat zijn de functies die niet in de EXE zitten, maar die uit een DLL komen. Zie daarvoor de export tabel van de DLL. En nee, een EXE heeft normaliter geen export tabel. (Het formaat ondersteunt het theoretisch, maar dat is alleen omdat DLL's en EXE allebei PE formaat zijn)

Ik ben het wél met .oisyn eens: Wat zou je er mee kunnen? Afgezien van het praktische probleem hoe je die functies technisch zou moeten aanroepen (is nog wel te doen), veel functies kun je niet zomaar aanroepen. Stel dat de EXE in C++ geschreven is, dan kun je de member functies van een class alleen aanroepen nadat de constructor gedraaid heeft, maar niet nadat de destructor gedraaid heeft, en alleen nadat de class statics geïnitialiseerd zijn. Dat zijn normaal gesproken dingen die de compiler voor je regelt, inclusief de argumenten, maar die je nu opeens in assembly mag gaan opknappen.

Zal ik het nog erger maken? Functies heb je in je source code. Een moderne optimizer maakt daar een zooitje van, vanwege performance redenen. Twee functies kunnen samengevoegd worden, één functie kan opgesplitst worden in twee delen (hot/cold split), of in twee varianten. En die optimalisaties kunnen overlappen, dus de grenzen van functies zijn simpelweg vluchtig. Met x64 exception handling is het zelfs geen kwestie van optimizers, exception handlers zijn altijd gesplitst. Tenzij de optimizer ze natuurlijk weer samenvoegt.

[.oisyn]

MSalters schreef op woensdag 15 februari 2017 @ 21:52:
@Squ1zZy suggereert een import tabel. Dat zijn de functies die niet in de EXE zitten, maar die uit een DLL komenu. Zie daarvoor de export tabel van de DLL. En nee, een EXE heeft normaliter geen export tabel. (Het formaat ondersteunt het theoretisch, maar dat is alleen omdat DLL's en EXE allebei PE formaat zijn)

Dit is op zich iets minder theoretisch dan het lijkt; je kunt gewoon functies exporteren op de gebruikelijke manieren, en je kunt de linker zelfs een import library laten genereren voor je executable. Een mogelijke use case is bijvoorbeeld het aanbieden van functionaliteit in de host executable voor de in te laden DLL.

Dat gezegd hebbende, het is idd niet gebruikelijk dat een exe ook een export table heeft.

[ Voor 5% gewijzigd door .oisyn op 15-02-2017 22:10 ]

[Will_M]

Klein vraagje wat misschien niet ter zake doet maar: Klinkt dit als het zoeken naar de code van closed source software?

Als een .exe als Windows service draait en niet verder gedocumenteerd is door de leverancier dan lijkt het me zo te zijn dat de leverancier liever niet heeft dat je, zónder te betalen, wat andere functies gaat gebruiken, toch?

[johnkeates]

Er is waarschijnlijk geen "lijst". Misschien als er debug symbols zijn, of als het managed code is, maar in de meeste gevallen zal je in closed-source production binaries weinig tekst tegen komen die functienamen opgeeft. IDA Pro zal je nog wel het meeste geven over de werking.

[Will_M]

johnkeates schreef op woensdag 15 februari 2017 @ 22:19:
Er is waarschijnlijk geen "lijst". Misschien als er debug symbols zijn, of als het managed code is, maar in de meeste gevallen zal je in closed-source production binaries weinig tekst tegen komen die functienamen opgeeft. IDA Pro zal je nog wel het meeste geven over de werking.

Dan loop je vaak alsnog tegen een "EULA" aan.... Iets met reverse engineering wat niet toegestaan is

[.oisyn]

Het is een mythe dat reverse engineering niet is toegestaan. Er zitten wat juridische haken en ogen aan, maar het mag zeker wel binnen de juiste wettelijke kaders. Een voorbeeld is het leveren van compatibiliteit daar waar de maker een dergelijke oplossing niet biedt.

[Will_M]

.oisyn schreef op woensdag 15 februari 2017 @ 23:05:
Het is een mythe dat reverse engineering niet is toegestaan. Er zitten wat juridische haken en ogen aan, maar het mag zeker wel binnen de juiste wettelijke kaders. Een voorbeeld is het leveren van compatibiliteit daar waar de maker een dergelijke oplossing niet biedt.

En dus mág je de code hergebruiken óf op een andere manier implementeren , het is toch maar een mythe?

[.oisyn]

Ik regeer op je opmerking Iets met reverse engineering wat niet toegestaan is. Het is niet zonder meer "niet toegestaan", al wordt dat vaak wel gedacht hier op tweakers.net (-> mythe). De TS heeft vooralsnog niet genoeg losgelaten over het beoogde doel om te kunnen bepalen of het wel of niet is toegestaan wat hij wil.

[Verwijderd]

wimmel_1 schreef op woensdag 15 februari 2017 @ 23:07:
En dus mág je de code hergebruiken óf op een andere manier implementeren , het is toch maar een mythe?

Je trekt een conclusie die je totaal niet kan trekken. Reverse engineeren kan en mag vaak, zeker als je geen juridische band met de verkopende partij hebt. Net zoals je een magnetron kunt kopen en uit elkaar kunt halen, kan je kijken hoe een applicatie in elkaar zit. Die code elders gebruiken is echter een totaal andere kwestie en zal doorgaans weer niet mogen. Ontwikkel je echter een product dat samenwerkt met die magnetron, dan zal het vaak wel mogen.

wimmel_1 schreef op woensdag 15 februari 2017 @ 22:23:
Dan loop je vaak alsnog tegen een "EULA" aan.... Iets met reverse engineering wat niet toegestaan is

EULA's in de Amerikaanse stijl zijn in ieder geval in Europa (en wellicht in de VS) vaak ongeldig. Let wel dat je bij een zakelijke overeenkomst wel aan beperkende voorwaarden gebonden kan zijn.

[Gomez12]

Verwijderd schreef op donderdag 16 februari 2017 @ 00:21:
[...]
Je trekt een conclusie die je totaal niet kan trekken. Reverse engineeren kan en mag vaak, zeker als je geen juridische band met de verkopende partij hebt. Net zoals je een magnetron kunt kopen en uit elkaar kunt halen, kan je kijken hoe een applicatie in elkaar zit. Die code elders gebruiken is echter een totaal andere kwestie en zal doorgaans weer niet mogen. Ontwikkel je echter een product dat samenwerkt met die magnetron, dan zal het vaak wel mogen.

Om even op het bold stukje in te gaan, dat mag dan veelal enkel vanuit reverse engineering wetgeving/standpunt.
Wat er veelal gebeurt is dat er daarnaast nog allerlei andere wetten en standpunten van toepassing zijn waardoor het totaal weer niet mag.

Om even bij je magnetron voorbeeld te blijven, daar mag je best het stekkersnoer van doorknippen en dat gaan reverse engineering en er een 12V stekker opzetten voor in je auto.
Alleen veelal zul je officieel dat ding nooit mogen testen in je auto want waarschijnlijk kent je auto weer regels dat er enkel officieel CE-gekeurd spul op aangesloten mag worden en je magnetron kent weer regels dat die enkel bediend mag worden als hij met officieel CE-gekeurde bekabeling is aangesloten.

In de software wereld zie je dat nog weleens terug in de vorm van simplistische kopieerbeveiligingen waarover het verkeer moet gaan. Je mag het wel reverse-engineeren maar je mag de beveiliging weer niet breken en als er in de licentie voorwaarden staat dat die software enkel mag samenwerken met officiele beveiligde communicatie dan mag je dus niet met het origineel communiceren alhoewel je het protocol hebt mogen reverse-engineeren.

[...]
EULA's in de Amerikaanse stijl zijn in ieder geval in Europa (en wellicht in de VS) vaak ongeldig. Let wel dat je bij een zakelijke overeenkomst wel aan beperkende voorwaarden gebonden kan zijn.

Nope, gedeeltes van EULA's kunnen ongeldig zijn, vanwege de manier van verspreiden en tijdstip waarop het getoond wordt. Alleen 90% van de gemiddelde EULA is gewoon standaard gezeur wat overal voor geldt en die 90% is wel weer geldig.

[sig69]

Al zou je een nuttige functie naam tegen komen, dan ga je alsnog die .exe niet aan kunnen roepen om het resultaat van die functie ook in je export te krijgen.

[Verwijderd]

Gomez12 schreef op donderdag 16 februari 2017 @ 01:20:
Nope, gedeeltes van EULA's kunnen ongeldig zijn, vanwege de manier van verspreiden en tijdstip waarop het getoond wordt. Alleen 90% van de gemiddelde EULA is gewoon standaard gezeur wat overal voor geldt en die 90% is wel weer geldig.

Dan is de EULA dus niet geldig, maar het standaard gezeur terwijl dat toevallig ook in de EULA staat. Dat maakt nog wel wat uit, al is de praktische uitwerking hetzelfde.

Gomez12 schreef op donderdag 16 februari 2017 @ 01:20:
Om even bij je magnetron voorbeeld te blijven, daar mag je best het stekkersnoer van doorknippen en dat gaan reverse engineering en er een 12V stekker opzetten voor in je auto.
Alleen veelal zul je officieel dat ding nooit mogen testen in je auto want waarschijnlijk kent je auto weer regels dat er enkel officieel CE-gekeurd spul op aangesloten mag worden en je magnetron kent weer regels dat die enkel bediend mag worden als hij met officieel CE-gekeurde bekabeling is aangesloten.

Het CE-keur is veelal de verantwoordelijkheid van de maker/importeur. Dat kan je er dus zelf op zetten, al is het wel verstandig dat alleen te doen als je de boel ook daadwerkelijk getest hebt. Er zijn wel uitzonderingen.

Zou je echter een 12V naar 240V-converter bouwen en die zelf op de gewenste eigenschappen testen of laten keuren, dan is er niets op tegen die in combinatie met die magnetron te gebruiken. Dat hebben sommige magnetronfabrikanten (lees: softwareboeren) liever niet en die werken dat dan op alle mogelijke manieren tegen, maar dan mag het nog wel.

[ Voor 55% gewijzigd door Verwijderd op 16-02-2017 01:27 ]

[Gomez12]

Verwijderd schreef op donderdag 16 februari 2017 @ 01:24:
[...]
Het CE-keur is veelal de verantwoordelijkheid van de maker/importeur. Dat kan je er dus zelf op zetten, al is het wel verstandig dat alleen te doen als je de boel ook daadwerkelijk getest hebt. Er zijn wel uitzonderingen.

Het is gewoon illegaal om zelf een CE-keur op een elektrisch apparaat te zetten als het niet getest is.

Zou je echter een 12V naar 240V-converter bouwen en die zelf op de gewenste eigenschappen testen of laten keuren, dan is er niets op tegen die in combinatie met die magnetron te gebruiken. Dat hebben sommige magnetronfabrikanten (lees: softwareboeren) liever niet en die werken dat dan op alle mogelijke manieren tegen, maar dan mag het nog wel.

Wellicht dat CE een verkeerd voorbeeld was, omdat die controle achteraf plaatsvind. Maar aan de andere kant vind ik het ook wel een passend voorbeeld, want niemand gaat als je auto in de fik staat zeggen : Maar je hebt die converter zelf getest oh dan is het perfect en kan dat niet de oorzaak zijn. Iedereen gaat wijzen naar jouw converter dat dat de oorzaak is en omdat je het niet in massa geproduceerd hebt kan je naderhand ook niet laten nakijken of het CE-keur wel of niet terecht was, oftewel iedereen zal zeggen : Onterecht...

Alleen in wezen is dat voorbeeld ook niet zo interessant, wat ik meer probeerde duidelijk te maken is dat reverse engineering wellicht wel mag, maar dat dat nog niet 100% automatisch betekent dat je je eigen oplossing tegen het bestaande aan mag laten praten. Waardoor je praktisch 0 opgeschoten bent.

[EfBe]

PageFault schreef op woensdag 15 februari 2017 @ 15:12:
[...]


Hierboven beschreef ik de reden: ik wil gegevens via de kernel opvragen. Een hele boel zaken kan ik al opvragen, een aantal niet. Een heleboel kan ik ook via de omgekeerde weg het systeem in krijgen. Via een XML import gaat de rest van de gegevens ook.

Wat houdt 'gegevens via de kernel opvragen' in vredesnaam in? Kernel is OS kernel? daar kom je niet in met je user-land code.

Maar ik ben niet op zoek naar WAT de functies doen, maar WELKE er zijn met welke parameters. Ik wil ze alleen aanroepen. Ik heb geen interesse in het reverse engineeren van de code zelf. Dat kost teveel tijd en ik hoef de code niet te snappen.

Je kunt wellicht middels X64dbg (of z'n 32bit broertje) de symbols naar boven halen, wanneer je attached aan het running process, en wellicht de memspace dumpen, maar je zult ook middels de diepe analysis van bv x64dbg of IDA niet parameternamen naar boven krijgen als die niet in de exe zelf zitten. Je kunt hooguit per functie (die zijn dan wel te herkennen door de int3 headers) middels analysis en decompilation de parameters kunnen achterhalen, maar dat is niet simpel: de windows ABI passed sommige parameters in registers en andere op de stack (hangt ook weer van 32bit of 64bit af) en je zult zelf moeten uitvinden welke dat zijn: je hebt dan ook alleen maar assembler tot je beschikking dus waar de values vandaan komen en wat ze precies voorstellen... dat is erg lastig (als in: je moet breakpoints zetten, kijken waar de call chain vandaan komt etc. Wat MSalters al zei: het is erg erg lastig).

Je blijft te vaag over wat je werkelijk wilt. Dat vertelt me 2 dingen: 1) dat je iets wilt doen wat niet mag of 2) dat je niet weet wat je precies aan het doen bent.

[Verwijderd]

Gomez12 schreef op donderdag 16 februari 2017 @ 08:41:
Het is gewoon illegaal om zelf een CE-keur op een elektrisch apparaat te zetten als het niet getest is.

Hoe kom je daarbij? Voor zover ik weet geeft de fabrikant of importeur met het CE-merk aan dat het product wat hen betreft conform is en is er hierbij sprake van self certification. Hoewel het lastig is te weten of een product voldoet zonder het te testen, lijkt testen geen vereiste om het merk te dragen. Dat is dan ook gelijk bron van kritiek.

Even los van dat het inmiddels ietwat off-topic is

[PageFault]

De discussie gaat een beetje de andere kant op, interessant, maar niet helemaal waar ik heen wil

Zoals het er nu naar uit ziet, maak ik weinig kans om de functions en properties te weten te komen, anders dan de scripts welke ik al heb, ben ik bang.

Iemand ervaring met het koppelen van COM/OLE objecten in Visual Studio? Kun je daar de functions zien wanneer je een niet-eigen (of reeds gecompileerd) component gebruikt? C++ of VB maakt me niet zoveel uit, ga geen grote spannende dingen doen.

[PageFault]

Gomez12 schreef op woensdag 15 februari 2017 @ 19:39:
[...]

Waarom niet gewoon bij de leverancier je vraag stellen dan? Hun zullen dat echt wel intern gedocumenteerd hebben. Kopietje van die pagina's van de interne documentatie moet toch zo te maken zijn mits je leverancier wel mee wilt werken maar het echt te druk heeft.

En dat ze in Februari al kunnen zeggen dat ze dit jaar andere prioriteiten hebben neigt bij mij ernaar dat ze het of zien als een gigantisch project of ze hebben er gewoon geen zin in, of je betaalt simpelweg niet genoeg.

Als ik 1 ding geleerd heb in het zakenleven is het dat elke prioriteit te veranderen is met geld. Er zit een beetje een apart luchtje aan het feit dat ze nu al weten dat ze er in de komende 10 maanden geen tijd voor hebben.

Hun software is een gigantisch (en complex!) project met vele andere partijen (Microsoft, Apple, IRIS, ThereFore, etc.), dus dat hun roadmap al redelijk vast is voor de komende 2 jaar, lijkt me vrij logisch. Ze hebben nog een stapel vacatures, dus als je nog werk zoekt als developer...

[yeep]

PageFault schreef op vrijdag 17 februari 2017 @ 20:37:
De discussie gaat een beetje de andere kant op, interessant, maar niet helemaal waar ik heen wil

Zoals het er nu naar uit ziet, maak ik weinig kans om de functions en properties te weten te komen, anders dan de scripts welke ik al heb, ben ik bang.

Iemand ervaring met het koppelen van COM/OLE objecten in Visual Studio? Kun je daar de functions zien wanneer je een niet-eigen (of reeds gecompileerd) component gebruikt? C++ of VB maakt me niet zoveel uit, ga geen grote spannende dingen doen.

Het is voor mij jaren geleden dat ik met native code heb gewerkt, maar als het een COM object is kun je deze gewoon als dependency toevoegen aan bijvoorbeeld een .NET (kan VB zijn) project en dan kun je volgens mij met de ingebouwde object explorer kijken welke COM functies beschikbaar zijn.

Als het een geregistreerd COM object is (is volgens mij een voorwaarde voor de werking), kun je een applicatie uit de Windows SDK gebruiken om er in te neuzen: https://msdn.microsoft.com/en-us/library/d0kh9f4c.aspx