jaclaz

Actually you should have done the image BEFORE fiddling with the disk, and right now it would (unless you continue fiddling, doing "random" things to that poor little disk ) be just loosing some time. The idea is to first verify by ONLY reading some data on the disk, if it is recoverable (as filesystem). If it is not, the free space you have will become useful as target for the "file-oriented" recovery attempt. Ideally you should get "partition wizard", whatever it is, in the dustbin and not even think of using it again (unless told by someone to actually use it). Last time I checked them there were 3 or 4 programs called "partition wizard", WHICH one have you used? I need to: understand WHAT EXACTLY you did (please describe everything you did, with the most details you can remember)have you perform a couple of tests by reading/copying a few "key" sectorsThe point is this. IF you ONLY created a partition entry in the MBR AND did NOT "format" it, then it is possible that the filesystem is recoverable IF you - through any means - "formatted" the partition then IF it was a "quick" format, you have lost the filesystem for good BUT file recovery might be possible IF you - through any means - "formatted" the partition then IF it was a "full" format (as an example as performed by Vista or later) then not only the filesystem is lost forever but also each and every file that was there.To quickly disambiguate, of the above three actions, #1 is instantaneous, #2 would have taken several seconds/minutes, #3 would have taken hours. Without knowing what EXACTLY you did and under which EXACT OS and with WHICH EXACT tool, I cannot provide you with any meaningful support/advice. You seemingly do not know what is (let alone use it) a disk editor/viewer. Go here: http://mh-nexus.de/en/hxd/ http://mh-nexus.de/en/downloads.php?product=HxD and get this file: http://mh-nexus.de/downloads/HxDen.zip It is the portable English edition of the Nexus HD editor. Uncompress in a directory. Run Hxd.exe, it will ask you to create a configuration file in the directory, tell it "OK". Then Extras->Open Disk Select the disk, you want to choose among the Physical disks, and since it is /dev/sdc in TESTDISK, that disk should be Hard Disk 3 (the numbering is the same that you can see in disk management), LEAVE the tickbox to "read only". On the top bar there is an "edit box" Sector 0. Write in it 22661691 and press Enter. You should be now be on sector 22661691 of the disk. It should begin with "File0" and around the middle of it you should be able to see "$.M.F.T.". If you use the little up arrow beside the "Edit box" you can go on later sectors. Every other sector should begin with "File0", the next one beginning with "File0" should have around the middle "$.M.F.T.m.i.r.r." If you continue to go ahead, you should find a number of sectors with the "default" hidden fiels of a NTFS filesystem, like $LogFile, $boot, $Quota, etc. If you continue to go ahead, within a few sectors you should be able to recognize some file/directory names that were on the disk. If you can find some of them visually, there are good chances that the filesystem can be recovered, if after a few tens sectors there are no such filenames, the $MFT is lost (and your only chance is file based recovery). jaclaz

The screenshot shows very little. You should run TESTDISK again with a LOG (and post/attach the LOG, not a screenshot. Also, you did not provide an EXACT (enough) report of the actions you took. How EXACTLY (on which OS; with which tool giving which EXACT commands) did you try to delete the first partition? The issue (more or less) is the following (now). IF you recreated a NTFS partition starting on the SAME address (or a "near enough" one) you have effectively overwritten the $MFT of the original NTFS partition and you won't be able to recover the "previous" partition contents (but you might be able to recover most of the files in it, with file-oriented recovery software, very likely losing the filenames). IF on the other hand you recreated the new NTFS partition on a DIFFERENT address (or "far enough" one) like it would be if you created just a single partition starting from the beginning of the disk, there is a chance that the new $MFT did not overwrite the previous one and thus it is possible to recover a large part of the filesystem. The data "sector 16370235 and end at 3907024064 sector and total 3890653830 sectors" represent a "valid" partition created with the "old" Cylinder boundary standard (possibly through XP or a third party tool, not with Vista or later) On such a partition the $MFT should start at 786432*8+16370235=22661691 First check you should make would be to use a disk viewer/editor and verify that absolute sector 22661691 is the actual start of $MFT . jaclaz

You seemingly have this wrong. The LXDE "750 Mb" .iso is a "Live CD" including a "full" Debian distro using LXDE as desktop/graphical environment, there are a similar one using Fedora as base OS and yet another using Lubuntu (which is 696 Mb instead). They are "working builds" to demonstrate the use of LXDE. Normally you would install "a" Linux distro, then install to it LXDE and use it as desktop/graphical environment, replacing the one the "plain distro" uses by default. From this to re-package this install into a .iso (be it a Live CD or a simpler "install CD") there is a large (very large) leap. The slackware "mini", as explained here: http://www.slackware.com/~alien/slackboot/mini/ is the bare minimum to start installing (on hard disk and through packages) a "customized" Slackware. In layman terms, it is like you want to build a new house (without having ever worked in the field) and start by getting just a lot of timber, a hammer, a few nails and a hand saw. It is of course possible that you manage to build yourself (or adapt what you can find locally) all the pieces needed to have the house built, and assemble them properly, but it will be a loooong process. When it comes to making a .iso of it, it's more like you disassemble the house you just finished building, package every piece neatly and in order, make drawings and assembling instructions for it, and then give the whole lot to someone else that uses that for re-building the house. Not something I would advise. jaclaz

About the LG Smart TV issue, I would say that if "they" disable it (but still the device is "capable of" AND can be remotely managed - possibly through a "firmware update") the whole represents pure bull§hit as always. So you go to bed and find in your bed (say) a potentially dangerous/poisonous animal, let's say a biggish spider or a scorpion, what do you do: find a way to get it the heck out of your room/house or kill it go to bed and sing to it a lullaby (so that it also gets to sleep and thus becomes innocuous) jaclaz

What do you mean "tutorial"? (it is a rather "vast" topic) There are resources on the usage of available commands, if this is what you mean: http://ss64.com/nt/ Or you want something like an "introduction" to the command line and batch?: http://commandwindows.com/ More advanced: http://www.robvanderwoude.com/batchstart.php jaclaz

Check on the right column, under "Publications" on that page: http://www.wsusoffline.net/docs/ You will find a link to: http://www.h-online.com/security/features/Do-it-yourself-Service-Pack-747193.html which should clarify your doubts. The actual "Update Microsoft Windows and Office without an Internet connection" or the Introduction on: http://www.wsusoffline.net/ should actually have been enough, theory of operation is that you download from *any* machine connected to the internet all the updates for a given OS (independent from the actual hardware used for the downloading) then you transfer via "physical media" the downloaded files to the non-connected to the internet machine and upgrade the OS on that machine. jaclaz

You can try using WMIC (but I doubt it will be available at that stage ): http://setiathome.berkeley.edu/forum_thread.php?id=69381 Or you might need to use a third party tool, like: http://retired.beyondlogic.org/solutions/processutil/processutil.htm How to "automate" it, is another thing, but that should be T-39 stage, you may want to try DetachedProgram http://www.msfn.org/board/topic/19607-detachedprogram/ jaclaz BTW (and for the record): The original source of the "trick" is most probably: http://www.technostriker.com/2012/06/install-windows-xp-faster-then-ever.html which is NOT particularly supported by evidence, NOT EVEN anecdotal :

A .ini file has (AFAIK) the SAME capabilites of preventing the installing of the adware coming with Windows 7 as a .xml has. jaclaz

Does Windows 7 come bundled with adware? Can a unattend.xml file prevent the installation of the adware coming with windows 7? jaclaz

To be picky (as I am ) they also actually failed to design a mug for the left-handed, and (being also cheap ) US$ 7.99 for a mug? They will be geniuses if they manage to sell for 8 bucks something that costs to them less than 1 US$ apiece (example): http://salinaglass.com/promotional-coffee-mugs-c-1 AND they also make through these items their denigratory campaign. Now, if they would send me one of those mugs (free of shipping/handling charges), and together with it a US$ 80.00 check, then maybe we could talk of the matter. jaclaz

Well, you will need to list "the others" that thought that , last time we talked about this same topic I tried (vainly, as it results) to explain you why that is a mere assumption (specifically proven wrong) unless you analyze/know WHAT actually the manufacturer has included in the "Restore" and HOW EXACTLY it is performed: http://www.msfn.org/board/topic/163601-will-a-recovery-clean-the-hard-drive/ jaclaz

Happy to have been of use. Maybe you could detail the steps you did (for the benefit of other users that may find themselves in a situation similar to your one). jaclaz

JFYI, I am thinking to get a Motorolv or a Mdtdrdlv (NO, no typos ): http://www.dhgate.com/product/vintage-2013-cellular-phone-dual-sim-dual/172329567.html jaclaz

What makes you say that ? There are so many Vista haters out there who would say different. I liked the OS sure enough, but what makes it the Best Windows Yet? As erpdude said a few posts earlier, the "key" here is SP1. Anyone who had the Vista as it was provided originally (and it took 1 - one - whole year to get the SP1) cannot but hate it. Generally speaking, the "professional" user, long before the SP1 was released would have downgraded to XP and never looked back, the "common user" (who had it pre-installed on a PC) would have suffered one long year of "queer" behaviours and would have had so much time to hate the stupid OS that he/she cannot forget it. To the above you add that - still generally speaking - the Vista's coming with OEM hardware were invariably on seriously underpowered machines that contributed to spread the notion that VIsta is a resource hog (which BTW it is ). With SP1 Vista began behaving like a working OS, but it was too late. jaclaz

Well, I saw it coming since a loong time, JFYI (quoting myself from 2009! ): http://reboot.pro/topic/9915-the-good-thing-is-that-engineers-never-stop-to-surprise-me/ jaclaz

Good. But you will need to provide some background, like how you remember your disk was partitioned, and the like. Essentially the "relevant" part of the .log is: The "red" part is very possibly just a "glitch in the matrix", or however should not influence your booting. You seem like having the "typical" Windows 7 (or possibly 8) "boot" partition (what the good MS guys call "system") of 204800 sectors, which has some wrong geometry settings (this partition is normally hidden/not assigned a drive letter) and a second partition (which is the actual "system" and "data" partition). So you originally had just the "C:" drive, correct? If you re-run TESTDISK and press the P button when you have highlighted either the #1 or the #2 partitions, you should be able to see the "root" directory of each partition. in #1 you should be able to see at least: BOOTMGR <- file \boot\ <- directory in #2 you should be able to see the previous contents of your "C:" drive. Now, a good idea would be, before doing anything else/any attempt to repair, to make a copy a few "key" sectors. To do this, the easiest would probably be Hdhacker: http://dimio.altervista.org/eng/index.html The general way of operation is: first select (on the left side) WHAT you want click on the "Load Sector" Button click on the "Save Sector" Button and save the file on ANOTHER volume/disk/deviceYou will be accessing the \\.\Physicaldrive, normally the first disk will be \\.\PhysicalDrive0, the second disk (it seems from the TESTDISK log that you have two disk on the machine on which you are attempting the repair) will be \\.\PhysicalDrive1 and the third disk you will be trying to extract the data should be \\.\Physicaldrive2 (you can check in Disk Management, the numbering of Disks is the same) HDhacker uses the convention of numbering sectors starting from 1 (unlike "normal" LBA notation). You want to save sectors: 1 <- the MBR for the extension of 1 sector 2049 <- the PBR of first partition for the extension of 16 sectors 206848 <- (hopefully) the bootsectormirr of first partition for the extension of 1 sector 206849 <- the PBR of second partition for the extension of 16 sectors 572939712 <- (hopefully) the bootsectormirr of second partition for the extension of 1 sector then you compress the resulting 5 files (please meaningfully named ) into a .zip archive, upload it to zippy or the like and post a link to the file. With these data I should be able to suggest (hopefully) next steps to take. jaclaz

I don't know. I mean I don't know if running the CHKDSK (or actually merely accessing/mounting the filesystem through the Windows drivers) is actually producing some changes (even if it does not say so), or, if you prefer, if now restoring the "original" 100 sectors to the cloned disk, this latter is still identical to the original disk. This is the "advantage" of using an image (as opposed to a "real" disk), both TESTDISK and DMDE use their own methods to access the filesystem, independent from the Windows mount manager and filesystem recognizer/drivers. Even before running the FAT repair, TESTDISK may be able to show the contents of the disk. Of the 100 sectors file I sent you, besides the first 63 sectors (that I left untouched) and the 32 sectors (on which I wrote just a "basic" BPB only bootsector, I only "invented" or "faked" sector 95 (the ones after are not changed, I just reused the original ones). Since sector 96 started with the "continuation" of a "contiguous file", I wrote the sector 95 as if it started with that same (only) file. By manually inspecting the first 128 clusters of the filesystem (hoping that it is intact) it should be possible to make a "better" sector 95. Those would be 128*64=8,192 sectors x 512=4,194,304 bytes, starting at offset 63+32+2*238409=476,913 let's make this 9,000 sectors starting from LBA 476,500. Please understand how UNLIKE the sectors you provided till now, these sectors will contain filenames and file contents, so if there is any concern about privacy, trade secrets or similar, it would be NOT a good idea to share these data with a stranger on the Internet. jaclaz

Sure , point being how many of the programs you run are fully 64 bit, and how many are 32 bit? Or if you prefer, are you not running (say) between 80% and 95% of the time non-native 64 bit programs on that machine? Yep, but this only proves that the good MS guys like to re-use previous code/settings/approaches, not necessarily that it is "smart". As always I might be largely wrong , but IMHO this whole 64 bit stuff has simply been "pushed" onto users a tadbit earlier than actually needed, and does not always make sense in practice. You have a 64 bit OS because with it you can access more memory that allows for larger programs that need more RAM, which since it is available allows for having larger programs that need more RAM that need 64 bit OS which needs more RAM, which ..... A non-entirely-new concept : http://en.wikipedia.org/wiki/Ouroboros jaclaz

Well the idea was to write the file to the image (and not to the disk) and trying accessing the image (and not the disk) through TESTDISK (or DMDE). Even if I have recreated *somehow* some bootsector data and a "fake" first sector of the FAT table (which is enough to have the Windows recognize the filesystem) not necessarily my "fake" sector is "good" or "enough" to allow seeing the files "directly". Right now (unless I am mistaken) we have two non-synchronized FAT tables and how the Windows FAT32 filesystem driver will deal with this is all to be seen. TESTDISK has an option (ONLY ONCE valid values are in the bootsector) to attempt rebuild the FAT tables: http://www.cgsecurity.org/wiki/Advanced_FAT_Repair Now, you have to be careful, very careful. Until you wrote those 100 sectors file to the hard disk, you had two identical copies of the disk, the disk itself and the image you made out of it. We do not know (for sure) if when the Windows filesystem driver accesses a filesystem, it automagically changes some values (particularly if accessing a failed/not fully "kosher" one). In theory you should now make an image of the image (to be on the very safe side) and then use the TESTDISK on the second image, to which you will have to copy the 100 or try using TESTDISK on the actual disk (so that the image is left untouched form when it was made initially). It is very possible that also CHKDSK may be able to recover the files, but as said I would first try the TESTDISK FAT Repair. In any case, after EITHER of CHKDSK or TESTDISK FAT repair has been run, the (disk or image) on which it has been run will be changed (and if not repaired fully, you will have to restart from the previous "untouched" disk or image). jaclaz

That's good. This new file "238896 - 238995" is identical (actually it has one sector less at the end) to the file "sector from 487 to 587", which neatly confirms that the FAT size is 238896-487=238409 : You can try what posted on post #19: http://www.msfn.org/board/topic/170288-lost-partition-and-filesystem-problem-with-adata-sh14-disk/?p=1060289 Remember that file, once unzipped are the first 100 sectors of the image, you should apply them using dd or dsfi (rather than selecting in a hex editor, that may easily lead to mistakes ): dd example: dd if=/100sect2FAT.bin of=/mynyceimage.binor under Windows you can use, besides a dd port, the dsfi from the dsfok toolkit: http://members.ozemail.com.au/~nulifetv/freezip/freeware/ dsfi myniceimage.bin 0 0 100sect2FAT.binjaclaz

Well, it is really "queer". If you search on your image with an Hex editor for the hex string B9 F5 00 00 BA F5 00 00, you should find it in two places (do NOT search for them from the beginning of the image, start searching from around sector 500 and from, around sector 238900: on sector 586on sector 238995(this is where I have them in my "simulated" image, you will have to confirm this on the actual image you have or correct to the exact sector numbers where the strings are found) As you can see, 238995-586=238409 (i.e. the size of the FAT table I have) In both cases the string is at half of the sector, BUT it is at the beginning of the file you attached "sectors from 238896 to 238995" It seems like when you made that file you *somehow* introduced a "shift" . As I have hinted before, a FAT32 table contains 128 entries, this means (for allocated clusters, with contiguous files), that the very first entry in the very first sector of the table should have value: 01 00 00 00 (but it has not, because the first two entries are "markers or signatures") and the last entry of the first sector will have value: 80 00 00 00 (as 0x80 = 128) Second sector begins with: 81 00 00 00 Third sector begins with: 01 01 00 00 Fourth sector with: 81 01 00 00 Fifth sector with: 01 02 00 00 etc., etc. in other words, normally a sector belonging to a FAT 32 table (representing an allocated cluster) will begin with 01 or with 81. I hope you are following me. On the files you posted inside sectors.zip: "sector from 487 to 587" begins with 01 (good) "sector238503" begins with 01 (good) "sectors from 238896 to 238995" starts with B9 and the "01" can be found at offset 288/0x0120 (if you prefer all sectors on that file begin with either 39 or B9)Can you check/recheck your image and the procedure you used to make that file? Also (please again follow me) "sector from 487 to 587" begins with: 01 C4 00 00 , since 0xC401=50177 up to sector 486 there are 50176 entries, i.e. 50176/128=392 sectors of the FAT, to which you add the (63+32) = 95 sectors you get back the sector number 392+95=487 "sector238503" begins with: 01 A4 D1 01 , since 0x01D1A401=30516225, up to sector 238502 there are 30516224 entries. i.e. 30516224/128 238408 sectors + 95 = 238503 This means that sector 238503 still belongs to the first FAT table (which is good, or at least coherent with my previous calculations). Now if you try taking a new copy of a 100 sectors around 238896 (and hopefully this new copy will have as first bytes either 01 or 81) we will be able to verify the calculations. Explanation: Setting temporarily aside the "strage "shift", the first value in "sectors from 238896 to 238995" is 39 0B 01 00 , which is 68409, and 68408/128=534.4375, i.e. sector 238896 should correspond to either sector 534+95=629 or to sector 535+95=630 which would give us a size for the FAT of either 238896-629=238267 or 238896-630=238266 which are evidently "wrong" as we have already made sure that sector 238503 belongs to the first FAT. I cannot really think of anything (short of a strange controller issue of some kind OR a mistake you did when copying the sectors) that could justify the "shift" in that last file. Maybe it would be easier (if it is possible for you) if you could image first 95+2*238409+(say) 1000=477,913, let's round them to 488,000 sectors. That will result in a 488,000*512=249,856,000 bytes file which should compress with zip (or with 7-zip with a slightly higher compression ratio) to something less than 100 Mb. (you may need to upload it to a file hosting like zshare or similar and post a link to it) jaclaz

Good. jaclaz

I guess you are asking a bit too much. Particularly the "solid", but in any case it doesn't work really-really like this. I mean, there are several stages that do not allow IMHO to draw a line. A "vector" may be (in my personal experience the "best" vector is the user clicking on random things AND Outlook Express ) Flash or Java, but 1/3 to 4/5 of *any* program nowadays access the Internet, at the very least to check for it's own updates, so it is difficult to say. But the "vector" is only HOW the malware enters a machine, then the "payload" may make use of *any* vulnerability present on the system. Loosely I would say that the patches on "Patch Tuesday" (those that tend to lead to "Exploit Wednesday" ) - with the singular exception of Internet Explorer (and Outlook/Outlook Express) patches - are largely preventing the "payload" from doing damages/work, and very little about the "vectors", but it is difficult - as said - to draw a line between the two. jaclaz

Which you DID NOT report initially. jaclaz

At first sight you are missing the ENABLEDELAYEDEXPANSION, variables inside a FOR loop are not updated unless you use it: http://www.robvanderwoude.com/variableexpansion.php Try changing to !Errorlevel!, and in any case when experimenting you shouldn't redirect the output to NUL, as this way you cannot actually see what is happening, as a matter of fact I would add some more "troubleshooting useful" commands (that you can later remove, once satisfied with result), *like*: SETLOCAL ENABLEDELAYEDEXPANSION....ECHO "%SC%\ixhplayerg.%%a"PAUSEREG QUERY "%SC%\ixhplayerg.%%a" IF "!ERRORLEVEL!"=="0" do (ECHO Errorlevel is 0....jaclaz