KickWork

[da9000]

How does KickWork manage the "split pesonality" thing? Is it a modified Kickstart that is smart enough to detect this specific disk format? Does the disk show as an NDOS disk on WB?

[da9000]

Makes sense, what you say about the patched disk-handler. Thanks for the explanation.

As for "is a non-dos, but not NDOS disk": is there a difference? I thought NDOS=non-DOS, right?

[da9000]

OK, this makes a lot of sense. If I got it right: change the trackdisk.device in the KickWork ROM so that it returns a normal bootable disk block, so that WB thinks the disk is normal. At the same time mark the on-disk bitmap so that the ROM file blocks appear as used (which they are). Love hacky stuff like this! :-)

[da9000]

Piru wrote:
bootable floppy, imaginatively called "mkkickwork". Once the

Hahaha, definitely a (vowel-hating?) coder

Sounds awesome, Piru! I'll give it a try as well!

Cheers

PS. Since we're on this thread (of thought), and SKick was mentioned would anyone mind giving a few dirty details on how SKick does its job? Thanks

[da9000]

Excellent thread!

@Piru:
Thank you for the in-depth explanations and reverse engineering!

Only a small question: when you say "The application loads the kickstart and then scans it for the locations to patch.", do you scan certain fixed locations (so it only works on certain Kickstart versions), or some other form of heuristic (so the program will work with other Kickstart versions) ?

@Mr. Loew:

Glad to have you here and hear from you. I'd be curious to know if Kickwork or any other of your software is still being used by businesses/corporations, and if so what sectors/industries?

[da9000]

@Mr. Loew:

Thanks for the info!

As for the question to Piru, I meant it for his version of the software - that's what he was describing, if I understood correctly.

[da9000]

If I may ask:

do you search for "byte patterns" or instruction fingerprints if you like, which span a few bytes before, including, and after the target location?

In other words,if the hypothetical byte stream is:
39 b3
50 34
25 64  <-- target
14 8a
9f ff

Would you be searching for "35 25 64 14" ?

Also, do you start searching from a certain approximate location, or do you search the entire ROM (from start for example)?

Just curious what's a more effective method.

[da9000]

Cool stuff! I love technical analyses! I need to do some refreshing on jump-tables and libraries.

Almost all made sense, so just a couple of questions:

1)
For the life of me I can't decode your acronym for rl() :-). I can see it reverses the order of the bytes (swizzling?). Why is it necessary?

EDIT: a guess: ReverseLong? Can't be! You'd ditch u_int32_t for long!??! :-D

2)
I see the "magic pattern" code:

Code: [Select]


  if (romptr(p1) && romptr(p2) &&
        rl(p + 4) == p1 && rl(p + 12) == p2 &&
        romptr(rl(p + 16)) && romptr(rl(p + 20)) &&
        rl(p + 24) == p1 && rl(p + 28) == p1 && rl(p + 32) == p1)


but where do you check for ptr3 and ptr4?

romptr(rl(p + 16)) and the call afterwards are only checking bounds, right?

[da9000]

Ah, having not seen the wl(), I was lead down the wrong path of guessing. Doh!  I assume you're want endianess safety because you're a UAE user?

As for ptr3/ptr4: gotcha. Smart and tricky ;-)

[da9000]

Doh! Bad assumption again! Forgot you're a MorphOS dev, and that means PPC! But good point on the WinUAE vs E-UAE and A1000 emu.

Double doh! Just realized you posted a link to the source! Now I can see the bitmap setting code and trackdisk replacement code. Cool stuff - sweet code!

Anyways, you're right about not doing it properly and endian agnostic to begin with (especially with networking code :-))

EDIT:
Since I've got some of your attention on this thread, Piru, if you have a little time (if not, that's ok), would you mind checking my very last post, and very last questions for you on this older thread: http://www.amiga.org/forums/showthread.php?t=26716
I'd love to hear from you on it (again, only if you have time, if not, no prob). Thanks