On Fri, 19 Dec 2008 10:55:54 +0100, Danny Backx <danny.ba...@scarlet.be>
wrote:
> 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
>
No I think you are right, this is the way to go.
> 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
>> >>
>> >
>
--
Vincent R.
------------------------------------------------------------------------------
_______________________________________________
Cegcc-devel mailing list
Cegcc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
