Mobile Home Serial Number Search - Athens Man Loses Bill Sentimental Value. Victim Told Police Awoke Discovered His Wallet Gone Searched Home Initially Did Not Find Have Serial Number Special Bill. Victim Told Police Awoke Discovered His Wallet Gone Searched Home Initially Did Not Find Have Serial Number Special Bill. Download now the serial number for serial para norton ghost 15. All serial numbers are genuine and you can find more results in our database for serial software. Smart Serials is a serial numbers collection website safe to browse by all. DOWNLOAD serial para norton ghost 15 SERIAL NUMBER.
Awesome work, Phil. I had Easy68K in my 'Quantel Harriet' folder as well, but I've been stepping through the code in the MAME debugging instead. (I added a basic skeleton driver for the Harriet, but I'm not handling the serial stuff yet.) Due to my lack of 68K experience, I was finding it tough to work out which arguments were actually put on the stack for that SecurityPAL routine, so I didn't have an example string to go on. I also couldn't find a place in the code where it actually checks the serial number of the PAL?
I need to get my head around the code you've produced. Lol The comments about the 777777 thing were added by another guy in Oz btw (no, not that one.:p ) I was still working through that routine last night, but didn't make a huge amount of progress once I realised it was a fair bit more complex than I first thought. I did find the identical security routine in the main OS file btw (from the previous working Harriet that I had, which was sent to a friend some time ago). I'll send you the files from that, so you can have a look with IDA Pro etc. I'm still a tad baffled that the binary you posted doesn't match the one I generated from the EQN though? However, you file does indeed match 100% to the one that Mr Dexter read using the programmer, so that confirms that. Did you also spot that the /A2 input in the EQN was inverted?
I guess you must have?:p Have you tried randomly changing a few bits in the binary / equations, to see how the output changes, or would that just completely scramble everything, or cause the routine to return with an error? I did a search through the main OS file for any addresses starting with 0xFD0xxx btw, and 0xFD0000 only appears in that same routine as in the ROM monitor. There are four or five other places in the raw hex that starts with 0xFD0xxx, but that's probably just random data. So, I think we can be fairly confident that all their crypto works through that same routine. Once we work out how to produce the correct response for the different serials, we should just be able to patch the code instead of generating a PAL each time (and therefore essentially 'cracking' the Quantel OS). Now, I'll have to try to understand Phil's code now. Code: $ make &&./quanenc cc -g -ggdb -c -o quanenc.o quanenc.c cc -g -ggdb -o quanenc quanenc.o Quantel Paintbox Protection PAL builder.
Serial numbers: 12345, 76543 Description: HUMMINGBIRD Raw buffer: 00 00 30 39 00 01 2A FF 48 55 4D 4D 49 4E 47 42 49 52 44 20 20 20 20 20 20 20 20 20 20 20 20 20 00 00 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Raw checksum: 1649 Enc checksum: 5212 Encrypted buffer: 43 6F 40 40 72 68 4D 97 3C 75 65 0E 60 6E 16 37 28 3C 30 45 4C 00 6C 54 44 00 11 19 18 15 0E 00 55 73 65 28 77 69 74 68 6F 75 74 20 70 65 72 6D 69 73 73 69 6F 6E 20 66 6F 72 62 69 64 64 65 6E $ make &&./quanalg./quanenc/enc.bin make: 'quanalg' is up to date. Code: Harriet #12360: 00 00 00 08 00 00 00 00 PFrame Paintbox #15462-E: 00 00 10 00 04 00 00 00 Editbox #17624-1: 10 00 01 00 00 00 00 00 Editbox #17624-2: 00 42 01 00 00 00 00 00 Network #17642-N: 00 60 00 00 00 00 00 00 If the description string is meaningless to the machine (it could well be), this may well be a bitmask which says 'unlock these features by default'. In which case, you'd need to know what the bits mean. I wonder how complex the 'licence string' scheme is. Whether it just locks to serial number (in which case that's all you need to get right) or whether these bits matter too. I'm not sure the monitor ROM would - at least I wouldn't expect it to.
All I'd expect it to do is see if the PAL is there and maybe print the serial number. The main software would be what checked the serial number, read license strings, decrypted those, and decided whether you were worthy of advanced features and such. I'm guessing the thing boots from disk, and that there's more advanced licence checking in there. As regards the stack - what it's putting on the stack are two pointers. 'retcodesuccess1' is a pointer to a variable which receives a return code from the function (ehh, the usual 68k calling convention is to use D0, but whatever). 'inputCryptoString' isn't actually an input - it's an output.
It's a 64-byte buffer (not 0x3F - the guy in Oz missed that a DBF loop loops n+1 times) which receives the decrypted version of the 'cryptstring', which is actually the contents of the security PAL. That string encodes the serial number, description string (up to 24 characters, space padded) and 32 bytes of additional data which is usually 0x00 but some bits can be set to '1'. And here's the PAL generator. Modify the constants at the top (serial numbers and product description string), compile it, run it, and it'll spit out two files. ENC.BIN is a 'PROM-like' binary you can load into QuanAlg to check the PAL. ENC.PLD is an Atmel-WinCUPL equation file which can be used to produce a GAL20V8. If you want to compile the PLD file, go into the WinCUPL options and set Logic Minimisation to 'None' or 'Quick'.
I found that at least with this file, Quine-McCluskey minimisation caused WinCUPL to crash during the CUPLM phase. There's also an example showing how to 'fudge' the data bits which are nonzero in the Harriet PLD, so you can generate a functional duplicate of that.
@phil - I just sent you a big message via PM, but it didn't seem to appear in the Sent Items, so let me know if you received it OK. Luckily, I remembered to do a Ctrl-A, Ctrl-C, then paste the message into a text file. (The way this forum shows the previously sent replies on the Messages screen is a bit strange too.) Here's my Verilog of the 12360 PAL, but with the 'binary' terms converted to Hex. It's very possible I made a few typos in that one, but originally I was using the file I'd converted from the EQN. That was using NotePad to change the OR / AND / NOT operators though, and change the pin numbers to proper names etc.
I got the same exact result when running the binary or hex term version on the dev board, but it still didn't match what you produced, or what Mr Dexter got from reading on the TL866, so I've obviously screwed something else up. Lol I did invert the A2 bit input in the code, and also realise that the 68K doesn't hook up /LDS or /UDS, nor has A0 etc., but it should have produced the same result as reading the PAL as a 'ROM'.
It's not important now, just one of those things that's bugging me. Hehe I'll have a look now to see how to disassemble the whole OS file with IDA Pro.
Unless anyone else knows? I managed it some time ago, but now can't recall how to just blindly dump the whole 68K binary back to an ASM file? Once we have enough of it disassembled, we should see exactly which routines are accessing that same PAL Security routine, and hopefully how it processes the passwords too. The passwords themselves seem to simply be written in cleartext at the start of the main OS file.
The OS itself looks to be only 2 or 3 MBytes. The whole rest of the HDD image is just for storing the uncompressed video frames. (4:2:2 component, which the guy in Oz kindly converted back to RGB for us.) Here are a few example images from the Harriet unit I sent to Mr Dexter. Clearly, some of those images were from the BBC's 'Airport' program. I remember it well. Hehe That Harriet unit, and the previous one seemed to have been used right up until about 2002-2004. Amazing really.
You can see how it stores the fonts and brushes as uncompressed, and even captures the palette box if it was enabled at the time. Kind of unsurprising, as the whole thing operates directly on the framebuffer(s), with only a certain amount of 'hardware acceleration' for things like 3D rotations and scaling. The Harriet system uses the 68010, but also has the MC68450 DMA Controller. The classic Paintbox DPB-7001 used only the 68000, and virtually all of it's drawing functions were done using jellybean TTL logic, and some multipler chips etc.
It stored the chosen brush shape on a separate RAM board, and would then do a Read-Modify-Write on the framebuffer contents, depending on the pressure of the stylus on the tablet / selected colour etc. It could also do 'Copy 'n' paste' and masking effects between the two separate frame stores. Extremely impressive for 1981, especially since the 68000 CPU only got released in 1979 (IIRC). For anyone not familiar with the PB, here's the unit I'd been helping to get running for about three years (but sadly failed, as I'm 200 miles away from it. Lol) This is the PB which is now in Mr Dexter's possession. And here's a demo of it's painting functions. Again, crude by today's standards of course, but absolutely groundbreaking for it's time.
There were a number of copyright challenges by Quantel against Adobe over the years. It's clear that many of the techniques used in programs like Photoshop share a lot of similarities, but I guess we'll never know quite how much of it was 'inspired' by the Quantel units. Right - back to trying to figure out Phil's (and amyk's) code. I've started to find more routines in the main OS file now. It's interesting that it also has ASCII strings for different add-on options, like 'HD Painting', 'AV Painting' etc. As Mr Dexter said the other day, the Harriet isn't technically a 'Harriet' unless it's linked to other units to make a more complete system.
It should really be referred to as a 'V-Series' unit, AFAIK? There are more routines for crypt / decrypt of files using the passwords (and serial number by the looks of it). I still haven't figured out how to force IDA to just disassemble the entire 2.11MB file, but I'm getting closer to finding which routines talk to the PAL, or use the serial number etc. Here's my Verilog of the 12360 PAL, but with the 'binary' terms converted to Hex. It's very possible I made a few typos in that one, but originally I was using the file I'd converted from the EQN. That was using NotePad to change the OR / AND / NOT operators though, and change the pin numbers to proper names etc.
I got the same exact result when running the binary or hex term version on the dev board, but it still didn't match what you produced, or what Mr Dexter got from reading on the TL866, so I've obviously screwed something else up. I remember watching the videos of that on Youtube while Retrogamer was trying to get it up and running. I wondered what had happened to it. With regard to the OS. It looks like it's been loaded at address 0x0. I bet that isn't the load address. You need to know what address (in RAM) the boot ROM loads the OS into, and what address it starts executing from.
If you give IDA that, it should get a long way into the disassembly. I think it might be stopping because the load/exec addresses are wrong. Yep, I'm just trying to disassemble what I can atm, then work out where it normally loads the executables in RAM. I would imagine it loads the entire 2-4MB OS file(s) directly into RAM, as it does seem to point to routines in that range a lot. I did have the OS file for my older Harriet mostly disassembled in IDA, but the older IDA did have some bugs and glitches. So, I've started again with IDA 6.6 instead. I have nearly 50% of the code done so far, but I'm having to do a Ctrl-U to go to the next Undefined code, then hit C to convert to ASM.
Most of the strings / data come before the routine of course, so I'm having to skip those manually too. Our guy in Oz did a superb job of figuring out most of the 'Harriet' memory map btw. (hope this is OK to post?). I have found a few routines in the OS file which process the serial numbers, but they also appear to JSR to routines in RAM. Here's one example. ROM:00070D50 loc70D50:; CODE XREF: ROM:00070D48j ROM:00070D50 adda.w #$44,sp; 'D' ROM:00070D54 movem.l d0-a4,-(sp) ROM:00070D58 lea -$A(a6),a1 ROM:00070D5C lea ($404100).l,a2 ROM:00070D62 lea ($403CF2).l,a3 ROM:00070D68 lea ($6362DE).l,a4 ROM:00070D6E moveq #$C,d2 ROM:00070D70 moveq #1,d5 ROM:00070D72 subq.w #2,sp ROM:00070D74 pea -$4A(a6) ROM:00070D78 jsr $4710E8.