VB Decompiler Hosted by TheAutomaters.com     Memberlist   How to get VB Header structure memory address      VB Decompiler Forum Index -> Structures Author Message vbgamer45 Regular user Joined: 07 Jul 2004 Posts: 93 Location: 127.0.0.1 Posted: Tue Aug 24, 2004 6:01 pm     Post subject: I generally access it via a file. To get all the pe information and strutures I need. I try to avoid dealing with memory, until I really use it is when I deal with pcode. I do not understand why you would want to read the PE format using memory like in this topic at [url:3105ndtz]http://visualbasicforum.com/showthread.php?t=77387[/url:3105ndtz] Dealing with files just makes things easier. Back to top MrUnleaded Site Admin Joined: 21 Sep 2002 Posts: 385 Location: California Posted: Tue Aug 24, 2004 6:20 pm     Post subject: [="Dr Memory":1hkukhqi]"something like that in VB.NET" Omygawwd! Don't worry, they'll probably develop a cure soon! [/:1hkukhqi] There is nothing wrong with VB/.Net unless you are a unix/linux freak.... its called a high-level langauge "Rapid Application Development" is what the monopoly calls it.... its a lot faster then C++....thats for sure. _________________ -MrU Back to top Dr Memory Expert Joined: 16 Aug 2004 Posts: 147 Location: Surrey, UK Posted: Tue Aug 24, 2004 6:59 pm     Post subject: True, but debugging, disassembling, reverse engineering, etc, are primarily low-level systems programming problems - so I just didn't think there'd be much mention of it here ... anybody managed VB dll injection with it yet? Don't get me wrong, I am not "against" VB.NET, the world of networking moves ever on and such tools are needed.... it's just not a tool for back-end engineers, is it? My daughter has just started Comp Sci at uni and they are doing Java - so she will be more OOP-correct than her poor old dad, who, being an engineer from the old socialist school, refuses to be involved with anything that is based on Class distinction! Unix? Actually no, in fact I've always been very critical of it, much to one old friend's annoyance! I was spoilt as a child, you see, I got to play for 10 years with a very sophisticated mainframe OS - source code and all - a wonderful thing called MCP .... many ideas now standard were first done by them ... the first true Virtual Memory architecture, hardware-controlled stack, among others .... Whoops, there I go again ..... sorry .... I have those functions here somewhere...... Back to top Dr Memory Expert Joined: 16 Aug 2004 Posts: 147 Location: Surrey, UK Posted: Tue Aug 24, 2004 7:26 pm     Post subject: API decs: I have omitted the standard API decns, just this one which is not so common though: Code: Private Declare Function GetModuleInformation Lib "psapi.dll" _ (ByVal hProcess As Long, ByVal hModule As Long, mInfo As MODULEINFO, _ ByVal cbSize As Long) As Long Private Type MODULEINFO lpBaseDLL As Long ImageSize As Long EntryPoint As Long End Type Dim mInfo As MODULEINFO There's 2 functions, ExeVBHeader() and DllVBHeader(dllName As String). For EXE's, a pointer to the value we want is found at the EXE's entry point + 1, as it starts with "push IT, call ThunRTmain", and we just want IT. On all NT platforms, the entry point for the base module of any process is available via the simple GetModuleInformation. All you need for that is a process handle and a module handle, so you can find the header in your own app (as shown here) or you can find it for another VB app, by getting a process handle to it. Given the handle, we just need a couple of lines to get the WINMAIN entry point, add 1 to it, look in memory at that address and bingo ... Code: Function ExeVBHeader() As Long ' ' MathImagics Software Engineering ' Surrey Uk July 2004 ' Call GetModuleInformation( GetCurrentProcess(), ' or any valid process handle! &H400000, ' general case uses GetModuleHandle mInfo, 12) If mInfo.EntryPoint Then RtlMoveMemory ExeVBHeader, ByVal mInfo.EntryPoint + 1, 4 End If End Function DLL next ...... Back to top Dr Memory Expert Joined: 16 Aug 2004 Posts: 147 Location: Surrey, UK Posted: Tue Aug 24, 2004 7:50 pm     Post subject: The DLL case is similar, but doesn't need psapi, it uses the standard GetProcAddress api... In an ActiveX dll, the only references to IT are at the entry points to the public COM functions, which are invariably exported (unless the thing is a custom-built DLL, designed to work without the registry (A "Privately Published" COM Class library) Same deal as before, only there's an extra opcode before it, so we add 2 instead: Code: Function DllVBheader(Name As String) As Long Dim dllHandle As Long, pVBH As Long dllHandle = GetModuleHandle(Name) If dllHandle = 0 Then dllHandle = LoadLibrary(Name) If dllHandle Then pVBH = GetProcAddress(myHandle, "DllRegisterServer") + 2 RtlMoveMemory DllVBheader, ByVal pVBH, 4 End If End Function Back to top MrUnleaded Site Admin Joined: 21 Sep 2002 Posts: 385 Location: California Posted: Tue Aug 24, 2004 8:30 pm     Post subject: in your example: Function DllVBheader(Name As String) As Long can you give an example of name? I think when MoogMan was around this was the way he did somethings. I think I am doing it the hard way. _________________ -MrU Back to top MrUnleaded Site Admin Joined: 21 Sep 2002 Posts: 385 Location: California Posted: Tue Aug 24, 2004 8:34 pm     Post subject: Would a exe have to be run in order to use these functions? and if so how do we get from that point to the Handle? _________________ -MrU Back to top _aLfa_ Site Admin Joined: 21 Sep 2002 Posts: 233 Location: Aveiro, Portugal Posted: Tue Aug 24, 2004 9:11 pm     Post subject: [="Dr Memory":2x3hoy3r]' MathImagics Software Engineering ' Surrey Uk July 2004[/:2x3hoy3r] *cough* MathImagics *cough* _________________ One thing only I know, and that is that I know nothing. (Socrates) Back to top Dr Memory Expert Joined: 16 Aug 2004 Posts: 147 Location: Surrey, UK Posted: Tue Aug 24, 2004 11:31 pm     Post subject: Hmmm??? I'm sure I said so ..... yes, that's us! We are the Doctor... Back to top Dr Memory Expert Joined: 16 Aug 2004 Posts: 147 Location: Surrey, UK Posted: Wed Aug 25, 2004 4:40 am     Post subject: MrUnleaded: DllVBheader function takes a filename or pathname - LoadLibrary() follows the "dll search path" rules if you don't specify the path, and registered ActiveX dll's don't need to be in any of those folders (local dir, system32, windows, etc) because the registry records where they are... So, since this function only applies to those dll's it's probably wise to spell it out: DllVBHeader("C:LibXa.dll"). To use ExeVBHeader on another process, you start with a process id, then use OpenProcess to get a process handle you can use with GetModuleInformation. See EVBF for samples Back to top Dr Memory Expert Joined: 16 Aug 2004 Posts: 147 Location: Surrey, UK Posted: Wed Aug 25, 2004 4:45 am     Post subject: If you have a "Process Viewer", i.e. a VB prgram that can list the running processes, like TaskMgr, then youy are already walking the system process list and will have these handles anyway - you could easily add an extra column in your report view to show the VBH locations of any VB exes in the process list ... Back to top    VB Decompiler Forum Index -> Structures All times are GMT Page 1 of 1   You can post new topics in this forum You can reply to topics in this forum You can edit your posts in this forum You can delete your posts in this forum You can vote in polls in this forum Powered by phpBB © 2001, 2005 phpBB Group