Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.computer.security > #6129 > unrolled thread

Kaspersky Rescue Disk Report - can't see full paths

Back to article view | Back to alt.computer.security

Contents

  Kaspersky Rescue Disk Report - can't see full paths Shadow <Sh@dow.br> - 2019-06-05 12:21 -0300
    Re: Kaspersky Rescue Disk Report - can't see full paths Paul <nospam@needed.invalid> - 2019-06-05 17:26 -0400
      Re: Kaspersky Rescue Disk Report - can't see full paths Shadow <Sh@dow.br> - 2019-06-05 20:28 -0300
      Re: Kaspersky Rescue Disk Report - can't see full paths "Apd" <not@all.invalid> - 2019-06-06 01:19 +0100
        Re: Kaspersky Rescue Disk Report - can't see full paths Shadow <Sh@dow.br> - 2019-06-06 00:06 -0300
          Re: Kaspersky Rescue Disk Report - can't see full paths "Apd" <not@all.invalid> - 2019-06-06 10:46 +0100
            Re: Kaspersky Rescue Disk Report - can't see full paths "wasbit" <wasbitREMOVE@hotmail.com> - 2019-06-07 09:53 +0100
              Re: Kaspersky Rescue Disk Report - can't see full paths "Apd" <not@all.invalid> - 2019-06-07 10:43 +0100
              Re: Kaspersky Rescue Disk Report - can't see full paths Shadow <Sh@dow.br> - 2019-06-08 16:13 -0300
          Re: Kaspersky Rescue Disk Report - can't see full paths "David B." <BDonTJ@REMOVE.gmail.com> - 2019-06-07 08:11 +0100
        Re: Kaspersky Rescue Disk Report - can't see full paths Paul <nospam@needed.invalid> - 2019-06-06 02:15 -0400
          Re: Kaspersky Rescue Disk Report - can't see full paths "Apd" <not@all.invalid> - 2019-06-06 10:48 +0100

#6129 — 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

[toc] | [next] | [standalone]

#6130

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

[toc] | [prev] | [next] | [standalone]

#6131

On Wed, 05 Jun 2019 17:26:10 -0400, Paul <nospam@needed.invalid>
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-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

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

[toc] | [prev] | [next] | [standalone]

#6132

"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" />

[toc] | [prev] | [next] | [standalone]

#6133

On Thu, 6 Jun 2019 01:19:56 +0100, "Apd" <not@all.invalid> 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"
> 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 ?
	TIA
	[]'s

	PS TY too Paul
-- 
Don't be evil - Google 2004
We have a new policy  - Google 2012

[toc] | [prev] | [next] | [standalone]

#6135

"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"
>> 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.

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.

[toc] | [prev] | [next] | [standalone]

#6138

"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.

-- 
Regards
wasbit 

[toc] | [prev] | [next] | [standalone]

#6139

"wasbit" wrote:
> FileInsight - https://www.aldeid.com/wiki/FileInsight
>
> Download link works but I didn't open the zip file.

The download is hosted at mcafee.com so I wonder why they don't link
to it from their site. It's a Nullsoft installer package and the exe
within was last updated in 2009 which is the latest version I have.

[toc] | [prev] | [next] | [standalone]

#6140

On Fri, 7 Jun 2019 09:53:08 +0100, "wasbit" <wasbitREMOVE@hotmail.com>
wrote:

>"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.

	It's a Nullsoft installer. Just extract it with 7-Zip. And
delete the Virustotal plugin.
	;)
	No, haven't tried it yet.
	[]'s
-- 
Don't be evil - Google 2004
We have a new policy  - Google 2012

[toc] | [prev] | [next] | [standalone]

#6137

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!)

[toc] | [prev] | [next] | [standalone]

#6134

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"
>  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.

It required a little touch-up here and there though.

https://stackoverflow.com/questions/35734572/how-to-xor-a-file-buffer-in-c-and-output-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" Object="@Filesystem[65ba0377-31a7-52e4-8e5b-5415b3a73f12]/Downloads/EICARAntiVirusTestFile.com" Info="EICAR-Test-File" />
             <Event2 Action="Scan" Time="132042226096655583" Object="" Info="Finished" />
             <Event3 Action="Select action" Time="132042226311598366" Object="@Filesystem[65ba0377-31a7-52e4-8e5b-5415b3a73f12]/Downloads/EICARAntiVirusTestFile.com" Info="Quarantine" />
             <Event4 Action="Disinfection" Time="132042226311607367" Object="" Info="Started" />
             <Event5 Action="Quarantined" Time="132042226311647998" Object="@Filesystem[65ba0377-31a7-52e4-8e5b-5415b3a73f12]/Downloads/EICARAntiVirusTestFile.com" Info="" />
             <Event6 Action="Disinfection" Time="132042226311706514" Object="" Info="Finished" />
         </Block0>
     </EventBlocks>
</Report>

HTH,
     Paul

[toc] | [prev] | [next] | [standalone]

#6136

"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"
>>  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.

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.

[toc] | [prev] | [standalone]

Back to top | Article view | alt.computer.security

csiph-web