Hey Im trying to crack the newest VBox 4.6.2 and I have stumbled on a bunch of possible OEP. How do i find out the correct one?

All help is appreciated

jabz

Before anyone here will help you, you need to post what you have achieved so far.

Apart from that there are numerous items on the board regarding this very topic.

/hobferret

sorry ok..i guess what im saying is i need help finding the correct OEP. i have read a lot of tutoirals on Vbox.. well not a lot but whatever is available, and every which one has a different method. When i use these methods on my program, i get different OEP possibilities. For example if i break on GetVersionExA i get in the part of code and a few lines up, i could see the stack being set up, with PUSH EBP.....and so on, if i break on GetVersion...i get the same result with the stack being set up..but at a different address. Furthermore when i have tried to trace it manually, i got to parts of code that looked like this

INT 3
INT 3
INT 3
INT 3
PUSH EBP
MOVE ESP,EBP
. ;so on
.
.
INT 3
INT 3
INT 3
PUSH EBP
MOVE ESP,EBP
. ;so on


as you can see, im clearly not sure what is happening, ill be glad if someone can explain this.
Thanks.
Jabz

I have been messing around with some VBox 4.6.2 protected apps that will go unmentioned here. I have tried to manually unpack it.

the first few bytes before the OEP, which set up the stack frame, are stolen, and you can reconstruct them if you carefully trace the last 10 to 20 instructions of the Vbox module, lost in between obfuscated code.

There are traps, so quick shortcuts, like braking in GetVersion and GetVersionExA often land in some senseless code which appears in partially unpacked-decoded segments but jump back into Vbox code.

I hope I made some sense

Naides

naides

I have never seen a VBox with stolen bytes, maybe I am wrong but unlikely

Most likely if you set a break on an API [NOT GOING TO SAY WHICH ONE] After the NAG you will be a few lines down from the EP, code may appear obfuscated if you just scroll up, however, if you look for the bytes which create the stack frame and then do U ADDRESS it will appear. It's the way some debuggers show the code following the break

If you wanna PM me a program that has STOLEN bytes I would like to see it

/hobferret

I have a target wrapped in VBox 4.6.2 that I want to unwrap. I have been using the tut written by Lunar_Dust as a guide. The first several steps match almost exactly even though the target app is different. However, I get completely lost when I try to find the OEP. I have tried breaking on GetVersion, but the code I get doesn't match the tut. I'm not sure where to go from here. Any help would be much appreciated.

BTW, I am brand new to unpacking. This is my first attempt.

maybe a bpm on access on the code section can help you.

GetVersion has been used and abused. It worked in old programs, not any more. Try reading HobFerret Tut, try Ricardo Narvaja manual unpacking tuts, do not stick to the tutors so tighly. They are good, Lunar Dust one is very well written, but they do not have universal applicability.

Where can I find the Hobferret tut? I have found it on the exetools forum, however, I am not elegible to download until I make "3 valid postings." As yet, I cannot talking intelligently enough about the subject to make such postings.

I have used google, etc. and there is not much out there on vbox 4.6.

PM me with the target, I would like to try my method of finding the OEP on this program.

hobferret tut:
http://www.exetools.com/forum/showthread.php?t=4160

%UNDEFINED%:

He already said he found it on the exetools forum, but couldn't download there yet. Paying attention is useful.


regards,

Well, sometime we are so anxious to be helpful, we forget to pay attention to the details. And a thank you to Naides for reminding me that this tut contains target specific information and, as such, is not appropriate for posting on this Forum. If you want to PM %UNDEFINED% I'm sure he can e-mail it to you or put it up somewhere where it might be permitted,

Regards,

I am so sorry JMI, I actually hadn't read it yet.

My thanks to Naides for catching that, I should have been more careful.

And you are right JMI, somtimes I get that way, I am not the most experienced Unpacker, I don't get into keygening or other types of R.E., so when someone asks for help on a packer target that I have spend many hours exploring, I tend to jump without thinking, but I guess that it why you are here.

Not to babysit or wipe my pooper, to moderate and protect this forum from honest mistakes as well as blatant disreguard or forum policy.

I thank you for not banning me for breakinig Woodmann rules.

We aren't really that heartless that we would ban you simply for violating a rule about attaching a tut with target specific code. At least not on the first instance. I had actually read it when it was first posted on exetools and I also had forgotten that it contained target specific code. It is sufficient that the error was recognized and corrected. Punishment is generally reserved for more flagrant and/or intentional violations. These rule are in place to protect the Board from efforts to shut it down and not as a tool for banning the unwarry or even careless.

Enough said.

Regards,

I have made some small steps, but steps none the less. After completing the code injection similar to what is described by Lunar_Dust, I used imprec and I still have lots of imports in the kernel32.dll that are still invalid. These invalid calls are to the vboxtb.dll that I used in my code injection. I tried all of the different trace options in imprec with no success. Does anyone have a clue what's going on and/or suggestions on a possible fix?

QUOTE REMOVED JMI

Letmein

If you look in the dissembly window in Imprec you will see that all point to the Vbox dll

Have you tried options 2&3 in Imprec?

Have you dumped the target at the OEP? Dont forget you need to put the CORRECT OEP inti Imprec or else it will all be bo****ks

If you want my tute on Vbox gimme a valid email address and I will send you what I have

/hobferret

Using either the "Quick Reply", on the bottom far right, or the "Post Reply" on the bottom left saves posting an unnecessary "quote" and saves room in the database.

Regards,

Yes I have tried options 2 and 3 in imprec. They didn't help. As for dumping at the OEP - how can I verify that. I set a breakpoint on GetModuleHandleA and stepped through the code as detailed by RemedY in his tut. Once arriving at the OEP, I did a dump - full... The one thing I'm fairly certain I didn't do was change the OEP in Imprec, but I didn't think that was necessary until I was ready to "Fix Dump"

Hi again

PM the target and I will try and help you

Regards

/hobferret

PM the target also I would like to check it out. Thanks.

LetMeIn

OK had a quick look and here is what I get

OEP @ 2DF1AE

IAT START 2E7000 END 2E78F8

No probs with Imprec except two which are easy resolved by disassemble/hexview

/hobferret

I have the OEP and the IAT Start the same as you. Where does the 2E78F8 factor in?

I'm still getting invalid imports in the kernel32.dll in addition to the 2 that you mentioned. There must be some minor detail that I'm missing. Is there a point when you let the program fully load? If so, does the code injection come before or after?

2E78F8 is the end of your IAT he's telling you your IAT is 8F8 long

Ok, so does that mean I need to change the "size" from 00001000 to 000008F8 under the "IAT Infos Needed" in Imprec?

And I thought that it was only me and JMI that were suffering brain cell death

Well said venom925 that would have been my reply

LetMeIn - - WAKEY WAKEY

/hobferret

thanks

Sorry, hobferret, what with my advanced age and all, I forgot what we were talking about.

Regards,

PUSH EBP ; Real entry point of SFX code
MOV EBP,ESP
PUSH -1
PUSH <removed by me >.482E63DC

forgive me ,hobferret, but would this not be the OEP if so its located at 96BC0 .

venom925

No that is not the OEP

Real OEP is 2DF1AE
2DF1AE 6A74
2DF1B0 PUSH 6858792E48

OK

JMI Dont worry you are only 1 year older than me

/hobferret

Hi to all

There is one thing I should mention:-

In the tute I wrote a while back forget about all that crap after breaking on GetProcAddress; just do a bpx on FreeLibrary and you are nearly at the OEP

/hobferret

hobferret:

I'm not worried. I just can't remember how old I am, so I don't know how young you are.

Regards,

JMI

Put it this way I was swimming down the old man's pipe when you were born

So you have 9 months start on me

/hobferret

Heck. Before you were born, I was already taking my first trip to Europe...... by boat, no less. No Wait. That was my only trip, but at least it lasted several years and the trip home was again by boat. Not too many of our generation who have made that trip in anything other than an airplane.

Regards,

Well then

In my job I have been round the world so many times I should be in the Guiness book of records

The only boat trip I have been on was between the north and south islands of New Zealand

I am in England now and staying here because I don't like the idea of flight anymore for obvious reasons and I ain't crossing the Atlantic in a boat at any price

/hobferret

Especially NOT in an empty cargo hauler. Up and down, side to side, up and down, side to side = barff, barff, barff.

It's not a journey, it's an adventure. Film at 11:00.

Regards,

Ok, I've worked on it some more and I still have the same problem - kernel32 imports. I have changed the size to 8F8 and the OEP to 002DF1AE. I have checked my code injection and it works. I still get an invalid kernel32 thunk. I'm completely lost.

I dont know what you are doing wrong but here is the kernel32 imports

Try and do the rest for yourself, you will never learn anything if someone else does the work for you

Better let everyone know where you are different

/hobferret

FThunk: 002E7148 NbFunc: 00000094
1 002E7148 kernel32.dll 0064 CreateProcessW
1 002E714C kernel32.dll 01EE GlobalHandle
1 002E7150 kernel32.dll 031A SetProcessWorkingSetSize
1 002E7154 kernel32.dll 0364 VirtualAlloc
1 002E7158 kernel32.dll 0367 VirtualFree
1 002E715C kernel32.dll 036C VirtualQuery
1 002E7160 kernel32.dll 021E IsBadReadPtr
1 002E7164 kernel32.dll 008D DuplicateHandle
1 002E7168 kernel32.dll 00B9 FatalAppExitW
1 002E716C kernel32.dll 032C SetUnhandledExceptionFilter
1 002E7170 kernel32.dll 02FA SetErrorMode
1 002E7174 kernel32.dll 00DC FindResourceW
1 002E7178 kernel32.dll 018E GetPrivateProfileStringW
1 002E717C kernel32.dll 0398 _lcreat
1 002E7180 kernel32.dll 0396 _hwrite
1 002E7184 kernel32.dll 01F3 GlobalSize
1 002E7188 kernel32.dll 0379 WinExec
1 002E718C kernel32.dll 0275 OutputDebugStringA
1 002E7190 kernel32.dll 0154 GetFileInformationByHandle
1 002E7194 kernel32.dll 0245 LocalFree
1 002E7198 kernel32.dll 01A5 GetShortPathNameW
1 002E719C kernel32.dll 016B GetLongPathNameW
1 002E71A0 kernel32.dll 0134 GetCurrentDirectoryW
1 002E71A4 kernel32.dll 038B WritePrivateProfileStringW
1 002E71A8 kernel32.dll 01CE GetTimeZoneInformation
1 002E71AC kernel32.dll 01D4 GetVersion
1 002E71B0 kernel32.dll 0214 InterlockedExchange
1 002E71B4 kernel32.dll 00F0 GetACP
1 002E71B8 kernel32.dll 02F7 SetEndOfFile
1 002E71BC kernel32.dll 039A _lopen
1 002E71C0 kernel32.dll 0395 _hread
1 002E71C4 kernel32.dll 0180 GetNumberFormatW
1 002E71C8 kernel32.dll 0166 GetLocaleInfoW
1 002E71CC kernel32.dll 0397 _lclose
1 002E71D0 kernel32.dll 0399 _llseek
1 002E71D4 kernel32.dll 0192 GetProcessAffinityMask
1 002E71D8 kernel32.dll 016D GetModuleFileNameA
1 002E71DC kernel32.dll 0157 GetFileTime
1 002E71E0 kernel32.dll 01B7 GetSystemTimeAsFileTime
1 002E71E4 kernel32.dll 0036 CompareStringA
1 002E71E8 kernel32.dll 03A9 lstrcpyn
1 002E71EC kernel32.dll 039D lstrcat
1 002E71F0 kernel32.dll 02B6 ResetEvent
1 002E71F4 kernel32.dll 0141 GetDiskFreeSpaceExW
1 002E71F8 kernel32.dll 010A GetComputerNameW
1 002E71FC kernel32.dll 00B4 ExpandEnvironmentStringsW
1 002E7200 kernel32.dll 0324 SetThreadExecutionState
1 002E7204 kernel32.dll 01B2 GetSystemInfo
1 002E7208 kernel32.dll 0050 CreateFileMappingW
1 002E720C kernel32.dll 0354 UnmapViewOfFile
1 002E7210 kernel32.dll 0251 MapViewOfFile
1 002E7214 kernel32.dll 006A CreateThread
1 002E7218 kernel32.dll 00BC FileTimeToLocalFileTime
1 002E721C kernel32.dll 01D5 GetVersionExA
1 002E7220 kernel32.dll 0138 GetCurrentThreadId
1 002E7224 kernel32.dll 02AD RemoveDirectoryW
1 002E7228 kernel32.dll 0164 GetLocalTime
1 002E722C kernel32.dll 01C3 GetTempPathW
1 002E7230 kernel32.dll 025E MultiByteToWideChar
1 002E7234 kernel32.dll 00B1 ExitThread
1 002E7238 kernel32.dll 00BD FileTimeToSystemTime
1 002E723C kernel32.dll 0153 GetFileAttributesW
1 002E7240 kernel32.dll 01D6 GetVersionExW
1 002E7244 kernel32.dll 0137 GetCurrentThread
1 002E7248 kernel32.dll 0169 GetLogicalDrives
1 002E724C kernel32.dll 0049 CreateDirectoryW
1 002E7250 kernel32.dll 0035 CompareFileTime
1 002E7254 kernel32.dll 0135 GetCurrentProcess
1 002E7258 kernel32.dll 0213 InterlockedDecrement
1 002E725C kernel32.dll 033D SystemTimeToFileTime
1 002E7260 kernel32.dll 0217 InterlockedIncrement
1 002E7264 kernel32.dll 0146 GetDriveTypeW
1 002E7268 kernel32.dll 01F0 GlobalMemoryStatus
1 002E726C kernel32.dll 0104 GetCommandLineW
1 002E7270 kernel32.dll 039F lstrcatW
1 002E7274 kernel32.dll 028C QueryPerformanceFrequency
1 002E7278 kernel32.dll 0337 SizeofResource
1 002E727C kernel32.dll 028B QueryPerformanceCounter
1 002E7280 kernel32.dll 02AA ReleaseMutex
1 002E7284 kernel32.dll 0172 GetModuleHandleW
1 002E7288 kernel32.dll 005C CreateMutexW
1 002E728C kernel32.dll 0041 CopyFileW
1 002E7290 kernel32.dll 0051 CreateFileW
1 002E7294 kernel32.dll 0221 IsBadWritePtr
1 002E7298 kernel32.dll 0155 GetFileSize
1 002E729C kernel32.dll 0188 GetPrivateProfileIntW
1 002E72A0 kernel32.dll 0037 CompareStringW
1 002E72A4 kernel32.dll 014B GetEnvironmentVariableW
1 002E72A8 kernel32.dll 03A0 lstrcmp
1 002E72AC kernel32.dll 0327 SetThreadPriority
1 002E72B0 kernel32.dll 00D4 FindNextFileW
1 002E72B4 kernel32.dll 00C6 FindClose
1 002E72B8 kernel32.dll 0338 Sleep
1 002E72BC kernel32.dll 023E LoadLibraryW
1 002E72C0 kernel32.dll 023D LoadLibraryExW
1 002E72C4 kernel32.dll 00CD FindFirstFileW
1 002E72C8 kernel32.dll 03A6 lstrcpy
1 002E72CC kernel32.dll 007E DeleteFileW
1 002E72D0 kernel32.dll 023B LoadLibraryA
1 002E72D4 kernel32.dll 0194 GetProcessHeap
1 002E72D8 kernel32.dll 0202 HeapFree
1 002E72DC kernel32.dll 01FC HeapAlloc
1 002E72E0 kernel32.dll 00EA FreeLibrary
1 002E72E4 kernel32.dll 03AC lstrlen
1 002E72E8 kernel32.dll 0206 HeapReAlloc
1 002E72EC kernel32.dll 029D ReadFile
1 002E72F0 kernel32.dll 0385 WriteFile
1 002E72F4 kernel32.dll 0300 SetFilePointer
1 002E72F8 kernel32.dll 0030 CloseHandle
1 002E72FC kernel32.dll 0372 WaitForMultipleObjects
1 002E7300 kernel32.dll 004B CreateEventW
1 002E7304 kernel32.dll 01CB GetTickCount
1 002E7308 kernel32.dll 02FB SetEvent
1 002E730C kernel32.dll 0374 WaitForSingleObject
1 002E7310 kernel32.dll 03A5 lstrcmpiW
1 002E7314 kernel32.dll 0191 GetProcAddress
1 002E7318 kernel32.dll 03A3 lstrcmpi
1 002E731C kernel32.dll 03A2 lstrcmpW
1 002E7320 kernel32.dll 016E GetModuleFileNameW
1 002E7324 kernel32.dll 03A8 lstrcpyW
1 002E7328 kernel32.dll 007B DeleteCriticalSection
1 002E732C kernel32.dll 0090 EnterCriticalSection
1 002E7330 kernel32.dll 0162 GetLastError
1 002E7334 kernel32.dll 03AE lstrlenW
1 002E7338 kernel32.dll 03AB lstrcpynW
1 002E733C kernel32.dll 023A LeaveCriticalSection
1 002E7340 kernel32.dll 020F InitializeCriticalSection
1 002E7344 kernel32.dll 024E LockResource
1 002E7348 kernel32.dll 01EB GlobalFree
1 002E734C kernel32.dll 01F6 GlobalUnlock
1 002E7350 kernel32.dll 01E4 GlobalAlloc
1 002E7354 kernel32.dll 01EF GlobalLock
1 002E7358 kernel32.dll 0378 WideCharToMultiByte
1 002E735C kernel32.dll 00E6 FormatMessageW
1 002E7360 kernel32.dll 0326 SetThreadLocale
1 002E7364 kernel32.dll 016F GetModuleHandleA
1 002E7368 kernel32.dll 01A6 GetStartupInfoA
1 002E736C kernel32.dll 0322 SetThreadAffinityMask
1 002E7370 kernel32.dll 0223 IsDBCSLeadByteEx
1 002E7374 kernel32.dll 02AB ReleaseSemaphore
1 002E7378 kernel32.dll 0241 LocalAlloc
1 002E737C kernel32.dll 0290 RaiseException
1 002E7380 kernel32.dll 00B0 ExitProcess
1 002E7384 kernel32.dll 0136 GetCurrentProcessId
1 002E7388 kernel32.dll 0240 LoadResource
1 002E738C kernel32.dll 00EC FreeResource
1 002E7390 kernel32.dll 00E0 FlushFileBuffers
1 002E7394 kernel32.dll 01F2 GlobalReAlloc

I thought its against the rules of posting iat or upload it here?!?!?!?!

esther

I dont think so because it is not program specefic i.e. nobody has named the program this bit of the IAT belongs to

/hobferret

And cutting and pasting will not get one a working IAT either.

Regards,

Many thanks to hobferret!! After the manual entry in the kernel32 FThunk I was able to "Fix Dump" and it worked!!! I have attached a word document that has the same Thunk that hobferret listed above. The missing entries I had are highlighted in red. If anyone cannot view the word document, let me know and I'll try an alternate format.

I would still like to know what caused my problem. If anyone discovers how or why this happened, please let me know. I would like to improve on my skills.

Thanks again to hobferret and others, I certainly couldn't have done it without you!!!

Justin

It would help if you outlined what and how you did it. i.e. where you dumped it, which version of Imprec you used and exactly what occured when you tried to get the kernel32 API's, what OS and version etc

/hobferret

I have a zip file of the tutorial I used for this project written by RemedY. It is even written using the same app I tried to unpack. I will gladly pm it to anyone who would like to see it. The text is in German, but the screen shots of code are in English. I used this tut in conjuction with the one written by Lunar_Dust to feel my way through this.

I am running Win XP Home Edition, I used Ollydbg 1.10, Imprec 1.6, and LordPE Deluxe.

I used a break on GetModuleHandleA and used alternating "Alt+F9" and "F9" commands to step through to the OEP. Once arriving at the OEP I did a "dump full..." with LordPE. I used Imprec to check invalid imports. Traced the code and found a empty place to inject my code (as outlined in the RemedY tut mentioned above). Used Imprec again to check that all my imports were valid and they were except for some of the kernel32.dll APIs. That's when hobferret stepped in and saved the day!

Hi again Justin

I don't know why you have found it necessary to "inject code"

The real easy way to find the OEP is to run the prog in Olly - when you get to the nag screen do a bpx on FreeLibrary - you are only a few steps from the EP - use F7 not F8

I use XP Pro with SP1 and have only had a problem with 2 User32.dll calls, the two usual suspects which have been mentioned all over the place

Anyways glad you have gotten it working but I am still confused why you have had to use code injection

/hobferret

I'm probably the one who is confused. I say "inject code" because of what Lunar_Dust did in his tutorial. Does he not use a form of code injection? Granted that it is very little code, but code nonetheless. I have also heard of this referred to as "Semi-automatic" IAT restoration.

Is there an easier way to restore the IAT?

could you please send me your tut about VBOX?

Thanks in advance

ThunderPwr

ThunderPwr

I would if I still had it locally, unfortunately I suffered a HDD failure on my Slave where all was kept so I dont have it anymore.

You can get if off Exetools site

/hobferret

New registrations are currently disabled on exetools while we catch up with the influx of new members.

Regards,

Rename to *.zip

hobferret's tut: (443 kb)
http://d-jester1.tripod.com/UVBXAPM_Hob.bmp

Lunar_Dust's tut: (756 kb)
http://d-jester1.tripod.com/UVBXFHMX_Lunar.bmp

Both tut's on VBOX 4.6

I'm trying to go back and figure out what happened with my IAT, so I'm trying to do it long hand by following Ricardo's manual IAT tuts. Following his method I sifted through the PE header of the section named for the target app and found the IAT starting at F1E20C and ending at F1E300 giving it a length of 140. In an earlier post hobferret showed the IAT start at 2E7000 and ending at 2E78F8 giving it a length of 8F8. Can someone help me understand?

Hi

If in doubt about IAT length etc:-

Get to the OEP in Olly then look for something like CALL DWORD PTR [ADDRESS]

Get that in the memory window then scroll up to the top of the block, that should be the first pointer, go down till you see a load of rubbish - you then are likely at the end of the IAT. Some progs have great big empty blocks in the IAT so you need to make sure you are at the finish

/hobferret

round and round I go...I have arrived at the same point in my second target app as I have in the first. I have the OEP located. I have the IAT located and sized. When I get the imports, all get resolved except the ones directed to the standard vbox routine. I have tried using Imprec 1.6. I have tried using Revirgin 1.2. I haven't had any success with either. I have tried using all the trace function in each program, but they just lock up or return with a fail. I'm sure the problem is user error.

Is there a way to manually trace through these calls to find the API after the vbox routine is completed? Am I missing a plugin that I need to be using?

Also, a special thanks to hobferret for his tireless support to get me this far.

if you have the offset of the redirected call which points into the vbox dll you can set a breakpoint on this offset and then wait until softice breaks then u can see the right api and fix the offset in imprec or revirgin.
btw it would be very nice if u could send me the name of the target via pm.

LetMeIn

Remember what I said before get to the OEP in Olly then look for something like CALL DWORD PTR [ADDRESS]. Any unresolved can be stopped in this block and then traced to see where you end up!

I still do not understand why you are having so much trouble, have you checked to see if the program is still running when you are trying to resolve the IAT?

Sometimes the program will crash out when you are tracing, that's when you encounter a fail or a read error! Don't know what else to say but it's got to be something you are doing wrong!

/hobferret

I know why I'm having so much trouble...I'm an idiot!!! I didn't have the program running while I was trying to use the trace options in Imprec. I knew that it had to be something simple.

I have traced out the IAT and I now have a working "unwrapped" exe.

Hobferret - Thank you so much for your patience and guidance. You fed me with just enough info to keep me going, but not so much that you gave it away. I couldn't have done it without you!

Since the discussion seems to be about HASP SL (Formerly Priviledge Client & Vbox)

I too am having difficulty rebuilding my IAT for Vbox 4.6 target all attempts with impREC return vboxtb:Ordinal 001

I understand why but Lunar_Dust spoke of using impREC's "Hook" and "Trap Flag" to find the decrypted API.

Aparently I am doing something wrong because neither work.

could someone either PM me or (if JMI is okay with it) upload their impREC.ini file so I can see if something is not set up right

I am working on XP Pro SP2; Logged in as Admin

Thanks

It would be best to leave these things to PM or email, rather than posting .ini files. If there was just a portion which was a problem, that would be one thing, but we do not want to be providing cookie cutter ini files for people to past into their cracking efforts.

Regards,

%UNDEFINED% -

Don't use trace level 1 (disasm). It will always return a vboxtb.

1. Make sure that in the bottom right hand corner of Olly that it says "running" and not "paused." Hint: let the prog completely load.

2. Use trace level 2 first on all unresolved. Some will trace some will not.

3. Use trace level 3 on the rest. It was my experience that the program crashed each time i ran this, so be prepared to restart each time. I suggest a hand written table so you don't lose your work or save and reload your tree each time.

Hope that helps!!

LetMeIn

%UNDEFINED% try raising your timeout in imprec sometimes this will find a few more imports i have mine set at about 300 ms also keep in mind the vbox keeps 2 calls for it self so youll have to find those for your self, very easy to do in olly