API's that are replaced are all those what executable uses for accessing outside files and libraries. If our file wants to open some file, Thisntall will check is that file bundled as a virtual file. It just compares name of that file with internal list. If file is bundled, it will allocate block for it, extract it and return it's handle to main exe.
If file is not bundled, then it will use acctuall API to open that file. In case of our DLL, Thinstall will extract it to ome virtual block, then fill it with imports and return it's block base as module handle. There are several problems that we have while traying to dump these DLL's. Dumping is easy. We use LordPE to dump that memory block. But we need to repair those DLL's and that is interesting part.
We place breakpoint on fbf line and we just run. Now we just use LordPE to dump memory range at , size Note that this library will probably be loaded at different base. It can be without. We can check now our first dumped dll withth LordPE. You will see that this is just resource dll with two sections. Dll can be loaded in memory and we dumped first file, but if our target is not just dummy one, we still would have problem. It is because file on disk have image alignment like in memory but in PE header is information for file alignment.
That is all, this dll doesn't have imports or exports. Dumping second DLL If we run now, we get another error message: An error has occured Line number: 2 Please contact the program vendor 53 We need to extract second DLL, which is called at the same place.
But this DLL have imports and exports. But it can be much easier. Also more interesting too. We restart target , find OEP again and then place two breakpoints at our old spot. We run to break when second dll is wanted, ei. Then we place bp on VirtualAlloc.
We know that dll will be loaded on address in my case so we will wait untill Thinstall allocates that block. So Run untill you can follow in dump that address. When you can follow in dump, place memory breakpoint on first couple bytes, then run again. Thinstall has allocated this block for PE header. Then it will allocate next at for code section, etc As said, first block is for PE header. When it breaks second time at VirtualAlloc, PE header is written.
Now we can see information about that DLL. We now know where OEP is and where is import table. Import table is the most important thing because that is last data that will be written before jumping to OEP. So I placed memory breakpoint at C and size 8F ofcourse, after another block is allocated for that part of image.
Lo C 61 64 4C 69 62 72 61 72 79 41 00 00 00 00 47 65 adLibraryA Ge C 74 50 72 6F 63 41 64 64 72 65 73 73 00 00 00 00 tProcAddress They will be filled last. I bynary copied all that data for later. Run to break there and when you break, remove bp. Then paste back that thunks and dump whole block with LordPE. Search Advanced search…. New posts. Search forums. Log in. Install the app. Contact us. Close Menu. JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. That's where ThinLoader stores its configuration well, only where the program is.. So, here it is. Feel free to use it and report any bugs you find.. Version 0. Last edited by iamzenitraM on Sun Mar 16, pm, edited 1 time in total. In the thinstall package. I like the concept a lot though. Something worth mentioning: your executable is currently tripping 2 virus scanners out of over 2 dozen as AdWare.
External drives are too, on the Package. Rest of places are WriteCopy. I'd add multiple sandboxes, but I can't find a way to change the stored data folder on real-time. Maybe a external program that runs before Thinstall loads itself and renames any folder to ThinData, and then renames it back again after finishing would do the trick, but then you would be able to run one sandbox at once.
I'm looking at the scripting functions, but I still have to figure out how to run them from AutoIt. Another thing is, standard autoit icon? About the actual direction of the project, instead of aiming this toward your exe being used as a launch platform, why not make it a sort of use on runtime sort of thing.
You should make it so that after running it the first time, it saves it's run settings the exe it runs with in an INI file, that way you can seamlessly use the ThinLoader exe instead of the app's from that point out.
0コメント