13 replies to this topic

[David Andersen]

I thought you would be interested in this post which describes how to use debug.exe (included with Windows) to dump information directly from RAM. It says in the comments that one guy was able to retrieve the content of currently open web sites from RAM.

Maybe communicate between scripts by modifying the other scrips variables directly in ram? Maybe read text out of textboxes that can not otherwise be read? I do not know how long it would take to search through all RAM for anchor information, but I am guessing it would be fast. Once the anchor information is found, one could say that 10 bytes later, one should read the interesting information.

The link: <!-- m -->http://www.osix.net/...article/?id=488<!-- m -->

[m^2]

I thought you would be interested in this post which describes how to use debug.exe (included with Windows) to dump information directly from RAM. It says in the comments that one guy was able to retrieve the content of currently open web sites from RAM.

Maybe communicate between scripts by modifying the other scrips variables directly in ram? Maybe read text out of textboxes that can not otherwise be read? I do not know how long it would take to search through all RAM for anchor information, but I am guessing it would be fast. Once the anchor information is found, one could say that 10 bytes later, one should read the interesting information.

The link: <!-- m -->http://www.osix.net/...article/?id=488<!-- m -->

It requires admin rights.

[David Andersen]

It would be nice if it didn't, but can't you just give it admin rights? I guess you are in a corporate environment?

[m^2]

It would be nice if it didn't, but can't you just give it admin rights? I guess you are in a corporate environment?

Nope. I just give a note, this might be important for some people.

[David Andersen]

That's true. Thanks a lot for the comment!

I am still thinking about the possibilities this would create. I believe the main usage is as a workaround for those really difficult problems, say a combobox that is totally hopeless to get information out of. The info in this combobox should be in memory somewhere, even if it is a Java application drawing the fonts directly onto the screen. Earlier On-screen OCR was the only hope in these cases.

[haichen]

If you only want to grab some data try http://www.nirsoft.n...ils/sysexp.html

SysExporter utility allows you to grab the data stored in standard list-views, tree-views, list boxes, combo boxes, text-boxes, and WebBrowser/HTML controls from almost any application running on your system, and export it to text, HTML or XML file.

[Lexikos]

There is no need to use an external process. ReadProcessMemory can be used via DllCall to read memory from another process. There are examples floating around the forums.

Maybe communicate between scripts by modifying the other scrips variables directly in ram?

IIRC, using ReadProcessMemory for inter-process communication is less efficient than more conventional techniques, such as pipes. ReadProcessMemory is undoubtedly faster than using debug.exe.

[David Andersen]

majkinetor!

That seems like a useful tool for example for reading text out of a stubborn Java control, which otherwise could not be read.

[Lexikos]

majkinetor is right, but just to waste time, I wrote a script demonstrating how to enumerate virtual memory regions of a given process, displaying a colourful "map" of committed/reserved/free pages. (Requires screen resolution of at least ..x768.)

SetBatchLines, -1

/*
INITIALIZE BITMAP
*/
; Prepare BITMAPINFO structure.
VarSetCapacity(bi,40,0), NumPut(0x200001, NumPut(-724, NumPut(725, NumPut(40,bi))))
; Create bitmap, retreiving handle (bmp) and pointer to data (bits).
bmp := DllCall("CreateDIBSection","uint",0,"uint",&bi,"uint",0 ,"uint*",bits,"uint",0,"uint",0)
if !bmp
{
    MsgBox, CreateDIBSection failed - error %A_LastError%.
    ExitApp
}

/*
ENUMERATE MEMORY REGIONS
*/
Process, Exist, explorer.exe
; Retrieve a process handle with PROCESS_QUERY_INFORMATION (0x400) access right.
hProc := DllCall("OpenProcess","uint",0x400,"int",0,"uint",ErrorLevel)
if !hProc
{
    MsgBox, OpenProcess failed - error %A_LastError%.
    ExitApp
}

VarSetCapacity(mbi, 28, 0)  ; MEMORY_BASIC_INFORMATION
ptr := 0            ; Address to query.
bit_ptr := bits     ; Address to write bitmap data.

Loop
{
    ; Retrieve information about the next region of consecutive pages with the same properties.
    if !DllCall("VirtualQueryEx","uint",hProc,"uint",ptr,"uint",&mbi,"uint",28)
        Break

    ; Retrieve information from the mbi structure.
    ; To interpret these values, refer to:
    ;   http://msdn.microsoft.com/en-us/library/aa366775(VS.85).aspx
    mbi_BaseAddress := NumGet(mbi, 0, "UInt")
    mbi_AllocationBase := NumGet(mbi, 4, "UInt")
    mbi_AllocationProtect := NumGet(mbi, 8, "UInt")
    mbi_RegionSize := NumGet(mbi, 12, "UInt")
    mbi_State := NumGet(mbi, 16, "UInt")
    mbi_Protect := NumGet(mbi, 20, "UInt")
    mbi_Type := NumGet(mbi, 24, "UInt")
    
    ; For each page (4096 bytes), write one pixel.
    Loop, % mbi_RegionSize//4096
        NumPut(mbi_State=0x1000 ? 0xff0000ff : mbi_State=0x2000 ? 0xffff0000 : 0, 0 + bit_ptr+=4)

    if (bit_ptr >= bits+2099600)    ; Sanity check. Should never happen.
    {
        MsgBox Oops, ran out of bits.
        ExitApp
    }
    
    ptr += mbi_RegionSize   ; Next region.
    if (ptr > 2**32-1)  ; Don't overflow 32-bit integer. Testing shows VirtualQueryEx fails at 0x7fff0000, so the loop never gets this far.
    {
        MsgBox Oops, too far.
        Break
    }
    
    Progress, % ptr*100//0x7fff0000
}
Progress, Off

; Free the process handle.
DllCall("CloseHandle","uint",hProc)


/*
SHOW GUI
*/
Gui, Add, Picture, W725 H724 +0xE
Gui, +LastFound
SendMessage, 0x172, 0, bmp, Static1     ; STM_SETIMAGE=0x172
Gui, Show

[David Andersen]

That is really cool! I am guessing white is free, blue reserved and red committed?

[Lexikos]

Red reserved, blue committed.

[kiropes]

majkinetor is right, but just to waste time, I wrote a script demonstrating how to enumerate virtual memory regions of a given process, displaying a colourful "map" of committed/reserved/free pages. (Requires screen resolution of at least ..x768.)

Lexikos, forgive me but I did not understand.
With the program indicated by majkinetor
I can see all the code of my script
compiled in "exe"
how can I avoid this?

[Lexikos]

Lexikos, forgive me but I did not understand.

What's there to not understand?

With the program indicated by majkinetor
I can see all the code of my script
compiled in "exe"
how can I avoid this?

The best solution is to close your eyes.

AutoHotkey reads the script into memory and decrypts it in order to load it. It seems that even though this memory is freed once the script is loaded, the data is still there until something writes over it. Even if you were to somehow figure out where it is and overwrite it, there are ways to catch the script immediately after it is decrypted, before it gets a chance to execute. This has been discussed before; for instance, Someone decompiled my passworded and protected script.

Experimenting with my own compiled script reveals everything beyond the first few lines, which were presumably overwritten.