Iris 3.00 (tE!lock8 + Sheriff Licence System)
=============================================
Ok, back to reality. I tried again to play the 4 versions of violin I bought...
as well as the piano(Win32) but my violin system still can't see my VGA card or
my USB ports.....I don't have a T1 to D/L the latest CD.img .... :-(
So I revereted back to the piano (Win32) and hacked around Iris3 from eEye.com.
Ahh that's a better tune....
Ok my old friend Laurentiou made a *new* version. But wait WTF is new ? Well
packing it with tE!lock instead of PeShiELD is a new erm , challenge ! , -ok
don't snigger at the back. Some ppl can't get past this new protection. As the
target is 'protected' with tE!lock you should D/L it from www.exetools.com and dump/rebuild it then
IDA it to study what tE! has done. See that latest 'dummy' section renaming tool
? Fake a known packer like UPX or CryptX
I found some interesting stuff. But what I was after was the 'end-point'. Where
tE! code gives control back to Iris.exe
Have a look at your 'rebuilt' tE! disassembly. I found some interesting code at
:-
.SEC:004098F6 mov ecx, 109h
.SEC:004098FB lea edi, unk_409909[ebp]
.SEC:00409901 mov esi, edi
.SEC:00409903
.SEC:00409903 loc_409903: ; CODE XREF: .SEC:00409907j
.SEC:00409903 lodsb
.SEC:00409904 xor al, [esi]
.SEC:00409906 stosb
.SEC:00409907 loop loc_409903
(It will only be interesting to *YOU* once you've reversed tE!lock and study it
a while

)
This 'loop' injects the last interesting bit of code before revealing the OEiP
and passing the hand back to the original exe. This code is fixed in every tE!
lock protected app. So we could call it the 'signature' bytes. So we need to
search for the following series :- "B9,09,01,00,00,8D,BD,09,99,40,00,8B,F7" at
an appropriate moment. In Win98/ME run icedump with /protect on and set eax to
the same number less 80000000 (eg eax= 8010604E then set eax = 10604E) to
bypass the IDT check. Now search with SI for the bytes. Found here at VA 55FEEE
so set a BPX 55FEEE and press F5. SI pops so press F10 until the 'loop' is
finished. Now press F8 until you see the usual POPAD (here at VA 56005) and you
are there at OEiP 46286C. Now, for those of you new to tE!lock, you will not
know that he plays with the PE header. Namely that he makes the section counter
to FFFF instead of 0500 (or no. of sections there really are - reverse byte
order) so you need to put this back at 400000+PE+7th&8th bytes. Now you can
EBFE or use ICEdumps PEdump ? err no cos the IT is f*cked as well. Check out
the mapping/destroying of the IT at offset VA 483318+ Either let it map the
IAT/IT then dump the exe to copy+paste this IAT/IT in a destroyed OEiP DMP or
use RV to rebuild the IAT/IT
for you.
Fix up the DUMPED.EXE and it should run ? NO ? WTF!. Well check out another nice
feature of tE!lock The MUTEX. Don't run away screaming in phear. Laurentiu just
checks for the existence of a child-process in memory. What is he looking for ?
well would you guess he chose the name "IrisMutex". OMG what a big clue. So 2 or
3 things to do. 1) make notepad.exe protected in tE!lock with the same name
mutex and run it. Launch Iris 3 and it should run. :-) and it does, Q.E.D. Repack
Iris Dump with tE!lock...erm we aint finished playing yet ! or reverse a JMP
So lets be coding gods and REVERSE A JMP ! Set a BPX CreateMutexA and fire up
your dumped.exe and SI will pop at 4473C1. See GetLastError call. He checks for
the 'IrisMutex' if found eax will return with an expected result 'B7'. See that
JNZ 4474D0 well make it a JE 4474D0. That fixed it ! Cool I just joined the
l33t
