New Member (re: Visual MASM IDE)

[jj2007]

I'm using a third party communications library to download the masm32 or the WinSDK ISO files. I'm also using the same library to check for a new version via a simple http get on my S3 storage. So, I guess it must be using wsock for the communication. The library is made by Eldos, a commercial library (https://www.eldos.com). Does that help?

I can't release the source since I'm using commercial libraries. Hope this helps.

OK, that explains the wsock. Now to WriteProcessMemory. Where and why does your IDE write to other people's processes?

[ThomasJaeger]

jj2007,

The only reference I could find about WriteProcessMemory is in my syntax highlighter for the API's. WriteProcessMemory is listed as one of the API commands. I did a windows grep search on my source and the third party libraries just to be sure and that's the only reference I could find.

Why do you say I'm writing to other people's memory? Why all this suspicion? I created Visual MASM actually mainly for myself because I wanted an IDE that helps me with my assembly. I wanted to get learn Windows assembly because my old DOS assembly knowledge is minimal. If you do not like it, do not use it. I'm simply sharing what I thought would be a nice gesture.

[jj2007]

jj2007,

The only reference I could find about WriteProcessMemory is in my syntax highlighter for the API's. WriteProcessMemory is listed as one of the API commands. I did a windows grep search on my source and the third party libraries just to be sure and that's the only reference I could find.

Why do you say I'm writing to other people's memory? Why all this suspicion?

Because I have written my own IDE (like several other people here), and never saw a need for using wsock functions, hooks and, worst case, WriteProcessMemory. If it is your syntax highlighter, just post the code (+- 50 lines) that uses WriteProcessMemory. We will understand it.

[rrr314159]

Evidently jj2007 is using some utility, grep, or a virus checker, that flagged your prog. If something unimportant like merely mentioning a questionable API call in a syntax highlighter causes an anti-virus to finger your prog, you need to know about it. Undoubtedly the question will come up again; it will be good to have an answer ready; or maybe you'd want to spell that one API reference with asterisks in the middle, or something. As for suspicion - of course people are suspicious on the internet, and they should be! No reason to take it personally; u wanted your program examined for any problems, that's exactly what we (well, not me - some of our less lazy members) are doing.

[qWord]

jj2007,
[...]Why all this suspicion?

Because he is the author of the best software library of the world and thus measure of all things.
But don't worry, the more infallible MasmBasic installer also marked me as potential criminal.

[adeyblue]

It's obviously a legit program, but you can see where he's coming from. Connecting to who knows where and downloading code, unpacking and executing embedded executables (its resources contain the 7-zip exe), and importing of the cryptographic and more furtive parts of the API (its skinning engine hooks GDI) are hallmarks of undesirable software

[jj2007]

Because he is the author of the best software library of the world and thus measure of all things.
But don't worry, the more infallible MasmBasic installer also marked me as potential criminal.

Hmmm.... how does your shrink evaluate these symptoms? Simple inferiority complex, or something more serious?

[ThomasJaeger]

I understand. You guys are a tough crowd but I do understand your concerns.  :icon_cool:

Here is a sample Delphi source that I use in my heavily customized SunEdit control in my SynHighlighterAsmMASM unit. This simply has a very large Unicode string that lists all API functions:

  Apis: UnicodeString =
    '__chkstk,__cppvalidateparameters,__glsparser_create,'+
    '__glsparser_print,__glsstring_appendchar,__glsstring_assign,__glsstring_init,'+
    '__pdxgetcmdline,__pdxinitializedata,__validateparameters,__wsafdisset,'+
   ...
    'writeprocessmemory,writeprocessorpwrscheme,writeprofilesection,'+
   ...

This is where you will see WriteProcessMemory listed. I do embed the the 7zip.dll because some of the code completion lists are ver large (almost 40,000 EQU's and API function names) and I simply reached the limit to hard code these things inside a function (more than 64 Kb in Delphi). So, I embedded the lists compressed as resources and then extract them in memory as streams and feed them to my customized SynEdit control. This controls is customized for MASM specifically and only MASM, like the MASM directives etc.

I was always fascinated with having a single EXE file. It's so simple. But, if you guys think I should put these resources as external resources, I can make that change.

Thanks you all for your feedback so far.

[qWord]

or something more serious?

hopefully not!

[jj2007]

This is where you will see WriteProcessMemory listed.

No, this is where you see writeprocessmemory listed. I see WriteProcessMemory, and it's not in the resource section. Besides, it seems you are actually using it somewhere, albeit not successfully:

Tested it a little bit and often got Access violation writing process memory

And the only legit use of WriteProcessMemory is code injection in the context of a debugger.

[ThomasJaeger]

Ok, so I did some further investigation and I found WriteProcessMemory used in the skinning library. The component is installed in a different folder than my source so my initial grep did not see it. I see it being used twice in the sSkinManager.pas unit:

procedure acHookProc(Proc, Dest: Pointer; var BackupCode: TXRedirCode);
var
  n: ACUInt;
  Code: TXRedirCode;
begin
  Proc := acGetActualAddr(Proc);
  if Proc <> nil then
    if ReadProcessMemory(GetCurrentProcess, Proc, @BackupCode, SizeOf(BackupCode), n) then begin
      Code.Jump := $E9;
      Code.Offset := PAnsiChar(Dest) - PAnsiChar(Proc) - SizeOf(Code);
      WriteProcessMemory(GetCurrentProcess, Proc, @Code, SizeOf(Code), n);
    end;
end;


procedure acUnhookProc(Proc: Pointer; var BackupCode: TXRedirCode);
var
  n: ACUInt;
begin
  if (BackupCode.Jump <> 0) and (Proc <> nil) then begin
    Proc := acGetActualAddr(Proc);
    Assert(Proc <> nil);
    WriteProcessMemory(GetCurrentProcess, Proc, @BackupCode, SizeOf(BackupCode), n);
    BackupCode.Jump := 0;
  end;
end;

These functions are called by

procedure HookGetSysColor;
begin
  if not SysColorsHooked then
    acHookProc(@Windows.GetSysColor, @acGetSysColor, WinGetSysColor);

  SysColorsHooked := True;
end;

procedure HookGetSysColorBrush;
begin
  if not SysColorsHookedBrush then begin
    SysColorsHookedBrush := True;
    acHookProc(@Windows.GetSysColorBrush, @acGetSysColorBrush, WinGetSysColorBrush);
  end;
end;

and others. When you buy the skinning library, you get all the source code with it, too. So, I honestly think there is nothing to worry about. But, if you still think there is something fishy, please feel free to purchase the library and investigate the source code further.

[jj2007]

Ok, so I did some further investigation and I found WriteProcessMemory used in the skinning library.

Any idea why vertograd saw access violations for such usage?

[ThomasJaeger]

Ok, so I did some further investigation and I found WriteProcessMemory used in the skinning library.

Any idea why vertograd saw access violations for such usage?

Another user reported this error:
Access violation at adress 0072BCC4 in module 'VisualMasm.exe'. Read of  address 00000030.

Access violations are very common in Delphi when an object is being accessed that is nil, for example. This is most likely one of my internal objects such as objects from the Project Explorer (my guess, because the project explorer and the management of it was one of the most complicated things). I'm trying to find out why and what caused it. This should not happen and I must have missed a check on a particular object. It's embarrassing that this error even happens and I thought I tested well enough.

I will spend some time the next few days and use all feedback so far to fix issues and apply some improvements on what I have got so far on feedback.

[GoneFishing]

Ok, so I did some further investigation and I found WriteProcessMemory used in the skinning library.

Any idea why vertograd saw access violations for such usage?

It turned out  those access violation message boxes don't contain "writing process memory" text . Sorry for misleading , but in that post I stated that I didn't remember the exact error message . In the attached archive you'll find 2 screenshots which illustrate "sticky tooltip" bug and that access violation message box (in fact I got it way too often on Windows XP SP3 ) .

P.S.: Maybe it will help: Note those "adresses" in "Read of  address 000000xx" string.
       I think  it's a character mistakenly  treated as an address

[jj2007]

Maybe it will help: Note those "adresses" in "Read of  address 000000xx" string.
       I think  it's a character mistakenly  treated as an address

It's a number actually: 30h = "0", 34h="4".