News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change

Main Menu

Need help with bug

Started by Don57, February 08, 2013, 08:31:52 AM

Previous topic - Next topic

Don57

I have been through Olly for days trying to find the error, but no luck. I have checked all registers before and after Format_Data proc and
they seem fine. Any change I make to the data dump seems to skew the data.

Two version of the program the first one runs properly, check entry in Reg Data.txt file
under CoreFTP it lists DisplayName and UninstallString in the second version both those
entries are changed to SystemComponent. I have checked all the registers before and after
call on line 414 Format_Data they seem fine. The only changes are in lines 464 and 474 rem them.
It should not make a difference but it does. Every change I make in Format_Data PROC seems
to skew the data.

jj2007

Shouldn't both lines be commented out, as shown below?

      ; INVOKE Convert_Hex2ASCII, OFFSET lp_RegValueNameLen                     ; Convert to ASCII hex FOR DEBUGGING
      ; INVOKE Dump_Data2Heap, OFFSET lp_RegValueNameLen                        ; RegValueNameLen plus 8 spaces

Don57

I am trying to dump the data o the heap in a format that can be scanned later. All I really want is the DisplayName, Uninstall, and the Quietuninstall data, but if I don' write the other data to the heap as well, all the data goes bad. I need to format the name in a 50h space
and the uninstall data in 100h space. If I try sorting on the fly the data goes bad. It is quite frustrating.


I just rewrote EnumerateKeys PROC thinking that i was loosing a pointer or index there, but still the same.

Don57

Found something interesting on he net.

For 64 bit , in many parts of the registry, requests from 32-bit processes are redirected to a separate subkey.

    HKLM\Software\Wow6432Node\Microsoft\Windows NT\CurrentVersion

There are several ways to disable this.  You can call RegDisableReflectionKey, or you can specify KEY_WOW64_64KEY in the flags of
the registry call. If you disable this you only read the 32 bit keys. If you set the path to WOW6432Node i think you get he 64 bit keys. I'm thinking that I will leave the routine alone and figure out a data sort. I think I rewritten the data read 30 times and this is the only one that works a 32bit kludge for a 64 bit system.

dedndave

this is kind of half-done, as i don't have time to finish it at the moment
i make "memo" notes at the top of source to remind myself what i want to work on   :P
i plan on adding an Nt (UNICODE only) version so that you can work with strings that contain embedded nulls

but, it does work - and, it will also work for UNICODE builds
however, if you redirect UNICODE output to a file from the console command line, it will be empty
so - if you want to see a full dump by redirecting to a text file, use the ANSI build

the idea is to recursively enumerate registry keys in a manner similar to other enumerations
(like enumerating fonts, processes, or windows, etc)

the caller provides 2 call-back functions, one for keys and one for values
as it is now written, if you return any non-zero value from either call-back, enumeration stops
i want to alter that so that you may control recursion depth, as well

it still needs a lot of work   :P
but you get the idea

Don57


dedndave

i hope you downloaded it ok
it only shows 2 d/l's here   :P