I'd like to change the domain name in an .EXE file from
"http://OakRoadSystems.com/" to " https://BrownMath.com/". (I own
both domains, but I'm consolidating them. While I still have the
source code, I no longer have the compiler.)

It's a 32-bit executable, about 168K in size, and it runs on the
command line (no GUI). I compiled it with Microsoft C in 2005, but no
longer have the compiler. I'll make both executables available, if
that helps. (One of them is already on my Web site as a free utility.)

I used Vim to make the edit, using spaces to make the new string the
same length as the old one. The edited EXE seems to run just fine,
rather to my surprise since I'd have thought there was a checksum.
Malwarebytes doesn't treat it as suspicious. I did a binary compare
and the only difference in the two files is the changed string.

Are there any other potential "gotchas" in what I did?

--
Stan Brown, Tehachapi, California, USA https://BrownMath.com/
https://OakRoadSystems.com/
Shikata ga nai...

"Stan Brown" wrote:
> I'd like to change the domain name in an .EXE file from
> "http://OakRoadSystems.com/" to " https://BrownMath.com/". (I own
> both domains, but I'm consolidating them. While I still have the
> source code, I no longer have the compiler.)
>
> It's a 32-bit executable, about 168K in size, and it runs on the
> command line (no GUI). I compiled it with Microsoft C in 2005, but no
> longer have the compiler. I'll make both executables available, if
> that helps. (One of them is already on my Web site as a free utility.)
>
> I used Vim to make the edit, using spaces to make the new string the
> same length as the old one. The edited EXE seems to run just fine,
> rather to my surprise since I'd have thought there was a checksum.

User-mode executables don't care about the header checksum. A kernel-
mode driver would.

> Malwarebytes doesn't treat it as suspicious. I did a binary compare
> and the only difference in the two files is the changed string.

Then Vim must have worked - I'm more surprised at that. I would have
used a utility for editing binary files (a hex editor).

> Are there any other potential "gotchas" in what I did?

Only if the spaces are significant in whatever way you are using the
string.

Stan Brown wrote:

> I'd like to change the domain name in an .EXE file from
> "http://OakRoadSystems.com/" to " https://BrownMath.com/". (I own
> both domains, but I'm consolidating them. While I still have the
> source code, I no longer have the compiler.)
>
> It's a 32-bit executable, about 168K in size, and it runs on the
> command line (no GUI). I compiled it with Microsoft C in 2005, but no
> longer have the compiler. I'll make both executables available, if
> that helps. (One of them is already on my Web site as a free utility.)
>
> I used Vim to make the edit, using spaces to make the new string the
> same length as the old one. The edited EXE seems to run just fine,
> rather to my surprise since I'd have thought there was a checksum.
> Malwarebytes doesn't treat it as suspicious. I did a binary compare
> and the only difference in the two files is the changed string.
>
> Are there any other potential "gotchas" in what I did?

I think I would've used "https://BrownMath.com/\0\0\0\0" (4 binary zeroes),
but no, there should be no issues.

However -- you could always download a C compiler and rebuild it from source.
Just because you currently don't have MSC doesn't mean that you can't get it
again. There is a free version here for Windows, Mac, and 64-bit Linux:

https://code.visualstudio.com/Download

....and there are many other compilers that might work for you:

https://alternativeto.net/feature/c-support/
https://www.thefreecountry.com/compilers/cpp.shtml

--
- I just hope you know what you're doing.
- I hope that same thing, on occasion.

"Stan Brown" <the_stan_brown@fastmail.fm> wrote

| I'd like to change the domain name in an .EXE file from
| "http://OakRoadSystems.com/" to " https://BrownMath.com/". (I own
| both domains, but I'm consolidating them. While I still have the
| source code, I no longer have the compiler.)
|

No problem with the spaces. If the strings were different
lengths you'd likely mess up the resource table. Everything
depends on pointers. So, for example, in the main PE header
there are 4-byte numbers pointing to the resource table
offset and size. It all works that way. If you mess with that
you have problems. If you added or removed just one byte
after those pointers you'd be unable to find function addresses
in a DLL, resources, etc. The whole thing would malfunction.
But what you're doing is just altering the data portion of a
string resource. And since you kept the length, the string size
indicator is still OK and the resource table size is still OK.

I don't know where a checksum would come from. You
would have had to have had an original checksum to check.
And it's not certain that such a small change would affect
a checksum. If you mean your own AV, I guess you'd just have
to tell it the file's OK.

It might be interesting to do a checksum on the original
and the current to see if they match. My understanding is
that the process involves computing some kind of formula
with a number of bytes in the file, but not all of them. And
I would expect such a tool to have the intelligence to
skip tables and do the checksum on the "text" section that
contains the executable data. But I don't know if that's true.

On 12/7/2021 8:32 AM, Stan Brown wrote:
> I'd like to change the domain name in an .EXE file from
> "http://OakRoadSystems.com/" to " https://BrownMath.com/". (I own
> both domains, but I'm consolidating them. While I still have the
> source code, I no longer have the compiler.)
>
> It's a 32-bit executable, about 168K in size, and it runs on the
> command line (no GUI). I compiled it with Microsoft C in 2005, but no
> longer have the compiler. I'll make both executables available, if
> that helps. (One of them is already on my Web site as a free utility.)
>
> I used Vim to make the edit, using spaces to make the new string the
> same length as the old one. The edited EXE seems to run just fine,
> rather to my surprise since I'd have thought there was a checksum.
> Malwarebytes doesn't treat it as suspicious. I did a binary compare
> and the only difference in the two files is the changed string.
>
> Are there any other potential "gotchas" in what I did?
>

A hex editor. Using a hex editor, ensures no inadvertent changes
are made to a file.

Edited string should be shorter than the original.

Unused bytes on the end should be 0x00. Nulls are
a termination for strings in C. If this was Pascal,
the first byte in the string would be the byte count,
and that would be more of a problem. C makes it easier
to hack.

Original ABCD E F G H 0x00 # A string terminated by a null, 9 char total
Edited QRST 0x00 0x00 0x00 0x00 0x00 # Fill to the same length with nulls

C stops, when it hits the first null.

All as detailed by Auric.

*******

https://mh-nexus.de/en/hxd/

You can use the English Portable version from the second
section of the downloads page.

https://mh-nexus.de/en/downloads.php?product=HxD20

The portable version, whatever directory it is sitting in,
it creates a "Settings" folder, which is moderately annoying.
It does that, because there's some language thing stored
in the Settings folder.

hxd.exe
Settings\ <=== folder

*******

Mingw32, is a project that uses GCC as its compiler.

https://en.wikipedia.org/wiki/MinGW

The executable format produced, cannot be debugged with windbg.
GCC output is debugged with gdb. Visual Studio C is debugged
with windbg. Other than that, I've used mingw32 a lot for
my hobby projects. I tried a couple times to install mingw64
projects, but I never got any output from them. Whereas the
original mingw32 works pretty well.

At one time, there was a big difference in size between
GCC output (a.out) and other compilers. But over the years,
they are basically in the same ballpark now, so that's not
a concern any more.

You can work with big disks or big files with mingw. There
is an open64() and fopen64(). These allow 64 bit offsets
to be used, for accessing very large disk drives or files.
I needed something like that, because I have a simple minded
compressor for big files, that removes large sections of all
zero content. So other compressors in a pipeline, won't have
to sit there chewing on zeros all day.

And this environment is not visual studio, so it doesn't
have the semantic tapioca pudding you want. It's a very basic
environment for 60 line programs. You would not attempt to
"write Firefox in it".

The biggest code I've written, was 5000 lines, but that
was a long time ago, and I'm not a software developer. Today,
60 lines is my limit. I get in less trouble that way.

Paul

"Paul" <nospam@needed.invalid> wrote

| Unused bytes on the end should be 0x00. Nulls are
| a termination for strings in C. If this was Pascal,
| the first byte in the string would be the byte count,
| and that would be more of a problem. C makes it easier
| to hack.

In a typical case, software reading the string table
would be checking length bytes to find the length of
the string and then retrieving those bytes, typically
as 2-byte unicode. It's not going to read until it hits a null.
So spaces are better because treating nulls as text can
cause problems.

Not a big deal, but the resource table/string table,
as part of Windows PE file structure, has its own format.
It has nothing to do with programming language.

On Tue, 7 Dec 2021 15:21:56 -0000, Apd wrote:
>
> "Stan Brown" wrote:
> User-mode executables don't care about the header checksum. A
> kernel-mode driver would.

Thanks -- I didn't know they made that distinction.
>
> > Malwarebytes doesn't treat it as suspicious. I did a binary compare
> > and the only difference in the two files is the changed string.
>
> Then Vim must have worked - I'm more surprised at that. I would have
> used a utility for editing binary files (a hex editor).

Vim has a specifically binary mode. Use the ":set bin" command before
opening the file.

> > Are there any other potential "gotchas" in what I did?
>
> Only if the spaces are significant in whatever way you are using the
> string.

Great! I did of course make sure the string had the same length
(including spaces) as before, but it's just display text so there are
no implications as far as my program is concerned.

--
Stan Brown, Tehachapi, California, USA https://BrownMath.com/
https://OakRoadSystems.com/
Shikata ga nai...

On Tue, 7 Dec 2021 16:23:55 -0000 (UTC), Auric__ wrote:
> However -- you could always download a C compiler and rebuild it from source.
> Just because you currently don't have MSC doesn't mean that you can't get it
> again. There is a free version here for Windows, Mac, and 64-bit Linux:
>
> https://code.visualstudio.com/Download

Hmm ... I didn't know that. I'll check it out when I have time. I was
pretty careful to avoid Microsoft extensions to C, so it shouldn't be
_too_ hard to recompile.

--
Stan Brown, Tehachapi, California, USA https://BrownMath.com/
https://OakRoadSystems.com/
Shikata ga nai...

Stan Brown wrote:

> On Tue, 7 Dec 2021 16:23:55 -0000 (UTC), Auric__ wrote:
>> However -- you could always download a C compiler and rebuild it from
>> source. Just because you currently don't have MSC doesn't mean that you
>> can't get it again. There is a free version here for Windows, Mac, and
>> 64-bit Linux:
>>
>> https://code.visualstudio.com/Download
>
> Hmm ... I didn't know that. I'll check it out when I have time. I was
> pretty careful to avoid Microsoft extensions to C, so it shouldn't be
> _too_ hard to recompile.

If it's pure, unadulterated C (of the C99 variety), I find that I like
Fabrice Bellard's tcc. It's fast and light, especially when compared to
modern systems like gcc or MSVC. It's not developed any more (last updated in
2017) but it still works just fine. (And it's open source, so there may be a
more recent fork somewhere.)

https://bellard.org/tcc/

--
- You don't understaaaaaaaaaand!
- No, I guess I don't.

On Wed, 8 Dec 2021 16:51:02 -0000 (UTC), Auric__ wrote:
>
> Stan Brown wrote:
>
> > On Tue, 7 Dec 2021 16:23:55 -0000 (UTC), Auric__ wrote:
> >> However -- you could always download a C compiler and rebuild it from
> >> source. Just because you currently don't have MSC doesn't mean that you
> >> can't get it again. There is a free version here for Windows, Mac, and
> >> 64-bit Linux:
> >>
> >> https://code.visualstudio.com/Download
> >
> > Hmm ... I didn't know that. I'll check it out when I have time. I was
> > pretty careful to avoid Microsoft extensions to C, so it shouldn't be
> > _too_ hard to recompile.
>
> If it's pure, unadulterated C (of the C99 variety), I find that I like
> Fabrice Bellard's tcc. It's fast and light, especially when compared to
> modern systems like gcc or MSVC. It's not developed any more (last updated in
> 2017) but it still works just fine. (And it's open source, so there may be a
> more recent fork somewhere.)
>
> https://bellard.org/tcc/

It's a long time since I've looked at the code, but IIRC it's pure,
unadulterated C of the Kernighan & Ritchie variety! I assume TCC
would compile that.

--
Stan Brown, Tehachapi, California, USA https://BrownMath.com/
https://OakRoadSystems.com/
Shikata ga nai...