The MASM Forum Archive 2004 to 2012

General Forums => The Campus => Topic started by: skywalker on March 02, 2006, 12:43:49 AM

Title: Self incrementing Counter info
Post by: skywalker on March 02, 2006, 12:43:49 AM
Is it possible to have a self-incrementing counter inside a program? (Would store a value each time prog is run.)

Is that what code injection is that I have seen ?

Thanks.
Title: Re: Self incrementing Counter info
Post by: hutch-- on March 02, 2006, 02:44:56 AM
Andy,

The problem is storing the data somewhere. In the old days of DOS you wrote the result back to the exe file but under win32 this cannot be done. Most go for a registry setting or writing the data to a file somewhere but neither are secure.
Title: Re: Self incrementing Counter info
Post by: asmfan on March 04, 2006, 06:59:34 PM
i've just come an idea: using for storing counter resources. Imagine each time U execute the program it updates its resources from itself (BeginUpdateResource, UpdateResource...)
tell me what do you think about it.
Title: Re: Self incrementing Counter info
Post by: PBrennick on March 04, 2006, 08:02:13 PM
I would just use a .ini file, you can use ReadProfileString and WriteProfileString to do this in win.ini, create your own section and do it there.

Paul
Title: Re: Self incrementing Counter info
Post by: skywalker on March 05, 2006, 01:10:55 AM
Quote from: PBrennick on March 04, 2006, 08:02:13 PM
I would just use a .ini file, you can use ReadProfileString and WriteProfileString to do this in win.ini, create your own section and do it there.

Paul

So could you put your own section in the middle somewhere?

I can't find either function iin the APIs.

Title: Re: Self incrementing Counter info
Post by: donkey on March 05, 2006, 02:26:27 AM
GetProfileString (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/getprofilestring.asp) and WriteProfileString (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/writeprofilestring.asp), Microsoft has some bizzare naming conventions could have been Get/Set or Read/Write but they choose Get/Write ??? You should know that if you're running NT/2K/XP it just gets mapped to the registry anyway so it isn't really hiding it too well.
Title: Re: Self incrementing Counter info
Post by: PBrennick on March 05, 2006, 02:35:14 AM
Donkey,
Ah, why are we bothering to hide a use counter.  Maybe I just don't get it but this is no big deal.

Paul
Title: Re: Self incrementing Counter info
Post by: donkey on March 05, 2006, 02:40:41 AM
I guess I should also suggest SHSetValue and SHGetValue, two great little APIs from SHLWAPI.DLL, when you're only dealing with one simple value they are great for storing and reading from the registry. If I was doing this type of thing I would write an encrypted key the registry with the current count, that way it's harder to change, they could just delete it though but if you're sneaky about naming it they might never find it. Say...

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.zxr\

Not many people even know what those keys are for. If you'd like to know about them I use them in WinExplorer, they hold the openswith information for each extension. Since .zxr is not like to exist it's not a problem  :)
Title: Re: Self incrementing Counter info
Post by: donkey on March 05, 2006, 02:42:55 AM
Quote from: PBrennick on March 05, 2006, 02:35:14 AM
Donkey,
Ah, why are we bothering to hide a use counter.  Maybe I just don't get it but this is no big deal.

Paul


There is no other reason I can see to have a run counter other than for software expiry, other than that I haven't the foggiest idea why it could possibly be useful. I guess I just assumed that's what he was trying to do, re-reading the posts I think I might be mistaken.
Title: Re: Self incrementing Counter info
Post by: PBrennick on March 05, 2006, 02:51:40 AM
Donkey,
Maybe not, your thoughts are logical.  Expiry did not even occur to me.  I bet you are right.  This type of thing CAN be done in the file but share must be running on the target and that is just to easy to defeat.  If the user closes share.exe and removes it from the system  then UnlockRegion will not work (I don't think).

Paul
Title: Re: Self incrementing Counter info
Post by: rags on March 05, 2006, 03:44:00 AM
Quote from: donkey on March 05, 2006, 02:26:27 AM
You should know that if you're running NT/2K/XP it just gets mapped to the registry anyway so it isn't really hiding it too well.
Donkey,
Maybe I'm reading the SDK wrong, but I read it as saying if the specified ini file doesn't have a subkey in-
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\IniFileMapping
Then all reading and writing would be to the disk, and not the registry.
Am I correct in my understanding of get/write profie string?

Title: Re: Self incrementing Counter info
Post by: donkey on March 05, 2006, 04:38:57 AM
Quote from: rags on March 05, 2006, 03:44:00 AM
Donkey,
Maybe I'm reading the SDK wrong, but I read it as saying if the specified ini file doesn't have a subkey in-
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\IniFileMapping
Then all reading and writing would be to the disk, and not the registry.
Am I correct in my understanding of get/write profie string?

I was going by this...

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/writeprofilestring.asp

QuoteIf the section name specified by lpAppName does not exist as a named value or as a subkey, then there will be an unnamed value (shown as <No Name>) that specifies the default location in the registry where you will find the keys for the section.

Don't really use INI files at all any more, the registry is just too convenient and easy to use, also I like customizable toolbars so I have to create a subkey anyway. Never really liked INI files though they have their place I guess, I think I used one for the favourites menu in a RadASM add-in I wrote.
Title: Re: Self incrementing Counter info
Post by: PBrennick on March 05, 2006, 07:00:24 AM
I think the fact that Windows, itself, still uses INI files speaks for itself.  Remember that the registry, as a file can be compared to as a very large INI file.  Also, the registry is the most frequently written to file on the system.  It is a shared file that gets simultaneous writes on a constant basis and as such, it is the least stable file on the system.  I think that is why Windows still uses INI files in some situations.  I also use the registry frequently but some tasks, to me, just make more sense in an INI file and expiry is at the top of the list here because to defeat it if the registry is used all a user has to do is set a restore point.  Remember that and think about it and in general realize what the purpose of restore points is.  Windows will use this method to recover from registry crashes (caused by the share situation).  At times, a lot of times it just falls over and dies and it happens SO often that restore points technology had to be created.  I know that restore points are also useful for testing software, also, but expiry is the issue here, remember what I said and do not use the registry for this purpose.

Paul
Title: Re: Self incrementing Counter info
Post by: skywalker on March 05, 2006, 01:42:55 PM
Quote from: donkey on March 05, 2006, 02:26:27 AM
GetProfileString (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/getprofilestring.asp) and WriteProfileString (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/writeprofilestring.asp), Microsoft has some bizzare naming conventions could have been Get/Set or Read/Write but they choose Get/Write ??? You should know that if you're running NT/2K/XP it just gets mapped to the registry anyway so it isn't really hiding it too well.

Can you help us ? If you don't feel confortable showing how to adding a section to win.ini, how about making a new ini file ?

Thanks.



Title: Re: Self incrementing Counter info
Post by: zcoder on March 05, 2006, 01:57:14 PM
If you just need some kind of a file to
use only for your program, then why use
GetProfileString and WriteProfileString?

just make a Structure

MY_DATA STRUCT
mydata1     DWORD
mydata2     DWORD
mystring    MAX_PATH dup()
MY_DATA ENDS

Then fill in the items and sore the STRUCTURE as a file
this way when you read the file back into the structure
you don't have to convert any shit or invoke other API's
just to get to some info you need.


Just a sugestion.


Zcoder....
Title: Re: Self incrementing Counter info
Post by: PBrennick on March 05, 2006, 02:02:09 PM
Skywalker,
Who are you asking, please.  If you are asking Donkey, I don't want to interfere.

zcoder,
Using an include file, as you are suggesting, is probably a lot easier to do, also, and is a very good option in my opinion.  There is always more than one way to solve a problem, right?

Paul
Title: Re: Self incrementing Counter info
Post by: zcoder on March 05, 2006, 02:06:23 PM
PBrennick,
I used that idea on a program
after I found out that XP did not have
one of the reg keys I was using in 98

so I got feed up with MS changeing the rules
and MADE MY OWN RULE. :bg

Zcoder....
Title: Re: Self incrementing Counter info
Post by: PBrennick on March 05, 2006, 02:15:53 PM
zcoder,
Why don't you show Skywalker how to do that and, possibly, encrypt the value, also.  :U

Paul
Title: Re: Self incrementing Counter info
Post by: skywalker on March 05, 2006, 02:22:20 PM
Quote from: PBrennick on March 05, 2006, 02:02:09 PM
Skywalker,
Who are you asking, please.  If you are asking Donkey, I don't want to interfere.

zcoder,
Using an include file, as you are suggesting, is probably a lot easier to do, also, and is a very good option in my opinion.  There is always more than one way to solve a problem, right?

Paul

Thanks.

I was asking Donkey for help with writing to win.ini.

Anything I learn is useful to me.

Andy


Title: Re: Self incrementing Counter info
Post by: IAO on March 05, 2006, 02:28:15 PM
Hi to all:  My English is poor. But I try. :wink

Mr. skywalker.
Look in C or D:\MASM32\Example10\GETINI
This example can help you.
I think, that GETINI can help you.
You need ServPack2.

Thanks for your patience.
Bye ('_').
Title: Re: Self incrementing Counter info
Post by: zcoder on March 05, 2006, 02:28:54 PM
Ok, good idea.

Here is some code to work on.



.data?
CONFIGSETUP STRUCT
Window       dd ?
System       dd ?
System32     dd ?
Cookies      dd ?
Startup      dd ?
Minimized    dd ?
RegCheck     dd ?
FirstRun     dd ?
CONFIGSETUP ENDS

.data
hFile       dd 0
byteswrote  dd 0
pcs         CONFIGSETUP<0,0,0,0,0,0,0,0>




        invoke CreateFile,txt("Options.cfg"),GENERIC_READ,FILE_SHARE_READ,
                             NULL,OPEN_ALWAYS,FILE_ATTRIBUTE_NORMAL,NULL
        mov hFile,eax
        .if hFile == INVALID_HANDLE_VALUE
            invoke MessageBox,hWnd,txt("Error, Opening Options.cfg File"),txt("Create File Error!"),MB_OK
            ret
        .endif
        invoke ReadFile,hFile,addr pcs,sizeof pcs,addr byteswrote,0
        invoke CloseHandle,hFile
;*****************************************************************
; And this is how you can update the file after you have made some
; changes
;*****************************************************************

        invoke CreateFile,txt("Options.cfg"),GENERIC_WRITE,FILE_SHARE_WRITE,
                              NULL,CREATE_ALWAYS,FILE_ATTRIBUTE_NORMAL,NULL
        mov hFile,eax
        .if hFile == INVALID_HANDLE_VALUE
            invoke MessageBox,hWnd,txt("Error, Creating File"),txt("Create File Error!"),MB_OK
            ret
        .endif
        invoke WriteFile,hFile,addr pcs,sizeof pcs,addr byteswrote,0
        invoke CloseHandle,hFile



I hope that helps it is generic but you get the idea I hope.


Zcoder....
Title: Re: Self incrementing Counter info
Post by: donkey on March 05, 2006, 03:47:36 PM
Hi Skywalker,

The APIs are pretty much self explanatory...
invoke GetProfileIntA,"MyApp","Counter",1
inc eax ; add 1 to the counter
mov [count],eax
invoke dw2a,offset counter,[count]
invoke WriteProfileStringA,"MyApp","Counter",offset counter

If the section and key do not exist they will be created.

Donkey
Title: Re: Self incrementing Counter info
Post by: skywalker on March 05, 2006, 06:55:21 PM
Quote from: IAO on March 05, 2006, 02:28:15 PM
Hi to all:  My English is poor. But I try. :wink

Mr. skywalker.
Look in C or D:\MASM32\Example10\GETINI
This example can help you.
I think, that GETINI can help you.
You need ServPack2.

Thanks for your patience.
Bye ('_').

I'll read thru it and study it.

I just have service pack 1. Does the code use the Security Center ?

Thanks.
Title: Re: Self incrementing Counter info
Post by: Mark Jones on March 05, 2006, 06:55:53 PM
Here's a "Save structure to INI file" example.

http://www.masmforum.com/simple/index.php?topic=1073.0

Once I wanted a file to "remember" the last time it was used without any .ini files. So I looked in the finished .EXE for some slack space at the end of the .text section and recorded that offset. Then I had the app spawn a second app before closing, which loaded the first app and wrote a FILETIME value to the offset. Each time the original app is run, it looked for the FILETIME at that offset and read the value, then converted it to SYSTEMTIME and displayed it. Blindly modifying a PE section is not a good idea really, but it worked. "Good morning Dave... Your last login was January 13, 2006..." Sheesh I'm a dork! :toothy
Title: Re: Self incrementing Counter info
Post by: zooba on March 05, 2006, 07:59:04 PM
Quote from: Mark Jones on March 05, 2006, 06:55:53 PM
Once I wanted a file to "remember" the last time it was used without any .ini files. So I looked in the finished .EXE for some slack space at the end of the .text section and recorded that offset. Then I had the app spawn a second app before closing, which loaded the first app and wrote a FILETIME value to the offset. Each time the original app is run, it looked for the FILETIME at that offset and read the value, then converted it to SYSTEMTIME and displayed it. Blindly modifying a PE section is not a good idea really, but it worked. "Good morning Dave... Your last login was January 13, 2006..." Sheesh I'm a dork! :toothy

Why didn't you just modify a value in the initialised data section (of the actual executable, obviously)? That way it's really simple to read the value back  :bg
Title: Re: Self incrementing Counter info
Post by: Mark Jones on March 05, 2006, 08:07:02 PM
What can I say, I'm a dork. :green
Title: Re: Self incrementing Counter info
Post by: skywalker on March 05, 2006, 10:35:56 PM
Quote from: zcoder on March 05, 2006, 02:28:54 PM
Ok, good idea.

Here is some code to work on.



.data?
CONFIGSETUP STRUCT
Window       dd ?
System       dd ?
System32     dd ?
Cookies      dd ?
Startup      dd ?
Minimized    dd ?
RegCheck     dd ?
FirstRun     dd ?
CONFIGSETUP ENDS



I hope that helps it is generic but you get the idea I hope.


Zcoder....


I was getting an error with these all statements using txt("Error, Opening Options.cfg File"),
so I fixed one of them by putting in a pointer to a null terminated file name.

Am I going in the right direction ?
Is the txt some macro. I have the latest masm installed.

Thanks.


; struct.asm
.486                       
    .model flat, stdcall       ; 32 bit memory model
    option casemap :none       ; case sensitive


    include \masm32\include\windows.inc
    include \masm32\include\masm32.inc
    include \masm32\include\gdi32.inc
    include \masm32\include\user32.inc
    include \masm32\include\kernel32.inc
    include \masm32\include\Comctl32.inc
    include \masm32\include\comdlg32.inc
    include \masm32\include\shell32.inc
    include \masm32\include\oleaut32.inc
    include \masm32\macros\macros.asm

    includelib \masm32\lib\masm32.lib
    includelib \masm32\lib\gdi32.lib
    includelib \masm32\lib\user32.lib
    includelib \masm32\lib\kernel32.lib
    includelib \masm32\lib\Comctl32.lib
    includelib \masm32\lib\comdlg32.lib
    includelib \masm32\lib\shell32.lib
    includelib \masm32\lib\oleaut32.lib


.data?

CONFIGSETUP STRUCT
Window       dd ?
System       dd ?
System32     dd ?
Cookies      dd ?
Startup      dd ?
Minimized    dd ?
RegCheck     dd ?
FirstRun     dd ?
CONFIGSETUP ENDS

.data

hFile       dd 0
byteswrote  dd 0
pcs         CONFIGSETUP<0,0,0,0,0,0,0,0>
fname1  db "c:\work\dont_look_inside.cfg",0

.code

start:

main proc

  invoke CreateFile,ADDR fname1,GENERIC_READ,FILE_SHARE_READ,NULL,OPEN_ALWAYS,FILE_ATTRIBUTE_NORMAL,NULL
        mov hFile,eax
        .if hFile == INVALID_HANDLE_VALUE
            invoke MessageBox,hWnd,txt("Error, Opening Options.cfg File"),txt("Create File Error!"),MB_OK
            ret
        .endif
        invoke ReadFile,hFile,addr pcs,sizeof pcs,addr byteswrote,0
        invoke CloseHandle,hFile
        jmp end
;*****************************************************************
; And this is how you can update the file after you have made some
; changes
;*****************************************************************

        invoke CreateFile,txt("Options.cfg"),GENERIC_WRITE,FILE_SHARE_WRITE,NULL,CREATE_ALWAYS,FILE_ATTRIBUTE_NORMAL,NULL
        mov hFile,eax
        .if hFile == INVALID_HANDLE_VALUE
            invoke MessageBox,hWnd,txt("Error, Creating File"),txt("Create File Error!"),MB_OK
            ret
        .endif
        invoke WriteFile,hFile,addr pcs,sizeof pcs,addr byteswrote,0
        invoke CloseHandle,hFile

end:

    invoke ExitProcess,0


main endp

end start


Title: Re: Self incrementing Counter info
Post by: PBrennick on March 05, 2006, 11:49:19 PM
Skywalker,
1. I do not seem to have the txt macro so I replaced all occurences of txt with CTXT (keep the uppercase)
2. You have a line that says end:
    You cannot do the because end is a reserved word and it will cause nesting errors.
    Change end to TheEnd and the jump line to jmp TheEnd
3. A window has not been created so replace all occurrences of hWnd with NULL (keep the uppercase)

Once you make these changes, it will assemble without errors and when run it will show a message box that says options.cfg does not exist.  This is correct.  Once I got that far, I made some changes to the WriteFile line and was able to create options.cfg and store the string fname1 in it but you may want to try that yourself first.  If you have more questons just ask.  I am just helping until zcoder logs in.  I thought you should tackle this one thing at a time until eventually you will write the structure there.  If you want me to post the first set of changes as a complete program, I will.

Paul
Title: Re: Self incrementing Counter info
Post by: zcoder on March 06, 2006, 01:07:54 AM

      .386
      .model flat, stdcall  ; 32 bit memory model
      option casemap :none  ; case sensitive

;**********************************************************************
;     include files
;**********************************************************************     
      include \Masm32\INCLUDE\windows.inc
      include \Masm32\INCLUDE\user32.inc
      include \Masm32\INCLUDE\kernel32.inc
      include \Masm32\INCLUDE\comdlg32.inc
      include \Masm32\include\Comctl32.inc

;**********************************************************************
;     libraries
;**********************************************************************
      includelib \Masm32\LIB\user32.lib
      includelib \Masm32\LIB\kernel32.lib
      includelib \Masm32\LIB\comdlg32.lib
      includelib \Masm32\lib\Comctl32.lib

include\masm32\macros\macros.asm

;**********************************************************************
; Local prototypes
;**********************************************************************
        WinMain                 PROTO :DWORD
        WinProc                 PROTO :DWORD,:DWORD,:DWORD,:DWORD
        wsprintfA               PROTO C :DWORD,:VARARG

        wsprintf equ <wsprintfA>

;**********************************************************************
; Place all your Constance here.
;**********************************************************************
.const
ICO_MAINICON     equ 500

;**********************************************************************
; Inishilized DATA
;**********************************************************************
.data
Wwidth           dd 350
Wheight          dd 315
szClassName      db "Template_Class",0
szAppName        db "Template",0

;**********************************************************************
; Un-Inishilized DATA
;**********************************************************************
.data?
hWnd             dd ?
hInstance        dd ?
hIcon            dd ?

CONFIGSETUP STRUCT
Window       dd ?
System       dd ?
System32     dd ?
Cookies      dd ?
Startup      dd ?
Minimized    dd ?
RegCheck     dd ?
FirstRun     dd ?
CONFIGSETUP ENDS

.data

hFile       dd 0
byteswrote  dd 0
pcs         CONFIGSETUP<0,0,0,0,0,0,0,0>
fname1  db "c:\work\dont_look_inside.cfg",0

.code
;**********************************************************************
; This is the start of the code section, here we get our Module Handle
; and start our Program.
;**********************************************************************
start:
      mov hInstance,FUNC(GetModuleHandle,NULL)
      invoke WinMain,hInstance
      invoke ExitProcess,eax

;**********************************************************************
; This section creates the MAIN CLASS and the MAIN window.
; Then loops sending messages to our WinProc for Proccessing.
;**********************************************************************
WinMain proc hModule:DWORD

        LOCAL wc   :WNDCLASSEX
        LOCAL msg  :MSG

      mov hIcon,FUNC(LoadIcon,hModule,ICO_MAINICON)    ; icon ID
      mov wc.cbSize,sizeof WNDCLASSEX
      mov wc.style,CS_HREDRAW or CS_VREDRAW or CS_BYTEALIGNWINDOW
      mov wc.lpfnWndProc,offset WinProc
      mov wc.cbClsExtra,NULL
      mov wc.cbWndExtra,NULL
      m2m wc.hInstance,hModule
      mov wc.hbrBackground,COLOR_BTNFACE+1
      mov wc.lpszMenuName,NULL
      mov wc.lpszClassName,offset szClassName
      m2m wc.hIcon,hIcon
      mov wc.hCursor,FUNC(LoadCursor,NULL,IDC_ARROW)
      m2m wc.hIconSm,hIcon
      invoke RegisterClassEx, addr wc
      mov hWnd,FUNC(CreateWindowEx,WS_EX_LEFT,addr szClassName,addr szAppName,WS_SIZEBOX or WS_CAPTION or WS_SYSMENU or WS_MINIMIZEBOX or WS_MAXIMIZEBOX or WS_POPUP or WS_VISIBLE or WS_BORDER or WS_DLGFRAME,10,10,Wwidth,Wheight,NULL,NULL,hModule,NULL)
      invoke ShowWindow,hWnd,SW_SHOWNORMAL
      invoke UpdateWindow,hWnd

      ;===================================
      ; Loop until PostQuitMessage is sent
      ;===================================

    StartLoop:
      invoke GetMessage,addr msg,NULL,0,0
      cmp eax,0
      je ExitLoop
      invoke TranslateMessage, addr msg
      invoke DispatchMessage,  addr msg
      jmp StartLoop
    ExitLoop:

      return msg.wParam

WinMain endp
;**********************************************************************
; This is the Main programs code area. all messages for this APP are
; recived here, or the main app.
;**********************************************************************
WinProc proc hWin:DWORD,uMsg:DWORD,wParam:DWORD,lParam:DWORD


          .if uMsg == WM_CREATE
              invoke CreateFile,ADDR fname1,GENERIC_READ,FILE_SHARE_READ,NULL,OPEN_ALWAYS,FILE_ATTRIBUTE_NORMAL,NULL
              mov hFile,eax
              .if hFile == INVALID_HANDLE_VALUE
                  invoke CreateFile,txt("Options.cfg"),GENERIC_WRITE,FILE_SHARE_WRITE,NULL,CREATE_ALWAYS,FILE_ATTRIBUTE_NORMAL,NULL
                  mov hFile,eax
                  invoke WriteFile,hFile,addr pcs,sizeof pcs,addr byteswrote,0
                  jmp Create_end
              .endif
              invoke ReadFile,hFile,addr pcs,sizeof pcs,addr byteswrote,0
              invoke CloseHandle,hFile
Create_end:


          .elseif uMsg == WM_PAINT


          .elseif uMsg == WM_COMMAND


          .elseif uMsg == WM_SIZE


          .elseif uMsg == WM_CLOSE
                  invoke CreateFile,txt("Options.cfg"),GENERIC_WRITE,FILE_SHARE_WRITE,NULL,CREATE_ALWAYS,FILE_ATTRIBUTE_NORMAL,NULL
                  mov hFile,eax
                  .if hFile == INVALID_HANDLE_VALUE
                      invoke MessageBox,hWnd,txt("Error, Creating File"),txt("Create File Error!"),MB_OK
                      ret
                  .endif
                  invoke WriteFile,hFile,addr pcs,sizeof pcs,addr byteswrote,0
                  invoke CloseHandle,hFile
                  invoke DestroyIcon,hIcon
                  invoke DestroyWindow,hWin

          .elseif uMsg == WM_DESTROY
                  invoke PostQuitMessage,0
                  return 0
          .endif


          invoke DefWindowProc,hWin,uMsg,wParam,lParam
          ret
WinProc endp

end start


The code above is a complete app
it starts out by trying to open the Options.cfg file
if it fails on this then this might be the first time
the program has run so it writes one to the disk.

At this point you could fill default stuff into it before
writing it to disk.

Finally when the app close's you write it to the file.
this is good for apps that may do stuff like store the
window position, and other stuff then saves this
just before exiting.

I am sure you can dream up alot of use's and also
make up your own items to place in the structure
for the type of app you want to create.

you could also create it to show a count just after WM_CREATE
where it already read the file in. and inc a count in the struct
so when your app close's it will be saved.

So each time you run it it will show the count. this will show
you that this works great for keeping track of many things
your imagination can create.


If you need more info or help I can help you in that direction.

Zcoder....
Title: Re: Self incrementing Counter info
Post by: skywalker on March 06, 2006, 01:15:11 AM
Quote from: PBrennick on March 05, 2006, 11:49:19 PM
Skywalker,
1. I do not seem to have the txt macro so I replaced all occurences of txt with CTXT (keep the uppercase)
2. You have a line that says end:
    You cannot do the because end is a reserved word and it will cause nesting errors.
    Change end to TheEnd and the jump line to jmp TheEnd
3. A window has not been created so replace all occurrences of hWnd with NULL (keep the uppercase)

Once you make these changes, it will assemble without errors and when run it will show a message box that says options.cfg does not exist.  This is correct.  Once I got that far, I made some changes to the WriteFile line and was able to create options.cfg and store the string fname1 in it but you may want to try that yourself first.  If you have more questons just ask.  I am just helping until zcoder logs in.  I thought you should tackle this one thing at a time until eventually you will write the structure there.  If you want me to post the first set of changes as a complete program, I will.

Paul


This is what I just completed. It creates the file OK.

I'm thinking now i need to learn how to fill the structure and how to store it in the created file.

Later, I can learn how to modify it and search for things. In 16 bit, I used to use debug and the d command to see where in the .exe stored data/structures were. I think I still have a 32 bit command line debugger somewhere.

It helps me a lot to sometimes place markers in the code to see where stuff is being stored.

Is there an easy way to jump around code that you haven't had time to correct without using ; all over the
place ?

start:

main proc

  invoke CreateFile,ADDR fname1,GENERIC_READ,FILE_SHARE_READ,NULL,OPEN_ALWAYS,FILE_ATTRIBUTE_NORMAL,NULL
        mov hFile,eax
        .if hFile == INVALID_HANDLE_VALUE
            invoke MessageBox,NULL,ADDR mess,ADDR box,MB_OK
            ret
        .endif
        invoke ReadFile,hFile,addr pcs,sizeof pcs,addr byteswrote,0
        invoke CloseHandle,hFile
       
;*****************************************************************
; And this is how you can update the file after you have made some
; changes
;*****************************************************************

;        invoke CreateFile,txt("Options.cfg"),GENERIC_WRITE,FILE_SHARE_WRITE,NULL,CREATE_ALWAYS,FILE_ATTRIBUTE_NORMAL,NULL
;        mov hFile,eax
;        .if hFile == INVALID_HANDLE_VALUE
;            invoke MessageBox,hWnd,txt("Error, Creating File"),txt("Create File Error!"),MB_OK
;            ret
;        .endif
;        invoke WriteFile,hFile,addr pcs,sizeof pcs,addr byteswrote,0
;        invoke CloseHandle,hFile

    invoke ExitProcess,0
Title: Re: Self incrementing Counter info
Post by: PBrennick on March 06, 2006, 01:30:17 AM
Skywalker,
I think you are proceeding very well here.  We will continue to help you as you develop this application.  About the semi-colon thing, it is the only way I know how except if you are using a debugger.  You can get a free copy of Olly debug and use int 3 to set breakpoints so you can see what is happening.  Be careful about relying on debuggers, though.  One made a fool of me earlier today.

Have fun and treat the structure as a long data string. end it iwith a zero and put quotes around each line of text of the structure and put 13, 10 at the end of each line.  You will learn to put variables between each line where you will put the data that is stored in the real structure.  Think about these things and let me know if you need any more help.  These are just ideas about only one way of solving this problem.  There is always more than one way so if you come up with another way, well, that's cool.

Have fun and let us know how it is going.  Congratulations on getting it to assemble.  It must have been a good feeling.

Paul
Title: Re: Self incrementing Counter info
Post by: skywalker on March 06, 2006, 05:31:02 AM
Quote from: PBrennick on March 06, 2006, 01:30:17 AM
Skywalker,
I think you are proceeding very well here.  We will continue to help you as you develop this application.  About the semi-colon thing, it is the only way I know how except if you are using a debugger.  You can get a free copy of Olly debug and use int 3 to set breakpoints so you can see what is happening.  Be careful about relying on debuggers, though.  One made a fool of me earlier today.

Have fun and treat the structure as a long data string. end it iwith a zero and put quotes around each line of text of the structure and put 13, 10 at the end of each line.  You will learn to put variables between each line where you will put the data that is stored in the real structure.  Think about these things and let me know if you need any more help.  These are just ideas about only one way of solving this problem.  There is always more than one way so if you come up with another way, well, that's cool.


Have fun and let us know how it is going.  Congratulations on getting it to assemble.  It must have been a good feeling.

Paul


Thanks, it's getting easier to learn and remember with all the help that is given.

I have Olly Debug, trying to figure how best to use it. Unlike 16 bit, it's harder stepping though it and seeing where you are in relation to your source code. :-)

I'll put in some int3s and let it run to that point and study my regs, etc.

I have room to install the 2003 SDK. Does it have source code examples ? For 100 megs, I would hope so. :-)

Andy
Title: Re: Self incrementing Counter info
Post by: donkey on March 06, 2006, 05:41:28 AM
Hi skywalker,

The SDK comes with a few really good example snippets built in but unlike the MSDN library there are no working code examples. It is an excellent reference however and I rely on it for all my API questions. When used in conjunction with RadASM, you can just press F1 on any API call and have a complete explanation at your fingertips. Never underestimate the usefullness of reference material and never assume that you can have too much of it, you never know what you might need. For myself I constantly use the Platform SDK (the older XP one), x86eas.hlp, GoAsm.hlp, Agner's optimization manual, any thing I can find by Mark Larson and most of all the masm and winasm boards.
Title: Re: Self incrementing Counter info
Post by: PBrennick on March 06, 2006, 01:23:51 PM
Skywalker,

Quoteit's harder stepping though it and seeing where you are in relation to your source code.

Hutch always suggests, I think it is Hutch, to put a few nops before the code you want to check and after that code.  It is a very nice way of giving you something to search for.  nop means no operation so they will not compromise your code.

Paul
Title: Re: Self incrementing Counter info
Post by: donkey on March 06, 2006, 01:27:27 PM
Another good feature of OllyDbg is the ability to have it lock step your source line by line. When you link the project link it as a DEBUG project then you can have Olly open the source code, when you click on a line in the disassembled application it will hilite the line in the source that it pertains to. That is what the line number field in the PE specification is all about, something I sort of wish Jeremy would add to GoAsm but for now only MASM is capable of it AFAIK.
Title: Re: Self incrementing Counter info
Post by: AsmER on March 06, 2006, 10:07:15 PM
Hi everybody!

I have had the same idea in one of my c++'s program. I did it by writing 2 programs at the end but maybe it can help...
So first's program target was to open my application with self-incrementing counter, and write down 1 byte (because I needed value not grater than 256) at the end of it.
Main application just created a file handle to itself (EXE file) and read last byte (byte = counter), then modified it and overwrote last byte in file (from which was loaded to memory). In c++ nearly everything is possible (in c++ it worked), so if in assembler everything is possible, it should work as well.

I hope it is clearly enought. You can experiment with it (you know, for example you could encrypt it somehow - your choice ).

AsmER