If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
Kaspersky Rescue Disk Report - can't see full paths
Ran Kaspersky Rescue Disk last night.
I usually just do a simple scan, (boot, start-up and system files), which takes a couple of minutes and always comes back clean. This time I included all my drives, and it detected 460 "objects" Almost all were false positives (old Nirlauncher zips, debugging tools etc) and detected as "not-a-virus". But it's impossible to see the full path of most of the "objects" in the "report" window (lines are far too long and truncated) that were flagged as "trojans", "heuristic" and "exploit", so I can't submit them to Jotti for a second opinion. This happened last time I ran a full scan, but KRD 2018 was new, and I thought it was just a bug. It produced an encrypted file in my "C" drive: report_2019.06.04_22.39.09.klr.enc1 The "reason" they give that "the report might contain sensitive information" is ludicrous, whoever runs the rescue disk has "root" and access to everything so why not a log? I get it that some random user shouldn't see the report, but not allow the admin to generate a text file with the FULL non truncated PATHS? Previous version of the KRD allowed you to save reports as TXT, this version no longer does. Looks I left my computer on all night for nothing. Is there a command-line switch/program I can use IN the Rescue Disk to save the reports as text so I can actually READ the fsc^%$ing thing? TIA []'s -- Don't be evil - Google 2004 We have a new policy - Google 2012 |
#2
|
|||
|
|||
Kaspersky Rescue Disk Report - can't see full paths
Shadow wrote:
Ran Kaspersky Rescue Disk last night. I usually just do a simple scan, (boot, start-up and system files), which takes a couple of minutes and always comes back clean. This time I included all my drives, and it detected 460 "objects" Almost all were false positives (old Nirlauncher zips, debugging tools etc) and detected as "not-a-virus". But it's impossible to see the full path of most of the "objects" in the "report" window (lines are far too long and truncated) that were flagged as "trojans", "heuristic" and "exploit", so I can't submit them to Jotti for a second opinion. This happened last time I ran a full scan, but KRD 2018 was new, and I thought it was just a bug. It produced an encrypted file in my "C" drive: report_2019.06.04_22.39.09.klr.enc1 The "reason" they give that "the report might contain sensitive information" is ludicrous, whoever runs the rescue disk has "root" and access to everything so why not a log? I get it that some random user shouldn't see the report, but not allow the admin to generate a text file with the FULL non truncated PATHS? Previous version of the KRD allowed you to save reports as TXT, this version no longer does. Looks I left my computer on all night for nothing. Is there a command-line switch/program I can use IN the Rescue Disk to save the reports as text so I can actually READ the fsc^%$ing thing? TIA []'s https://forum.kaspersky.com/index.ph...ile-extension/ Use "-dontcryptsupportinfo" command line parameter https://support.kaspersky.com/8537 It's good that someone has a sense of humor. No, that doesn't work. A second idea, moving the report file from KRD2018_Data\Reports to KVRT_Data\Reports [Offline ISO scan] [Online scanner EXE] doesn't work either. Discussing this in public, likely doesn't help the next person trying to crack it. ******* When you look at the klr.enc1 files, what's the first thing you notice ? There's a couple of groups of 0xCF hex bytes. "Real" encryption would have high entropy. This smells funny... CF CF CF CF CF CF CF CF CF CF CF CF One of the executables has crypto library names in it, but this could be an attempt to throw us off the trail. Lightweight compressors, like LZ4, some of them "hardly touch" strings and the file contents after compression can be "recognizable". This file doesn't allow that, but the entropy level is not so high that a "good" method has been used either. That's about all I can contribute at the moment. I'm no good at "decryption", even simple character substitution would stop me :-) ******* The following are three sample files. To decode, place the text into a text file, then base64 -d in.txt report_2019.06.05_15.15.24.klr.enc1 The "sum -s" command appears to be a byte summation mod 65536 or so. The second number is the block count. The first number, a sum, where the number rolls over and cannot be bigger than 65535 maybe. If your conversion (base64 -d) is successful, you should get the SHA1 back. If the SHA1 is wrong, using sum -s may hint at "how much you're off by". Name: report_2019.06.05_15.15.24.klr.enc1 krdnone.txt Size: 440 bytes SHA1: 3726FD25D4E88F589A7A80CA9F930D6CC5E8DCA0 sum -s (mod 65536?) 15066 1 072Kn4Cdm9Hlz8/Pz9OiipuOi46bjs+5ip2choCB0s3ezc+/rKar0s2UrdvYrKna39bC3K7crcLc qdvcwq3Y193C1qzf2qvY297f2amrks3Po46cm6KAi4aJhoyOm4 aAgdLN3d/e1sHf2cHf2s/e2tXe 1tXf3sHY3N7Nz8DR5c/Pz8/TqpmKgZutg4CMhJzR5c/Pz8/Pz8/P062DgIyE38+7lp+K0s28jI6B zc+/nYCMipyciovSzdnf2c3PqYCagYvSzd/Nz6GKmpudjoOGlYqL0s3fzdHlz8/Pz8/Pz8/Pz8/P 06qZioGb38+ujJuGgIHSzbyMjoHNz7uGgorSzd7c3d/b3d3e3NnY1t/d3d3Z2M3PoI2Fioyb0s3N z6aBiYDSzbybjp2biovNz8DR5c/Pz8/Pz8/Pz8/Pz9OqmYqBm97ProybhoCB0s28jI6Bzc+7hoKK 0s3e3N3f293d3tvY1t7a3tnc2N7Nz6CNhYqMm9LNzc+mgYmA0s 2phoGGnIeKi83PwNHlz8/Pz8/P z8/TwK2DgIyE39Hlz8/Pz9PAqpmKgZutg4CMhJzR5dPAvYqfgJ2b0eU= Name: report_2019.06.05_15.21.26.klr.enc1 krdeicar.txt Size: 1179 bytes SHA1: B6CAB5F1246F7723F9ECFCB220B64F48BD17462D sum -s (mod 65536?) 15827 3 072Kn4Cdm9Hlz8/Pz9OiipuOi46bjs+5ip2choCB0s3ezc+/rKar0s2UrdvYrKna39bC3K7crcLc qdvcwq3Y193C1qzf2qvY297f2amrks3Po46cm6KAi4aJhoyOm4 aAgdLN3d/e1sHf2cHf2s/e2tXc 2NXe2MHe3NrNz8DR5c/Pz8/TqpmKgZutg4CMhJzR5c/Pz8/Pz8/P062DgIyE38+7lp+K0s28jI6B zc+/nYCMipyciovSzd7X3d/bzc+pgJqBi9LN3s3PoYqam52Og4aViovSzd/N0eXPz8/Pz8/Pz8/P z8/TqpmKgZvfz66Mm4aAgdLNvIyOgc3Pu4aCitLN3tzd39vd3d7Y1 97W3NvY2djXzc+gjYWKjJvS zc3PpoGJgNLNvJuOnZuKi83PwNHlz8/Pz8/Pz8/Pz8/P06qZioGb3s+ujJuGgIHSzauKm4qMm83P u4aCitLN3tzd39vd3d7X193c19fY397Wzc+gjYWKjJvSza+pho OKnJacm4qCtNnajY7f3NjYwtze jtjC2t2K28LXitqNwtrb3tqN3I7Y3Ine3bLAq4CYgYOAjoucwK qmrK69roGbhrmGnZqcu4qcm6mG g4rBjICCzc+mgYmA0s2qpqyuvcK7ipybwqmGg4rNz8DR5c/Pz8/Pz8/Pz8/Pz9OqmYqBm93Proyb hoCB0s28jI6Bzc+7hoKK0s3e3N3f293d3dnf1tnZ2tra19zNz6 CNhYqMm9LNzc+mgYmA0s2phoGG nIeKi83PwNHlz8/Pz8/Pz8/Pz8/P06qZioGb3M+ujJuGgIHSzbyKg4qMm8+OjJuGgIHNz7uGgorS zd7c3d/b3d3d2dze3trW19zZ2c3PoI2Fioyb0s2vqYaDipyWnJuKgrTZ2 o2O39zY2MLc3o7Ywtrd itvC14rajcLa297ajdyO2NyJ3t2ywKuAmIGDgI6LnMCqpqyuva 6Bm4a5hp2anLuKnJuphoOKwYyA gs3PpoGJgNLNvpqOnY6Bm4aBis3PwNHlz8/Pz8/Pz8/Pz8/P06qZioGb28+ujJuGgIHSzauGnIaB iYqMm4aAgc3Pu4aCitLN3tzd39vd3d3Z3N7e2d/Y3NnYzc+gjYWKjJvSzc3PpoGJgNLNvJuOnZuK i83PwNHlz8/Pz8/Pz8/Pz8/P06qZioGb2s+ujJuGgIHSzb6ajp2OgZuGgYqLzc+7hoKK0s3e3 N3f 293d3dnc3t7Z29jW1tfNz6CNhYqMm9LNr6mGg4qclpybioK02d qNjt/c2NjC3N6O2MLa3YrbwteK 2o3C2tve2o3cjtjcid7dssCrgJiBg4COi5zAqqasrr2ugZuGuY admpy7ipybqYaDisGMgILNz6aB iYDSzc3PwNHlz8/Pz8/Pz8/Pz8/P06qZioGb2c+ujJuGgIHSzauGnIaBiYqMm4aAgc3Pu4aCitLN 3tzd39vd3d3Z3N7e2N/Z2t7bzc+gjYWKjJvSzc3PpoGJgNLNqYaBhpyHiovNz8DR5c/Pz8/Pz8/P 08Ctg4CMhN/R5c/Pz8/TwKqZioGbrYOAjISc0eXTwL2Kn4Cdm9Hl Name: report_20190605_154715.klr.enc1 kvrtnone.txt Size: 449 bytes SHA1: F1C474508087B7971454DF089B93CE8E13AE4D1D sum -s (mod 65536?) 16956 1 072Kn4Cdm9Hi5c/Pz8/TooqbjouOm47PuYqdnIaAgdLN3s3Pv6ymq9LNlNzf2ayt2KrYw tet3t/C qaqp38Kr3q6rwtbf2q7Z1tmqq9bZ2pLNz6OOnJuigIuGiYaMjp uGgIHSzd3f3tbB39nB39rP3trV 29bV3tnB39nazc/A0eLlz8/Pz9OqmYqBm62DgIyEnNHi5c/Pz8/Pz8/P062DgIyE38+7lp+K0s28 jI6Bzc+/nYCMipyciovSzdfd1s3PqYCagYvSzd/Nz6GKmpudjoOGlYqL0s3fzdHi5c/Pz8/Pz8/P z8/Pz9OqmYqBm9/ProybhoCB0s28jI6Bzc+7hoKK0s3e3N3f293c2NnW2dna1tbe3 d/Nz6CNhYqM m9LNzc+mgYmA0s28m46dm4qLzc/A0eLlz8/Pz8/Pz8/Pz8/P06qZioGb3s+ujJuGgIHSzbyMjoHN z7uGgorSzd7c3d/b3dzY2Nrd3t/W2dvb183PoI2Fioyb0s3Nz6aBiYDSzamGgYach4qLzc/A0eLl z8/Pz8/Pz8/TwK2DgIyE39Hi5c/Pz8/TwKqZioGbrYOAjISc0eLl08C9ip+AnZvR4uU= Paul |
#3
|
|||
|
|||
Kaspersky Rescue Disk Report - can't see full paths
On Wed, 05 Jun 2019 17:26:10 -0400, Paul
wrote: Shadow wrote: Ran Kaspersky Rescue Disk last night. I usually just do a simple scan, (boot, start-up and system files), which takes a couple of minutes and always comes back clean. This time I included all my drives, and it detected 460 "objects" Almost all were false positives (old Nirlauncher zips, debugging tools etc) and detected as "not-a-virus". But it's impossible to see the full path of most of the "objects" in the "report" window (lines are far too long and truncated) that were flagged as "trojans", "heuristic" and "exploit", so I can't submit them to Jotti for a second opinion. This happened last time I ran a full scan, but KRD 2018 was new, and I thought it was just a bug. It produced an encrypted file in my "C" drive: report_2019.06.04_22.39.09.klr.enc1 The "reason" they give that "the report might contain sensitive information" is ludicrous, whoever runs the rescue disk has "root" and access to everything so why not a log? I get it that some random user shouldn't see the report, but not allow the admin to generate a text file with the FULL non truncated PATHS? Previous version of the KRD allowed you to save reports as TXT, this version no longer does. Looks I left my computer on all night for nothing. Is there a command-line switch/program I can use IN the Rescue Disk to save the reports as text so I can actually READ the fsc^%$ing thing? TIA []'s https://forum.kaspersky.com/index.ph...ile-extension/ Use "-dontcryptsupportinfo" command line parameter https://support.kaspersky.com/8537 It's good that someone has a sense of humor. No, that doesn't work. A second idea, moving the report file from KRD2018_Data\Reports to KVRT_Data\Reports [Offline ISO scan] [Online scanner EXE] doesn't work either. Discussing this in public, likely doesn't help the next person trying to crack it. ******* When you look at the klr.enc1 files, what's the first thing you notice ? There's a couple of groups of 0xCF hex bytes. "Real" encryption would have high entropy. This smells funny... CF CF CF CF CF CF CF CF CF CF CF CF Yes, the number of "CF CF CF CF CF CF CF CF CF CF CF CF"is roughly the same number of "objects detected". I didn't spot that. You've got good eyes. One of the executables has crypto library names in it, but this could be an attempt to throw us off the trail. Lightweight compressors, like LZ4, some of them "hardly touch" strings and the file contents after compression can be "recognizable". This file doesn't allow that, but the entropy level is not so high that a "good" method has been used either. That's about all I can contribute at the moment. I'm no good at "decryption", even simple character substitution would stop me :-) ******* The following are three sample files. To decode, place the text into a text file, then base64 -d in.txt report_2019.06.05_15.15.24.klr.enc1 The "sum -s" command appears to be a byte summation mod 65536 or so. The second number is the block count. The first number, a sum, where the number rolls over and cannot be bigger than 65535 maybe. If your conversion (base64 -d) is successful, you should get the SHA1 back. If the SHA1 is wrong, using sum -s may hint at "how much you're off by". Name: report_2019.06.05_15.15.24.klr.enc1 krdnone.txt Size: 440 bytes SHA1: 3726FD25D4E88F589A7A80CA9F930D6CC5E8DCA0 sum -s (mod 65536?) 15066 1 072Kn4Cdm9Hlz8/Pz9OiipuOi46bjs+5ip2choCB0s3ezc+/rKar0s2UrdvYrKna39bC3K7crcLc qdvcwq3Y193C1qzf2qvY297f2amrks3Po46cm6KAi4aJhoyOm 4aAgdLN3d/e1sHf2cHf2s/e2tXe 1tXf3sHY3N7Nz8DR5c/Pz8/TqpmKgZutg4CMhJzR5c/Pz8/Pz8/P062DgIyE38+7lp+K0s28jI6B zc+/nYCMipyciovSzdnf2c3PqYCagYvSzd/Nz6GKmpudjoOGlYqL0s3fzdHlz8/Pz8/Pz8/Pz8/P 06qZioGb38+ujJuGgIHSzbyMjoHNz7uGgorSzd7c3d/b3d3e3NnY1t/d3d3Z2M3PoI2Fioyb0s3N z6aBiYDSzbybjp2biovNz8DR5c/Pz8/Pz8/Pz8/Pz9OqmYqBm97ProybhoCB0s28jI6Bzc+7hoKK 0s3e3N3f293d3tvY1t7a3tnc2N7Nz6CNhYqMm9LNzc+mgYmA0 s2phoGGnIeKi83PwNHlz8/Pz8/P z8/TwK2DgIyE39Hlz8/Pz9PAqpmKgZutg4CMhJzR5dPAvYqfgJ2b0eU= Name: report_2019.06.05_15.21.26.klr.enc1 krdeicar.txt Size: 1179 bytes SHA1: B6CAB5F1246F7723F9ECFCB220B64F48BD17462D sum -s (mod 65536?) 15827 3 072Kn4Cdm9Hlz8/Pz9OiipuOi46bjs+5ip2choCB0s3ezc+/rKar0s2UrdvYrKna39bC3K7crcLc qdvcwq3Y193C1qzf2qvY297f2amrks3Po46cm6KAi4aJhoyOm 4aAgdLN3d/e1sHf2cHf2s/e2tXc 2NXe2MHe3NrNz8DR5c/Pz8/TqpmKgZutg4CMhJzR5c/Pz8/Pz8/P062DgIyE38+7lp+K0s28jI6B zc+/nYCMipyciovSzd7X3d/bzc+pgJqBi9LN3s3PoYqam52Og4aViovSzd/N0eXPz8/Pz8/Pz8/P z8/TqpmKgZvfz66Mm4aAgdLNvIyOgc3Pu4aCitLN3tzd39vd3d7Y1 97W3NvY2djXzc+gjYWKjJvS zc3PpoGJgNLNvJuOnZuKi83PwNHlz8/Pz8/Pz8/Pz8/P06qZioGb3s+ujJuGgIHSzauKm4qMm83P u4aCitLN3tzd39vd3d7X193c19fY397Wzc+gjYWKjJvSza+ph oOKnJacm4qCtNnajY7f3NjYwtze jtjC2t2K28LXitqNwtrb3tqN3I7Y3Ine3bLAq4CYgYOAjoucw KqmrK69roGbhrmGnZqcu4qcm6mG g4rBjICCzc+mgYmA0s2qpqyuvcK7ipybwqmGg4rNz8DR5c/Pz8/Pz8/Pz8/Pz9OqmYqBm93Proyb hoCB0s28jI6Bzc+7hoKK0s3e3N3f293d3dnf1tnZ2tra19zNz 6CNhYqMm9LNzc+mgYmA0s2phoGG nIeKi83PwNHlz8/Pz8/Pz8/Pz8/P06qZioGb3M+ujJuGgIHSzbyKg4qMm8+OjJuGgIHNz7uGgorS zd7c3d/b3d3d2dze3trW19zZ2c3PoI2Fioyb0s2vqYaDipyWnJuKgrTZ2 o2O39zY2MLc3o7Ywtrd itvC14rajcLa297ajdyO2NyJ3t2ywKuAmIGDgI6LnMCqpqyuv a6Bm4a5hp2anLuKnJuphoOKwYyA gs3PpoGJgNLNvpqOnY6Bm4aBis3PwNHlz8/Pz8/Pz8/Pz8/P06qZioGb28+ujJuGgIHSzauGnIaB iYqMm4aAgc3Pu4aCitLN3tzd39vd3d3Z3N7e2d/Y3NnYzc+gjYWKjJvSzc3PpoGJgNLNvJuOnZuK i83PwNHlz8/Pz8/Pz8/Pz8/P06qZioGb2s+ujJuGgIHSzb6ajp2OgZuGgYqLzc+7hoKK0s3e3 N3f 293d3dnc3t7Z29jW1tfNz6CNhYqMm9LNr6mGg4qclpybioK02 dqNjt/c2NjC3N6O2MLa3YrbwteK 2o3C2tve2o3cjtjcid7dssCrgJiBg4COi5zAqqasrr2ugZuGu Yadmpy7ipybqYaDisGMgILNz6aB iYDSzc3PwNHlz8/Pz8/Pz8/Pz8/P06qZioGb2c+ujJuGgIHSzauGnIaBiYqMm4aAgc3Pu4aCitLN 3tzd39vd3d3Z3N7e2N/Z2t7bzc+gjYWKjJvSzc3PpoGJgNLNqYaBhpyHiovNz8DR5c/Pz8/Pz8/P 08Ctg4CMhN/R5c/Pz8/TwKqZioGbrYOAjISc0eXTwL2Kn4Cdm9Hl Name: report_20190605_154715.klr.enc1 kvrtnone.txt Size: 449 bytes SHA1: F1C474508087B7971454DF089B93CE8E13AE4D1D sum -s (mod 65536?) 16956 1 072Kn4Cdm9Hi5c/Pz8/TooqbjouOm47PuYqdnIaAgdLN3s3Pv6ymq9LNlNzf2ayt2KrYw tet3t/C qaqp38Kr3q6rwtbf2q7Z1tmqq9bZ2pLNz6OOnJuigIuGiYaMj puGgIHSzd3f3tbB39nB39rP3trV 29bV3tnB39nazc/A0eLlz8/Pz9OqmYqBm62DgIyEnNHi5c/Pz8/Pz8/P062DgIyE38+7lp+K0s28 jI6Bzc+/nYCMipyciovSzdfd1s3PqYCagYvSzd/Nz6GKmpudjoOGlYqL0s3fzdHi5c/Pz8/Pz8/P z8/Pz9OqmYqBm9/ProybhoCB0s28jI6Bzc+7hoKK0s3e3N3f293c2NnW2dna1tbe3 d/Nz6CNhYqM m9LNzc+mgYmA0s28m46dm4qLzc/A0eLlz8/Pz8/Pz8/Pz8/P06qZioGb3s+ujJuGgIHSzbyMjoHN z7uGgorSzd7c3d/b3dzY2Nrd3t/W2dvb183PoI2Fioyb0s3Nz6aBiYDSzamGgYach4qLzc/A0eLl z8/Pz8/Pz8/TwK2DgIyE39Hi5c/Pz8/TwKqZioGbrYOAjISc0eLl08C9ip+AnZvR4uU= You lost me there. What's to prevent them from doing a simple XOR with a random string of HEX on each line of the report before the encoding ? What if "CF CF CF CF CF CF CF CF CF CF CF CF" is just a marker for EOL ? Too many variables. Still, it's a ****ty way to present a report. Truncated PATHS so you can't see the name of the "suspicious" executables. Whoever is running the scan should be able to print a report. They could use the machine_D and boot_time to make it printable only once, only by the admin that ran the scan. If a third party boots, it's no longer valid. OTOH, it must be possible to unencrypt it, or there would be no point in submitting the report to Kaspersky for analysis. Paul Thanks for the try. Where are my CORE "friends" when I need them ? []'s -- Don't be evil - Google 2004 We have a new policy - Google 2012 |
#4
|
|||
|
|||
Kaspersky Rescue Disk Report - can't see full paths
"Paul" wrote:
When you look at the klr.enc1 files, what's the first thing you notice ? There's a couple of groups of 0xCF hex bytes. "Real" encryption would have high entropy. This smells funny... CF CF CF CF CF CF CF CF CF CF CF CF It smells like spaces! XOR the base64 with 0xEF and you have plain text with a single linefeed terminating each line. It's an XML report. Here's a line from your second example, krdeicar.txt (wrapped for ease of reading): Event1 Action="Detect" Time="132042218823887019" " Info="EICAR-Test-File" / |
#5
|
|||
|
|||
Kaspersky Rescue Disk Report - can't see full paths
On Thu, 6 Jun 2019 01:19:56 +0100, "Apd" wrote:
"Paul" wrote: When you look at the klr.enc1 files, what's the first thing you notice ? There's a couple of groups of 0xCF hex bytes. "Real" encryption would have high entropy. This smells funny... CF CF CF CF CF CF CF CF CF CF CF CF It smells like spaces! XOR the base64 with 0xEF and you have plain text with a single linefeed terminating each line. It's an XML report. Here's a line from your second example, krdeicar.txt (wrapped for ease of reading): Event1 Action="Detect" Time="132042218823887019" " Info="EICAR-Test-File" / Thanks for that. You must dream in hex, as I did 2 decades ago. Alas, all I dream about now is staying alive. Simple XORing. Who would have guessed? Too hard for me to figure out without your help. I will now write a little program in free Pascal or maybe 16 bit assembler to automate the process, unless you can recommend freeware (no online datamining stuff) that does it automatically ? TIA []'s PS TY too Paul -- Don't be evil - Google 2004 We have a new policy - Google 2012 |
#6
|
|||
|
|||
Kaspersky Rescue Disk Report - can't see full paths
Apd wrote:
"Paul" wrote: When you look at the klr.enc1 files, what's the first thing you notice ? There's a couple of groups of 0xCF hex bytes. "Real" encryption would have high entropy. This smells funny... CF CF CF CF CF CF CF CF CF CF CF CF It smells like spaces! XOR the base64 with 0xEF and you have plain text with a single linefeed terminating each line. It's an XML report. Here's a line from your second example, krdeicar.txt (wrapped for ease of reading): Event1 Action="Detect" Time="132042218823887019" " Info="EICAR-Test-File" / Yup. Even when the problem switched from "encryption" to "encoding", I still couldn't see it. And I've had trouble spotting XOR() related patterns before too. It's a disease. ******* I tried to implement the function in gawk, but the conversion from substr() to number insisted on doing the wrong thing when the msb of a character is set. So I had to punt and use C instead. For which, somebody already wrote our program for us. Just change the XORBYTE constant, and it's ready to compile. It required a little touch-up here and there though. https://stackoverflow.com/questions/...-to-a-new-file #include stdio.h #include string.h #include errno.h /* gcc -o xorfile.exe xorfile.c */ int main(int argc, char *argv[]) { FILE *fpi, *fpo; int c; if (argc != 3) { fprintf(stderr, "usage: xorfile input_file output_file\n"); return -1 ; } if ((fpi = fopen(argv[1], "rb")) == NULL) { fprintf(stderr,"cannot open input file %s\n", argv[1]); return 1; } if ((fpo = fopen(argv[2], "wb")) == NULL) { fprintf(stderr,"cannot open output file %s\n", argv[2]); fclose(fpi); return 2; } while ( (c = getc(fpi)) != EOF ) { if (c == (0x0a ^ 0xEF)) putc( 0x0d, fpo ); /* convert LF to CR LF */ putc(c ^ 0xEF, fpo); } fclose(fpi); fclose(fpo); return 0; } In MinGW, for example gcc -o xorfile.exe xorfile.c xorfile report_2019.06.05_15.15.24.klr.enc1 readable.txt Looks like this. At first, it had the squares in it, because the line endings weren't the best. So I quickly bodged in enough of a fix so you wouldn't need Wordpad to read it. Report Metadata Version="1" PCID="{B47CF509-3A3B-3F43-B782-9C05D74106FD}" LastModification="2019.06.05 15:37:17.135" / EventBlocks Block0 Type="Scan" Processed="18204" Found="1" Neutralized="0" Event0 Action="Scan" Time="132042217819347678" Object="" Info="Started" / Event1 Action="Detect" Time="132042218823887019" " Info="EICAR-Test-File" / Event2 Action="Scan" Time="132042226096655583" Object="" Info="Finished" / Event3 Action="Select action" Time="132042226311598366" " Info="Quarantine" / Event4 Action="Disinfection" Time="132042226311607367" Object="" Info="Started" / Event5 Action="Quarantined" Time="132042226311647998" " Info="" / Event6 Action="Disinfection" Time="132042226311706514" Object="" Info="Finished" / /Block0 /EventBlocks /Report HTH, Paul |
#7
|
|||
|
|||
Kaspersky Rescue Disk Report - can't see full paths
"Shadow" wrote:
On Thu, 6 Jun 2019 01:19:56 +0100, "Apd" wrote: XOR the base64 with 0xEF and you have plain text with a single linefeed terminating each line. It's an XML report. Here's a line from your second example, krdeicar.txt (wrapped for ease of reading): Event1 Action="Detect" Time="132042218823887019" " Info="EICAR-Test-File" / Thanks for that. You must dream in hex, as I did 2 decades ago. Alas, all I dream about now is staying alive. I know what you mean. Simple XORing. Who would have guessed? A few years of malware analysis (and hex dreaming!) has got me used to seeing those kind of patterns. Too hard for me to figure out without your help. I will now write a little program in free Pascal or maybe 16 bit assembler to automate the process, unless you can recommend freeware (no online datamining stuff) that does it automatically ? McAfee made a Windows GUI tool called FileInsight which could do base64 and XOR decode among other things but I can't find it on their website now. I see Paul has posted some C code which does the job and is similar to one of the several utilities I wrote myself for such things. |
#8
|
|||
|
|||
Kaspersky Rescue Disk Report - can't see full paths
"Paul" wrote:
Apd wrote: "Paul" wrote: This smells funny... CF CF CF CF CF CF CF CF CF CF CF CF It smells like spaces! XOR the base64 with 0xEF and you have plain text with a single linefeed terminating each line. It's an XML report. Here's a line from your second example, krdeicar.txt (wrapped for ease of reading): Event1 Action="Detect" Time="132042218823887019" " Info="EICAR-Test-File" / Yup. Even when the problem switched from "encryption" to "encoding", I still couldn't see it. And I've had trouble spotting XOR() related patterns before too. It's a disease. Often when you see the high bit set in every byte in data which has a pattern is a clue that there is XOR present. A simple guess as to what might be a character sequence, like the spaces in this example, gives you the key. I tried to implement the function in gawk, but the conversion from substr() to number insisted on doing the wrong thing when the msb of a character is set. So I had to punt and use C instead. For which, somebody already wrote our program for us. Just change the XORBYTE constant, and it's ready to compile. My own code is much the same but I also pass the XOR constant as a command line argument. I pass it as a variable (even) length hex string since sometimes more than one byte is used in the key. The code is a little more involved in checking for valid hex, etc. |
#9
|
|||
|
|||
Kaspersky Rescue Disk Report - can't see full paths
On 06/06/2019 04:06, Shadow wrote:
Thanks for that. You must dream in hex, as I did 2 decades ago. Sounds like you weren't REALLY a medical doctor after all! Alas, all I dream about now is staying alive. You won't. https://en.wikipedia.org/wiki/Death_Cafe Read and learn! -- (And don't mess with the Russians!) |
#10
|
|||
|
|||
Kaspersky Rescue Disk Report - can't see full paths
"Apd" wrote in message
... On Thu, 6 Jun 2019 01:19:56 +0100, "Apd" wrote: snip McAfee made a Windows GUI tool called FileInsight which could do base64 and XOR decode among other things but I can't find it on their website now. I see Paul has posted some C code which does the job and is similar to one of the several utilities I wrote myself for such things. FileInsight - https://www.aldeid.com/wiki/FileInsight Download link works but I didn't open the zip file. -- Regards wasbit |
|
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
kaspersky rescue disk | John B. Smith | Homebuilt PC's | 20 | June 3rd 18 04:40 PM |
Kaspersky's Rescue Disk refuses to update | John B. Smith | Homebuilt PC's | 3 | September 3rd 16 06:08 PM |
Veritas DMP paths versus native OS paths on Linux | [email protected] | Storage & Hardrives | 1 | August 7th 08 03:30 PM |
Skybuck's Dream PC for 2006 Full Report, Posting 1 | SteveH | Homebuilt PC's | 0 | May 6th 06 04:36 PM |
Skybuck's Dream PC for 2006 Full Report, Posting 1 | SteveH | Homebuilt PC's | 0 | May 6th 06 11:32 AM |