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.php?/topic/400729-how-to-open-report-with-en
c1-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

 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
>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=
>

 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
--- NewsGate v1.0 gamma 2