jaclaz

Very good. The new beta works fine. The GRLDR issue (please find attached two "demo" .iso) is now also much clearer. Whilst the good Syslinux guys have decided (as seen since version 2.12) to pre-embed the size and the checksum (and write EFBEADDE as "filler"), the good grub4dos guys leave the whole set of bytes set to 00's. The net effect is that IF the .iso is made with mkisofs AND the -boot-info-table option was chosen, Isobuster has no troubles with it. Otherwise the size is still found as 2048 bytes since the bootinfotable in the first sector is all 00's. Given the complexity of the options of mkisofs I would guess that the amount of GRLDR based .iso's around made with the "-boot-info-table" represent maybe 0.01% of the total number of GRLDR based .iso's. And I plead guilty, too , for having built numberless of such .iso's without the switch: http://reboot.pro/topic/9696-oscdimg-and-grub4dos/?p=84348 I may ask tinybit/chenall (current grub4dos maintainers ) if they would consider to pre-populate the size and checksum in the bootinfotable in future versions of GRLDR (unless there is any size effect since GRLDR doubles as hard disk MBR + hidden sectors loaders). In any case, the "do a scan for listed file starting on same sector as the bootimage.img" option would be useful in Isobuster for past and current builds (and may cover a number of "other non 2048 bytes sectors"). To "cover" the ISOLINUX's iso's created WITHOUT the -boot-info-table switch with ISOLINUX's BEFORE 2.12, what happens if we find the first two sets of EFBEADDE and approximate (by excess) the size to 5 CD sectors or 10240 bytes? jaclaz testgrldrisos.zip

The bad news are that evidently yes *somehow* your checksum and the one that is "embedded" in Isolinux seemingly do not match. The good news are that - though it would be of course much better to understand the reason of the mismatch and solve it properly - to identify an Isolinux (at least any actually used version) there is not really-really a need to use the checksum. Check the attached file (Excel format .xls, let me know if you have issues with this). There is definitely a "pattern" . About the GRLDR image, the snippet I posted was with an old version of parted magic. Without opening a discussion on the choice of the Author that converted the package from Free to Commercial and deleted from servers all previous versions Of course previous versions are redistributable, so if you want to work on the same one I can upload it to somewhere, but more easilu (give me some time) I will make a small empty .iso making use of GRLDR and will attach it. jaclaz Isolinux_versions.zip

Not really-really, but I am quite good at sounding like I was an actual expert. The actual asm checking routine is this one: But there is another one calculating the checksum of bytes 64-2048, I'll see what I can do, but from this to "translate" it into an algorithm that you can re-implement, it is possibly a largish "leap" , I actually hoped you were expert in asm. However, fist thing I will see if among the various tools I have around I can find a pre-made one that can recreate it. The "option to scan" remains valid, since besides the specific ISOLINUX solution (once it will be "coded properly") which will however cover - say - 87.23% of Linux originated images) it would come useful for other loaders (like the grub4dos GRLDR example I posted). jaclaz

Not really-really, but almost. It's like going on a road trip and suddenly realizing that you took a wrong turn somewhere and have spent the last two hours driving in the wrong direction, and then having to turn around and make it up, after your wife that is sitting besides you and the kids that are in the backseats have been telling you that over and over since exactly two hours. To the shame of having chosen the wrong turn you have to add to it the awareness that, besides having done something stupid, you are also dangerously stubborn, and you have NO excuses as you were actually told you were going in the wrong direction. jaclaz

You may want to change the entry to: Simple, effective. jaclaz

In the meantime I checked a bit around. It seems like there is a "hardcoded" size in ISOLINUX.BIN. I checked the isolinux.asm of version 3.82, here is a snippet: So, the data is actually there. If mkisofs and the -boot-info-table are used the data are written by it, but if not the size is however already hardcoded in the field. And the corresponding binary dump still for 3.82 version where isolinux.bin is 14336 bytes, hence 0x3800 has it nicely set at offset 0x10: I have quickly checked a very early version (2.00) and that boot info table is not there, however . I'll do a few more checks, versions 4.07 and 5.10 also have the size explicited in that field to find if earlier versions have the data *somewhere* else. To make sure that the field is there and is correct, I guess it would be possible to re-calculate the checksum of the file and compare it with the next field, though I still have to see/understand how the checksum is calculated. jaclaz

As said I have no "foolproof" solutions, the one I use in the batch is only suitable for the case where ISOLINUX.BIN (or other file) is listed in the filesystem, but at least works for a number of ISOLINUX (and non-ISOLINUX) based images. What I simply do in bextract.cmd (have you had a look at it? it is all in all a 6 kb batch file, and though it uses a few external programs it doesn't really bite - unless provoked ) http://reboot.pro/topic/12406-editing-iso-files/ http://reboot.pro/topic/12406-editing-iso-files/?p=108486 It parses the output of isoinfo -d, this is the output for the slitaz3.0 file: getting the bolded red info. If the disk is bootable (88) and if it is No emulation (0) it gets the 33. Then it parses the output of isoinfo -l -i, here is a snippet: looking for any file starting on sector 33 and then uses the 14336 as size of the no-emulation loader image to be extracted and then extracts it: Additionally (if there is one) it attempts to extract the commands used in mkisofs to create the image, saving them in a file in a folder named <name_of_the_iso_boot>, in this case of slitaz3.0.iso there is not such info, but, as an example if you try the batch on an image like pmagic4.0.iso, you get: The "hidden" is only connected to the fact that isoinfo -x cannot extract "hidden" files (though isoinfo -l does list them) hence I resolved to do the extraction using a "direct access" tool, the dsfo from the DSFOK packkage. About the time needed to scan the filesystem(s), maybe you could add a "right click" option when you select the "Bootimage.img" shown as 2,048 bytes in size (and have this option ONLY when the size is 2,048 bytes ) to the effect of "Verify size by scanning the volume" (or something along the same lines, this way the scanning becomes "optional" and is performed by user decision). I see , which however brings us back on how it would be nice to distinguish at first sight (colour was suggested, but bolding would be also a good enough option) between "real names" (the ones you get from the bootcatalog.cat) and the "fake" names (like the generic "bootimage.img"). Or maybe I completely missed it in the docs , the current behaviour is that if there is a set name in the boot catalog that name is displayed with appended the ".img", whilst if the entry is blank, the "generic" BootImage.img is shown, right? You will have to agree that (when it works ) my directory searching approach is a bit more "user friendly". jaclaz

Well, the good news are that the release date of Windows 7 SP2 TE (Touch Enabled) - which seemingly would be a more fitting name for the Windows 9 beta - is as vague as the release date of nuhi's unnamed tool http://www.theverge.com/2014/8/21/6052807/windows-9-preview-press-event-september jaclaz

Well, you are seemingly not aware of recent EU discussions (but not only EU) about the "Right to be forgotten": http://en.wikipedia.org/wiki/Right_to_be_forgotten It is a "delicate" topic, with no actual (as I see it) "right" solution possible. jaclaz

Sure . The bad news (for the aliens) being that Nuhi's negotiator uses the same strategy Bruce Willis used in the Fifth Element jaclaz

Though of course they could remove this kind of information from google search results , which are "widely used", I believe , but yes, the issue with Pandora's box (actually jar) is that you cannot put back the evils in it and reseal it. jaclaz

@Isobuster Very good. Still, the original "issue" that is about ISOLINUX.BIN based CD/DVD's where the ISOLINUX.BIN is "hidden", remains: Files on which bextract.cmd works fine (but latest posted Isobuster does not ): http://reboot.pro/topic/12406-editing-iso-files/ http://mirror.slitaz.org/iso/3.0/slitaz-3.0.iso http://mirror.slitaz.org/iso/4.0/slitaz-4.0.iso As I see it there are two ways to solve these issues (both IMHO not entirely "proper") search in the 2,048 bytes that are listed in the boot catalog for the ISOLINUX string and/or the syslinux.com one (or other "pattern recognizer) and then find the ISOLINUX:BIN in the other filesystems structures (or find the file that starts on the same LBA as the boot image, as it may have been renamed) and use that size instead <- this would "cover" only part of the images, but should be OK for the vast majority of the "pure" ISOLINUX based ones, no matter the tool with which the .iso were made check if there is any "hole" in the LBA addressing starting from the LBA of the image in boot catalog and derive from this "hole" the real size of the image <- this would be somehow "risky" and would provide in nay case results rounded to 2,048 bytes, which may be "wrong"Or, do *something like* the above checks and then show a window/message to the effect of: It is just my opinion of course , but I would personally prefer the software telling me that it has doubts about something or that it is not 100% sure of something better that having it seeming to work 100% but providing at the end a "wrong" image (or image extents). About the 2OS images, there must have been a "glitch in the matrix" (on my side ) when extracting, I retested and everything is fine now (re:size ), still I would like to understand why (unlike other similarly based ISOLINUX.BIN images) the boot image is "recognized" as "Magic ISO Boot Record.img" The kav_rescue_10.iso and AcronisAntimalwareScanCD.iso are also OK , no EFI images in them AFAICT, I must have had inadvertedly turned off the "mkiso patch setting" . jaclaz

I guess it would be very difficult to do this splitting without "losing too much" in the one or the other thread. It is better IMHO to leave this as is, and start from scratch on the new one, people interested in the details/making of up to the current status will surely be able to get here as I posted a reference to this one on the new thread. jaclaz

Sure . Done! Here: http://www.msfn.org/board/topic/172655-strange-or-odd-multi-or-single-boot-cddvd-el-torito-images/ I hope that the place I made it in: http://www.msfn.org/board/forum/82-multi-boot-cddvds/ is appropriate (but a Mod can always move the whole thread to somewhere else). jaclaz

In a topic that was originally intended to be specific to Linux based and specific to a known Software firm boot CD's, here for the record: http://www.msfn.org/board/topic/172610-acronis-iso-boot-on-uefi-pc/ it came out how there are (still) some "not entirely standard" or not "entirely documented" ways to make bootable CD's by using (or abusing) the No-Emulation provisions of the El-Torito standards. Additional the relatively recent introduction of EFI bootable CD/DVD's gives reasons to attempt revising the way these CD/DVD's are made and how to interpret their contents. A known tool to inspect the contents of a .iso in the Windows world is Isobuster: http://www.isobuster.com/ a tool that is partially freeware (with limited functionality), with a Commercial license for the "full set" of available functions/features. Taking advantage of my familiarity with Isobuster's Author on another forum, I invited him to discuss here issues/features/changes/ideas/whatever about his tool when looking at these .iso's, he gladly accepted, and now there is this brand new thread to hopefully discuss the matter peacefully. Quick recap: traditionally it was believed (by me at least) that El-Torito no-emulation images were reserved to "special" loaders, such as:the known "ArnesBootRecord" or MicrosoftCorporation.img (sized 2,048 bytes and used in Windows NT based OS install disks and PE 1.x's)the known etfsboot.com (sized 2,048 bytes and used in Vista install disks and PE 2.x's)the known etfsboot.com (sized 4,096 bytes and used in 7 and later Windwos OS and in PE's >2.x)ISOLINUX.BIN (part of the Syslinux project, typically between 10 and 14 Kb in size)GRLDR (part of the grub4dos project, typically around 250 Kb, but of which only the first 4 sectors, i.e. 2,048 byes are actually the "boot image"other "special crafted" bootloaders still in the few Kbytes range in sizeit is possible to have El-Torito No-emulation images that are either a whole (large) volume (hundreds of Mbytes in size) or a volume (still large) with prepended to it a loaderin passing by the extension to the El-Torito standard adding to it the "EF" type of boot image (which is normally represented as a very small FAT formatted volume containing just the \efi\boot\ folder and an efi executable, such as bootia32.efi, bootia64.efi or bootx64.efi) has been talked aboutit also came out that this "EF" no-emulation boot image can be a rather largish FAT formatted volumethe El-Torito standard does not include anywhere in boot catalog a field for the SIZE of such images (though it includes a field for "Size to be initially loaded")The discussion provided some ideas to make clearer the structure of these .iso's, and allow the user to have valid data about the size of these images and the possibility to "extract" them "correctly", i.e. in a way that these images can be re-used to create other images and or be mounted/accessed with other commonly uised tools. Isobuster (the nick with which the Author of the Isobuster tool has registered on MSFN) already made a series of changes to the tool and we are in the phase of experimenting the modified tool on several different .iso's to see how efficient and useful are these changes and/or to propose new, further changes (where needed), etc. jaclaz

What is the part that you didn't understand in: ? I will try again as: (if possible) never, NEVER, NEVER (meaning actually NEVER) use a Windows based flashing tool and ALWAYS ONLY use a DOS based one, when booted in a "clean" (no autoexec.bat, no config.sys, NOTHING loaded but pure DOS) MS-DOS or FreeDOS. jaclaz

"Normal" SATA, i.e. simply "SATA". The "inside" of the connector is a little less that 34 mm: and the "two notches" are on the sides of the space in the middle. If you are going to put a (heavy) 3.5" disk in that case, you NEED (IMHO) to find a way to fix it "safely", consider the idea of putting "spacers" between the disk and the case (without completely preventing air flow around it of course) jaclaz

You see the good thing of the UK ? If the issue was on your side of the pond, you would have likely had a much higher frequency 60 Hz buzz instead . jaclaz

Bingo , you cannot post the same question over and over. Earlier today you posted some 8 or 9 times this same question (most probably due to a connection or board issue), under two different thread titles, but now you have already an answer by ilko_t, try following this thread. Answer ilko_t's questions, DO NOT start new threads about the same issue, please. jaclaz

Anyway, maybe you don't really-really need to fork from several hundred bucks for buying the mentioned in the article (which is obviously some form of not-so-hidden advertisement/plug) "special" phones, JFYI: https://secupwn.github.io/Android-IMSI-Catcher-Detector/ (though this will only tell you if you are at risk of being intercepted by an IMSI catcher) jaclaz

Well, of course they *need* (like I do) to add all those u's that you insist on removing from common words, but it is actually a very little overhead, while replacing -ize with -ise does not of course later the length of messages, and when your English friends sends messages to you, the message would be actually shortened on-the-fly. Those are "revocation letter" items #1 and #2 in it's most widely reknown version: http://www.snopes.com/politics/soapbox/revocation.asp jaclaz

Don't forget to include among the possibilities: A bum Skype installation at your end. The intervention of any of the three or-more-letters US or UK Government agencies. A man-in-the middle kind of attack/sniffing/whatever by hacking groups steganographing LOLCAT images in your astronomical photos in order to avoid custom fees. .Seriously, it seems like a very "strange" and "preoccupying" (given the amount of files exchanged globally through SkyPe) issue. Which format are the images? I mean it is not that the service is attempting to decompress (for virus scanning or *whatever* reasons) the contents (or a local antivirus or something similar)? Is this behaviour "bidirectional" (i.e. it happens BOTH if you send or receive the image) AND it happens ONLY with this other user? jaclaz

@isobuster JFYI: Files on which bextract.cmd works fine (and latest posted Isobuster does not): Kav rescue disk 10 http://rescuedisk.kaspersky-labs.com/rescuedisk/updatable/kav_rescue_10.iso has seemingly a "eltorito.img" on sector 228 sized 25225 bytes Acronis Antimalware CD https://kb.acronis.com/content/18647 has ISOLUX.BIN on sector 228 92 11691 bytes Files on which bextract.cmd DOES NOT work (and Isobuister also *somehow* fails): 2OS 3.16 http://sourceforge.net/projects/meos/ http://sourceforge.net/projects/meos/files/binarys/3.16/ (isobuster gets it seemingly "wrong" in size as 2 Kb, AND it recognizes it as MagicIso bootsector, though it is seemingly an ISOLINUX) 2OS 8.10 http://sourceforge.net/projects/meos/ http://sourceforge.net/projects/meos/files/binarys/8.10/ (isobuster gets it seemingly "right" in size, 14 Kb, AND it recognizes it as MagicIso bootsector, AND it is seemingly a modified ISOLINUX, BUT isobuster extracts only the first 12 Kb) jaclaz

Sure Harkaz's contributions are noteworthy, interesting and useful :, the comment was only about the non-news nature of those "news" for MSFN members. I would add - as a side note - that part of the (unfortunate) decline of Windows XP may be due (besides the scare-mongering tactics by MS and friends) to "physiologic" reasons. I mean, a large part of the XP installed base is most probably "OEM" and "pre-installed" on "portables" (laptop and notebooks) manufactured before 2009 (the "year of 7") and those kind of devices tend to age (due to shock, wear and what not) faster than desktops and they rarely are as repairable or as upgradable as desktops. jaclaz

Unless of course a secret court, presided by an anonymous judge, issued a secret order authorizing another (not the FBI) three-or-more-letters government agency to place them. We must be scared of this new generation of hackers with unlimited funding that can place fake cell towers across the U.S.A. Snippets from the article: no further comment needed. jaclaz