Jump to content
IObit Forum
Top Free Driver Updater Tools Best 25 PC Optimization Software Best 22 Antimalware Best 22 Uninstaller Software IObit Coupons & Discount Offers PC Optimizer Mac Boost Advice IObit Coupons A Good Utility Program From IObit IObit Promo Codes IObit Coupon Codes IObit Coupons and Deals FAQs Driver Booster Pro Review

verdy_p

Members
  • Posts

    36
  • Joined

Everything posted by verdy_p

  1. You've now proven thaty you make false assertions. Dashlane is reputed and recommended by serious security advisory organizations, IoBit is not. And the Adwares added by ioBit WITHOUT CONSENT (directly installed before we ever see the first dialog of your installer) are detected as malwares by almost all security suites (except yours...). They give false ads for abusing products, make illegal recurring payments, do not honor the cancellation requests. Your adverizers are really bad and this comes directly from your prodcut installer as soon as it starts, without ever asking and without providing even any way to unionstall them cleanly. They are siltently disguised under fake Microsoft product names as if they were essential Windows components. You've lied multiple times. I've now blocked all your products. You claim that "%AppData%\Roaming\Dashlane\ie\KWIEBar.dl" is a malware but simply do not check the digital signatures to see if they are legitimate copies of fake files created by others. This is the normal plugin used by Dashlane on IE to support and integrate the password manager. And seriously you've not investigated anything, because otherwise you would have detected that there are different versions of this file, one is legit is securely signed by Dashlane, others are unsigned and not made by Dashlane and have other purpose (these may be malwares, jsut like if one installs an unsafe copy of "explorer.exe" in Wnidwos which by itself is not malware but needed (and signed by Microsoft, unlike fake versions that may replace and contaminate them). I gave proof that this was a false positive. But now you insist in saying it is not only because you want to use absuive anticompetitive strategies to force users to buy your own product instead. Given the level of lies you produce, ioBit is now listed as a malware authoring companyn which is unable to choose its advertizing partners responsibly and does not respect its own users. ioBit must now be banned. Final dot. And note also that your servers have also been harvested and thousands/millions of user accounts on your servers have been stolen. Your servers are compromized (since at least 1 november 2015) and you never informed your users and continued to produce infected softwares made or distributed by your servers. Even Cnet has banned multiple versions of your free products because they were found to be contaminated (reported by many users, and asserted by notices posted on VirusTotal, and multiple national digital security agencies). But you refuse to solve this problem and continue doing this business without informing users correctly. denying a problem will not help you get more trust from your users.
  2. Dashlane is not a malware, the file I submitted was the original version downloaded secrely from their website. But ioBit is known to install various adwares (that turn to be real malwares) in its "free" products without asking permission to the user. Seriously, this is not the first time (all your "free" products have been regularly affected by multiple different versions of your malwares). Ten when you fix them, you just try to use another trick to avoid the detection and blocking by serious antivirus solutions. May be your "paid" versions are safe, but this is certianly not the case of your "free" versions which are constantly infected and extremely intrusive.
  3. May be some users have experienced problem only because this GUID was harnessed (in the registry of their own Windows installation) by another uynrelated malware trying to steal passwords stored in Dashlane, and installing another unsafe addon on this key. Clearly it is not enough to just check the GUID without looking at the software that is pointed by this TypeLib registry key. So the ioBit analysis is clearly unsafe if it just considers GUID's that are NEEDED by safe softwares (for example a malware may attempt to infect a GUID of Microsoft Office or Windows itself, this does not mean that the GUID itself is "malware", when it is needed by core functionality.)
  4. IObit Malware Fighter OS: Windows 7 Version: 3.1.0.18 Database Version: 1440 Scan Mode:Manual Time Elapsed: 00:00:24 Objects Scanned: 54820 Threats Found: 1 Save Time: 02/05/2015 03:31:31 |Name|Type|Description|ID| Malware GUID, GUID, HKEY_CLASSES_ROOT\Typelib\{3277cd27-4001-4ef8-9d96-c6ca745ac2f9}, 402319 ----- File in registry is "%AppData%\Roaming\Dashlane\ie\KWIEBar.dll" This is clearly NOT malware. In addition this addon is digitally signed by Dashlane. And VirusTotal does not report ANY alarm from ANY antivirus suite. VirusTotal report (100% clean): https://www.virustotal.com/fr/file/5...b242/analysis/ It is the required addon that allows Dashlane (a SAFE and SECURED password manager) to fill in forms to enter login/passwords that it will send to the visited site. Without it, the password manager is no longer functional at all, and we need to enter them manually, and update them manually in Dashlane! Dashlane is not an obscure company, it has an official street address, true phone contact, true fiscal number. The website is also clearly identified, as well as its billings, and there's never been any issue about payments and subscriptions for its cloud storage service (optional). This report is about the last updated version of Dashlane (see https://www.dashlane.com/) Here is what is installed in "%APPDATA%\Roaming\Dashlane\ie" (zipped and encrypted with password "infected", as instructed by you): http://www.wikisend.com/download/843...e-ie-addon.zip Note: the zipped file above has a 90 days lifetime on "wikisend" (the maximum allowed) starting today.
  5. Seriously, the "Surfing protection" (the name used in ASC for "Spigot.com" and that is installed when we REFUSE to install Spigot.com) is now recognized as a spyware, plus an adware that tracks us everywhere (not only in web browsers but also in all applications that have a web UI, and notably Office) Stop this lie !!! IObit is now officially recognized as malware (you can no longer download it from its official website with Chrome. Google has marked the webiste as malware after several users have proven that it was not only invasive, but also straling data illegally, and replacing system security impovement by other unsigned component modified to open backdoors. Spitgot.com is effectively extremely difficult to detect and to remove. Several antivirus kits are investigating the issue about how to detect it and making sure it is fully removed, but in fact they have problems with Spigot.com because ASC constantly attempts to reinstall it. I see only one safe solutoon : drop ASC completely (but even when you uninstall ASC, Spigot remains infecting the system and calling home, notably on "www.pong.com/gaming" and "www.pong.com/network", plus a few others each time you visit your online bank or a merchant site like eBay and Paypal, or RueDuCommerce and CDiscount in France. Several French banks have officially forbidden users to use ASC. ASC will soon be cleaned by more tools because of Spigot.com Next week, Bitdefender will provide a tool to completely remove the Spigot.com malware, but this will not work as long as ASC is installed: the only option will be to delete ASC at the same time.
  6. Yes I have the latest english.lng file (I indicated the vesion from which I worked) as well as your checker tool (no error found except on the few resources which contain literal % signs in strings like "100%", or numeric place holders that the tool does not corectly parses like "%.0n"). Still some translated elements do not appear in French: this is the case in the contents of the Toolbox. The most probable reason is that the .lng files provided with the installer (downloaded from YOUR site) do not actually match their expected version. Really, all .lng files provided within your installer SHOULD contain the version number for which they were generated. Note: you did NOT attach your reference English.lng file with your message !
  7. French.lng 6.1.9.215 This is also the update of the French language which is still compatible with the current release but also adds all the ressources for the current beta version 6.1.9.215. Here again lots of French orthoghaphic and grammatical typos corrected, and layout problems fixed with some long strings. Complete, but there's still NO display of the translations for individual tools and catégories in the Toolkit tab. Could IObit check the entry names or category names found in the English language file, as thery probably don't match what the program expects. Note that the resources for the Ultimate version are also integrated, including with the Antivirus integration.
  8. Fully completed language file (zipped) This is the fully updated French language file (for ASC v6.0.8.170): - added all missing untranslated entries - fixed a LOT of grammatical and orthographic typos - unified the terminology across all similar items - fixed strings lengths to avoid most collisions in the tested UI (only a pair of buttons need to be abbreviated to be readable) The attached French.lng file is zipped because this forum llimits the attachment size. Note that some UI are correctly translated according to the source English file, but still the translation is not displayed in ASC 6, in the Expert mode in the name and descriptions of tools in its second "Tools" tab.
  9. Considering that Vista uses a lot of memory, I think it is a bad idea not to create a permanent paging file, that should live in the middle of the boot partition (if you have only one physical drive), or on the first partiton of an alternate physical drive. If you don't create it, Widnows will create one for yuo but it will be extrmely fragmented. Set it to a size that is at least the recommended size displayed, but in only one time. Don't use the Windwos interface to change the paging file size, unless you first remove it, and reboot, then recreate it with the desired size only after defragmenting the drive. I've also seen absoutely no benefit for putting the paging file on multiple disks. Windows is more efficient with a single paging file. Disabling completely the shadow copies is not a very good idea these days. It's proven that those copies can really help in case of crashes, to avoid losing data (because Windows can recover from a crash using those copies). However, it's a good idea to reduce the size of those shadow copies (because the maximum size of these shadows is certanily too big). This is possible in the advanced system properties. However, there are other disk space that no existing tool can defragment: this is the USN journal, hose growth is completely unpredictable. The only way to defragment it can only pass through a offline backup (you can boot from a CDROM image, then run the full system backup from there; you'll have to reformat the NTFS volume completely before restoring the data from the backup.) I've looked everywhere on the Net, and there's apparently no documented way to defragment this USN journal (I had a system where it was extremely heavily fragmented). What is documented is a command line tool (fsutil.exe) in the Windows system directory that you can use to delete the USN journal, but it is immediately recreated: after testing it, I immediately realized that it was recreated and growing exactly at the same place as before, so the effect was only temporary and did not last more than 2 days. In fact the USN journal gets filled automatically by every file move made by the Windows defragmentation API. I cannot understand why the Windows NTFS driver does not allocate the spaace for the USN journal in just one operation and in a single fragment, all what it can do is to recerate it with a ridiculous initial size and then increase it incrementally with a strange formula that creates a lot of free gaps on disk. Given that it should be a cyclic file, it would be better if it was created in the third of the free space that Windows uses for allocated new files, and handled as a sparse file so that oldest (and smallest) initial fragments can be released, and later replaced cyclicly by larger newer fragments if more space is needed in the USN journal between two daily system snapshots. The maximum size shuold be tracked, and with the help of daily system snapshots and monitoring, the USN journal would reach its optimum size (and the older smaller fragments cuold be eliminated). Unfortunately, this USN journal is a space hog on NTFS within Vista (it was working much better in XP and Server 2003). I can't understand why Vista needs to write so many information in this journal (In fact I can see a reason: there are too many event log files in Vista, and Vista writes too many things in them, most of the events are monitored by absolutely nobody; in XP and Server 2003, there only 4 event files and it was enough and much faster, and did not require a lot of NTFS filespace management operations, so there was much less activity recorded in the USN journal). There's a way to improve the situation anyway: open the Vista Events Viewer: you can disable almost all the event logs in the "Applications and services logs\Microsoft\Windows" category (except those in the main "Windows logs" category): Just keep the standard "System" and "Security" event logs, that you can also cleanup their messages from time to time to recover their space after looking in it for past errors, or before rebooting to diagnose problems more easily. If you are not in a networked domain environment, you may also disable the Security event log. Keep the System event log as they are really needed. You can also recover system files fragmented space (i.e. all the hidden files stored in "C:\System Volume Information" that include system snapshots) by using the System control panel, creating two snapshots successively and then using Cleanmgr to drop all the oldest snapshots: the files currently open from the system snapshot cant be defragmented as they are active. This is visibly independant of the system shadow copies that are also written and tracked in the active system snapshot files. Note that I've not seen any system cleanup tool (including the most powerful ones, like RegCure which I think is still better than ioBit's ASC) performing the cleanup of the system event logs: this is extremely long to do manually in the Event Viewer, due to the number of categories and its almost unusable user interface where you constantly need to click everywhere in a confusive GUI layout for the various dialogs...
  10. What the article does not says is where SmartDefrag takes the dates of creation/modification. apparently it takes it by looking at the file attributes in directories, however this method is not reliable, and maintaining those dates within directories is dramatically slow. The NTFS filesystem has another reliable (and much faster) way to track the dates of change, as demonstrated in an MSDN article: you can use the "last USN" field that is present in ALL entries of the MFT. Every file or directory on NT has an associated entry in the MFT, except when they are "resident", i.e. when they are stored in the MFT entry of their parent container: this occurs when a stream or attribute is small enough to fit within the 1KB record in the MFT describing a file or directory. Normally, for all files, the NFS filename attribute is always resident, as well as the DOS 8.3 name, and (most of the time) the fragments location map to its content (except when the file is too fragmented: the file location map may require its own MFT record to store the whole list of fragments), and most named streams (such as the named stream that is added on files that were downloaded from the Internet to mark that they may be unsafe: these streams have only a few bytes of content when they are present), as well as the "standard" file attributes (compatible with DOS). The file content may also be resident (not allocated separately) if it can fit in the file's MFT record, as well as the directory entries of a directory that only contains very few files (if more files get added to the directory, the resident content will be moved out of the MFT record to an external file). But in all cases: all MFT records contain the value of the last USN assigned specifically to a version of a file; when a file or directory changes, and if journaling is enabled, the last USN entry gets updated to track the change. (Microsoft indicates that the last USN contains a timestamp, this may change in some future to use another method for linking a version to a file and timestamp, however this is still a usable timestamp in NTFS 5.0; apparently this has still not changed in Windows 7 Beta, and it is very unlikely that it will change for the next 6 years with Windows 8 or a major W7 Service Pack changing radically the way NTFS works...). Final note: It seems that the installation of MSN Live 8 and of other Microsoft "Live" products enables the USN journal by default, however it does not specify appropriate parameters to maintain it in a stable condition: the USN journal can grow dramatically. However, it has absolutely NO use unless your system is connected with a server that archives a live replication of your filesystem (for its restoration). On a standalone PC, or if you don't have a Windows server with FRS enabled you should disable this unneeded USN journal or just create it with a minimum size (that will still allow system snapshots to work reliably). If your USN journal is too large, you'll immediately see that your volume gets fragmented at lightning speed and that you need much more frequent defragmentations to maintain its performance! On a notebook, I really suggest you disable the USN journal completely, just delete it with this simple command from a command line window: "fsutil usn deletejournal /D C:" <without the quotes, then press ENTER> repeat this command for the other NTFS partitions you have outside C:
  11. How to defragment the USN Journal? I've currently seen absolutely no solution (not even in commercial applications or in offline defragmenters, or in defragmenters running rom Linux) about how to defragment the USN Journal on the NTFS partition containing the Windows installation. The number of fragments is growing ever, and now this is the only fragmented part that I can't optimize (this is true on Windows XP as well as on Vista). It seems that the USN Journal is ONLY handled by the NTFS filesystem driver, and this driver shuold handle internally a background task to recollect all those fragments. I've tried to disable the System Snapshots, and to clean up them with CleanMgr (including after a Failsafe boot to minimize the number of running processes or services, or booting from a BartPE live CD containing Windows XP, or a Linux kernel) however this just collects some fragments, but never most of them. For this reason, now the USN journal has more that 4000 fragments spread all over the disk, and this is certainly explaining why my disks have become so slow. Do I have to reformat completely the NTFS partition and then restore the files from a backup? This hevy fragmentation came after an installation of Service Pack 2 (that had failed completely the first time I tried it due to a bug in the installer of one of its storage drivers, requiring a preinstallation of another driver from the PC manufacturer to pass over this bug): I had to restore the system using the Windows builtin recovery from an archive, and since this time, my PC is dramatically slow. Note: I don't want to reinstall everything from scratch: I'll loose several licences. If someone can indicate me how to backup the installed partition or rebuild it from a backup without also restoring the fragmentation of the USN journal, I would be very pleased. Is there a Microsoft article somewhre speaking how to troubleshoot the USN journal? Final note: CHKDSK does not detect any error in the USN journal. And I don't use the NT Filesystem Replication Service (NTFRS): Should I enable it to perform the transfer of partition? Microsoft's PageDefrag CANNOT defragment the USN journal. I've tried to play with the defragmentation API, and visibly, you cannot move its clusters around. The USN journal is normally allocated ONCE after the NTFS volume is created, the first time Journaling is enabled on it. It normally never grows after it, the area is fixed on disk, even if the journal is used as a cyclic file (that's why it is marked as a "sparse" file, however it should only contain two fragments at most, unless the total USN journal size is grown). I've not found any API to truncate the used part of the USN journal, and you can't even move the unused alllocated part of the journal as long it is active (and there's no way to make it completely inactive, once it has been created on a volume, because the NTFS driver maintains it constantly open, even when Journaling gets disabled; this effectively puts a permanent exclusive system lock on it, including when booting in safe mode or when booting from another partition, and there's visibly no way to mount an inactive partition without also having the NTFS driver also opening this journal, even if it keeps it idle when journaling is disabled on this volume). If you look at a detailed map of the volume, you'll see these areas as unmoveable (for example with JkDefrag, another free, but open-sourcedn defragmenter: they appear in black). So I see only one way to defragment the USN journal: - disabling the journaling - rebooting from another partition, in a system that DOES NOT use the Windows NTFS driver (this means using Linux or some DOS extender) - in this system, emulating the NTFS driver and managing the NTFS structure completely (without using the Windows defragmentation API). Note that Microsoft's Systernal PageDefrag uses the Windows kernel, and its NTFS driver as well as the Windows defragmentation API, but can defragment the special files like Paging, because it does it at boot time, when those special files are not needed, and still closed. Due to its design, it cannot defragment the USN journal, that must still be active for the NT Defragmentation API to work reliably. My suggested workaround: - delete the USN journal from the NTFS volume: open a command prompt and run "fsutil usn deletejournal /D C:" <press ENTER> - recreate the USN journal immediately: run "fsutil usn createjournal m=1024 a=128 C:" <press ENTER> (change "C:" according to the drive letter of the NTFS volume where you need to defragment the USN journal) Caveat: the filesystem replication will stop working and you'll need to restart the volume replication from scratch (incremental updates are lost, it will take time and lots of I/O to resynchronize completely the replication, if you use NTFRS on a server, and you'll need admin authorization on the server to reenable the replication); this is not a problem if you are running a standalone desktop environment, but don't do it on a server relying on replication. After this operation, make sure you create a new System Snapshot, using "rstrui.exe" (in Vista, open the System control panel to do it, in XP, use the shortcut in the "System Tools" in the "Accessories" menu), then cleanup the old snapshopts that are no longer usable: run "CleanMgr" and in the advanced panel, click the button to keep only the last snapshot just created. Before doing all that, make sure your system was fully functional, because you won't be able to revert your system to a past snapshot.
×
×
  • Create New...