This doesn't look like a structure that's included in one of our tools,
it looks like something that might get filled up when our DLL gets
loaded.
Then we would need to figure out which entry in the structures created
by binutils and/or gcc is responsible for filling up this field.
Or am I completely on the wrong track ?
Danny
On Fri, 2008-12-19 at 10:35 +0100, mosfet wrote:
> On Thu, 18 Dec 2008 20:26:05 +0100, Danny Backx <danny.ba...@scarlet.be>
> wrote:
> > What's an o32_ptr ?
> >
> > Does all this mean that we're not filling up a structure in the DLL, and
> > that UPX is doing the right thing but we're not ?
> >
> > Danny
> >
> Yes o32_ptr is part of the PE format :
>
> //
> // MODULE structure, one for each DLL
> //
> struct _MODULE {
> DLIST link; /* Doubly-linked list to link all
> modules (must be 1st) */
> PMODULE lpSelf; /* ptr to self for validation */
> WORD wRefCnt; /* ref-cnt (# of processes loaded
> this module) */
> WORD wFlags; /* module flags */
> ulong startip; /* entrypoint */
> LPVOID BasePtr; /* Base pointer of dll load (not 0
> based) */
> PMODULE pmodResource; /* module that contains the
> resources */
> e32_lite e32; /* E32 header */
> LPWSTR lpszModName; /* Module name */
> DWORD DbgFlags; /* Debug flags */
> LPDBGPARAM ZonePtr; /* address of Debug zone */
> DWORD dwZone; /* the zone value */
> PFNIOCTL pfnIoctl; /* LoadKernelLibrary specific -
> entry to IOCTL funciton */
> openexe_t oe; /* Pointer to executable file
> handle */
> o32_lite *o32_ptr; /* O32 chain ptr */
> };
>
>
> /*
> * OBJECT TABLE
> */
> typedef struct o32_lite {
> unsigned long o32_vsize;
> unsigned long o32_rva;
> unsigned long o32_realaddr;
> unsigned long o32_access;
> unsigned long o32_flags;
> unsigned long o32_psize;
> unsigned long o32_dataptr;
> } o32_lite, *LPo32_lite;
>
>
>
> and as you wrote UPX is doing the right thing, I don't know exactly how but
> maybe when compressing and uncompressing
> it fixes the issue with o32_ptr.
>
>
>
> > On Thu, 2008-12-18 at 10:38 +0100, mosfet wrote:
> >> Hi,
> >>
> >> Thanks to a great Windows Mobile Hacker/tweaker mamaich, he has found
> why
> >> cegcc binaries are not loaded on WM6.1 platforms.
> >> Please find below his analysis :
> >>
> >> KITL output:
> >>
> >> 167564 PID:97eeb752 TID:b5980c3a CertVerify: \testDllexe.exe trust = 2
> >> 167635 PID:97eeb752 TID:b5980c3a CertVerify: testDll.dll trust = 2
> >> 167642 PID:b5980d96 TID:b5980c3a Data Abort: Thread=9662ea18
> >> Proc=908c0810
> >> ''
> >> 167645 PID:b5980d96 TID:b5980c3a AKY=00002105
> >> PC=9057048c(NK.EXE+0x0003048c) RA=000000e4(???+0x000000e4) BVA=78215000
> >> FSR=00000007
> >>
> >> The function NK.EXE+0x0003048c == PageInModule. It is called by
> >> LoaderPageIn.
> >>
> >>
> >>
> >> Disasm:
> >>
> >> 9043146C PageInModule ; CODE XREF:
> >> LoaderPageIn+1E4p
> >> 9043146C ; DATA XREF:
> >> .pdata:90518270o
> >> 9043146C
> >> 9043146C var_3C = -0x3C
> >> 9043146C var_38 = -0x38
> >> 9043146C var_34 = -0x34
> >> 9043146C var_30 = -0x30
> >> 9043146C var_2C = -0x2C
> >> 9043146C var_28 = -0x28
> >> 9043146C
> >> 9043146C STMFD SP!, {R4-R11,LR}
> >> 90431470 SUB SP, SP, #0x18
> >> 90431474 MOV R2, R1
> >> 90431478 MOV R6, R0
> >> 9043147C MOV R3, #0
> >> 90431480 MOV R4, R6
> >> 90431484 LDRH R1, [R4,#0x70]!
> >> 90431488 SUB R3, R3, #0x1000
> >> 9043148C LDR R0, [R6,#0xC4] <----
> >> crash
> >> is here
> >>
> >> 90431490 AND R5, R2, R3
> >> 90431494 MOV R2, R5
> >> 90431498 MOV R11, #0
> >> 9043149C BL FindOptr
> >> 904314A0 MOVS R10, R0
> >> 904314A4 MOVEQ R4, #0
> >>
> >>
> >>
> >> Here is equivalent source code :
> >>
> >> int PageInModule (PMODULE pMod, DWORD addr)
> >> {
> >>
> >>
> >> // ...
> >>
> >> e32_lite *eptr = &pMod->e32;
> >>
> >> // use page start to page in
> >> addr &= -PAGE_SIZE;
> >>
> >> if (!(optr = FindOptr (pMod->o32_ptr, eptr->e32_objcnt, addr)))
> >> // fail if can't find it in any section
> >>
> >> return PAGEIN_FAILURE;
> >>
> >>
> >>
> >> Obviously pMod structure here is broken.If you'd look into LoaderPageIn,
> >> you'll see that it walks through a zero terminated linked list of
> modules
> >> with the first element points to the next. And the last element
> describes
> >> your DLL and its pMod->o32_ptr is invalid.
> >>
> >> o32_ptr is filled from PE header, so there should be something wrong in
> >> PE.
> >>
> >> I've looked into the DLL, it has 14 sections - too much as I think. Try
> >> to
> >> compile it without debugging info.
> >>
> >> One workaround that makes your DLL work is compressing it with UPX:
> >> http://upx.sourceforge.net
> >>
> >>
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas,
> >> Nevada.
> >> The future of the web can't happen without you. Join us at MIX09 to
> help
> >> pave the way to the Next Web now. Learn more and register at
> >>
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> >> _______________________________________________
> >> Cegcc-devel mailing list
> >> Cegcc-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/cegcc-devel
> >>
> >
--
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info
------------------------------------------------------------------------------
_______________________________________________
Cegcc-devel mailing list
Cegcc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
