WARNING - WinUAE backdoor!

[Piru]

SFSSalv failing and VirusZ reporting modified vectors is probably no way connected to this.

However, UAE is wide open to malware, I spotted this years ago. In fact, the host system filesystem is wide open for access from within the emulation, too. So "amiga" apps could well plant x86 files to host system.

Anyway, if you want this thing to be analysed, just mail it to me.


UPDATE:

another strange occurance in SYS: caught my eye. It is a binary called uae_rcli, the size is 8956 bytes. I'm presume it can be used to open a remote connection to a UAE-System,

uae_rcli is standard part of UAE. uae_rcli.c

It could still be abused, naturally. But as of itself it isn't viral or backdoor.

[Piru]

Don't bother with uae_rcli. It's just compile of the source code I posted before.

To me it looks like your system is infected by either spyware/adware or virus, and I seriously doubt WinUAE has anything to do with it.

I recommond you scan your system with good AV (if you don't have any, try for example AntiVir), Ad-Aware and Spybot.

[Piru]

I've also noticed that I can run processes in the background in UNIX/Linux style, i.e. using & instead of RUN . My original OS3.1 does not mention that.

That's probably because your OS 3.1 manual doesn't cover AmigaOS 3.9 shell features.


Anyway, looking at that snoopdos log. Where is dos/LoadSeg debug?

It does read the file in LoadSeg it seems

4] Shell Process #FINDINPUT 4156B17, 412AD52, 4129D55 HD0 OK
[4] Shell Process #READ 1055B028, 1059C240, 400 HD0 OK
[4] Shell Process #READ 1055B028, 1059CEC4, 5978 HD0 OK
[4] Shell Process #READ 1055B028, 1059C240, 400 HD0 OK
[4] Shell Process #READ 1055B028, 105A2B7C, 2C0 HD0 OK
[4] Shell Process #READ 1055B028, 1059C240, 400 HD0 OK
[4] Shell Process #READ 1055B028, 1059C240, 400 HD0 OK
[4] Shell Process #END 1055B028 HD0 OK

That's LoadSeg reading the executable. But... does it return proper seglist? For that we need dos/LoadSeg enabled in snoopdos.

It could be the executable is corrupt and thus LoadSeg fails to load it.

[EDIT] actually... It does load it ok.

[4] sfssalv *Lock PROGDIR: Read OK
[4] sfssalv #LOC_OBJECT 4156C0A, 416CF67, FFFFFFFE HD0 OK
[4] sfssalv *Open HD0:C/sfssalv Read OK
[4] sfssalv #FINDINPUT 4156C3D, 4156B16, 4129D55 HD0 OK
[4] sfssalv #FREE_LOCK 4156B16 HD0 OK
[4] sfssalv #READ 10599AA0, 105B3F78, 8000 HD0 OK
[4] sfssalv #READ 10599AA0, 105B3F78, 8000 HD0 OK
[4] sfssalv #END 10599AA0 HD0 OK
[4] sfssalv RunCommand 8192 Fehl
[4] sfssalv #FREE_LOCK 4156C0A HD0 Fehl

However, it fails miserably when executing...