AMON, 2021-06-09 01:40 »
At first, I want to thank you for your efforts, PROBLEMCHYLD. I know this thread is old and you probably got other things in your mind than the system restore project, but if you still want to do it, I could give some vague hints. a friend of mine recently showed me "Ghidra" which is a disassembler where you can debug an application when it's running. I thought I should share that with you:
https://ghidra-sre.org/. I'm not sure if it works with WinME executables though, you would have to test that. Perhaps it helps you on your way.
Additionally; I don't know hex very good. But I can give general advice since I'm a software engineer.
You mentioned the hash checker algorithm mismatching files because you changed them, that's clear and intended behaviour of the program MS wrote there, so if you change these files, you need to update the expected hashes of these files to the new ones. You have to find out where these expected hashes are. There needs to be a table of these file hashes somewhere. It could be inside the EXE you disassembled, another DLL or if you are lucky even in a separate text file. Finding the location of these is the hard part. When you found these values, you can change these to the actual new hashes. Changing the values with a good hex editor shouldn't be so hard, but finding the expected hashes and understanding them is the hard part.
Hex are basically values from 0 to F (16-bit values), so the hashes aren't displayed as visible text in the hex editor. When you look at hex, you don't understand anything because it doesn't make sense to the human eye. But some of these 16-bit characters represent characters, so you probably want a hex editor which shows you the "translation to ANSI, UTF-8 or Unicode codepage" so you can search for the the hashes.
I think you should calculate the hash of an original file with the correct hash algorithm (MD5, SHA, etc, you probably need to try multiple of them), and search for this text inside the hex editor. When you find it, look around this block of assembly code if you find other data that looks like hashes, you need to search for patterns so you can understand what's going on. If you know which files were changed and aren't original, try to find and replace these hashes and check if it works. It is tedious work and not so easy. I am too dumb for this, but I believe that you can do it my friend.
At first, I want to thank you for your efforts, PROBLEMCHYLD. I know this thread is old and you probably got other things in your mind than the system restore project, but if you still want to do it, I could give some vague hints. a friend of mine recently showed me "Ghidra" which is a disassembler where you can debug an application when it's running. I thought I should share that with you: https://ghidra-sre.org/. I'm not sure if it works with WinME executables though, you would have to test that. Perhaps it helps you on your way.
Additionally; I don't know hex very good. But I can give general advice since I'm a software engineer.
You mentioned the hash checker algorithm mismatching files because you changed them, that's clear and intended behaviour of the program MS wrote there, so if you change these files, you need to update the expected hashes of these files to the new ones. You have to find out where these expected hashes are. There needs to be a table of these file hashes somewhere. It could be inside the EXE you disassembled, another DLL or if you are lucky even in a separate text file. Finding the location of these is the hard part. When you found these values, you can change these to the actual new hashes. Changing the values with a good hex editor shouldn't be so hard, but finding the expected hashes and understanding them is the hard part.
Hex are basically values from 0 to F (16-bit values), so the hashes aren't displayed as visible text in the hex editor. When you look at hex, you don't understand anything because it doesn't make sense to the human eye. But some of these 16-bit characters represent characters, so you probably want a hex editor which shows you the "translation to ANSI, UTF-8 or Unicode codepage" so you can search for the the hashes.
I think you should calculate the hash of an original file with the correct hash algorithm (MD5, SHA, etc, you probably need to try multiple of them), and search for this text inside the hex editor. When you find it, look around this block of assembly code if you find other data that looks like hashes, you need to search for patterns so you can understand what's going on. If you know which files were changed and aren't original, try to find and replace these hashes and check if it works. It is tedious work and not so easy. I am too dumb for this, but I believe that you can do it my friend.