30: summary:
. malware that spreads via usb devices
can infect other usb devices,
and the problem is not the os;
it is the hardware and usb standards
which expose the os to malware infection .
. Dragos Ruiu talks about a mac infection
which sounds like the one I got;
it prevented me from reinstalling the os;
and it started infecting my chromebook,
but the chrome os was able to clean it up .
. my 2005 ubuntu laptop was not so lucky .
. a laptop in my future that will likely do well
is one running the xen hypervisor,
hardened with the Qubes OS .
(see #Qubes #Xen vs Dragos Ruiu's #badBIOS).
11.5: co.self/dream: #badBIOS/usb infection is game-over:
. in this dream,
a guy seems caught with mouth open and head thrown back;
and, being colored flat black like hit by a death ray,
it reminded me of usb infection .
11.4: news.cyb/sec/#badBIOS:
arstechnica.com/security/2013/10/meet-badbios-...
Three years ago, security consultant Dragos RuiuDragos Ruiu 10.23:
was in his lab when he noticed something
highly unusual: his MacBook Air, on which he had
just installed a fresh copy of OS X,
spontaneously updated the firmware that helps it boot.
Stranger still, when Ruiu then tried to
boot the machine off a CD ROM, it refused.
. the malware is believed to be
transmitted through USB drives,
and infects the Basic Input/Output System (BIOS),
Unified Extensible Firmware Interface (UEFI),
and possibly other firmware standards .
. the malware can attack a wide variety of platforms,
escape common forms of detection,
and survive most attempts to eradicate it.
. simply plugging in a USB device from an infected system[30: -- suggesting you could fix your usb stick
into a clean one is sufficient to infect.
This was on a BSD system,
so this is definitely not a Windows issue.
- and it's a low level issue,
I didn't even mount the volume and it was infected.
Could this be an overflow
in the way bios id's the drive?
Infected systems seem to reprogram the
flash controllers on USB sticks
(and cd drives, more on that later)
to attack the system (bios?).
There are only like ten different kinds of flash controllers
used in all the different brands of memory sticks
and all of them are reprogrammable,
so writing a generic attack is totally feasible.
Coincidentally the only sites I've found with
flash controller reset software, are .ru sites,
and seem to 404 on infected systems.
by going to a .ru site,
and the malware tries to prevent such .]
The tell [consistent symptom of having this infection]erratasec.com 2013.10:
is still that #badBIOS systems refuse to boot CDs
(this is across all os's, including my Macs)
there are other more esoteric problems with
partition tables and devices on infected systems.
Also, USB cd drives are affected,
I've bricked a few plugging and unplugging them too fast
(presumably as they were being reflashed)
on infected systems.
Unsafely ejecting USB memory sticks
has also bricked them a few times
on #badBIOS systems for clean systems,
though mysteriously they are "fixed" and reset
by just simply replugging them into an infected system.
. malware can overwrite the BIOS flash memory,replies to Dragos Ruiu 10.23:
adding their own code that runs on startup.
. the malware theory Dragos proposes
has focused just on the BIOS flash memory,
but there are other places viral code can hide.
Each device in the computer has its own microprocessor,
sometimes called a "microcontroller".
Each microcontroller has its own
flash memory and "firmware",
most of which can themselves be updated.
Examples include:
trackpad, keyboard, battery, SD card reader,
camera, disk drive, bluetooth, wifi, Ethernet,
graphics processor, system agent, and CPU.
That last bit might surprise you,
but an Intel x86 CPU
at the heart of your computer itself
has an embedded microcontroller,
controlling such things as frequency
in order to conserve power.
While these devices seem diverse,
there are in fact only a few manufacturers
of microcontrollers and flash memory.
Thus, once a hacker has written viral code for one,
let's say the battery controller,
it's not too difficult to extend the code to
also infect the trackpad, for example.
A virus can overwrite any microcontroller flash memory
and stay resident in the system
despite complete wipes of the system,
even wiping the primary BIOS.
The upshot is this:
when a system gets infected by a virus,
the infection can likely become permanent,
being nearly impossible to completely remove .
There's just too many places code can hide,
and too many components that can interfere
with you trying to disinfect the system.
. unplugging a USB stick from an infected machine
and then plugging it into an uninfected machine
will transfer the virus.
This relies upon two important features of USB:
the first is that USB devices contain their own
microprocessor/firmware (of course),
and the second that drivers are buggy.
There are only a few popular vendors of
USB thumbdrive controllers.
There is a great website "http://flashboot.ru"
that documents all of them.
. they also have software to reprogram them
to emulate a CD-ROM drive,
making "read-only flash drives",
but you can also use this software to
download new firmware to the flash drives.
Thus, it's pretty straightforward for malware to
overwrite flash drive firmwares .
Once USB drive has hostile firmware,
it can now attack new machines when it's plugged in.
The reason is that software in Windows/Linux/Mac
that talks to USB devices
is inherently insecure.
They assume that all USB devices are friendly
rather than hostile,
and believe whatever these devices tell them.
This allows hostile devices to exploit vulnerabilities
in driver code.
For example, USB drivers are full of "buffer overflow" bugs.
Let's say that you have a buffer that's supposed to be
less than 16 bytes according to the specification,
but a hostile USB device gives you 100 bytes instead.
Driver writers don't check that sort of thing,
thus allowing a hostile USB device to
take control of the host system.
Edward J 2:59 AM:
I have been owned for 2 years now
[malware has "owned" is computer]
and went through 40 new Mac and PC computers.
I would take them back a few days after I bought them
because they were already hacked by then.
I actually got banned from returning things at Best Buy
due to abusing the policy!
http://wtfisthisapple.blogspot.com
http://hackfromhell.blogspot.com
Douglas Otis:
I ran into this issue several years ago.Dennis Roos:
Attempts to reflash the Bios
would cause the source media to be erased.
I had to use read-only media to reflash the bios
which was a PITA[pain].
It also refused to boot from optical media.
This was why I felt reflashing was in order.
The different BIOS manufactures all used
the same vulnerable compression code
where signature checks were bypassed
by giving the BIOS an evil logo to display.
So, this is finally happening?*:
It has been talked about for years ;)
[ pci rootkits, blackhat.com 2007 .pdf *]
In order to capture the traffic on the
USB bus that infects new devices,
have a look at Travis Goodspeed's work on
the GoodFET/FaceDancer board:
[ here is a summary of that .pdf,
providing some terminology used later:
a rootkit in the system bios via]-blackhat.com
the acpi (advanced config and power interface):
. the acpi tables within the bios
could be modified to contain malicious
aml (acpi machine language)
that allowed the root kit bootstrap code to
overwrite kernel code and data .
. intel secureFlash and phoenix trustedCore motherboards
prevent the system bios from being
overwritten with unsigned updates .
. the pci (peripheral component interconnect)
is a bus for attaching pci devices,
graphics cards, network cards, and storage controllers;
the north bridge is connecting
the host cpu bus to the root pci bus;
the south bridge connects the
root pci bus to the isa bus,
and also incorporates the interrupt controller,
the ide controller, the usb host controller
and the dma controller .
. pci speed limits impeded graphics performance,
so then the agp (accelerated graphics port) was created;
likewise, the pci express specification is even faster .
coresecurity.com`BIOS Rootkits:
Traditionally rootkit research has focused on accomplishingMichael Schuh:
persistence and stealthiness with software running at
the user or kernel level within the os;
The techniques used to run code undetected
have evolved over time ...
A potentially much more dangerous scenario
is that of malware that can effectively
avoid detection and removal because
it has stored itself on the computer's BIOS,
the firmware that runs during the boot process
prior to execution of the operating system itself.
Such malware would resist reinstallation of the os,
and even replacement of the hard disk ...
In 2009 Alfredo Ortega and Anibal Sacco
discovered a generic technique to
modify the BIOS of certain chipsets
so that they could insert homebrewed rootkit code.
The technique is applicable to any computer that supports
installation of BIOS updates that are
not digitally signed using cryptographically strong methods.
-- see Persistent BIOS infection .
Rutkowska showed it is possible toWhirIedPeas [and a reply]:
make the ACPI-Rootkit undetecteable.
wikipedia.org/wiki/Blue_Pill_(software)
it is even able to manipulate the
bios-settings and much more.
Malware can run at different layersFábio Olivé Nov 1:
on modern compute systems.
From top to bottom; Application level,
user-mode, kernel-mode, boot-sector,
firmware and finally microcode.
To understand the true significance of these levels,
a layperson would first need to understand
the process which occurs
every time their machines boot up:
Power is applied; the BIOS boot program runs;
it's job is to play any microcode updates into the CPU
and find the boot device;
the boot device runs it's boot-sector;
the boot-sector finds the kernel
and loads it into memory;
the kernel starts the first
user-mode process (init or smss);
initial user-mode process
starts up all the processes.
The lower you are in that chain of processes,
the easier it is to control/modify everything above.
[. he suggests the NSA likely has
a CPU microcode rootkit.]
BIOS is a type of firmware,
the most advanced type of firmware in most systems.
There are only a handful of companies in the world
who write these BIOS programs.
As far as resources, you have Phrack #66
which outlines how to create malicious VMware
and Award BIOS, the Maux firmware project,
and in 2009 there was that case of those used Dell servers
which had BIOS rootkits.
PC BIOS/firmware/SMM attacks:
"BIOS Chronomancy: Fixing the Core Root of Trust
for Measurement" By Butterworth et al. [blackhat 2013]
"Defeating Signed BIOS Enforcement" [Kallenberg et al.]
It was also their "Copernicus" BIOS inspection tool
that prompted this little wild goose chase
(even if experts eventually said
that his BIOS dump looks clean): [mitre.org]
The only common thing you'd haveThomas Spear Nov 1:
between all these OSes on modern machines
is ACPI. Neither OpenBSD or Linux
use the BIOS during normal operation,
except when ACPI and SMM take over
and preempt the OS.
So maybe a possible attack vector would be
ACPI dealing with the USB device before the
OS has a chance to interact with it,
the device exploits bugs in the ACPI
and installs SMM code that will preempt the OS
when it wants, and then hides the
exploit area of the device
so that you won't find anything.
Carlos Ferreira said "How in the world,Virus in acpi Monday, January 10, 2011:
can a simple query from the BIOS to the device,
re-write the BIOS itself? "
By living in the VGA or network firmware.
It can run on either of those CPUs
-- more likely the VGA
since we're already using CUDA et al
to do things like airsnort.
Does anyone know if the Northbridge or southbridge
of current motherboards is reprogrammable?
I believe on AMD systems one of the two is
integrated into the CPU along with the memory controller.
. theoretically, its possible for the malware to
create processes only within the GPU and video memory,
thereby avoiding detection from process lists.
-- being that Nvidia's CUDA and ATI's equivalent
are OS-agnostic, it's easy to see how this could
run across multiple OSs .
There are many Virtualization techs that do not require VT CPUS;19: @dragosr updates:
If you look at linux/mac projects there are many types,
the thing is that some use that tech to make virus.
M$ have many holes, adobe too,
a remote execution bug will allow code injection,
. they use cpu bugs too, they have many ways to get in.
from what I read they can virtualize with only
600k injected on the bios.
early example: Blue_Pill
. first thing,
your PC uses a simulated efi to boot....,
all your Windows installations use fake components,
fake drivers (all signed, they hack that too).
. here's a must read:
(root kit in acpi/ pic card) [blackhat 2007]
. they use acpi because of the irq
and that IRQ in Windows work as SYSTEM
so they own you, a look at your IRQ tables
and hardware will show it:
look for fake hardware Fireware/usb disabled in bios ...
dragosr 12 Nov Things I learned at PacSec:
8051 keyboard controller CPU core
is nearly universal across all
PC, Mac, Intel, AMD, Via... #badBIOS
dragosr 12 Nov
8051 kb controller firmware
is stored on reprogrammable serial EEPROM.
#badBIOS on Mac messed with
kb drivers, openbsd pckbc errors
xabean 12 Nov
.@dragosr if your #badbios is talking to
8051 MCUs and reflashing them (kbd ctlr),
that's the same MCU in Phison flash ctlrs.
dragosr 12 Nov
Interesting, 8051 cpu core phison flash controller
used in most popular SD cards too. #badBIOS
Akiba shops advertising it as sales feature
zumarek 13 Nov
@dragosr @newsycombinator
so is UEFI and AMT present on
all computers infected with #badBIOS (I think).
dragosr 13 Nov
@zumarek
nope some are old school award bios boxes, commel le564.
Waiting to get CLCC carrier and flash reader to extract.
dragosr 14 Nov
PacSec: Pierre Chiffier, EFI byte code could
easily be used to create hw independent malware (x86, arm...)
analysis complicated, no tools
dragosr 14 Nov
PacSec: Pierre Chiffier, most likely place to
store EFI byte code malware
is the fonts files.
dragosr 14 Nov
PacSec: MITRE folks will be putting out
advisories on multiple vulns in SMM
that enable corrupting BIOS and defeat reflashing.
dragosr 14 Nov
Read my last few tweets and
consider again how implausible or not
threats like #badBIOS are.
This industry faces clear, present threat.
30: @dragosr updates:
cynicalsecurity 14 Nov
.@dragosr I think the threat has been around
for a long time except not in mainstream.
Think PacSec 2008: no reactions to my talk...
dragosr 14 Nov
@cynicalsecurity wel maybe there was a reaction and development,
but we are just now noticing it and isolating :-)
dragosr 19 Nov
ACPI tools are crude, all I've found so far
are obsd ACPI dumpers. Still looking.
Need ACPI table disasm.
dragosr 19 Nov
And before anyone asks
I haven't ID'ed any #badBIOS ACPI stuff,
built ACPI less kernels as test,
not interesting data.
dragosr 19 Nov
ACPI hooks all kind of interesting spots across all OSes.
Tables allow full binary exec.
dragosr 20 Nov
It looks like one of the backup copies
#badBIOS keeps around for resiliency
is stored in pagefile.sys on windows systems.
clever/tricky
dragosr 21 Nov
One reason #badBIOS is difficult to detect is because
instead of modifying .exe's directly,
it applies patches to prefetch (.pf) files.
aionescu 21 Nov
@dragosr .pf files contain nothing but
timestamps, DLL names, and run counts.
Nothing to "patch".
What you're describing isn't possible.
dragosr 21 Nov
@aionescu heh,
let's look at those prefetch files
and prefetch functionality
a little deeper, i suggest :)
bellytales 21 Nov
@dragosr @aionescu
literally wrote the book on windows internals.
I think you might be misunderstanding
what .pf files do.
dragosr 21 Nov
@bellytales @aionescu ok,
I know how I would do it. ymmv :)
or maybe I'm wrong. but
seems pretty clear to me.
... and more importantly,
when I killed the pf files,
procmon started reporting info again :)...
for a short time :)
bellytales @bellytales 21 Nov
@dragosr @aionescu Of course, that's normal.
just like all of the other logs.
What you're infected with is called Microsoft Windows.
dragosr 21 Nov
@bellytales @aionescu because google update always
messes with dhcp and interface configurations?
cliffcheney 23 Nov
@dragosr How would I go about imaging a macbook pro firmware?
dragosr
Damn fine q. @cliffcheney "How would I go about
imaging a macbook pro firmware?"
copernicus doesn't run on macs.
zumarek 23 Nov
@dragosr @cliffcheney is this to restore or forensic ?
c7zero 23 Nov
@dragosr can help with that or run from Win bootable USB
snare 23 Nov
@dragosr @cliffcheney flashrom supports many chipsets.
I've ripped a few MBPs with it.
1147700 Nov 24
@snare @dragosr you must
not use chipset when paranoia dumping the BIOS/ME.
chipsets can and will hide sections.
use ext. reader instead.
@dragosr 24 Nov
@1147700 @snare everyone is pointing me at the xeltec 5000
as the programmer/reader to get
1147700 Nov 25
@dragosr @snare what are you trying to dump?
this is an expensive parallel dumper
... for SPI flashes as BIOS/ME
we used a Dediprog SF100, or an openbiosprog
- both in flashrom (where I d go and peek 4 more)
snare 25 Nov
@1147700 @dragosr I used a buspirate for offline dumping.
was a bit flaky, but did the job.
8 comments:
10.7: mis.cyb/ergo'kybd/double enter adds a bracket:
. occasionally in ko'edit,
my quick double enter keying
is also adding a "[",
which ko'edit turns into
"[
]" . I'm wondering if malware has somehow damaged the keyboard .
[8: shortly after this I would have a malware attack,
where it changed the permissions on all itunes
and caused a freeze . long time to repair permissions .]
10.11: mis.cyb/camera/
card is unwritable until reinsertion:
. I'm taking picts of the mac and that went fine,
then removed the card for use by chrome
(but not inserted in chrome yet)
then needed to take more picts
so reinserted the card,
and, the first shot showed the card was still working;
but for the 2nd shot it said something like
"cannot record: no mem card"
but when I reinserted the card it was fine .
. the only difference to that card
is that it was exposed to chrome earlier
which was exposed to an sd card
which was exposed to the cracked mac .
. that caused me some worry,
but the card is old too
and may need an intensive formatting
that looks for bad sectors .
12.13:
. I never had trouble with that card again;
and am now convinced the problem was from
malware malforming some file structures
in order to implement an attempt to
infect yet another card reader firmware .
10.15: mis.cyb/ergo'kybd/
sd card jammed chrome's access to kybd:
. some of the keys weren't getting to chrome,
I had just used the sneakernet sd card on the same usb,
and I needed to not only unplug the sd card or reader,
but also re-plug in the kybd .
backup logs for #badBIOS imac attacks
round#1
10.3: proj.cyb/backup/sd card copy is working:
. the opening of pdf's caused a malware
(either from mac pdf viewer or Vmware's
ubuntu linux firefox pdf viewer,
or from prior infection by sd card
from sharing with ubuntu linux laptop);
lucky to get mac restarted and updated .
[... but the malware was persistent,
and would be getting trickier ...]
. bak to 2nd sd card and use chrome
to see if the bak is actually readable: ok;
(but I didn't notice my latest log was zero'd).
mis.cyb/backup/my current log had been zero'd:
. last successful bak of it was 8:57 .
proj.cyb/backup/log is saved:
. bak to card, check on chrome .
4: proj.cyb/backup/got more recent bak of lost log:
. (mis.cyb/mac.vmware.xu/infected vm is still infecting wo net)
but trouble was worth it:
ko'edit did bak my log, and I got it back .
proj.cyb/backup/copied pim to external drive .
5: proj.cyb/backup/bak to usb40gb, and to dvd .
proj.cyb/backup/test dvd burn:
. the cdr opens and then books sparsebundle opens .
round#2:
7: pos.cyb/backup/should primary be on mac hd?:
( another crash and
wondering if I'll ever get back in?!
)
. consider if you need to use mac's recovery mode again,
will it be to restore or reinstall?
restore will eat what isn't saved .
. the current backup system
assumes the bak should be on 2 drives
and the bak should be auto'd by timemachine,
which is saving to an external partition,
so then the primary data is on
the same drive as vmware's dom0,
(the mac's internal drive)
but if dom0 keeps failing to
come back from reset,
then either you need to be repetitively
bugging Apple with os downloads
(how long can that go on?),
[... the malware would soon end that ...]
or your primary data should be
not on the dom0 drive,
and you should manually bak often to dom0,
in the very rare possibility
that the external data drive fails .
. if install fails then today's loss is not great
since there are baks an hour ago,
and I was mostly doing review .
7: proj.cyb/backup/able to bak log after crash:
. mac is restarting but slow,
bak log to card#2 .
proj.cyb/backup/sd card chk:
. bak sd card,
. the log I was reviewing was last saved at 926 .
round#3:
8: proj.cyb/backup/get log from downed vm:
. started the external drive on mac
and restarted the infected vm to get log .
proj.cyb/backup/bank info on card:
. turn mac's wifi off to unencrypt bank info
(no more wifi for mac intended after this).
copy bank essentials to card#2;
. I started to put bank entirety in card #1,
but [!] mis.cyb/mac/freeze with beachball after drive-write interruption .
. then I decided I could get that from the cd,
or from the data drive,
and I wouldn't need to get into mac again .
-- 10.8: imac replaced with chromebook
malware myth busting
10.9: proj.cyb/backup/the dvd's sparse bundle
can be safely opened from another mac:
. my backup after the malware attack
is not quite complete;
some of my bank data is in a mac crypt;
the easiest access to that
is on the usb data.drive;
but that might spread the infection
to the next mac I used for opening it;
however, a dvd opening would be safe, [13:
assuming that the mac is not infected,
and doesn't have ears for
unencrypted files in the trash .]
13: pos:
. I was wondering if I really needed
anything in that recent bank backup
that isn't also on last year's backup offsite .
[sic: bad assumption: ]
. I can safely use the offsite data.drive
on another mac without risk of infection .
[16: assuming it didn't infect the packaging,
like zip folders are known to be
vulnerable to malware .]
[12.13: sci:
. zip encryption can unleash malware,
so maybe mac encryption can do the same?
it appears that the #badBIOS malware's
essential path to root comes from
the OS's trust in usb firmware;
it may be that mac encryption is safe .
. the most important point is that
we don't know when this infection happened;
it could be that I have long been
backdoored and used in a botnet;
but, they didn't make themselves obvious
until one of the knowers of the backdoor
wanted to teach me a lesson about
not downloading so much of a pdf library
(I had downloaded over 2GB of pdf's).]
10.9: proj.cyb/backup/without infecting xuw:
. I'm assuming that my sd card is infected,
and I'm afraid of spreading the infection
to xuw (uniX Ubuntu Walkable(laptop)).
[sic: false assumption: ]
. you can load the card's data onto chromebook,
restart chromebook, then reformat the drive,
and then put the data back on that drive;
or find another card that is not exposed to mac .
128mb card is candidate .
[12.12:
. but later we see it's not the card,
but the card reader's firmware
that was spreading the infection;
so, it's quite likely that
the infection has been lurking
and the laptop was already infected .]
#badBIOS on ubuntu linux laptop (xuw):
10.13: mis.cyb/xuw/sd slot won't unmount:
. it seemed to ignore the unmount instruction,
so I powered down before removing card .
14: mis.cyb/xuw
/write from chrome shows on xuw as written tomorrow:
. I recently copied a log from chrome to sd card,
and looked at the file on xuw .
. malware wrote its time stamp as tomorrow?
it seems to be toying with victim, joking:
"you cut off my malware's internet connection;
would you at least give me the time of day?"
31: mis.cyb/xuw.file explorer
/says sd card has undeletables:
. the sd card was acting funny on xuw,
so reformat it on chrome;
I had earlier had chrome doing
a move of zip'd baks from sd card's
root folder to its bak.subfolder,
but on xuw they were still showing up like ghosts;
when I tried to move them on xuw,
it complained of errors that prevent such a mov .
[ later I would find that my text editor on xuw
has a file picker that gave a normal view .]
#badBIOS 2013.11 on xuw (ubuntu linux laptop)
11.1: mis.cyb/xuw/sd card doesn't look formatted:
. it continues to show the same garbage as before .
sci.cyb/xuw.ko'edit/file browser unaffected by undeletables problem:
. when I open my sd card after format,
the default file system viewer
shows undeletable files on the card;
but, when I choose the card from ko'edit's open file command,
the sd card looks just like it does when viewed by chrome:
everything is as expected .
2: mis.cyb/xuw/ko'edit crash? shutdown and restart xuw:
. it wanted to send a report home,
but I'm not doing any more internet with this laptop .
3: mis.cyb/xuw.ko'edit/bad save:
. during a cut&paste from log to another file,
ko'edit crashed and restored,
but it also lost the paste,
so I saved its restore as a bak,
and got into the previous save of the log;
it warned me that it could restore that one for me;
which I politely declined, and everything was saved .
news.cyb/xuw/has a file delete with no warning:
. depending on how you open a file,
there is more than one possible file browser,
and one of them has a delete that doesn't ask for a confirm .
4: sci.cyb/xuw/file manager with timestamp:
. thunar just says what day a file was updated;
if you want to know the exact time,
see menu/accessories/file manager .
. I tried to pin that to task bar,
but couldn't figure out how to do that in lubuntu .
9: mis.cyb/xuw.ko'edit/crashed:
. I was just thinking how fast I was navigating
and how ko'edit on this infected box
crashes when I do that,
then it happened right after I thought that !
16: mis.cyb/xuw.gnome image viewer/dicey rotation saves:
. after making jpg's with camera,
and getting no saved results from ristretto,
[@] mis.cyb/xuw.ristretto image viewer/not saving all my rotations
I was using gnome's viewer to do rotations;
you have to save each time;
but if you close the window,
it asks you if you want to save all edits;
and it seems to spend a bit of time saving
... still it seems not all were saved:
. the jpg view in finder showed they were rotated,
but then the actuals were not always rotated;
so, I'm wondering if my pdf-malware is also into jpg's,
controlling them as a prank or part of reinfection .
mis.cyb/xuw/error moving folder of jpg:
. I recently brought over jpg's from chrome
just to see if things were viewed properly
when I knew the jpegs were properly rotated
(wondered if it was some sort of file caching error
or something else the xuw malware might be doing)
and since I was done viewing them,
I moved them to a nearby bak.folder,
but it said there was an error,
and it couldn't finish the move .
. other file operations were doing ok,
so that I was able to bak my log .
19: mis.cyb/xuw/deleting from trash file raises a bunch of errors,
mis.cyb/xuw/denied access to mac drive:
. I was able to navigate several places,
but not to the pim folder where my primary data is;
whereas, chrome os would let me do it
(seems more resiliant against malware).
12.15: pol/purges/gemini/illuminati/
reprogrammable firmwares:
. one very good reason for using
software-reprogrammable firmwares
in usb devices and motherboards
is to cause malfunction after warranty expires
(and also to backdoor systems for NSA).
. when we recycle broken computer equipment
they could be refurbished simply by
reprogramming the firmware;
and that could generate extra income,
for wholesalers (and the CIA,
or whoever helped collect the parts
for covert refurbishing).
. the motherboards may need new models,
but all the usb devices
reuse the same microcontrollers .
Post a Comment