The maximum size of the log would be limited to the size of RAM with this
solution.
Is there a way to do this with a database or the file streaming API?
----- Original Message -----
From: Bobby Kolev <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, August 19, 1999 1:44 PM
Subject: Re: How to save data from *any* patched API call? (Hack/patch
related)
> Below is something I believe I mentioned recently. This time I just found
> the mail and enclose it.
> BGK
>
>
> The technique I use (example is of patching DmOpenDatabase, stripped of
> error checking) is:
>
> // My global data.
>
> typedef struct {
> various global data
> } GlobalsType, *GlobalsPtr;
>
> // Special structure used to create a snippet of code, which gets called
> // as the patched routine, sets up the global ptr, and then jumps to the
> // real patch code.
>
> typedef struct {
> Word opCodes[3];
> VoidPtr codeP;
> GlobalsPtr globalsP;
> } PatchType, *PatchPtr;
>
> // Snippet of patch installation code.
>
> GlobalsPtr gP = (GlobalsPtr)MemPtrNew(sizeof(GlobalsType));
> MemPtrSetOwner(gP, 0);
>
> PatchPtr openDBPatch = (PatchPtr)MemPtrNew(sizeof(PatchType));
> MemPtrSetOwner(openDBPatch, 0);
>
> // set up code to do move.l *+8,a0 followed by jmp instruction.
>
> openDBPatch->opCodes[0] = 0x207A;
> openDBPatch->opCodes[1] = 0x0008;
> openDBPatch->opCodes[2] = 0x4EF9;
>
> openDBPatch->globalsP = gP;
> openDBPatch->codeP = DmOpenDatabasePatch;
>
> SysSetTrapAddress(sysTrapDmOpenDatabase, openDBPatch);
>
> // DmOpenDatabase patch. This gets called with the pointer to
> // globals in register a0.
>
> static DmOpenRef
> DmOpenDatabasePatch(UInt cardNo, LocalID dbID, UInt mode)
> {
> GlobalsPtr gP = GetGlobals();
>
> // do stuff in the patch code.
> }
>
> // Return a pointer to our globals. Since they get passed to us in A0,
> // and we're returning the GlobalsPtr result in A0, we don't need to
> // do anything expect help the compiler generate appropriate code.
>
> static inline asm GlobalsPtr
> GetGlobals(void)
> {
> } // GetGlobals
>
> >An even better approach would be to just allocate the extra needed
> >space on the front of your "globals" chunk so you only allocate one
> >chunk. This will probably require some clever inline assembly to put
> >it all together, but it is possible. Probably would make for a good
> >tech note since it solves the issue of having access to globals in
> >code that runs at interrupt time.
>
> To do this, you'd put a PatchType record at the beginning of the
> GlobalsType record, and do only one allocation - plus the first opcode
> would need to change to load the address of the instruction into A0. I had
> them separated since I was patching several different traps, all of whom
> wanted to share the same global pointer.
>
> -- Ken
>
> -----Original Message-----
> From: Todd L. Cignetti <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> Date: Thursday, August 19, 1999 12:11 PM
> Subject: How to save data from *any* patched API call? (Hack/patch
related)
>
>
> >Greetings,
> >
> >I understand that some API's should not be patched, but I need to do it
> >anyway, for a school project. Let's say I wanted to make an ordered list
> of
> >every system call that occurred, as it occurred. I could patch every
> >individual system call, in HackMaster fashion, to update a log database,
> and
> >then call the regular system call. More simply, I could replace the trap
> 15
> >handler with a new handler that would log each system call to a database,
> >and then jump to the regular trap 15 handler.
> >
> >The problem is where to store the log? The Feature manager is not
> >re-entrant (probably not a good place to write a big log anyway). I
would
> >guess the database functions are not re-entrant either.
> >
> >Is there a good way to save this data? Is there any possible way to save
> >data from *any* patched API call? Would allocating a big hunk of dynamic
> >ram work? (I know it would be rude, possibly even evil, but would it work
> >for this toy school project?)
> >
> >-Todd
> >
> >
> >
> >This post was sortof related, so I included it:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Post from 7/23/99:
> >At 5:29 PM +0000 1999/07/23, [EMAIL PROTECTED] wrote:
> >>Does Palm have a list of which traps should "absolutly not" be trapped ?
> >>It would be very helpfull to have something to reference when writting
> >>trap code.
> >
> >They're listed in Appendix A of the Palm OS documentation under the
heading
> >"System Use Only Functions". Not listed there, however, are all APIs
> >beginning with 'Hwr' and 'Prv' which are also very much off-limits.
> >
> >Also note there may be issues with trap patches installed from HackMaster
> >hacks for otherwise seemingly legitimately patchable public APIs, due to
> the
> >need to call the feature manager from within the trap patch to obtain the
> >call-through address.
> >
> >For example, if the patched API is ever called from within an interrupt
> >service routine, system kernel timer, or pre-emptive background thread
(to
> >name a few). The feature manager is not re-entrant for these cases, so
> >FtrGet will eventually crash the device, which could possibly destroy the
> >user's data depending on which API had been patched.
> >
> >This list is obviously incomplete, but it's a start. Hope the info helps!
> >
> >Regards,
> >
> >Jim Schram
> >3Com/Palm Computing
> >Partner Engineering
> >
> >
> >
>
>
