Here we go guys. I have been working on this project for many years and have asked for help in many other forums. I didn't get the assistance I needed due to lack of interest. I am not giving up on this because I'm not a quitter. I have most of the work done and all I need to do is find the proper offset to patch. Here is the big problem, I don't know how to hex and find the right offsets. I do know how to use hex edit tools though. What I have here is two dumps and hoping one of you guys can help me. What we are looking to patch is the hash check, timestamps, version check etc... so SR can replace the necessary files. I have learned, system restore does a unique check from the catalog file and if the files doNOT match the catalog file hashes, timestamps, version, it fails. That's all folks!
I'll try and take a look at that, but first of all I need to understand how it works, because I never cared about this system, it actually annoyed the heck outta me when trying to replace Notepad with Metapad in XP. It may be of help at times, however. Please do not get your hopes too high though. ![Embarrassed :oops:](./images/smilies/icon_redface.gif)
![Embarrassed :oops:](./images/smilies/icon_redface.gif)
- PROBLEMCHYLD
- Posts: 991
- Joined: 2013-03-22 12:55
Thanks friend. Its a great tool and it can be tweaked and used for a full system backup tool. I just need to bypass it when it does all them checks (timestamps, file version, hash etc....)
OK, read all this then come back....
viewtopic.php?f=1&t=71&start=10
So the files are sourced from WinME.
So it's placing the System Restore capability from ME into 98, specifically the
capability to do SR, - BUT wants to disable the System File Protection (SFP)
feature (also called Windows File Protection in later OSes).
_
(P.S. Hey, but didn't non-OEM Windows ME CD's have MSBACKUP on them...
I guess the SFP feature still has to be disabled; assuming that's achieved, then
Msbexp.exe not suitable for backups because... __ ?)
viewtopic.php?f=1&t=71&start=10
So the files are sourced from WinME.
So it's placing the System Restore capability from ME into 98, specifically the
capability to do SR, - BUT wants to disable the System File Protection (SFP)
feature (also called Windows File Protection in later OSes).
_
(P.S. Hey, but didn't non-OEM Windows ME CD's have MSBACKUP on them...
I guess the SFP feature still has to be disabled; assuming that's achieved, then
Msbexp.exe not suitable for backups because... __ ?)
SFC.DLL, size 41232 bytes, viewed in notepad has version 4.90.0.2533
and that file opened in Borg Disassembler v2.28 as PE Executable,
Resources & Debug & Data & 32-bit Disassembly & Demangle selected,
shows the following...
1000:761142e4--DisableSFP:
1000:761142e4--55---------------------push----ebp
1000:761142e5--8bec------------------mov-----ebp, esp
1000:761142e7--6aff-------------------push----0ffh
1000:761142e9--6890231176--------push----offset loc_76112390
1000:761142ee--6810591176--------push----offset loc_76115910
1000:761142f3--64a100000000------mov-----eax, fs:dword ptr [00h]
1000:761142f9--50----------------------push----eax
1000:761142fa--64892500000000---mov-----dword ptr fs:[00h], esp
1000:76114301--83ec14---------------sub------esp, 14h
1000:76114304--53---------------------push----ebx
1000:76114305--56---------------------push----esi
1000:76114306--57---------------------push----edi
1000:76114307--8965e8---------------mov-----[ebp-18h], esp
1000:7611430a--68e4791176--------push-----offset loc_761179e4
1000:7611430f--e8fdf5ffff--------------call------loc_76113911
1000:76114314--87c0-------------------test-----eax, eax
1000:76114316--7537------------------jnz-------loc_7611434f
etc...
any use?
and that file opened in Borg Disassembler v2.28 as PE Executable,
Resources & Debug & Data & 32-bit Disassembly & Demangle selected,
shows the following...
1000:761142e4--DisableSFP:
1000:761142e4--55---------------------push----ebp
1000:761142e5--8bec------------------mov-----ebp, esp
1000:761142e7--6aff-------------------push----0ffh
1000:761142e9--6890231176--------push----offset loc_76112390
1000:761142ee--6810591176--------push----offset loc_76115910
1000:761142f3--64a100000000------mov-----eax, fs:dword ptr [00h]
1000:761142f9--50----------------------push----eax
1000:761142fa--64892500000000---mov-----dword ptr fs:[00h], esp
1000:76114301--83ec14---------------sub------esp, 14h
1000:76114304--53---------------------push----ebx
1000:76114305--56---------------------push----esi
1000:76114306--57---------------------push----edi
1000:76114307--8965e8---------------mov-----[ebp-18h], esp
1000:7611430a--68e4791176--------push-----offset loc_761179e4
1000:7611430f--e8fdf5ffff--------------call------loc_76113911
1000:76114314--87c0-------------------test-----eax, eax
1000:76114316--7537------------------jnz-------loc_7611434f
etc...
any use?
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.
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.