Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Hex editor with flexible Find/Replace?
108 views
Skip to first unread message
Terry Pinnell
Feb 27, 2017, 3:55:21 AM2/27/17
to
I'm not a techie or programmer but occasionally need to edit binary
files. For example, my app Macro Express Pro creates its macro files in
proprietary (MXE) format. If I make changes to this Win 10 PC
file/folder organisation then scores or even hundreds of macros will
have to be edited. For example, a macro script command that contains the
string 'C:\xyz\abc' might need changing to 'D:\wxyz\abcd'.
I have the handy freeware program HxD, which lets me make changes *of
the same length* (such as changing C:\abc to D:\def) but I'm looking for
a program that will achieve those more complex edits.
Ideally freeware, but *any* recommendations would be appreciated please.
--
Terry, East Grinstead, UK
files. For example, my app Macro Express Pro creates its macro files in
proprietary (MXE) format. If I make changes to this Win 10 PC
file/folder organisation then scores or even hundreds of macros will
have to be edited. For example, a macro script command that contains the
string 'C:\xyz\abc' might need changing to 'D:\wxyz\abcd'.
I have the handy freeware program HxD, which lets me make changes *of
the same length* (such as changing C:\abc to D:\def) but I'm looking for
a program that will achieve those more complex edits.
Ideally freeware, but *any* recommendations would be appreciated please.
--
Terry, East Grinstead, UK
JJ
Feb 27, 2017, 5:58:46 AM2/27/17
to
different length.
Below screenshot shows a two byte data replaced with 3 bytes. The original
data following the 2 bytes of data are shifted by one byte - increasing the
file size by one byte.
<http://i.imgur.com/CMutSGg.jpg>
The software is old, abandoned, and its author's website is gone. But it's
still working on Windows 7 x64. Note that it doesn't seem to be able to edit
file which is larger than 2GB.
<http://web.archive.org/web/20070720191528/http://www.mirkes.de/en/freeware/tinyhex.php>
Unfortunately, the last version download is not archived, but you can get it
from e.g. Softpedia or other software library sites.
<http://www.softpedia.com/get/Others/Miscellaneous/tiny-hexer.shtml>
terry...@gmail.com
Feb 27, 2017, 7:50:27 AM2/27/17
to
Many thanks, JJ, I'll download that when I get back to my PC, as it looks exactly what I need.
Terry, East Grinstead, UK
Terry, East Grinstead, UK
Terry Pinnell
Feb 27, 2017, 11:12:00 AM2/27/17
to
for example, 'Terry' with 'Terry2', when I try to import or run that my
application behaves as if it's corrupt or inaccessible. ('Jerry' is OK.)
But I also tried two other hex editors recommended elsewhere with same
result. So, given that you and others get success, I suppose I'm not
using them correctly.
Is there some easily accessible app (Excel, Google Earth, ...) with
which we can try an example please?
Terry
Shadow
Feb 27, 2017, 8:21:58 PM2/27/17
to
files and editing binary/data files, specially if the latter are
indexed.
In an executable it will change all the jump addresses, and in
an indexed file (by binary position) you will also retrieve the wrong
data.
So the only way would be: import to original app ---> edit
---> save.
A PITA ...
[]'s
--
Don't be evil - Google 2004
We have a new policy - Google 2012
JJ
Feb 27, 2017, 11:33:29 PM2/27/17
to
On Mon, 27 Feb 2017 16:11:56 +0000, Terry Pinnell wrote:
>
> Duly installed and tested. Although it appears to successfully replace,
> for example, 'Terry' with 'Terry2', when I try to import or run that my
> application behaves as if it's corrupt or inaccessible. ('Jerry' is OK.)
>
> But I also tried two other hex editors recommended elsewhere with same
> result. So, given that you and others get success, I suppose I'm not
> using them correctly.
>
> Is there some easily accessible app (Excel, Google Earth, ...) with
> which we can try an example please?
>
> Terry
You can't edit an executable or any binary files that way because they have
>
> Duly installed and tested. Although it appears to successfully replace,
> for example, 'Terry' with 'Terry2', when I try to import or run that my
> application behaves as if it's corrupt or inaccessible. ('Jerry' is OK.)
>
> But I also tried two other hex editors recommended elsewhere with same
> result. So, given that you and others get success, I suppose I'm not
> using them correctly.
>
> Is there some easily accessible app (Excel, Google Earth, ...) with
> which we can try an example please?
>
> Terry
data structure which contains file offsets and data sizes of parts within
the file. It would 100% guaranteed to broke the program/data if those
offsets and sizes aren't updated.
If what you're trying to edit is a resource string (not all text in an
executable files are resource string, BTW), use Resource Hacker instead (for
editing 32-bit executable files only). For editing resources of 64-bit
executable files, use CFF Explorer.
Wildman
Feb 28, 2017, 12:28:45 AM2/28/17
to
On Mon, 27 Feb 2017 16:11:56 +0000, Terry Pinnell wrote:
a string in that way if it is an embedded string. You can change the
string but it must remain the same length. OTOH if the string is a
resource, you can edit it with a program like Resource Hacker as JJ
mentioned.
--
<Wildman> GNU/Linux user #557453
The cow died so I don't need your bull!
Spamblk
Feb 28, 2017, 12:33:43 AM2/28/17
to
Terry Pinnell <m...@somewhere.invalid> wrote in
<news:8jj8bcphdp7q2kki9...@4ax.com>:
> Duly installed and tested. Although it appears to successfully replace,
> for example, 'Terry' with 'Terry2', when I try to import or run that my
> application behaves as if it's corrupt or inaccessible. ('Jerry' is OK.)
>
> But I also tried two other hex editors recommended elsewhere with same
> result. So, given that you and others get success, I suppose I'm not
> using them correctly.
>
with a longer string but it issues a dialog that the operation will change the
filesize. In my experience it is possible to effectively shorten strings in an
executable without changing filesize by overwriting that part of a string to be
changed then using the hex editors numeric hex input facility to insert code 00
(null) character to terminate the string. The onsolete characters after the
'\0' tend to be ignored in most cases.
OTOH Adding characters to a string might then corrupt a following string, a
symbol or perhaps even change executable code. For executable files, I wouldnt
have thought being able to variable size replace with a hex editor would be all
that useful. You might get away with for example adding 5 characters to a
string in one place and claim the 5 characters back in another place in such a
way as to prevent the executable choking. I wouldnt count on it though. You
would have to get to know that executable really well. It would be easier to
recompile even if that means chasing after libraries or dependencies and other
prerequistites that the compiler might demand.
Terry Pinnell
Feb 28, 2017, 4:35:19 AM2/28/17
to
I could not pursue yesterday but was up early this morning and installed
three additional hex editors professing to replace 'unequal length'
text. And established that none give the desired result using my simple
approach, i.e.essentially using them as I do my text editor. I'm now
clear that was a fool's errand.
But I haven't quite given up and intend to experiment further today in
the light of all the latest advice.
I also muddied the water by wrongly specifying the file extension for
hex editing as MXE. That should have been MEX, sorry.
For those interested in more detail:
MEX is a proprietary binary file that can contain any number of macros.
I want to globally edit the file containing *all* my many hundreds of
macros, as described. Here's what an MEX file called 'PHOTOS - FOLDER
(ph).mex' containing a single macro looks like in three different text
editors:
https://dl.dropboxusercontent.com/u/4019461/MEX-OpenedIn3TextEditors.jpg
Here's the MEX file, should anyone want to play with it:
https://dl.dropboxusercontent.com/u/4019461/PHOTOS%20-%20FOLDER%20%28ph%29.mex
(The function of that very simple macro is to type the string
'D:\Pictures\PHOTOS\' when the abbreviation '=ph' is typed.)
MXE is a text file containing the script of one macro. It is obviously
normally edited in MX Pro itself.
My only current method of 'global' editing of the form described is to
use a macro to operate successively on each macro - a glacially slow
process, apart from its inelegance! Hence my hope of doing so in a hex
editor on hundreds of macros at once!
Diesel
Feb 28, 2017, 7:01:18 AM2/28/17
to
Terry Pinnell <m...@somewhere.invalid>
news:bqaabc5e8d07tdm21...@4ax.com Tue, 28 Feb 2017
It may not be the hex editors fault because the .mex file you
provided has the length of the string it's expecting to be inside. If
you change the length of the string and do not adjust that value as
well, it'll read the wrong amount of bytes for the string and not
work as you intended.
values provided in hex. file offset 0x235 is the length in bytes
specified in hex of your string that begins 3 bytes beyond it. In the
sample provided via your link, only one byte is being used, 3 are set
to null. Is there a character length limit for a macro string? If so,
do you know what it might be? In your .mex file, the amount of bytes
which represent your string is 19, which is represented by (13) in
hex at hex offset 0x235. If your string exceeds 256 bytes total
length though, the .mex file will change another currently null byte
to another value along with the one at 0x235 to represent the larger
amount of characters in your string. That is, if you can have macros
longer than 256 characters. I'm not familiar with the program you
used to create the file.
> For those interested in more detail:
> MEX is a proprietary binary file that can contain any number of
> macros. I want to globally edit the file containing *all* my many
> hundreds of macros, as described. Here's what an MEX file called
> 'PHOTOS - FOLDER (ph).mex' containing a single macro looks like in
> three different text editors:
> https://dl.dropboxusercontent.com/u/4019461/MEX-OpenedIn3TextEditor
> s.jpg
>
> Here's the MEX file, should anyone want to play with it:
> https://dl.dropboxusercontent.com/u/4019461/PHOTOS%20-%20FOLDER%20%
> 28ph%29.mex
>
> (The function of that very simple macro is to type the string
> 'D:\Pictures\PHOTOS\' when the abbreviation '=ph' is typed.)
>
> MXE is a text file containing the script of one macro. It is
> obviously normally edited in MX Pro itself.
>
> My only current method of 'global' editing of the form described
> is to use a macro to operate successively on each macro - a
> glacially slow process, apart from its inelegance! Hence my hope
> of doing so in a hex editor on hundreds of macros at once!
>
>
Are all of your macros stored individually, or as one giant mex file?
I'd need to see this large file, if the latter. As well as any
smaller ones that have more than one macro present.
--
Sarcasm, because beating the living shit out of deserving people is
illegal.
news:bqaabc5e8d07tdm21...@4ax.com Tue, 28 Feb 2017
09:35:12 GMT in alt.comp.freeware, wrote:
> Thanks to all for those helpful follow-up replies.
>
> I could not pursue yesterday but was up early this morning and
> installed three additional hex editors professing to replace
> 'unequal length' text. And established that none give the desired
> result using my simple approach, i.e.essentially using them as I
> do my text editor. I'm now clear that was a fool's errand.
So far, quick glance information only...
> Thanks to all for those helpful follow-up replies.
>
> I could not pursue yesterday but was up early this morning and
> installed three additional hex editors professing to replace
> 'unequal length' text. And established that none give the desired
> result using my simple approach, i.e.essentially using them as I
> do my text editor. I'm now clear that was a fool's errand.
It may not be the hex editors fault because the .mex file you
provided has the length of the string it's expecting to be inside. If
you change the length of the string and do not adjust that value as
well, it'll read the wrong amount of bytes for the string and not
work as you intended.
values provided in hex. file offset 0x235 is the length in bytes
specified in hex of your string that begins 3 bytes beyond it. In the
sample provided via your link, only one byte is being used, 3 are set
to null. Is there a character length limit for a macro string? If so,
do you know what it might be? In your .mex file, the amount of bytes
which represent your string is 19, which is represented by (13) in
hex at hex offset 0x235. If your string exceeds 256 bytes total
length though, the .mex file will change another currently null byte
to another value along with the one at 0x235 to represent the larger
amount of characters in your string. That is, if you can have macros
longer than 256 characters. I'm not familiar with the program you
used to create the file.
> For those interested in more detail:
> MEX is a proprietary binary file that can contain any number of
> macros. I want to globally edit the file containing *all* my many
> hundreds of macros, as described. Here's what an MEX file called
> 'PHOTOS - FOLDER (ph).mex' containing a single macro looks like in
> three different text editors:
> https://dl.dropboxusercontent.com/u/4019461/MEX-OpenedIn3TextEditor
> s.jpg
>
> Here's the MEX file, should anyone want to play with it:
> https://dl.dropboxusercontent.com/u/4019461/PHOTOS%20-%20FOLDER%20%
> 28ph%29.mex
>
> (The function of that very simple macro is to type the string
> 'D:\Pictures\PHOTOS\' when the abbreviation '=ph' is typed.)
>
> MXE is a text file containing the script of one macro. It is
> obviously normally edited in MX Pro itself.
>
> My only current method of 'global' editing of the form described
> is to use a macro to operate successively on each macro - a
> glacially slow process, apart from its inelegance! Hence my hope
> of doing so in a hex editor on hundreds of macros at once!
>
>
I'd need to see this large file, if the latter. As well as any
smaller ones that have more than one macro present.
--
Sarcasm, because beating the living shit out of deserving people is
illegal.
David B.
Feb 28, 2017, 8:08:51 AM2/28/17
to
to visit his most recent post here:-
From: Terry Pinnell <m...@somewhere.invalid>
Newsgroups: alt.comp.os.windows-10
Subject: Re: OT: Hex editor recommendation?
Message-ID: <epqabctn6c0msoop7...@4ax.com>
It's really good to see you trying to help someone, Dustin. :-)
--
"Do something wonderful, people may imitate it." (Albert Schweitzer)
Terry Pinnell
Feb 28, 2017, 9:13:17 AM2/28/17
to
Diesel <m...@privacy.net> wrote:
>Terry Pinnell <m...@somewhere.invalid>
>news:bqaabc5e8d07tdm21...@4ax.com Tue, 28 Feb 2017
>09:35:12 GMT in alt.comp.freeware, wrote:
>
>> Thanks to all for those helpful follow-up replies.
>>
>> I could not pursue yesterday but was up early this morning and
>> installed three additional hex editors professing to replace
>> 'unequal length' text. And established that none give the desired
>> result using my simple approach, i.e.essentially using them as I
>> do my text editor. I'm now clear that was a fool's errand.
>
Many thanks for getting on the case, much appreciated, especially as I'm
>Terry Pinnell <m...@somewhere.invalid>
>news:bqaabc5e8d07tdm21...@4ax.com Tue, 28 Feb 2017
>09:35:12 GMT in alt.comp.freeware, wrote:
>
>> Thanks to all for those helpful follow-up replies.
>>
>> I could not pursue yesterday but was up early this morning and
>> installed three additional hex editors professing to replace
>> 'unequal length' text. And established that none give the desired
>> result using my simple approach, i.e.essentially using them as I
>> do my text editor. I'm now clear that was a fool's errand.
>
way out of my depth!
>So far, quick glance information only...
>
>It may not be the hex editors fault because the .mex file you
>provided has the length of the string it's expecting to be inside. If
>you change the length of the string and do not adjust that value as
>well, it'll read the wrong amount of bytes for the string and not
>work as you intended.
>values provided in hex. file offset 0x235 is the length in bytes
>specified in hex of your string that begins 3 bytes beyond it. In the
>sample provided via your link, only one byte is being used, 3 are set
>to null. Is there a character length limit for a macro string? If so,
>do you know what it might be? In your .mex file, the amount of bytes
>which represent your string is 19, which is represented by (13) in
>hex at hex offset 0x235. If your string exceeds 256 bytes total
>length though, the .mex file will change another currently null byte
>to another value along with the one at 0x235 to represent the larger
>amount of characters in your string. That is, if you can have macros
>longer than 256 characters. I'm not familiar with the program you
>used to create the file.
I'm an (advanced) end-user but not a programmer. So navigating around
'offsets' in hex editors is not a skill I have. But I'll try to learn if
you take it slowly ;-)
"values provided in hex. file offset 0x235 is the length in bytes
specified in hex of your string that begins 3 bytes beyond it."
https://dl.dropboxusercontent.com/u/4019461/LengthInBytes-1.jpg
I don't know of any character length limit for a macro string. Some of
my macros have hundreds of lines of script. The one I uploaded has just
three:
Keystroke Speed: 10 milliseconds
Text Type (Simulate Keystrokes): D:\Pictures\PHOTOS\
Delay: 50 milliseconds
The macro file resulting from exporting that macro as an MEX file
is 1,391 bytes long. Which is hex 31 33 39 31 according to my converter.
>> For those interested in more detail:
>> MEX is a proprietary binary file that can contain any number of
>> macros. I want to globally edit the file containing *all* my many
>> hundreds of macros, as described. Here's what an MEX file called
>> 'PHOTOS - FOLDER (ph).mex' containing a single macro looks like in
>> three different text editors:
>> https://dl.dropboxusercontent.com/u/4019461/MEX-OpenedIn3TextEditor
>> s.jpg
>>
>> Here's the MEX file, should anyone want to play with it:
>> https://dl.dropboxusercontent.com/u/4019461/PHOTOS%20-%20FOLDER%20%
>> 28ph%29.mex
>>
>> (The function of that very simple macro is to type the string
>> 'D:\Pictures\PHOTOS\' when the abbreviation '=ph' is typed.)
>>
>> MXE is a text file containing the script of one macro. It is
>> obviously normally edited in MX Pro itself.
>>
>> My only current method of 'global' editing of the form described
>> is to use a macro to operate successively on each macro - a
>> glacially slow process, apart from its inelegance! Hence my hope
>> of doing so in a hex editor on hundreds of macros at once!
>>
>>
>
>Are all of your macros stored individually, or as one giant mex file?
over 2,000 macros in the file FULL-2016.mex. Its size is 11 KB.
>I'd need to see this large file, if the latter. As well as any
>smaller ones that have more than one macro present.
https://dl.dropboxusercontent.com/u/4019461/TwoMacrosExported.mex
(Right click and Save As if you want to download for a closer look in
your hex editor.)
Also, here are illustrations showing recent work:
https://dl.dropboxusercontent.com/u/4019461/Original%2BNativeEdit.jpg
https://dl.dropboxusercontent.com/u/4019461/OriginalAttemptedHexEdit-1.jpg
https://dl.dropboxusercontent.com/u/4019461/HexEditRejected.jpg
JJ
Feb 28, 2017, 10:34:22 AM2/28/17
to
On Tue, 28 Feb 2017 14:13:14 +0000, Terry Pinnell wrote:
>
> Do you mean the total length of the file, in bytes?
He meant the length of the text. In binary files, some formats includes the
>
> Do you mean the total length of the file, in bytes?
length of the text (or any data) stored in the file. Some other formats
simply use a special character to mark the end of of a text.
Like he mentioned, the "D:\Pictures\PHOTOS\" text has its text length stored
in file offset 0x235. If you edit the text and end up with different text
length, the data that specify the text length must also be updated to
reflect that changes.
But that's not all. Keep in mind that binary file are usually structured and
the data that specifies the text length may not be the only data which you
need to update. For example, in your "PHOTOS - FODLER (ph).mex" file, the
MEX file format also stores the file size, which is at file offset 0x6. That
must be updated too if after editing, the file size changed.
Who knows what other data need to be updated when part of the file is
changed and ended up with different length. You'll need to have the complete
specifications of how MEX file format. While MEX files seems to be small, I
counted about 25 fields of different information in the first 0x250 bytes of
file. That's not a small number to guess what each field means.
If you want to change one file path text, try below method to find out which
data needs to be updated.
1. Save a single macro (any macro) into file. Call it "file1.mex".
2. Using your MX Pro software, change the file path in the macro by adding
one character onto it.
3. Save the macro and call it "file2.mex".
4. Compare "file1.mex" and "file2.mex" using a binary file comparer
software, or do it manually.
5. In "file2.mex", any non text data whose value is one point higher than
the one in "file1.mex", should be considered as data which stores data size
- whichever data that is. Take notes on their offsets since they should be
updated when you change the file path text within a MEX file.
Terry Pinnell
Feb 28, 2017, 11:35:17 AM2/28/17
to
dropped, as you see from my screenshots after creating the two files you
suggested:
https://dl.dropboxusercontent.com/u/4019461/HexEditing-02.jpg
Looking in file2.mex for any non text data whose value is one higher
than that in file1.mex makes finding needles in haystacks look easy!
What would be very helpful would be for an experienced and generous user
with a little time to spare to find a binary file that is mutually
accessible, unlike my MX Pro files, and we could then step through a
successful edit.
(I was thinking of maybe Excel. But in an initial test with 'xyz' in
cell A1 of a worksheet, I couldn't even get a hex editor to find xyz,
much less replace it.)
Shadow
Feb 28, 2017, 12:51:54 PM2/28/17
to
On Tue, 28 Feb 2017 13:08:48 +0000, "David B."
<Dav...@nomail.afraid.invalid> wrote:
>I'm not sure if Terry is having more than one problem
Try reading his post. Then you'll know.
<Dav...@nomail.afraid.invalid> wrote:
>I'm not sure if Terry is having more than one problem
Shadow
Feb 28, 2017, 1:04:49 PM2/28/17
to
0x13h = 19
D:\Pictures\photos\ = 19 chars, if you include the ":' and the
"\"
0x14h = 20
D:\Pictures\photos2\
13 hex = 16+3 = 19 decimal
14 hex = 16+4 = 20 decimal.
So you've found where it keeps the length. Remember, to count
in hex you need 16 fingers.
Now you need to find how it handles the offsets.
The "easiest" way, though, would be to reverse the app and see
the routines it uses.
Shadow
Feb 28, 2017, 1:41:00 PM2/28/17
to
decimal.
So it appears to keep multiple markers.
What version are you using to write the data ? I downloaded
Macro Express Pro v4.7.1.1 and it appears to be written in Delphi,
IOW, not protected. I didn't install though.
Just a thought, if you have a commercial licence, they could
probably make something to batch convert your data .... you can always
ask.
Terry Pinnell
Feb 28, 2017, 3:20:24 PM2/28/17
to
I'm continuing to try the 'reverse engineering' approach but it has not
yet added any practical insights.
The odds are poor on getting helpful documentation on the MEX structure
from its developer, Insight, but I have just emailed them.
I'd be more confident if I could edit ANY 'longer' replacement
successfully. That's why I'm hoping someone can suggest a mutually
accessible application and file and step through a hex edit with me. I
now appreciate that all files have their own structure, but even one
radically different to an MEX would help me get the basic stuff right.
terry...@gmail.com
Mar 1, 2017, 12:33:52 AM3/1/17
to
I had a prompt and thorough reply from the developers of MX Pro. As I expected, they are unable to provide detailed table structure documentation for their MEX files. And there are other complications (packing) which would make it impossible in practice.
So I'll drop my pursuit of a no-brainer global hex edit. Thanks for all the interest and advice.
Terry, East Grinstead, UK
So I'll drop my pursuit of a no-brainer global hex edit. Thanks for all the interest and advice.
Terry, East Grinstead, UK
Diesel
Mar 1, 2017, 4:01:46 AM3/1/17
to
terry...@gmail.com
news:a8a7a854-cb23-4ca4...@googlegroups.com Wed, 01
reverse engineer without the benefit of source code. While it may not
be reliable to know all possible byte configurations, it's feasable
one could reverse engineer enough of their data file in order to
construct a program which can do the selective replacing you were
originally looking for.
I would require additional mex samples and you'd have to be willing
to test some modified results and report back. It would also take
several days for me to write/debug this program for you, as a bit of
reverse engineering is involved, and, spare time isn't all that
plentiful these days. I'm willing to write the program to do this, if
at all possible.
If you can specify the exact version you're using, that would be very
helpful too; I could reduce development time by having a local copy
of it to analyze.
> So I'll drop my pursuit of a no-brainer global hex edit. Thanks
> for all the interest and advice.
No, short of using more macros, I know of no way to do a global hex
edit without writing a program specifically to do it for you.
And, as I wrote, that requires spending more time with the .mex files
and some variants, so one can see what remains static (if anything)
and what is subject to change and what those changes are supposed to
represent.
1.3kilobytes of binary data may not seem like much to you, but, as
another poster pointed out, it actually contains a lot of
information; much of which is presently unknown to myself. So,
writing the program will take a bit of time because, well, most of
the time will be spent studying the mex file format in more detail.
news:a8a7a854-cb23-4ca4...@googlegroups.com Wed, 01
Mar 2017 05:33:45 GMT in alt.comp.freeware, wrote:
> I had a prompt and thorough reply from the developers of MX Pro.
> As I expected, they are unable to provide detailed table structure
> documentation for their MEX files. And there are other
> complications (packing) which would make it impossible in
> practice.
Well, not exactly, no. One aspect to 'cracking' is the ability to
> I had a prompt and thorough reply from the developers of MX Pro.
> As I expected, they are unable to provide detailed table structure
> documentation for their MEX files. And there are other
> complications (packing) which would make it impossible in
> practice.
reverse engineer without the benefit of source code. While it may not
be reliable to know all possible byte configurations, it's feasable
one could reverse engineer enough of their data file in order to
construct a program which can do the selective replacing you were
originally looking for.
I would require additional mex samples and you'd have to be willing
to test some modified results and report back. It would also take
several days for me to write/debug this program for you, as a bit of
reverse engineering is involved, and, spare time isn't all that
plentiful these days. I'm willing to write the program to do this, if
at all possible.
If you can specify the exact version you're using, that would be very
helpful too; I could reduce development time by having a local copy
of it to analyze.
> So I'll drop my pursuit of a no-brainer global hex edit. Thanks
> for all the interest and advice.
edit without writing a program specifically to do it for you.
And, as I wrote, that requires spending more time with the .mex files
and some variants, so one can see what remains static (if anything)
and what is subject to change and what those changes are supposed to
represent.
1.3kilobytes of binary data may not seem like much to you, but, as
another poster pointed out, it actually contains a lot of
information; much of which is presently unknown to myself. So,
writing the program will take a bit of time because, well, most of
the time will be spent studying the mex file format in more detail.
David B.
Mar 1, 2017, 4:27:33 AM3/1/17
to
For this non-techie fellow, will you please explain what you were trying
to do/accomplish in the first place?
I have little experience of Hex matters, but when faced with various
code puzzles by Dustin Cook (an ex-malware writer - VXer as he calls
it!) - he's posting here as 'Diesel' - I tried to use THIS facility:-
http://www.convertstring.com
I encountered /problems/ - but then, I didn't really have a clue what I
was doing! Anyway, I ended up in much discussion with the author. Quite
by chance I had stumbled across some inherent errors which, after quite
some time, he eventually corrected. He actually thanked me for bringing
the bugs to his attention!
Anyway, YOU may find the facility helpful in achieving your objective.
Perhaps you'll let me know?
=
Is this REALLY your home, Terry? https://goo.gl/AGYBoS
Dustin doesn't understand this type of humour! ;-)
I originally hail from Maidstone, so am well aware that you live in a
great part of our wonderful country, though I expect you are finding it
much busier nowadays.
burfordTjustice
Mar 1, 2017, 5:59:54 AM3/1/17
to
On Wed, 1 Mar 2017 09:27:29 +0000
"David B." <Dav...@nomail.afraid.invalid> wrote:
> Is this REALLY your home, Terry?
Attempt to suck another to giving up information
"David B." <Dav...@nomail.afraid.invalid> wrote:
> Is this REALLY your home, Terry?
for stalking noted.
Shadow
Mar 1, 2017, 8:14:59 AM3/1/17
to
On Tue, 28 Feb 2017 21:33:45 -0800 (PST), terry...@gmail.com wrote:
>I had a prompt and thorough reply from the developers of MX Pro. As I expected, they are unable
>to provide detailed table structure documentation for their MEX files. And there are other complications
>(packing) which would make it impossible in practice.
It would have been nice if they had included multiple database
>I had a prompt and thorough reply from the developers of MX Pro. As I expected, they are unable
>to provide detailed table structure documentation for their MEX files. And there are other complications
>(packing) which would make it impossible in practice.
editing as a feature in an update. Not hard to do, since they have the
source code.
But that's the problem with closed source, the little guy
doesn't have a voice. If you were a big company, it would be in the
next release.
>
>So I'll drop my pursuit of a no-brainer global hex edit. Thanks for all the interest and advice.
Shadow
Mar 1, 2017, 8:25:00 AM3/1/17
to
On Wed, 1 Mar 2017 09:27:29 +0000, "David B."
<Dav...@nomail.afraid.invalid> wrote:
>On 01/03/2017 05:33, terry...@gmail.com wrote:
>> I had a prompt and thorough reply from the developers of MX Pro. As I expected, they are unable to provide detailed table structure documentation for their MEX files. And there are other complications (packing) which would make it impossible in practice.
>>
>> So I'll drop my pursuit of a no-brainer global hex edit. Thanks for all the interest and advice.
>>
>> Terry, East Grinstead, UK
>
>
>Hi Terry :-)
>
>For this non-techie fellow, will you please explain what you were trying
>to do/accomplish in the first place?
It was explained in his first message, and then detailed. Read
<Dav...@nomail.afraid.invalid> wrote:
>On 01/03/2017 05:33, terry...@gmail.com wrote:
>> I had a prompt and thorough reply from the developers of MX Pro. As I expected, they are unable to provide detailed table structure documentation for their MEX files. And there are other complications (packing) which would make it impossible in practice.
>>
>> So I'll drop my pursuit of a no-brainer global hex edit. Thanks for all the interest and advice.
>>
>> Terry, East Grinstead, UK
>
>
>Hi Terry :-)
>
>For this non-techie fellow, will you please explain what you were trying
>to do/accomplish in the first place?
the thread. Though why a "non-techie" would be interested is beyond
me.
<CUT_USUAL_STALKING>
[]'s
To Terry --> BD is a psychopath, he will attempt to turn any thread
into off-topic stalking trash. Avoid any exchanges with him, specially
via email or social media. HTH.
burfordTjustice
Mar 1, 2017, 8:32:27 AM3/1/17
to
David B.
Mar 1, 2017, 10:26:37 AM3/1/17
to
On 01/03/2017 13:23, *Shadow LIED AGAIN*!
> On Wed, 1 Mar 2017 09:27:29 +0000, "David B."
> <Dav...@nomail.afraid.invalid> wrote:
>
>> On 01/03/2017 05:33, terry...@gmail.com wrote:
>>> I had a prompt and thorough reply from the developers of MX Pro. As I expected, they are unable to provide detailed table structure documentation for their MEX files. And there are other complications (packing) which would make it impossible in practice.
>>>
>>> So I'll drop my pursuit of a no-brainer global hex edit. Thanks for all the interest and advice.
>>>
>>> Terry, East Grinstead, UK
>>
>>
>> Hi Terry :-)
>>
>> For this non-techie fellow, will you please explain what you were trying
>> to do/accomplish in the first place?
>
> It was explained in his first message, and then detailed. Read
> the thread. Though why a "non-techie" would be interested is beyond
> me.
Lots of things are beyond you! :-P
> To Terry --> BD is a psychopath, he will attempt to turn any thread
> into off-topic stalking trash. Avoid any exchanges with him, specially
> via email or social media. HTH.
You, of course, are simply lying.
> On Wed, 1 Mar 2017 09:27:29 +0000, "David B."
> <Dav...@nomail.afraid.invalid> wrote:
>
>> On 01/03/2017 05:33, terry...@gmail.com wrote:
>>> I had a prompt and thorough reply from the developers of MX Pro. As I expected, they are unable to provide detailed table structure documentation for their MEX files. And there are other complications (packing) which would make it impossible in practice.
>>>
>>> So I'll drop my pursuit of a no-brainer global hex edit. Thanks for all the interest and advice.
>>>
>>> Terry, East Grinstead, UK
>>
>>
>> Hi Terry :-)
>>
>> For this non-techie fellow, will you please explain what you were trying
>> to do/accomplish in the first place?
>
> It was explained in his first message, and then detailed. Read
> the thread. Though why a "non-techie" would be interested is beyond
> me.
> To Terry --> BD is a psychopath, he will attempt to turn any thread
> into off-topic stalking trash. Avoid any exchanges with him, specially
> via email or social media. HTH.
Terry Pinnell
Mar 1, 2017, 3:41:33 PM3/1/17
to
"David B." <Dav...@nomail.afraid.invalid> wrote:
>On 01/03/2017 05:33, terry...@gmail.com wrote:
>> I had a prompt and thorough reply from the developers of MX Pro. As I expected, they are unable to provide detailed table structure documentation for their MEX files. And there are other complications (packing) which would make it impossible in practice.
>>
>> So I'll drop my pursuit of a no-brainer global hex edit. Thanks for all the interest and advice.
>>
>> Terry, East Grinstead, UK
>
>
>Hi Terry :-)
>
>For this non-techie fellow, will you please explain what you were trying
>to do/accomplish in the first place?
It's been a long thread, but my opening post summarised my aim. An aim
>On 01/03/2017 05:33, terry...@gmail.com wrote:
>> I had a prompt and thorough reply from the developers of MX Pro. As I expected, they are unable to provide detailed table structure documentation for their MEX files. And there are other complications (packing) which would make it impossible in practice.
>>
>> So I'll drop my pursuit of a no-brainer global hex edit. Thanks for all the interest and advice.
>>
>> Terry, East Grinstead, UK
>
>
>Hi Terry :-)
>
>For this non-techie fellow, will you please explain what you were trying
>to do/accomplish in the first place?
now abandoned!
>I have little experience of Hex matters, but when faced with various
>code puzzles by Dustin Cook (an ex-malware writer - VXer as he calls
>it!) - he's posting here as 'Diesel' - I tried to use THIS facility:-
>
>http://www.convertstring.com
>
>I encountered /problems/ - but then, I didn't really have a clue what I
>was doing! Anyway, I ended up in much discussion with the author. Quite
>by chance I had stumbled across some inherent errors which, after quite
>some time, he eventually corrected. He actually thanked me for bringing
>the bugs to his attention!
>
>Anyway, YOU may find the facility helpful in achieving your objective.
>Perhaps you'll let me know?
>
Just our cottage down the road at Wakehurst ;-)
Terry, East Grinstead, UK
Terry Pinnell
Mar 1, 2017, 3:46:47 PM3/1/17
to
task out of all proportion to its benefit.
In case it's of interest to you and others who have been forensically
pursuing this, here's the opening part of the reply I received from MX
Pro support:
"Terry,
RE: Structure of MEX files?
There are tables that point to different locations in the macro file.
Even if I could document the structure for you (which I can't) it would
be a near impossible task to do what you want to do.
When Macro Express changes a macro it determines if the new macro will
fit in the existing space. If it cannot then it adds it to a new spot at
the end of the list of macros and marks the original space as unused.
The Pack commands reclaims that space. (The Pack command comes with its
own side-effects, however.)"
Terry, East Grinstead, UK
JJ
Mar 1, 2017, 9:35:36 PM3/1/17
to
On Wed, 01 Mar 2017 20:46:46 +0000, Terry Pinnell wrote:
>
> In case it's of interest to you and others who have been forensically
> pursuing this, here's the opening part of the reply I received from MX
> Pro support:
>
> "Terry,
>
> RE: Structure of MEX files?
>
> There are tables that point to different locations in the macro file.
> Even if I could document the structure for you (which I can't) it would
> be a near impossible task to do what you want to do.
>
> When Macro Express changes a macro it determines if the new macro will
> fit in the existing space. If it cannot then it adds it to a new spot at
> the end of the list of macros and marks the original space as unused.
> The Pack commands reclaims that space. (The Pack command comes with its
> own side-effects, however.)"
>
> Terry, East Grinstead, UK
That's the polite way of saying:
>
> In case it's of interest to you and others who have been forensically
> pursuing this, here's the opening part of the reply I received from MX
> Pro support:
>
> "Terry,
>
> RE: Structure of MEX files?
>
> There are tables that point to different locations in the macro file.
> Even if I could document the structure for you (which I can't) it would
> be a near impossible task to do what you want to do.
>
> When Macro Express changes a macro it determines if the new macro will
> fit in the existing space. If it cannot then it adds it to a new spot at
> the end of the list of macros and marks the original space as unused.
> The Pack commands reclaims that space. (The Pack command comes with its
> own side-effects, however.)"
>
> Terry, East Grinstead, UK
No, you can't do that. Even if it's possible, we won't tell you.
So, I was curious. I downloaded the software and done my research. I
concluded that the MEX file format has a checksum code in it. Well... That's
sucks. It's a much bigger hassle than figuring out the MEX file format.
Since it's a macro software, why not create a macro to automate the macro
software itself? e.g. create a macro that changes those paths by automating
the macro software's macro editing GUI. Put the macros you want to change
into a single file to make things simpler.
Or ultimately, use other macro software which are more open.
Terry Pinnell
Mar 2, 2017, 6:11:42 AM3/2/17
to
answer from them. Mind you, it's a competitive market and I see their
need for protection. As mentioned before, I'd dearly like to be able to
share some of my productivity macros with others, but Insight insist on
their having MX installed in order to run my exported playable macros.
Re the alternative, yes, that's what I've been doing. It's been a long
thread and you must have missed my post on 28 Feb which included:
"My only current method of 'global' editing of the form described is to
use a macro to operate successively on each macro - a glacially slow
process, apart from its inelegance! Hence my hope of doing so in a hex
editor on hundreds of macros at once!"
Archer
Mar 2, 2017, 10:03:13 AM3/2/17
to
On Mon, 27 Feb 2017 08:55:16 +0000, Terry Pinnell
<m...@somewhere.invalid> wrote:
>Ideally freeware, but *any* recommendations would be appreciated please
You can try this hex editor which I have been using for years with
<m...@somewhere.invalid> wrote:
>Ideally freeware, but *any* recommendations would be appreciated please
great satisfaction
https://mh-nexus.de/en/hxd/
--
HTH Archer
Diesel
Mar 2, 2017, 6:07:45 PM3/2/17
to
JJ <jj4p...@vfemail.net>
news:173vcxcy4yw55.zv6bmpqt1sla$.d...@40tude.net Thu, 02 Mar 2017
read your posts concerning it's internals. I was hoping it wouldn't
be using a checksum, but, alas, evidently it is. It does make things
a much bigger pain in the arse now for the purposes of changing
much/any of the file contents.
> Or ultimately, use other macro software which are more open.
Agreed. It shouldn't be that difficult to alter an existing file to
make wanted changes, if the program can't do it via gui/cli on it's
own, that is. the program responsible for .mex files was annoying
enough creating the proprietary file format in the first place, but,
quickly rose to arsehole with the checksum also being present.
Although I haven't had a chance to try to verify that or anything
aside from what I wrote about it initially, I have no reason to doubt
you. if I was in need of Macro software, there's wouldn't even be on
the list of ones to evaluate for that stunt alone. I'm one of those
who votes with his wallet. As, at the end of the day, it's the only
real way to get any company - small or large to even consider
noticing you, for a second or two in their business make money day.
news:173vcxcy4yw55.zv6bmpqt1sla$.d...@40tude.net Thu, 02 Mar 2017
02:35:26 GMT in alt.comp.freeware, wrote:
> On Wed, 01 Mar 2017 20:46:46 +0000, Terry Pinnell wrote:
>>
>> In case it's of interest to you and others who have been
>> forensically pursuing this, here's the opening part of the reply
>> I received from MX Pro support:
>>
>> "Terry,
>>
>> RE: Structure of MEX files?
>>
>> There are tables that point to different locations in the macro
>> file. Even if I could document the structure for you (which I
>> can't) it would be a near impossible task to do what you want to
>> do.
>>
>> When Macro Express changes a macro it determines if the new macro
>> will fit in the existing space. If it cannot then it adds it to a
>> new spot at the end of the list of macros and marks the original
>> space as unused. The Pack commands reclaims that space. (The Pack
>> command comes with its own side-effects, however.)"
>>
>> Terry, East Grinstead, UK
>
> That's the polite way of saying:
>
> No, you can't do that. Even if it's possible, we won't tell you.
>
> So, I was curious. I downloaded the software and done my research.
> I concluded that the MEX file format has a checksum code in it.
> Well... That's sucks. It's a much bigger hassle than figuring out
> the MEX file format.
I didn't have a chance to take much of a look at the file yet. I've
> On Wed, 01 Mar 2017 20:46:46 +0000, Terry Pinnell wrote:
>>
>> In case it's of interest to you and others who have been
>> forensically pursuing this, here's the opening part of the reply
>> I received from MX Pro support:
>>
>> "Terry,
>>
>> RE: Structure of MEX files?
>>
>> There are tables that point to different locations in the macro
>> file. Even if I could document the structure for you (which I
>> can't) it would be a near impossible task to do what you want to
>> do.
>>
>> When Macro Express changes a macro it determines if the new macro
>> will fit in the existing space. If it cannot then it adds it to a
>> new spot at the end of the list of macros and marks the original
>> space as unused. The Pack commands reclaims that space. (The Pack
>> command comes with its own side-effects, however.)"
>>
>> Terry, East Grinstead, UK
>
> That's the polite way of saying:
>
> No, you can't do that. Even if it's possible, we won't tell you.
>
> So, I was curious. I downloaded the software and done my research.
> I concluded that the MEX file format has a checksum code in it.
> Well... That's sucks. It's a much bigger hassle than figuring out
> the MEX file format.
read your posts concerning it's internals. I was hoping it wouldn't
be using a checksum, but, alas, evidently it is. It does make things
a much bigger pain in the arse now for the purposes of changing
much/any of the file contents.
> Or ultimately, use other macro software which are more open.
make wanted changes, if the program can't do it via gui/cli on it's
own, that is. the program responsible for .mex files was annoying
enough creating the proprietary file format in the first place, but,
quickly rose to arsehole with the checksum also being present.
Although I haven't had a chance to try to verify that or anything
aside from what I wrote about it initially, I have no reason to doubt
you. if I was in need of Macro software, there's wouldn't even be on
the list of ones to evaluate for that stunt alone. I'm one of those
who votes with his wallet. As, at the end of the day, it's the only
real way to get any company - small or large to even consider
noticing you, for a second or two in their business make money day.
Diesel
Mar 2, 2017, 6:07:45 PM3/2/17
to
Terry Pinnell <m...@somewhere.invalid>
news:3gcebcl9ov14iibeq...@4ax.com Wed, 01 Mar 2017
20:46:46 GMT in alt.comp.freeware, wrote:
[snip]
> That's generous of you but I've definitely concluded that it would
> be a task out of all proportion to its benefit.
Alright then.
> In case it's of interest to you and others who have been
> forensically pursuing this, here's the opening part of the reply I
> received from MX Pro support:
It confirms to a point what myself and several? other posters who've
taken a look and commented, (Especially JJ) what we suspected to
begin with. I tend to disagree with the near impossible task aspect
though. It would be far easier for them (since they have the actual
source code to the application) to either write a utility based on it
that does what you seek to do, or incorporate the functionality into
the main program; although I do confess, I'm not sure the customer
base warrants the changes/newly created program time and effort
required.
Based on my own experiences with other programs though, while I agree
the task would be a difficult one from a reverse engineering
perspective, the actual effort required to write the resulting
program itself wouldn't be a difficult task.
Although I certainly understand the reasoning behind a checksum -
makes it more difficult to turn one/more macros into something
potentially harmful without your knowledge or consent. Having that
present does make the process that much more difficult. Not only
would you have to mapout the bytes which control the section you
actually want to play with, you also have to deal with a checksum as
well. Is the checksum specific for a certain amount of bytes, or the
entire .mex file (aside from it's own bytes of course)? Once you
determine what exactly it's trying to ensure stays as you wrote it
originally, you have to determine how it's generated so that you can
generate new ones to go along with the requested changes you make to
it.
It may have multiple checksums, one per macro record in fact, which
again, is something you'd (the program) have to compensate for. If I
understood you correctly, you wrote previously that you have more
than one macro stored as a single file. It would be necessary to
rewrite the entire file if automated (which is what a hex editor that
can extend bytes without overwriting what's already there) just to
change a single macro string inside. Further, it may also be
necessary to do quite a few patch record updates throughout the large
file to adjust for what was done to that single record. And this
entire process would have to be repeated anytime you decided a text
string needed to be changed in some way. Does the macro language
allow for presets of any kind? For example, could you use %appdata%?
If so, you might consider doing a different folder layout to be more
in tune with one. Another option would be a different folder layout
that doesn't require drive letter specification and would be the same
across all systems your macro is intended for.
And you always have the best (imho) option, switch to software that
is open which wouldn't make what should have been a relatively
trivial direct file editing task much more difficult than it needs to
be. I tend to use/run software that has open file formats. If not
outright open, doesn't go out of their way to make my efforts to map
it out a difficult pain in my backside.
> When Macro Express changes a macro it determines if the new macro
> will fit in the existing space. If it cannot then it adds it to a
> new spot at the end of the list of macros and marks the original
> space as unused. The Pack commands reclaims that space. (The Pack
> command comes with its own side-effects, however.)"
Off the top of my head, possibly due to a bug in the routines that
'pack' and/or the file layout itself, one could damage/outright lose
one or more valid macros during the packing process. I could see that
happening, since it treats the .mex files much like an OS treats it's
file system. Files you delete via normal methods aren't deleted, the
first letter is renamed to a non standard character which tells the
OS not to show it to you on directory/folder/file listings and that
the space it once took is available for use, if the OS is asked to
write something that can fit within those confines AND that area is
next in line for a partial/complete fill in.
I know, likely much more detailed information than you wanted.
Apologies. :)
news:3gcebcl9ov14iibeq...@4ax.com Wed, 01 Mar 2017
20:46:46 GMT in alt.comp.freeware, wrote:
[snip]
> That's generous of you but I've definitely concluded that it would
> be a task out of all proportion to its benefit.
> In case it's of interest to you and others who have been
> forensically pursuing this, here's the opening part of the reply I
> received from MX Pro support:
taken a look and commented, (Especially JJ) what we suspected to
begin with. I tend to disagree with the near impossible task aspect
though. It would be far easier for them (since they have the actual
source code to the application) to either write a utility based on it
that does what you seek to do, or incorporate the functionality into
the main program; although I do confess, I'm not sure the customer
base warrants the changes/newly created program time and effort
required.
Based on my own experiences with other programs though, while I agree
the task would be a difficult one from a reverse engineering
perspective, the actual effort required to write the resulting
program itself wouldn't be a difficult task.
Although I certainly understand the reasoning behind a checksum -
makes it more difficult to turn one/more macros into something
potentially harmful without your knowledge or consent. Having that
present does make the process that much more difficult. Not only
would you have to mapout the bytes which control the section you
actually want to play with, you also have to deal with a checksum as
well. Is the checksum specific for a certain amount of bytes, or the
entire .mex file (aside from it's own bytes of course)? Once you
determine what exactly it's trying to ensure stays as you wrote it
originally, you have to determine how it's generated so that you can
generate new ones to go along with the requested changes you make to
it.
It may have multiple checksums, one per macro record in fact, which
again, is something you'd (the program) have to compensate for. If I
understood you correctly, you wrote previously that you have more
than one macro stored as a single file. It would be necessary to
rewrite the entire file if automated (which is what a hex editor that
can extend bytes without overwriting what's already there) just to
change a single macro string inside. Further, it may also be
necessary to do quite a few patch record updates throughout the large
file to adjust for what was done to that single record. And this
entire process would have to be repeated anytime you decided a text
string needed to be changed in some way. Does the macro language
allow for presets of any kind? For example, could you use %appdata%?
If so, you might consider doing a different folder layout to be more
in tune with one. Another option would be a different folder layout
that doesn't require drive letter specification and would be the same
across all systems your macro is intended for.
And you always have the best (imho) option, switch to software that
is open which wouldn't make what should have been a relatively
trivial direct file editing task much more difficult than it needs to
be. I tend to use/run software that has open file formats. If not
outright open, doesn't go out of their way to make my efforts to map
it out a difficult pain in my backside.
> When Macro Express changes a macro it determines if the new macro
> will fit in the existing space. If it cannot then it adds it to a
> new spot at the end of the list of macros and marks the original
> space as unused. The Pack commands reclaims that space. (The Pack
> command comes with its own side-effects, however.)"
'pack' and/or the file layout itself, one could damage/outright lose
one or more valid macros during the packing process. I could see that
happening, since it treats the .mex files much like an OS treats it's
file system. Files you delete via normal methods aren't deleted, the
first letter is renamed to a non standard character which tells the
OS not to show it to you on directory/folder/file listings and that
the space it once took is available for use, if the OS is asked to
write something that can fit within those confines AND that area is
next in line for a partial/complete fill in.
I know, likely much more detailed information than you wanted.
Apologies. :)
Diesel
Mar 2, 2017, 6:07:48 PM3/2/17
to
Terry Pinnell <m...@somewhere.invalid>
news:n9cebcp7mj2q5238c...@4ax.com Wed, 01 Mar 2017
doesn't have the foggiest idea of what you're asking about, or, what
the replies entailed. He recognized the word 'hex' and jumped into
the thread.
While jumping in, and explaining himself, he couldn't resist the urge
to drop my name. It's not that my name isn't already well known, but,
I don't post using it, and it's not proper netiquette to call someone
by anything other than the posting nym they use. It certainly has no
purpose in this thread. Nor does one aspect of myself that was nearly
two decades ago. All the while, as if to remain on topic in some
small way, recommending a website that's near worthless for the
purposes of this discussion.
If you really were that bored, you could use it to decode hex offsets
into their decimal equs', but the site would convert as a character
and not a number, and, you want the number obviously. So might as
well use hex/dec calc instead, the first time. Saves a few steps and
no website required.
>>Is this REALLY your home, Terry? https://goo.gl/AGYBoS
>
> Just our cottage down the road at Wakehurst ;-)
:) That's one of BD's favorite things to do. Use people to take a
shot at another person. In this case, he used you to take a shot at
me, for old times sake. You see, my problem with him started several
years ago when another poster attempted to disclose my physical
address. BD took it upon himself to convert what he thought was my
house address to a google streetmap viewable link. Once done, he
posted this link to several different newsgroups with the subject
(and ones close to this) "Is this your house, Dustin?"
Unfortunately, BD is a very real stalker. He has it in for several
people (I'm only one of them) and he proceeds to stalk them, in life
AND in death (He actually placed a phone call to the funeral home, if
he's to be believed) for reasons only he knows. If he feels you've
crossed him, or won't tell him anything he wants to know about you
for his personal records, he becomes suspicious of you and, you'll be
added to his stalker list.
If you have any sort of technical/advanced mechanical skills, don't
be too quick to acknowledge or demonstrate any of it here or in any
other newsgroup where he's known to post. Those of us with trade
skills who won't discuss our personal lives or much about our jobs
are suspicious to him.
And one more thing, don't provide personal pics or video of any kind.
He doesn't understand the word copyright, and, wouldn't respect it if
he did have a clue about it. Consider your things copied without your
permission and subject to editing by him at any time, as well as,
sharing on sites you didn't place it on yourself, whenever he chooses
to do so.
Just doing my civic duty and warning you. What you choose to do is
entirely your decision.
news:n9cebcp7mj2q5238c...@4ax.com Wed, 01 Mar 2017
20:41:27 GMT in alt.comp.freeware, wrote:
> Thanks, but it won't help in this case.
I agree with your statement that it won't help in this case. BD
> Thanks, but it won't help in this case.
doesn't have the foggiest idea of what you're asking about, or, what
the replies entailed. He recognized the word 'hex' and jumped into
the thread.
While jumping in, and explaining himself, he couldn't resist the urge
to drop my name. It's not that my name isn't already well known, but,
I don't post using it, and it's not proper netiquette to call someone
by anything other than the posting nym they use. It certainly has no
purpose in this thread. Nor does one aspect of myself that was nearly
two decades ago. All the while, as if to remain on topic in some
small way, recommending a website that's near worthless for the
purposes of this discussion.
If you really were that bored, you could use it to decode hex offsets
into their decimal equs', but the site would convert as a character
and not a number, and, you want the number obviously. So might as
well use hex/dec calc instead, the first time. Saves a few steps and
no website required.
>>Is this REALLY your home, Terry? https://goo.gl/AGYBoS
>
> Just our cottage down the road at Wakehurst ;-)
shot at another person. In this case, he used you to take a shot at
me, for old times sake. You see, my problem with him started several
years ago when another poster attempted to disclose my physical
address. BD took it upon himself to convert what he thought was my
house address to a google streetmap viewable link. Once done, he
posted this link to several different newsgroups with the subject
(and ones close to this) "Is this your house, Dustin?"
Unfortunately, BD is a very real stalker. He has it in for several
people (I'm only one of them) and he proceeds to stalk them, in life
AND in death (He actually placed a phone call to the funeral home, if
he's to be believed) for reasons only he knows. If he feels you've
crossed him, or won't tell him anything he wants to know about you
for his personal records, he becomes suspicious of you and, you'll be
added to his stalker list.
If you have any sort of technical/advanced mechanical skills, don't
be too quick to acknowledge or demonstrate any of it here or in any
other newsgroup where he's known to post. Those of us with trade
skills who won't discuss our personal lives or much about our jobs
are suspicious to him.
And one more thing, don't provide personal pics or video of any kind.
He doesn't understand the word copyright, and, wouldn't respect it if
he did have a clue about it. Consider your things copied without your
permission and subject to editing by him at any time, as well as,
sharing on sites you didn't place it on yourself, whenever he chooses
to do so.
Just doing my civic duty and warning you. What you choose to do is
entirely your decision.
Terry Pinnell
Mar 3, 2017, 2:56:19 AM3/3/17
to
as discussed at length up-thread, like all hex editors it cannot meet
the requirement I was hoping for.
Terry, East Grinstead, UK
0 new messages