New OllyDbg detection by Armadillo?

I just ran across something quite strange today. I am examining the target TheaterTek 2.11 with OllyDbg.

I have HideDebugger and the OutputDebugStringA patch installed. I also renamed Ollydbg.exe to "this.exe"

When I examine the code with Version 2.0 of TTek, I find there are 3 subroutines concerning ArmAccess. VerifyKey, InstallKey, and EnvironmentUpdate.

When I step through version 2.0 these routines confirm LoadLibraryA of armaccess.dll (inside the packed exe) and it jumps into the 39xXXX range which is where the Armadillo code is located within TTek 2.0.

This is good. Now here is where it changes.

I installed the 2.11 patch and now the same 3 routines fail to LoadLibraryA of armaccess.dll. Matter of fact there are a bunch of CALL ESI routines for checking USERNAME, USERKEY that no longer point to the 39xXXX range. They now show CALL ESI; kernel32.GetEnvironmentVariableA.
*NOTE: When you unpack the armadillo .exe file these CALL ESI do show as kernel32.GetEnvironmentVariableA, but never inside the original packed code till now.

When you close Olly and execute the original 2.11 exe file, it does check the ArmAccess information.

Does anyone know why the original packed Armadillo .exe would no longer point towards the internal Armadillo code between 2 versions of the program?

PeID .93 reports Armadillo 3.78

Any help would be appreciated.

I was able to get the new 2.11 version to run properly within Olly.

If I used the OllyScript I had to finding the Arm OEP, the program would not work properly within Olly.

If I used the manual bp CreateThread method to find the CALL ECX then I was able to get the the OEP. This time around all routines worked as expected within Olly.

So I modified the TEAM RES script to allow it to work with my application. You may want to try it.

Also I found that using the bp Virtual Protect method is not working this time around. There are actually 17 occurances of PUSH 14 all at the same address. If I follow the code below the PUSH 100 and bp on the next CALL... then step into the CALL and place a RETN... then SHIFT+F9... the program runs then terminates.

Any ideas?