12 September 2021, 00:54 | #21 |
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,658
|
Admiral, we are sort of jabbing from different perspective to reach a goal, bootblock code that works on all OS versions that can kill resident viruses (as a shorthand). It started as weird behavior (so that's what I reported in OP), now it turns out my code was mostly correct and we have some code that partially helps with killing viruses on 2.0+. I understand that you're confused, because the entire thread must be read as context. A 'spurt session' to try to solve the problem, with some great info.
Perhaps someday there will be universal code for this utility work, but for now I just need to optimize 36 bytes. Send 36 bytes pls. |
12 September 2021, 02:51 | #22 |
Engineer
Join Date: Oct 2018
Location: Shadow realm
Posts: 167
|
|
12 September 2021, 14:31 | #23 |
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,658
|
I've just replaced a legacy piece of code with shorter code, so I have bytes to spare! I'm now in the process of testing on all systems and cleaning up the source. Then it will be shared with source here
|
12 September 2021, 14:50 | #24 |
ex. demoscener "Bigmama"
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 1,642
|
Wouldn't rebuilding execbase effectively destroy any virus' connection to the system, regardless of if its code is still in memory or not? I would think so.
|
12 September 2021, 15:06 | #25 | |
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,658
|
Quote:
Clearing RAM is useful only for tests outside your dev env where all code works. If junk in bitplanes, hardreset to clear RAM and if it works you found the bug (relying on some memory being cleared) in five seconds. This can only be done on 1.3, unless I manually clear it first on 2.0+. (Side note: And Ctrl-Amiga-Amiga or code softreset clears all RAM on one specific setup, ECS machine with KS1.3... it's a mess. It would be very nice if somehow this could be fixed, but...) |
|
12 September 2021, 20:57 | #26 |
Engineer
Join Date: Oct 2018
Location: Shadow realm
Posts: 167
|
ColdCapture() runs before execbase checksum is even checked, so you'd have to explicitly wipe that one.
|
14 September 2021, 18:03 | #27 | ||
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,658
|
The bootblock is now feature complete and I'm prettifying it without going over 1K.
My question in OP was based on emulation behavior, so it is answered by this: Quote:
I also wanted to ask about these two comments seen together: Quote:
|
||
14 September 2021, 18:17 | #28 | ||
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,573
|
Quote:
Quote:
|
||
14 September 2021, 18:40 | #29 | |||
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,658
|
Quote:
Anyway, the cause is known now, so for me it's answered. But it was good that I asked because my boot block is in better shape. Quote:
I.e. The case to be debunked is when the reset instruction is unaligned? Quote:
If so, what is the correct way to wipe ColdCapture() before reset? |
|||
14 September 2021, 18:45 | #30 | |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,491
|
Quote:
clr.l $2a(a6) EDIT: but if execbase is destroyed there is no need to clear it.. I explicitly used st 7.wbecause in any ROM there is a check for an odd execbase address (which of course cannot be accepted), therefore nothing can be executed from resident vectors or pass the checksum checks. Last edited by ross; 14 September 2021 at 19:39. |
|
14 September 2021, 19:14 | #31 | |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,573
|
Quote:
Unaligned RESET followed by JMP (A0) in next long word. Cache disable and flush followed by dozens of NOPs before RESET/JMP (A0) to guarantee flushed pipeline. (JMP instruction executing confirmed by testing with odd A0. It crashed.) |
|
14 September 2021, 19:39 | #32 | ||
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,658
|
Quote:
This has to be the most confusing section in the entire book, not least because of calling a normal soft reset a "Cold Reboot". The 'why' question remains interesting. It seems to be the jmp (a0) instruction that should be aligned. Could it fail to prefetch jmp (a0) under some circumstances? That section only mentions as reason that the RAM will disappear when the reset instruction is executed. Could DMA interfere? The example doesn't turn off DMA. Could it be required from an early A1000 hardware bug? I'll change my code to follow HRM of course, so maybe it's best pursued in a dedicated thread. Annoying as hell Quote:
1. Your code destroys (actually not, asks ROM to later destroy) Exec and resets 2. Reset invokes ColdCapture() 3. ROM notices Exec is bad and rebuilds it, clearing ColdCapture() ...and that because of 2, if ColdCapture() has virus code it could be prepared and nonetheless "re-inject itself"/restore Exec values it saved when first injecting itself? Then Exec wouldn't be rebuilt. |
||
14 September 2021, 19:49 | #33 | |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,491
|
Quote:
But someone could have patched _LVOColdReboot().. Well, destroying execbase sure do the job |
|
14 September 2021, 20:23 | #34 |
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,658
|
Ahem. Sorry again. The HRM section about resetting actually doesn't say anything about jmp (a0) having to be aligned. It aligns the Supervisor() target address. Must all code invoked by supervisor state be 4-aligned? SuperState() on 2.0+ doesn't.
Also if things can be patched and monitored maybe it's best to do as much as possible with hardware code. TRAP into supervisor instead of using Exec etc. If we're turning off ints anyway, I mean... |
14 September 2021, 21:06 | #35 |
Registered User
Join Date: Jun 2016
Location: europe
Posts: 1,064
|
Can you link the reset code you are looking at? I just checked elowar http://amigadev.elowar.com/read/ADCD.../node02E3.html, PDF and the actual book, and they have the same code: reset is longword aligned and shares the same longword with jmp (a0) (which is the idea).
What I'm concerned about is jumping to a RAM address (too soon) after reset. Reset takes 132 cycles so there is plenty to time to fetch the next opcode, but at what point within those cycles is RAM replaced by ROM? Immediatelly, after the next opcode fetch, ...? If you jump into RAM (e.g. lea 2.w,a0 + jmp (a0)) does that work with all hardware profiles? So I consider jumping into ROM ($0fxxxxxx) safer. About the reboot vectors. Yeah, manual exec nuke from the orbit (e.g. nuke exec base or one of checksumed vectors so the checksum doesn't match) is the only way to be sure. Or fix them and redo the checksum (well, as long as you assume the virus didn't take over your MMU). For example: Code:
clr.l ColdCapture(a6) clr.l CoolCapture(a6) clr.l WarmCapture(a6) lea SoftVer(a6),a0 moveq #(ChkSum-SoftVer)/2-1,d0 moveq #-1,d1 csum sub.w (a0)+,d1 dbf d0,csum move.w d1,(a0) Last edited by a/b; 14 September 2021 at 21:27. |
15 September 2021, 13:22 | #36 |
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,658
|
Shoulda checked my black HRM I guess. It just sounded like this code was final. In this example (see attachment), the reset instruction is unaligned.
I'm assuming the hardware makes sure the "zeropage" has something in it (even from a poweron) so that the CPU can function. Like providing a jump into ROM at the a0 target address. There's no hope of fitting anything together with some elaborate antivirus on a bootblock. It's mostly for stopping relatively simple early viruses when testing old, unknown disks. If it prevents a resident virus from staying in memory, that's a good enough hard reset. Last edited by Photon; 15 September 2021 at 13:30. |
15 September 2021, 13:45 | #37 |
Registered User
Join Date: Jun 2016
Location: europe
Posts: 1,064
|
Ah, ok... It must be one of the earlier editions (mine is 3rd edition from 1991). Just checked my PDF collection, it's probably the revised&updated edition from 1989 (I was still in the c64 waters at the time).
One way to explain it is that they probably used an optimizing assembler that changed 2 to 2.W, in which case everything fits together nicely. A few lines underneath is move.l 4,a6, and you typically don't write that in your size constrainted ROM code (it's move.l 4.W,a6), which supports this explanation. |
15 September 2021, 14:41 | #38 | |
Engineer
Join Date: Oct 2018
Location: Shadow realm
Posts: 167
|
Quote:
So you'd need to clear ColdCapture _and_ nuke one of the other two with a non-zero value. Furthermore, clearing the vectors and recalculating checksum is not good enough, as the kept ExecBase could have a hook elsewhere. |
|
15 September 2021, 15:15 | #39 |
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,658
|
a/b, it's more likely that a mistake was left in the code, and that this was corrected. (And despite the unaligned RESET, it might not have been a mistake at the time. One of my absolute thoughts is: "You can never be future-compatible, you can only be backwards compatible or not".) And when KS2+ released, a function to do it was added, even though the old code from 1989 works fine on KS2+ (for a soft reset).
For a hard reset, you could say that I need to reset without using the OS, since the OS could be compromised. (Disable, Supervisor/SuperState, ColdReboot could all be "hacked".) But I don't want some overthought, overwrought antivirus code that may fail on some system. I could take over the hardware, nuke Exec, hardware reset and prevent most of it and that's fine. For the soft reset I'll use the only allowed code, 2nd edition. If I am to do this, I need a non-Supervisor() way to read VBR. Last edited by Photon; 15 September 2021 at 20:12. |
15 September 2021, 23:08 | #40 |
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,658
|
This wall of code replaces the code in OP. It's tested in WinUAE on A1200-060 3.1, stock A1200 3.1, A500 3.1 and A500 1.3, and on real A500-ACAPlus-3.1 and A500 1.3.
The code can be run from assembler/CLI/WB as is, but ADF is also attached. If something is resident (such as invoked Early Boot menu, accelerator stuff, or virus), it will report a red color else green, and then wait for LMB=Soft Reset or RMB=Hard Reset. If RMB, it must report green on next bootblock run, or report green on next run from assembler/CLI/WB as long as nothing installs itself resident in s-seq before. I'm looking for feedback on reliability before I commit. (Edit: Please see the ;** and must be comments.) Cheers. Code:
LowMemChkSum=$24 ChkBase=$26 ColdCapture=$2a CoolCapture=$2e WarmCapture=$32 EAllocMem=-198 INTENA =$dff09a DMACON =$dff096 COLOR00 =$dff180 ABSEXECBASE =4 ;Pointer to the Exec library base MAGIC_ROMEND =$01000000 ;End of Kickstart ROM MAGIC_SIZEOFFS =-$14 ;Offs from endROM to KS size V36_EXEC =36 ;Exec with the ColdReboot() function TEMP_ColdReboot =-726 LIB_VERSION =20 ;offset in Exec _LVOSupervisor =-$1e JUMPPTR BootCode ;for assemblers with this function BOOT: dc.b "DOS",0 dc.l 0,880 BootCode: move.l 4.w,a6 move.l #BootCodeE-BootStart,d7 *--- alloc ---* move.l d7,d0 ;size moveq #2,d1 ;chip jsr -198(a6) ;AllocMem() move.l d0,a1 *--- copy ---* move.l a1,a2 lea BootStart(PC),a0 .copyl: move.b (a0)+,(a1)+ subq.l #1,d7 bne.s .copyl jmp (a2) ;jump into chipmem ******************** BOOT START ******************** BootStart: ;a6=Execbase move.w #$272,d1 move.l $2a(a6),d0 ;CHECK COLD- & COOLCAPTURE & KICKTAGPTR or.l $2e(a6),d0 or.l $22a(a6),d0 beq.s .novirus move.w #$822,d1 .novirus: move.w d1,COLOR00 ;signify presence btst #6,$bfe001 ;no symbols for these, geddoudaheere... beq.s SoftReset ;LMB:Soft Reset btst #2,$dff016 ;RMB:Hard Reset bne.s BootStart ;*magic hand gesture* there is no boot HardReset: *--- disable ints and dma ---* move.w #$4000,INTENA ;disable ints to avoid interference move.w #$0580,DMACON ;and some DMA to avoid delayed prefetch clr.w COLOR00 ;cosmetic (avoid random bg color) *--- clr coldcapture, set other two+nuke chkbase(+lowmemchksum?) ---* clr.l ColdCapture(a6) ;must be 0 st CoolCapture+3(a6) ;must not be 0 st WarmCapture+3(a6) ;must not be 0 not.l ChkBase(a6) ;must be not correct (clr is unsafe) *--- normal reset but rebuild Exec ---* lea.l GoHard(pc),a5 ;<KS20 supervisor address bra.s _ElbowTemperatureReboot ;** really allow Exec to do it? SoftReset: lea.l GoAway(pc),a5 ;<KS20 supervisor address _ElbowTemperatureReboot: ;a5=GoAway or GoHard ; move.l ABSEXECBASE,a6 ;HRM code minus load of a5,a6 cmp.w #V36_EXEC,LIB_VERSION(a6) blt.s .pre20 jmp TEMP_ColdReboot(a6) ;Let Exec do it... ;NOTE: Control flow never returns to here ;---- manually reset the Amiga --------------------------------------------- .pre20: jsr _LVOSupervisor(a6) ;supervise-jump to code at (a5) ;NOTE: Control flow never returns to here ;-------------- MagicResetCode ---------DO NOT CHANGE----------------------- CNOP 0,4 ;IMPORTANT! Longword align! GoAway: lea.l MAGIC_ROMEND,a0 ;(end of ROM) sub.l MAGIC_SIZEOFFS(a0),a0 ;(end of ROM)-(ROM size)=PC move.l 4(a0),a0 ;Get Initial Program Counter subq.l #2,a0 ;now points to second RESET reset ;first RESET instruction jmp (a0) ;CPU Prefetch executes this ;NOTE: the RESET and JMP instructions must share a longword! ;---------------------------------------DO NOT CHANGE----------------------- ;-------------- MagicResetCode ---------DO NOT CHANGE----------------------- ;sorry, this is a changed copy. 4 bytes inserted, OK. see * CNOP 0,4 ;IMPORTANT! Longword align! GoHard: lea.l MAGIC_ROMEND,a0 ;(end of ROM) sub.l MAGIC_SIZEOFFS(a0),a0 ;(end of ROM)-(ROM size)=PC move.l 4(a0),a0 ;Get Initial Program Counter subq.l #2,a0 ;now points to second RESET st 7.w *Exec made odd to force rebuild reset ;first RESET instruction jmp (a0) ;CPU Prefetch executes this ;NOTE: the RESET and JMP instructions must share a longword! ;---------------------------------------DO NOT CHANGE----------------------- BootCodeE: ******************** BOOT END ******************** ds.b 1024,0 ;filler Last edited by Photon; 16 September 2021 at 00:53. Reason: see edit |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Amiga 1200 problem with soft reset (and hard reset) | joora | support.Hardware | 6 | 21 July 2020 10:53 |
Crack tells me to "hard reset" to clear Ram | apachacha | support.WinUAE | 6 | 28 December 2011 11:30 |
is this correct? | CU_AMiGA | MarketPlace | 1 | 28 September 2007 20:05 |
Hard and soft reset | Photon | request.UAE Wishlist | 3 | 28 November 2006 16:08 |
Hard reset | BippyM | support.WinUAE | 3 | 22 February 2006 01:47 |
|
|