Sfor
Content Type
Profiles
Forums
Events
Posts posted by Sfor
-
-
I'll add my two cents, as well. I'm sticking with SystemRescueCD, Partimage and BackupPC.
Advantages of Partimage:
- free
- can do bare bone recovery
- does copy only used parts of partition, so the resulting image is small. The built in commpression makes it yet smaller.
- does make a copy of the MBR, and is able to restore it.
- copies can be made through network connection and stored on another computer
Disadvantages of Partimage
- it is not as simple to use as other tools
With a bit of tweaking I made a PXE botable image of SystemRescueCD with network support. Now I can remotely power on a computer, boot a SystemRescueCD on it through PXE then make a copy, or restore a partition. So, I can make backups of workstations, while being at home. I know the FOG can do all that, and do it in a simpler and more automated way, but the FOG is not particulary convenient when dealing with FAT32 or multiple partitions.
So, my solution is to manualy make copies of system partitions once a few months or less often, while the data are kept safe by BackupPC servers in a complete automated manner.
1 -
On 20.01.2017 at 5:02 PM, Mathwiz said:
Make sure IE isn't set to use the Proxomitron (localhost / 8080) for http connections. It has to get through on http in order to receive the redirect to https.
Also, try Heinoganda's ProxHTTPSProxy version (with the updated Python cryptography package); otherwise you'll probably get a 417 error when Google.pl redirects you to https (unless you have google.pl in your SSL Pass-Thru section).
Well, the IE proxy setting just for https was enough to solve the problem. It was not necesary to add the passtrough entry.
0 -
On 13.01.2017 at 11:36 PM, Mathwiz said:
1. I should point out it's rather easy to use ProxHTTPSProxy without the Proxomitron: just change the line
ProxAddr = http://localhost:8080to
ProxAddr = http://localhost:8081... so its front server connects directly to its rear server without trying to go through the Proxomitron.
But the IE does not connect to http://www.google.pl/ in such a case.
Quote400: Bad Request
The following error occurred while trying to access http://www.google.pl/
The proxy setting of the client is misconfigured. Please set the HTTPS proxy port to 8079 and check the Docs for other settings.
With Proximitron in the middle, the http connection is redirected to https without problems, so there is no "Bad Request" message, then.
0 -
It seems the ProxHTTPSProxyMII teamed with The Proximitron can add the TLS 1.2. I was able to confirm it with IE 8.
While trying to get the thing working I noticed an interesting option in the The Proximitron version Naoko 4.5. In "config" - "HTTP" section there is "Use SSLeay/OpenSSL to filter secure pages (requires ssleay and libeay23 DLL files)".
It seems there is option to filter the HTTPS without ProxHTTPSProxyMII. But, I was unable to provide The Proximitron with the DLL libraries it would be satisfied with. So, perhaps just The Proximitron could do the TLS 1.2 conversion.
0 -
Well, I'm unable to install the Chrome 36, as it is always updating itself to 49. So, I can not test how it behaves with TLS.
I think the first thing to test is if Chrome is able to work without schannel.dll. There is a chance, the Chrome prior to 37 does have it's own TLS support (without TLS 1.2, however). Without knowing that there is a chance of wrong understanding of what is going on with the Chrome and schannel.dll.
0 -
Well, using the site https://www.ssllabs.com/ssltest/viewMyClient.html I found the both Firefox and Chrome are supporting TLS 1.2 with the schannel.dll provided with the XP. So, I strongly doubt the Chrome is using schannel.dll. So, replacing the file to the React OS version should not affect both Chrome and Firefox.
On the other hand the ChromeSetup.exe does not work with the React OS schannel.dll. So, the Chrome setup does use the schannel.dll, after all.
0 -
Unfortunately the applications I wish to test against TLS 1.2 support are not browsers. They are mostly goverment tax declaration form senders and managers. The goverment tax service will not work with just a browser, as the protocol is not user friendly.
I did play a bit with schannel.dll. After replacing it with a file taken from Windows 7, the IE 8 stopped working with https, completely. There were no visible error messages, the IE just did not make any connection.
-------------------------------------------------------
I did the same experiment with schannel.dll and mbedtls.dll from ReactOS. The result was almost the same as with Windows 7 schannel.dll file. The difference is, with some sites IE 8 crashes, with most of thei it does not connect.
It seems the ReactOS is using mbed TLS 2.3.0 and schannel.dll is just a wrapper for mbedtls.dll. mbed TLS 2.3.0 should support the TLS 1.2.
Another question is, if Microsoft added TLS 1.2 support with updates for Windows XP Embedded. If so, it would be logical to use them instead.
Another task is testing if a particular application is gaining TLS 1.2 support. To do so it would be necesary to redirect connections to some other server. Well, redirecting to a different IP through DNS is a simple task, but I have no experience with HTTPS servers. I would be good to have a server with an ability to switch between TLS 1.0 and 1.2.
On the other hand, perhaps it would be a better choice to use a proxy, instead. While using the original server, to switch on and off TLS 1.0 with the proxy.
Yet another idea is to leave Windows TLS support as is, and to use a TLS 1.2 capable proxy to make the connection, instead.
0 -
Well, since some sites (like Google Maps for an instance) are not giving all options to Windows XP users, I'm using masking agent with Windows XP and Firefox. So, my Internet activity adds to Windows 7 share. Im a bit curious, how many Windows XP users are masking their user agent strings. The Windows XP share could be bigger than expected, because of that.
Recently, I encountered a problem which can significantly decease the Windows XP usefulness. The world wide TLS 1.0 to TLS 1.2 migration can affect many Windows XP based activities. The simple web browsing will be ok thanks to Firefox, because it has own system independent TLS implementation. But most of the Internet based utilities use the system support for TLS.
1 -
More and more web sites are turning the TLS 1.0 off. There is no big deal with the web browsing, because the Firefox handles the TLS 1.2 just fine. But, some other applications will be affected.
A nice example are the utilities made to send XML based electronic goverment declarations. The Polish goverment servers will turn off TLS 1.0 in the middle of 2017. I strongly doubt the utilities used to send the declarations do have own TLS 1.2 support as the Firefox does. The declarations can not be sent through the browser, so Firefox will not do.
Is there a way to check if an application has it's own TLS support?
Is there a way to add TLS 1.2 support to Windows XP?
0 -
On the affected computer the Security center seems to be working correctly. But the "Change the way Security Center alerts me" link is disabled.
How to get this link working?
---------------------------
Oh, well. ComboFix did the job.
0 -
The network connection status icon (the one with two computers and their screens flashing when the connection is active) is a valuable help, when there are problems with network connection. So, I'm always living it as always visible on my clients computers. In case of a problem, when I'm unable to access a particular computer remotely, I can always ask the user if everything is right with the icon.
But, there is a downside. Sometimes users are mistaking the network connection icon with some other, shuting down the network connection by mistake.
I'm trying to find out a way to keep the icon displayed, while disabling the possibility of shuting down the network connection with it.
Perhaps it could be possible to replace the system icon with some other? Or, perhaps, it is possible to restrict the user rights, so it will be not possible for him to shut down the network connection?
0 -
Thank you, very much.
I was able to turn the "files with unknown extension" search option on. It was a bit difficult to find it, because the Microsoft article is in English, while my Windows is in Polish. After quite a while I was able to overcome the translation related difficulties. They hid this option well, indeed.
0 -
Well. I tried to find log files with a certain keyword in them, but the Windows XP just ignored the files with .B and .BLG extensions. When I did the same in Windows 2000 the files were located, correctly.
So, there is quite a difference between the Windows 2000 and XP Find Files function.
Is it possible to affect the way Windows XP searches the files? Or, should I rather use a different file search tool?
0 -
Well, it works correctly, now. The reason is simple. The files on the server had read only attribute set, while the local copies did not. That's why the symbolic links were working differently, depending on where they were pointing to.
0 -
You are right. I did use the Link Shell Extension and the driver mentioned there. There are many pages related to this topic and many of them are not quite precise.
What I found so far:
- The symbolic links are working in general. The only requirement is the driver and NTFS partition. However it is possible to link to files on a server without driver and without NTFS, as well. For an example I did link to a Windows 2000 share set on FAT32 partition.
- the application I'm toying with accepts the symbolic link for one of the files. The file is accessed correctly, as far as I can see. However two other data files are as good as missing. It could be related somehow to the file open procedure. The problematic files are opening correctly in Explorer, but the application does not seem to be able to open them. However, everything works fine, if the symbolic links are pointing to the files located on the same system (other partition). So, the symbolic links to networked shares do not work as intended in some cases.
0 -
Well. My investigation shows the Symbolic Links with ability to link through networked systems were added in Windows Vista. Also, it looks like there is a file system filter driver able to add such a feature to Windows XP.
I'm trying to speed up network application booting by moving executables to local HDD. To do that I need to copy a directory of the application from the server to local HDD with an exception of a few data files. Some data files are accessed within the same folder the EXE file was run from. So, in order to make this idea a reality it is necesary to make symbolic links on workstations, so the application will seek the databases on local HDD, but the data will be kept on the server.
- the hard links within a single NTFS partition will not solve the problem
- the directory junction feature will not do the trick
- the symbolic links from Windows Vista (and newer) should be able to solve the problem
- perhaps there is some other solution I'm not aware of. For an example there was an APPEND command in the DOS. In any case the Path enviroment string does not do the trick.
0 -
To make such an experiment, it is enough to make a backup copy of the protocol.ini file.
For an example. I did install two ndis network adapters with different driver files. Then I did different bindigs in the Network Properties dialog. One network adapter is binded just to the TCP/IP the other got also NetBeui and Microsoft Networking. Then I did two versions of the protocol.ini files by removing all the bindings of one of the adapters in both copies. Of course both copies have different bindings missing.
Then I made two batch files to replace the protocol.ini file with one or the other copy. The batch files are renaming the network adapter DOS driver filenames, so just one is available at a time, as well.
Now I can switch the Windows to work with one adapter or the other, by running a batch file, without entering the Network Properties dialog. So it is enough to run a batch, then reboot. Or to call a batch in clean DOS, then net start, then run windows GUI.
What's more, both network adapter drivers are working with the same hardware. I had to hex edit the driver file and modify inf to do that. So, my Windows 98 has an ability to switch between two different network setup profiles, now.
0 -
I suppose what I should test fundamentally is whether the DOS driver is actually working in DOS.
I have no DOS programs that use internet access, so has anyone got any suggestion as to how I can test it in DOS?
Cheers, Dave.
Well. Testing the DOS driver with TCP/IP protocol is simply forcing things. It should be faster and simpler to test just the NetBeui with Microsoft Networking. This will answer the question, if "the DOS driver is actually working in DOS". What's more important, all the necesary elements are available, and were linked together, already.
0 -
Well. The task is to test the drivers able to work with Windows 98, right? I doubt Windows 98 GUI can work with DOS based TCP/IP driver. So what's the point in testing it?
0 -
I would not recommend to test the DOS drivers with TCP/IP. The reason is quite simple, DOS drivers do not support TCP/IP.
On the other hand, the NetBeui should work along with Microsoft Networking Client.
0 -
It looks like all the items are there, but there is some problem with the link.
In case of my system, there are bindings in the network applet list. I did bind the NDIS driver with TCP/IP and NetBeui transport protocols. I binded them with Microsoft Networking services. The interesting part is the TCP/IP binding does not appear in the PROTOCOL.INI. All the TCP/IP is done by the GUI part of the Windows, while the DOS part does just the NetBeui.
Also, the network performance is affected by the processor temperature. It looks like the DOS portions of this network system is much more dependant on the CPU, then the 32bit counterparts.
0 -
The NDIS network adapter will not appear by itself. One has to install it the way I showed quite a few posts ago.
0 -
No, it does not. There is just the NDIS network adapter. When the DOS driver is not present, the according NDIS network adapter entry has a ! mark on it.
I found the Windows 98 boots quicker without the network adapters. So, I made a DOS boot menu with option to boot faster without the network. If the net start is not run in autoexec.bat, the windows starts quicker, but network does not work.
0 -
What can I say. It simply works.
Not in the DOS, of course. Somehow GUI network components are able to use the DOS drivers. But for it to work correctly there has to be a link established between the Windows components and DOS drivers (I believe NDIS.VXD does it). In my case the bindings made with GUI were transfered correctly to the protocol.ini. The example I provided was made by Windows GUI network setup functions.
Long ago, when I was still playing with 10Mbit ISA network adapters, all of them had Windows 95 dedicated driver sets with both 16 and 32bit drivers in them. It was possible to select the version to be used. With 16bit drivers I was possible to skip loading GUI and use NetBeui protocol for networking in DOS. But since the PCI came in, all the driver packages were provided with just 32bit versions.
0
This SMBv1 Vulnerability Business ...
in Windows XP
Posted
SMB (NetBios) does work without TCP/IP, as well. The problem is the Windows XP does not install it by default. So it is necesary to install the files by hand. So, it is possible to use SMB without TCP. The plain NetBios will not go trough the internet, as it is not possible to be be routed. That's why, back in the Windows 98 days I used to link the Microsoft Networking with just the NetBios leaving TCP/IP unlinked.
Unluckily, Linux systems are unable to use SMB without TCP/IP. So, no connection to Linux SMB shares with just the NetBios. Still, having both NetBios and NetBios over TCP/IP linked to Microsoft Networking is a good thing to have, when DHCP server is down.
Also I was not interested in NetBios without TCP/IP on newer than XP systems, so I do not know if Vista and 7 can use plain old NetBios without using TCP/IP. Im working with mixed Linux and Windows networks, so I lost my interest with windows 9x style NetBios years ago.