nachin da...

vidia argumentite koito poema edna fkt ot dll i return type-a na fkt-to. ima li takyv nachin. triabva li da se reassemblira? blagodaria predvaitelno. programi koito go praviat syhsto vyrshat rabota, no mi e interesno dali ima nachin.

spored men nqma

no vse pak mnogo shte se zaradvam nqkoi obori moeto mnenie :)

DEassemblira e rabotata, no i s tova nqma da stane...

ti kato hvanesh argumentite kakuv tip sa shte znaesh li koi za kakvo e ?...

trqbva dokumentaciq za tazi fkt (20 sec go mislih kakvo e tova, nadqvam se 4e e function :))

inache tozi vupros i men me e zanimaval dosta
loshoto e che nishto ne moje da se napravi...

by Wise Guy
[email protected]

dali i deassemblira (na bg), ili reassemble na engl. ne iskam da sporia...
a kato hvana argumentite kakyv tip sa, i kakyv e tipa na vryshtane shte moga da si importna funkciata i da ia izpolzvam, ne i iskam source, i ne iskam da znam kak raboti. neshto kato cherna kutia, chatkash li? ako ne chatkash zaebi:)
inache bi bilo got da se razbere neshto poveche po vyprosa...

s REassemblirane shto da ne stane? kakvo iskash da kajesh che ne moje da stane? criptirat fuknciata li kvo li?

"Дезасемблира" на български (заедно със всичките възможни варианти на произношението). "Disassemble" на английски. В общия случай, ако знаеш асемблер за i386 задачата е сравнително проста. Ако не знаеш асемблер най-вероятно въобще няма да се справиш. Точка.

pyrvo ima malka razlika mejdu dos assembler i 32bit assembler. i vtoro ako znaesh "malko" i386 (??) asm, tova vyobshte ne oznachava, che shte se spravish. i treto pitah dali ima nachin da se vidi/izvadi/dopostroi export table-a na dll-file-a. i dali niakoi znae neshto poveche za formata/specifikaciata (osven che e podoben na pe) na tozi tip fileove (govoria za windows, 32bitovi registri, 32 bitovi dyljini na dumite, x86 cisc tehnologia;) ). ne sym pital za znachenietzo na niakakva duma; ako me interesuvashe tova shtiah da otida v klub filosofia i da razgadavam smisyla na sveta, ili v klub literatura i drujno da chetem "pod igoto" i da se gnevim za chernite porobiteli... aman ot vseznmaikovci, kato ne znaesh ne pishi...

допускам, че нямаме debug info (DBG, SYM или PDB файл).
ако DLL-то е писано на C++, и фунцията е export-ната по име, и не е премахнат C++ name mangling-a, точно по този name mangling може да се определят параметрите.
виж например имената на export-натите функции от msvcp60.dll

иначе без дизасемблиране и последващо изследване на функцията няма как да се мине. изследването е необходимо не само за определяне типа на параметрите, calling convention-a и т.н, но и за значението на параметрите.. защото ако имаш функция int foo(int, int) - това не ти дава кой знае каква информация за използването й...

sys sigurnost move da se widqt tezi parametri kakwi sa, sled kato edno quickview go prawi. a wyw VS maj ima nqkakyw tool, kojto wyr6i rabota.

stoj, ta gledaj

Не съм много навъре с асемблера, но с него най-много да фанеш броя на параметрите, calling конвенцията и най-много размерите на предаваните параметри. И после какво ще правиш ако са някакви сложни структури или указатели към такива. Просто никога няма да го нагодиш. Този случай е естествено при export-ване на C функции. А в някои случаи може и имената да не можеш да видиш.
Ако се export-ват по C++ начин има начин да хванеш всичко но това е компилаторно зависимо. С VC++ е по един начин с Borlad C++100% е по друг. Но дори и при С++ начин пак могат да се скрият имената. Тогава остават само ID-та е export таблицата. За пример виж MFC42.dll.
Та искам да кажа че това е умряла работа.

Положението въобще не е толкова черно колкото изглежда на пръв поглед.
Като започнем с това че съвременните дизасемблери са доста по интелигентни от едновремешния debug. Така че почти сигурно ще хванеш броя/размера на параметрите (или поне на повечето :-) само като разгледаш дезасемблираната функция. Що се отнася до хващането на смисъла на това което се подава, просто не трябва да гледаш самата функция, а този който я вика. В повечето случаи параметрите, включително указателите към структури и самите структури се настройват непосредствено преди извикването на функцията така че може да видиш настройката на параметрите и това как се подготвят. Освен това може просто да прехванеш извикването няколко пъти и да видиш какво се подава, така че да хванеш някакъв общ принцип по който се подготвят параметрите. Основното е да имаш _много_ време и нерви. Впрочем не мисля че дискусията ще е от полза за coder-а който изглежда че не се разбира много с асемблера (или поне докато си мисли че под DOS не може да се работи с 32-битови сегменти по подразбиране :-)

prav si za nerazbiraneto mi za asm-to... no diskusiata (stiga da e dobre argumentirana, a ne samo zaiajdane) shte mi donese malko polza... ne znam no sym ostanal s vpechatlenieto, che tia koito se pravat na nai-znaeshti se okazvat nai-golemite dyrveta... kakto i da e, a ia sega mi kaji kato si takyv razbirach, kakvo imash predvid pod podgotviane na argumentite? zashto ne kajeshmalko poveche, ili e po-dobre horata da si ostanat s vpechatlenieto che razbirash mnogo kato govorish malko:)...

pak kazvam, aman ot prazni glavi:)

Няма кой знае какво повече за казване. dll-те са стандартни New Executable файлове, всяка документация за формата майкрософтовските exe файлове ще ти свърши работа. Мисля че на [линк] трябва да има нещо в раздела за windows. В общия случай може да разбереш имената на функциите, не повече. Ако файла е някакъв вид COM обект може да го разгледаш чрез някаква програма от типа на COM-viewer-а който е към Visual Studio 6. Тогава ще видиш и броя на параметрите/типа им. В общия случай обаче ако имаш обикновен dll, трябва да го дизасемблираш/трасираш. Ако можеш да го трасираш най-добре е да трасираш около мястото където клиента го вика, защото ще можеш да видиш calling конвенцията, броя на параметрите и техния размер, без никакъв проблем. Освен това параметрите най-често се изчисляват непосредствено преди викане на функцията, така че имаш шанс и да видиш горе-долу какъв им е смисъла. Ако дебъгера е поне малко интелигентен ще може да сравниш на момента дали някой от параметрите е window handle или нещо подобно. След това вече можеш да разгледаш кода на самата функция и да видиш какво прави с параметрите. Само ти трябва малко повече време. Отделно по мрежата има няколко полуработещи декомпилатора за повечето стандарти компилатори на C. Ако се разровиш ще ги намериш. Ако не друго с тях може да разбереш какъв компилатор е ползван. Ами т'ва е. Общи приказки, ама какво друго да ти кажа. Проблема си е изцяло твой, де. Така или иначе най-вероятно няма да разбереш смисъла на параметрите ако са повече от 3-4, без да схванеш горе долу каква е логиката не функцията.

мъничка поправка само.
DLL-тата Win32 са във формат Portable Executable, (New Executable беше формата в Win3.x)

и функциите съставящи COM интерфейсите не се експортират като функции от DLL-то (OCX или там каквото му е разширението).

iasno, sega shte se chete...:)
blagodaria

> мъничка поправка само.
> DLL-тата Win32 са във формат Portable Executable, (New Executable беше
> формата в Win3.x)
Наистина съм сбъркал. Сутринта преди да пиша тук, хвърлих поглед на един DLL. Явно съм видял PE, kato NE в хедъра. Така или иначе вече от доста време не съм съвсем в час с това което става под Windows, а и 2-та формата най-често се описват заедно в документациите, така че не съм го излъгал (поне не много :-)

> и функциите съставящи COM интерфейсите не се експортират като
> функции от DLL-то (OCX или там каквото му е разширението).
Не съм го твърдял никога. Но ако DLL-а е от някоя програма, която се е изпълнявала на компютъра му, най-вероятно компонентите вътре вече са регистрирани, и някой viewer ще ги покаже без проблем, като ползва стандартните функции за работа с компонентните.