On Mon, 1/19/2026 8:52 AM, John C. wrote:
Paul wrote:
John C. wrote:
Microsoft desperately wants you to use WIA and not Twain drivers. To
that end, one of their updates made it so that my otherwise perfectly
functioning scanner didn't show up in most of my graphics programs
(Irfanview being a major exception.)
Google Gemini told me that if I simply configured my graphics programs
(eg. Adobe Photoshop Elements) to always run in Administrator mode, the
problem would go away.
This worked for me, so if any of you out there also experienced this
problem you might want to give it a try.
HTH.
That's not a preferred way to run applications in Ring 3.> That's not Safe Hex.
Sure, if I was running all -or just certain of- my applications in administrator mode it would be. However, I've been using Adobe Photoshop Elements 2.0 for literally decades and know that it's a really for real Adobe program, so I don't see the harm in running it in administrator mode.
Likewise, the installed driver for my Canon Canoscan 8400F flatbed
scanner and I didn't install it to run in administrator mode. If PSE 2
wants to do so though, I don't see any risk in that either.
Paul, can you please explain -explicitly- why running Adobe Photoshop Elements 2.0 in administrator mode would be unsafe hex?
Two image libraries were exploited, by specially crafted images.
(This has also happened with movie player codecs, and the problem
is serious enough from a probabilities perspective, that movie
players run in a container for safety. We cannot find all the
bugs in decoders, too many lines of code.)
I believe it was the JPEGLIB for sure, and the other one might
have been TIFFLIB. The companies using the FOSS libraries for
image processing, used those libraries *without reviewing them*.
When the management at the software companies reviewed the incident,
I think their reaction would be "yikes! We've been using code
without review???".
After the exploits happened in the field, the companies then
broke open the libraries they had been blindly compiling and
linking, to find that the basic "C hardening" had not been done.
There might be six C library routines, which a compiler will
remind you, "don't use X, use routine X2". Actually, the addition
of those warnings in the compiler, might be traceable to the
JPEGLIB incident. Add automation to the compiler, to warn people
about the weak sauce in the C standard library.
The incidents resulted in two things. It resulted in improvements
to the libraries in question. But it also made an addition to
the workflow happen, which is review of materials being imported
from FOSS-land for "freshness and quality". There are some
libraries, which were poorly commented and mysterious,
and for such libraries, that caused "extreme friction" in
the community regarding reuse of code. The code was of such
poor composition, that even experts in big companies were not
exactly sure what the intention of the code was. Opaque would
be the word.
That happened at work. There were two modules that were key to
some expensive hardware working correctly. Two designers had
worked on the modules. There were *no comments*. Assembler
level sequences (probably semaphores) were in there. After the
two individuals left, eventually someone attempted to open the
modules, and discovered the Chinese Puzzle inside. The management
response was to lock the modules so they could not be changed.
That's how "unsafe" working in there was.
*******
Adobe Photoshop Elements 2.0 *might* be pretty old. Could the
program have existed during the JPEGLIB exploit era ? Could
a new exploit be discovered by fuzzing ?
We don't know. What Safe Hex should we use ? The safest.
An exploit is pretty lame, if it requires a user to elevate.
That would be a weak sauce. Normally people would not even
bother to wait around for "UAC abusers" to happen along so
they can tip over their machine. Any exploit issued on purpose
these days, will be of the type to self-elevate, and it
comes with its own burglars toolkit to do necessary jobs.
For example, every malware issued, has the kit in it to
ruin all the Restore Points, which is why in an incident
where a machine is compromised, you just delete all the RP
without even thinking about it (as the repair person).
That's because, by experience, no malware worthy of the name,
enters Windows without injecting copies of itself into the RP.
There are actually SDK for malware, which have all the features
as tick boxes.
+-+
| | Infect all Restore Points
+_+
That's how automated and organized the Black Hats are.
If you read the articles about malware now, there can be
a detailed description of the progression once inside the
machine. But many of the articles also include the statement
"we don't know how the code got inside the machine". The attack
mechanism was shielded well enough, they cannot determine
which library got tipped over, whether it was elevated or not.
Again, the offense is winning at the stuff, the defenders not
so much.
When someone in another group, made comments showing their
machine was exploited, would I be surprised that Windows Defender
missed it ? Not surprised at all. WD is not known for heuristic
detection features, and any unique attack code is just going to
waltz right in ("signature not created for it yet"). While
we use and trust WD for the job, as people who view the scoreboard
for malware, the malware is winning and we are losing. We rate
WD as being "as good as the average product in the ecosystem".
This is why we take as few risks as is practicable.
The only reason I don't have malware on the machine, is because
no nation state picked me as a target. At the right time, they
will tip over *all* the machines, in unison... And it is unlikely
that even Safe Hex individuals will be shielded. I'm not being
"smug" about this shit. I know I'm defenseless as long as
the network cable is connected, and I move *any* files from
outside the machine, inside the machine.
Paul
--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)