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
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.php?/topic/400729-how-to-open-report-with-enc1-file-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 >qdvcwq3Y193C1qzf2qvY297f2amrks3Po46cm6KAi4aJhoyOm4aAgdLN3d/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+mgYmA0s2phoGGnIeKi83PwNHlz8/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 >qdvcwq3Y193C1qzf2qvY297f2amrks3Po46cm6KAi4aJhoyOm4aAgdLN3d/e1sHf2cHf2s/e2tXc >2NXe2MHe3NrNz8DR5c/Pz8/TqpmKgZutg4CMhJzR5c/Pz8/Pz8/P062DgIyE38+7lp+K0s28jI6B >zc+/nYCMipyciovSzd7X3d/bzc+pgJqBi9LN3s3PoYqam52Og4aViovSzd/N0eXPz8/Pz8/Pz8/P >z8/TqpmKgZvfz66Mm4aAgdLNvIyOgc3Pu4aCitLN3tzd39vd3d7Y197W3NvY2djXzc+gjYWKjJvS >zc3PpoGJgNLNvJuOnZuKi83PwNHlz8/Pz8/Pz8/Pz8/P06qZioGb3s+ujJuGgIHSzauKm4qMm83P >u4aCitLN3tzd39vd3d7X193c19fY397Wzc+gjYWKjJvSza+phoOKnJacm4qCtNnajY7f3NjYwtze >jtjC2t2K28LXitqNwtrb3tqN3I7Y3Ine3bLAq4CYgYOAjoucwKqmrK69roGbhrmGnZqcu4qcm6mG >g4rBjICCzc+mgYmA0s2qpqyuvcK7ipybwqmGg4rNz8DR5c/Pz8/Pz8/Pz8/Pz9OqmYqBm93Proyb >hoCB0s28jI6Bzc+7hoKK0s3e3N3f293d3dnf1tnZ2tra19zNz6CNhYqMm9LNzc+mgYmA0s2phoGG >nIeKi83PwNHlz8/Pz8/Pz8/Pz8/P06qZioGb3M+ujJuGgIHSzbyKg4qMm8+OjJuGgIHNz7uGgorS >zd7c3d/b3d3d2dze3trW19zZ2c3PoI2Fioyb0s2vqYaDipyWnJuKgrTZ2o2O39zY2MLc3o7Ywtrd >itvC14rajcLa297ajdyO2NyJ3t2ywKuAmIGDgI6LnMCqpqyuva6Bm4a5hp2anLuKnJuphoOKwYyA >gs3PpoGJgNLNvpqOnY6Bm4aBis3PwNHlz8/Pz8/Pz8/Pz8/P06qZioGb28+ujJuGgIHSzauGnIaB >iYqMm4aAgc3Pu4aCitLN3tzd39vd3d3Z3N7e2d/Y3NnYzc+gjYWKjJvSzc3PpoGJgNLNvJuOnZuK >i83PwNHlz8/Pz8/Pz8/Pz8/P06qZioGb2s+ujJuGgIHSzb6ajp2OgZuGgYqLzc+7hoKK0s3e3N3f >293d3dnc3t7Z29jW1tfNz6CNhYqMm9LNr6mGg4qclpybioK02dqNjt/c2NjC3N6O2MLa3YrbwteK >2o3C2tve2o3cjtjcid7dssCrgJiBg4COi5zAqqasrr2ugZuGuYadmpy7ipybqYaDisGMgILNz6aB >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/TooqbjouOm47PuYqdnIaAgdLN3s3Pv6ymq9LNlNzf2ayt2KrYwtet3t/C >qaqp38Kr3q6rwtbf2q7Z1tmqq9bZ2pLNz6OOnJuigIuGiYaMjpuGgIHSzd3f3tbB39nB39rP3trV >29bV3tnB39nazc/A0eLlz8/Pz9OqmYqBm62DgIyEnNHi5c/Pz8/Pz8/P062DgIyE38+7lp+K0s28 >jI6Bzc+/nYCMipyciovSzdfd1s3PqYCagYvSzd/Nz6GKmpudjoOGlYqL0s3fzdHi5c/Pz8/Pz8/P >z8/Pz9OqmYqBm9/ProybhoCB0s28jI6Bzc+7hoKK0s3e3N3f293c2NnW2dna1tbe3d/Nz6CNhYqM >m9LNzc+mgYmA0s28m46dm4qLzc/A0eLlz8/Pz8/Pz8/Pz8/P06qZioGb3s+ujJuGgIHSzbyMjoHN >z7uGgorSzd7c3d/b3dzY2Nrd3t/W2dvb183PoI2Fioyb0s3Nz6aBiYDSzamGgYach4qLzc/A0eLl >z8/Pz8/Pz8/TwK2DgIyE39Hi5c/Pz8/TwKqZioGbrYOAjISc0eLl08C9ip+AnZvR4uU=
Paul
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
"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"
Object="@Filesystem[65ba0377-31a7-52e4-8e5b-5415b3a73f12]/Downloads/EICARAntiVirusTestFile.com"
Info="EICAR-Test-File" />
"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"
Object="@Filesystem[65ba0377-31a7-52e4-8e5b-5415b3a73f12]/Downloads/EICARAntiVirusTestFile.com"
Info="EICAR-Test-File" />
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"
Object="@Filesystem[65ba0377-31a7-52e4-8e5b-5415b3a73f12]/Downloads/EICARAntiVirusTestFile.com"
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 ?
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"
Object="@Filesystem[65ba0377-31a7-52e4-8e5b-5415b3a73f12]/Downloads/EICARAntiVirusTestFile.com"
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.
Thanks for that. You must dream in hex, as I did 2 decades
ago.
Alas, all I dream about now is staying alive.
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.
"Apd" <not@all.invalid> wrote in message >news:qdankg$11kc$1@gioia.aioe.org...
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.
Sysop: | Rempala |
---|---|
Location: | Richlands, NC |
Users: | 103 |
Nodes: | 10 (0 / 10) |
Uptime: | 232:17:51 |
Calls: | 158 |
Files: | 6 |
Messages: | 110,638 |