EDIT:Thanks JMI, I will try my best to keep within the spirit of this forum.

EDIT:UPDATE
Ok, here is the start of the data that is accessed by the code I showed,
I should've included this info before.

007A5000 00001000 ; is the baseRelocRVA for this chunk of reloc's
007A5004 0000015C ; is the sizeof this chunk including the first 2 DWORDS
; each of these WORDS are the RVA'S of the reloc's themselves
; although unlike microsofts version, each relocRVA is relative
; to the previous relocRVA's in this chunk
007A5008 3000 0016 0012 0018 000C 0010 0020 000C
007A5018 0004 0004 0004 0004 0004 0004 0004 000C
... etc.

Now that I look more closely at the data that is accessed by the code,
I realize that the data is definetly in pecompact's own format. Yes I know
it's obvious.
I guess I got confused when glancing at the data because the pecompact reloc
format is somewhat similiar to microsofts format and I didn't examine the data as closely
as I should've and made some wrong assumptions and thus when I stepped through
the code below and it didn't behave as I assumed it should, I got confused.
Everything is clear now.

Although I don't understand why pecompact put the reloc's in this format,
from what I can tell it gains nothing.It'll use the same space, and add a few
extra calculations.


EDIT:UPDATE END

I'm working on unpacking a dll that was according to peid packed with
"PECompact 1.68 - 1.84 -> Jeremy Collake".

I found oep, dumped with lordpedlx, found iat start/size manually in olly,
used import REC to create fix the import table,
then tried to run exe that uses this dll, which also used to be packed with pecompact
and the program wouldn't run, would give access violations.

Searched (here and on the web) about unpacking dll's and read about relocations (and have the tut on this version posted here), which I already knew about but didn't come to mind while I was working on this target, doh!


So I find the pecompact code that does the relocations and the start of the relocations data,
but I'm confused with some things.


007AC699 ADD EDX,DWORD PTR SS:[EBP+4090E6] ; basereloc_rva + imagebase
007AC69F LODS DWORD PTR DS:[ESI] ; get reloc sizeofblock
007AC6A0 MOV ECX,EAX
007AC6A2 SUB ECX,8 ; get #of relocs for this chunk
007AC6A5 SHR ECX,1 ; ""
007AC6A7 MOV WORD PTR SS:[EBP+409755],0

START OF LOOP THRU RELOCATION (type/offset words)
*********************************************************
007AC6B0 XOR EAX,EAX ; clear eax, duh
007AC6B2 LODS WORD PTR DS:[ESI] ; get the reloc (high 4 bits)type/(low 12 bits)offset
007AC6B4 OR EAX,EAX
007AC6B6 JE SHORT OneWay.007AC701 ; check if zero

This next bit of code is what confuses me, why are they adding to each relocation WORD (type/offset WORD) ?
I thought they weren't relative to each other but instead each one was relative to "base RVA of the relocation
chunk".

007AC6B8 ADD AX,WORD PTR SS:[EBP+409755] ; WTF? add last relocword to new relocword ? and on and on ?
007AC6BF MOV WORD PTR SS:[EBP+409755],AX
007AC6C6 PUSH EAX ; save reloc type/base
007AC6C7 SHR EAX,0C ; calc type of reloc
007AC6CA CMP EAX,1
007AC6CD JNZ SHORT OneWay.007AC6DD
007AC6CF POP EAX
007AC6D0 AND EAX,0FFF
007AC6D5 ADD EAX,EDX
007AC6D7 ADD WORD PTR DS:[EAX+2],BX
007AC6DB JMP SHORT OneWay.007AC701
007AC6DD CMP EAX,2
007AC6E0 JNZ SHORT OneWay.007AC6EF
007AC6E2 POP EAX
007AC6E3 AND EAX,0FFF
007AC6E8 ADD EAX,EDX
007AC6EA ADD WORD PTR DS:[EAX],BX
007AC6ED JMP SHORT OneWay.007AC701
007AC6EF CMP EAX,3
007AC6F2 JNZ SHORT OneWay.007AC700
007AC6F4 POP EAX ; restore reloc type/offset
007AC6F5 AND EAX,0FFF ; get offset of reloc word (low 12 bits)
007AC6FA ADD EAX,EDX ; add reloc rva to imagebase
007AC6FC ADD DWORD PTR DS:[EAX],EBX ; DO THE RELOC ! ebx = diff. in imagebases
007AC6FE JMP SHORT OneWay.007AC701
007AC700 POP EAX
007AC701 DEC ECX ; decrement the #of relocs left in this chunk to process
007AC702 JNZ SHORT OneWay.007AC6B0
****************************************************************
END OF LOOP THRU RELOCATION (type/offset words)

007AC704 JMP SHORT OneWay.007AC692
007AC706 RETN

Do any of you know if "PECompact 1.68 - 1.84" keeps the relocation in it's original form ?
If so I'm confused how relocations table is used, I got my info from
win95 system programming secrets--pietrek.

I was hoping someone more experienced would take a look and see if I'm just
misinterpreing the code in that section.