here's my lame readme about plugsapi [i've posted that lame plugs here]. and execuse me if any mistakes written here, any correction needed
. trw2000 consists a loader and a master plugs. i call it master plugs coz :
- it's a plugs indeed, but a master/main plugs
- it loaded first before other plugs, so it can provide api services
for other/slave plugs loaded later [what i called plugsapi].
in the plugs init routine of trw2000.sys, it first registering every local function that will be exported as plugsapi. these exported api were placed in one struct. the plugsapi struct declaration can be read at plugapi.h file. the struct itself not comprises plugsapi only, but some trw internal variable are there too.
what the plugsapi plugs coded by me doing is just dumping this struct with address related to each struct members. so u can see directly to those addresses and recognize these function's names
. then u can busy to rename all the function in ur disasembled list of trw2000.sys file. from here u have had little knowledge to reverse the master plugs.
now, after registering each struct members, the master plugs enumerates slave plugs and load it. i don't know yet what the rule used to load the slaves here. i bother with rule coz ordinary vxds are using it. its called InitOrder. but the case here is, the first loaded plugs is always master plugs, and there's no plan from author to let slave plugs providing another plugsapi service set to enhance the plugs functionality.
when a plugs loaded, execution gets in to plugs init proc, where u can see the param passed to this proc is a ptr named [PLUGS_API* plugsapi]. i don't know who is passing this ptr, but i guest the master plugs is the one who did it when loading plugs, bcoz the only one who knows his own locals functions address is master plugs, right? that's why every plugsapi called in plugs src code have form like: api->???. if u see it in assembly form, its looks like this:
call dword ptr [e?x+??h]
where the e?x contain ptr passed by master plugs.
after initialization proc, slave plugs are ready to receive cmds or do something else.
so, the point is... this plugsapi method is rather diff with vxdservices method, in which the master plugs don't have to 'snaps' the slaves apicall for the 1st time.
hmm... is there anyone imagine the add_api like implementations here
. if there is, then here's i tell what come to my mind when thinking about it:
- the export table must have one method, that is add api entry.
- if there's unload scenario here, the plugsapi service provider
responsible to handle dead entry and to redirect that dead
entry to return false/true to the caller. huh... that's hard,
isn't it?
- make plugsapi set proto in a separate header file
- make a rule in loading, or load order. the provider must have
top priority before users, right? here maybe we can use an INI
file instead of... argh, i don't know how WDM's DDB looks like.
- ok, say the new plugs provider loaded by master plugs, and he
had an export table. then who'll load the users of that new
provider? if its master who load it, then master plug have to
somehow registering new plugsapi set and snaps the users link,
right? how complicated it is...
- anyone wants to do this...
.
There are software and hardware breakpoints. 