A computer components & hardware forum. HardwareBanter

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.

Go Back   Home » HardwareBanter forum » General Hardware & Peripherals » Homebuilt PC's
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

Kaspersky Rescue Disk Report - can't see full paths



 
 
Thread Tools Display Modes
  #1  
Old June 5th 19, 04:21 PM posted to alt.comp.hardware.pc-homebuilt,alt.comp.anti-virus,alt.computer.security
Shadow[_2_]
external usenet poster
 
Posts: 195
Default 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  
Old June 5th 19, 10:26 PM posted to alt.comp.hardware.pc-homebuilt,alt.comp.anti-virus,alt.computer.security
Paul[_28_]
external usenet poster
 
Posts: 1,467
Default 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  
Old June 6th 19, 12:28 AM posted to alt.comp.hardware.pc-homebuilt,alt.comp.anti-virus,alt.computer.security
Shadow[_2_]
external usenet poster
 
Posts: 195
Default 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  
Old June 6th 19, 01:19 AM posted to alt.comp.hardware.pc-homebuilt,alt.comp.anti-virus,alt.computer.security
Apd
external usenet poster
 
Posts: 4
Default 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  
Old June 6th 19, 04:06 AM posted to alt.comp.hardware.pc-homebuilt,alt.comp.anti-virus,alt.computer.security
Shadow[_2_]
external usenet poster
 
Posts: 195
Default 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  
Old June 6th 19, 07:15 AM posted to alt.comp.hardware.pc-homebuilt,alt.comp.anti-virus,alt.computer.security
Paul[_28_]
external usenet poster
 
Posts: 1,467
Default 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  
Old June 6th 19, 10:46 AM posted to alt.comp.hardware.pc-homebuilt,alt.comp.anti-virus,alt.computer.security
Apd
external usenet poster
 
Posts: 4
Default 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  
Old June 6th 19, 10:48 AM posted to alt.comp.hardware.pc-homebuilt,alt.comp.anti-virus,alt.computer.security
Apd
external usenet poster
 
Posts: 4
Default 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  
Old June 7th 19, 08:11 AM posted to alt.comp.hardware.pc-homebuilt,alt.comp.anti-virus,alt.computer.security
David B.[_5_]
external usenet poster
 
Posts: 1
Default 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  
Old June 7th 19, 09:53 AM posted to alt.comp.hardware.pc-homebuilt,alt.comp.anti-virus,alt.computer.security
wasbit[_4_]
external usenet poster
 
Posts: 20
Default 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

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

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


All times are GMT +1. The time now is 11:01 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 HardwareBanter.
The comments are property of their posters.