Recommended BASIC cruncher or obfuscator

Hi folks,

I know that crunching or “absoluting” a BASIC program is sort of bad form due to making it harder to maintain, but there are still times when it is needed.

What’s the recommended program(s) for crunching or “absoluting” a BASIC program these days, such that it still works on RISC OS 5?

It’s a while since I did any BASIC, so I’m a bit out of touch on such programs.

Thanks in advance…

StrongBS 2 by Mohsen Alshayef was always the most thorough, but was buggy so there were some optimisations that had to be switched off (and StrongBS 3 was actually worse).

BasCrunch by Ragnar Hafstað is old, unambitious but seems OK.

BasCompress by Cy Booker may be your best bet.

My build process for large Basic apps was (eg, 1003KB Vantage runimage)

• StrongBS (custom settings, 552KB)
• Celerity (mine, 664KB including data)
• Bas2App (mine, 664KB)
• Cruncher (by BASS – not 32b, 335KB)

(Celerity was an optimiser that pre-built the whole of Basic’s workspace, with all variables pre-defined and prioritised, all DEFs pre-defined and removed from the code, and data blocks pre-loaded and bound to their variable ptrs… which is why the result is larger than the input – it’s not possible to get Basic to initialise faster, and makes reverse-engineering really rather hard)

ISTR that either AppBasic or DrWimp (or both?) came bundled with a cruncher and an Absolute wrapper. The best obfuscation however is to compile it with ABC.

StrongBS did seem to be good, and with promise … but I found it to be very buggy. I tried to contact Mohsen, but failed, and gave up with it.

BasCompress is not 32bit AFAIK. The source was made available, but it was missing some vital bits and I don’t think anyone ever managed to generate it. Shame, because it was excellent (though not bugless).

There were others, but none 32bit AFAIK.

I now use the recent Crunchie by Steve Drain. It is 32bit, and although the result is not quite as compressed as BasCompress, I decided it was sufficient for my purposes – which was about 30K source lines in 36 files totalling 2MB, 1k DEFs, 1k variables, which reduces to 350KB.

Hmm… Menu → Utilities → Cookies → Delete all cookies kills my NetSurf. Version 3.8 Dev CI #4320. Is it just me?

such that it still works on RISC OS 5?

I think StrongBS would work if you have an older RISC OS machine to run it on. The important thing is to leave it as crunched BASIC and not try to obfuscate it in an application wrapper.

Our best bet, I would imagine, is the one written with RISC OS 5 in mind. So I’ll second Martin’s suggestion of Crunchie.
https://www.riscosopen.org/forum/forums/1/topics/13539

The best obfuscation however is to compile it with ABC.

While that’s a pretty solid obfuscation, it suffers from the problem that it’s not quite as capable as real BASIC, so it really depends upon what is being obfuscated.

StrongBS did seem to be good, and with promise

Certainly – there was a huge range of options to customise how it behaved. It’s a shame it’s just faded away like that. :-(

I would support the use of Crunchie. Works very well on RISC OS 5 (and comes with full un-crunched source code, but runs on it’s own crunched code).

And if further obfuscation is needed then key strings can be hand coded when the program is written and decoded at run time.

N.B. Crunchie uses basic’s built-in crunch to get things off to a good start!

And if further obfuscation is needed then key strings can be hand coded when the program is written and decoded at run time.

Don’t need to overdo it!

I think most people, when presented with crunched BASIC, will think “oh my God” and give up. While certain things are obvious in context (x%!8=x%!12 – my ref = your ref for a WimpMessage reply), some things just make the brain ache… a%?(39+(b%-1)*24)=c%+16*((a%?(39+(b%-1)*24))DIV16) or the like. Remember, variables shortened, functions shortened, SWI calls reduced to numbers. You’d have to be pretty damn good to sight-read that…

Of course, Wimp stuff in BASIC is kind of painful anyway. That’s why we use a library (or for the grey haired ones among us, why we wrote our own library) and now forget about all that nasty low level stuff. :-) https://heyrick.eu/blog/index.php?diary=20151226

Oops! Found a bug in Crunchie. ;-)>

I looked through my collection of software on the Pi, and there’s precious little written in BASIC (that stuff would basically¹ predate ~1997ish). I did have, however, my !Teletext software. It’s a big BASIC program (quarter megabyte of source), so it wasn’t exactly a kind test.

Crashed on startup with a problem about unknown mnemonic.

Here’s the original code:

  REM Call this as:
  REM   A% = current_frame%
  REM   CALL transferpage_code%

  DIM transferpage_code% 32
  FOR loop% = 0 TO 2 STEP 2
    P% = transferpage_code%
    [ OPT loop%

      ADR   R12, reg13_store      ; we should store R13 - does SWI corrupt it?
      STR   R13, [R12]

      SWI   "XTTX_TransferPage"   ; ##TODO## handle if it fails failure

      LDR   R13, [R12]            ; pull back R13 so BASIC doesn't go sulky-sulky
      MOV   PC, R14               ; 32bit safe :-)

    .reg13_store
      EQUD  0
    ]
  NEXT

And…

Um…

DIMB2%32:FORF0%=0TO2STEP2:P%=B2%:[C2 F0%:D2 E2,F2:G2 H2,[E2]:
I2"XTTX_TransferPage":J2 H2,[E2]:K2 L2,M2:.F2:N2 0:]:NEXT

(it’s all one line originally, reformatted for here)

Now that is what I call obfucated!

Edit: Turns out it’s not a bug, it’s that Crunchie doesn’t do exclusions for assembler code “out of the box”…

¹ See what I did there?

I would support the use of Crunchie.

Thank you. ;-)

I now use the recent Crunchie by Steve Drain. It is 32bit

Being just BASIC, and hence 32-bit, should be important. Unless nemo has ‘done a job’ on them, the crunchers he lists cannot be used on RO5, I think, nor the one supplied with AppBasic.

However, Crunchie is still beta and there are bugs and some features to sort out – I did promise you Martin. ;-)

Turns out it’s not a bug, it’s that Crunchie doesn’t do exclusions for assembler code “out of the box”

Treatment of assember is not satisfactory, especially distinguishing program variables used within the code – I hear you Jan. ;-)

It is time to return to Crunchie from my current obsession with Object Oriented BASIC.

Crunchie is released under the modified BSD licence, so anyone can use it as they wish – just don’t blame me.

I know that crunching or “absoluting” a BASIC program is sort of bad form due to making it harder to maintain, but there are still times when it is needed.

Crunching for speed is a real, but a marginal benefit, I think. Crunching for size is also a marginal benefit today. Crunching for obscurity can be justified commercially, probably. Absoluting seems pointless, because the program can be extracted from memory very simply when loaded.

Celerity … it’s not possible to get Basic to initialise faster

Apart from the other benefits of Celerity, is initialising fast at all important generally? I would rather use time at the start to make a progam run more quickly later.

in case of desperation, or if your program has assembler, you could try the crunch utility inside !reggraph, from www.tellima.nl/riscos. It also can absolute it, but as Steve says, it’s pointless: Iconbar icon of Zap, menu,create, read memory, drag the switcher icon from the dialogwindow onto your app’s window, and find the BASIC program inside the memory then loaded.
You may have to experiment with the settings and the exclude-variable list file (e.g. the names of library proc’s/fn’s when you use libraries). And use the simplistic program checker before. This appl has little experience with crunching beyond my own programs: ymmv.
I do hope that Steve continues development on his cruncher because it’s good to have more choices when others don’t work. The emails with Steve also caused me to find a number of errors in my own program.

I rather doubt that crunching for speed is going to make much measurable difference, and what’s size now? It took my teletext software from a quarter megabyte to a little under 100K. Still got 960MiB free however you look at it. ;-)

Crunching for commercial obfuscation is about the only justifiable reason these days, but it’s worth noting that by doing that one is preventing the smarter users from extending (or, cough, bug fixing) the program.

Don’t waste time making it an absolute. Most of that can be defeated by trying to run the program in a TaskWindow (it will bomb out – Window manager in use, to which you can go into BASIC then OLD and then SAVE)…

initialising fast at all important generally?

Clearly. That’s why slow start programs chuck up a splash screen. A visual “look, I’m doing something, really”.

Apart from the other benefits of Celerity, is initialising fast at all important generally? I would rather use time at the start to make a progam run more quickly later.

It makes a discernible difference to start time, but the most important benefit is that you know how much memory you need straight away – you don’t need to do cyclometric testing to ensure every variable and PROC/FN has been defined before you can judge whether your wimpslot is correct.

It is only fairly recently that the var/PROC chains were kept in MRU order – originally they were always in definition order, so the 200 FNs used to load your windows, create your icons etc, would have to be checked and skipped past for Every Uncached PROC/FN call or variable dereference… and that was noticeable in tight loops. Creating them in optimised order made a big difference. MRU mitigates that to a large extent.

Clearly. That’s why slow start programs chuck up a splash screen. A visual “look, I’m doing something, really”.

< grumble mode on >
The tip of the “dancing dinosaurs” iceberg. Back in the late 90’s it became fashionable to animate things like mouse pointers, the trouble was it took processor time and slowed the machine. Pretty dino.
MS truly lost the plot with the GUI file transfer “swirly paper” in which the primary process was/is the animation, said animation called the file transfer for a small period and went back to animating.

Ever wondered why the likes of robocopy exist and are way faster than the MS GUI based transfer?

If you do it fast enough you don’t get chance to see an animation which would slow things down…

You could edit that post to finish it with < grumble mode off >

MS truly lost the plot with the GUI file transfer “swirly paper” in which the primary process was/is the animation, said animation called the file transfer for a small period and went back to animating.

Which reminds me of one of my favourite XKCD posts: Estimation

You could edit that post to finish it with < grumble mode off >

I endeavour to stay at least close to the truth¹, so when the “dancing dinosaurs” mood wears off I can close that one. Maybe after a beer (or two)

¹ I will never be in politics with that kind of attitude.

You could edit that post to finish it with < grumble mode off >

You must be new to the forum. There’s no way of turning grumble mode off. 🤭

This is why some of us never turn < grumble mode on >

Ooops!

My default setting since <checks watch> 1987.

You must be new to the forum. There’s no way of turning grumble mode off.

Maybe, it was introduced just for us newcomers (2012)