I'm sure you are right... non-disclosure about fits their posture.
Perhaps if we had someone who was about to make a purchase of PocketDOS??
Thus stimulating the e-commerce aspect??
I wonder if it still works.
The man who posted the responses on De Herrera's board, as well as being intimately acquainted with PocketDOS and it's workings, was also a sometime flyer at one of my old haunts. He was even able to unbend enough to comment on a rather clever series of procedures derived by one of the other ghosts there. That is positive thinking, and an uncharacteristic appreciation of life in the real world... where the curious will educate themselves in this way, and benefit from it... whether we like it or not.
And I quote...
"Interesting... We changed the protection schemes in PocketDOS
(v1.11.1 and later
), so it would be interesting to see if these methods would still work on later versions
(we would expect not
).
Of course it goes without saying that we do not promote the piracy of our
(or anyone else's
) software. Despite numerous requests
(and promises to refrain from the administrators
), this board still promotes the piracy of our software. This is vaguely useful to us, as piracy would still happen without this board, and this gives us a "heads up" on what
(some of
) the "pirates" are doing...
We have spent many years and a lot of money
(for development tools and test hardware
) to develop this product. It's not made by a big company, but by individuals who are trying to make a living from it. Needless to say, if we can't make a living from it, then we can't develop it further...
PS. We are not the people who wanted to sue this site
(if that was the question
)."
Unquote
I'll reproduce the post in question for the benefit of the 200 odd readers that we seem to have interested... please feel free to disperse it to atoms if you feel it's a bit too risque. However by the same token, it may well stimulate the PocketDOS people into some kind of reaction.
Ours is after all, a positive case, with positive outcomes.
As an educator myself, albeit from more than a decade back, I obviously cannot condone the suppression of knowledge... any knowledge... unlike our verminous governments and their police... and took an academic interest myself in this adventure into what I have always regarded as shark infested waters... ie. coding for Intel PC derivative processors and their overly-complex segmented memory models.
As a dear old colleague
(died in the wool Z80 man
) used to say increasingly frequently until he met the great PIO chip in the sky, "The Intel Line of 8088/8086 processors were designed to run process control in a chemical plant, and they should have been quietly left to do so.".
Quote Begins:
Protection: Nagscreen, keycheck, CRC in program and in the Pdos_con.dll
There is a keygen for this, but it doesn't work because it doesn't use the Device-id.
Tools used:
-Ida Pro 5.0
-Highlighter to mark the executed code
-Microsoft Windows Mobile 5.0 MSFP Emulator
(and activesync installed
)
-Axe hex editor
(or any other
)
-Win CE Cab manager
(to decompile the installation cab
)
The first contact:
-PocketDos begins as bad as they come: With a nagscreen
To make it worse, it stays for 15 seconds..
So fire up IDA PRO, and disassemble the program
(extracted from the cab
).
Search for the string:
The XREF for it is: sub_850B0
ff_85334 double click on the xref
(and again
)
Ida switches automaticly in graph mode, tracing this back to the beginning of the sub, and checking for alternative routes,
you can clearly see that this whole sub best can be passed.
So after a quick analysis I decided it's best to ignore most of the sub, and end it as soon as possible.
In Ida
(text view
) it looks like this:
Code:
sub_850B0:
text:000850C0 MOV R7, R1
.text:000850C4 BL sub_85810
.text:000850C8 MOV R5, R0
.text:000850CC CMP R5, #6
.text:000850D0 0c0100aa BGE loc_85508 ; 0c0100ea skip all this demo and registration nonsence
.text:000850D4 CMP R5, #4
.text:000850D8 BNE loc_8511C
In hex-editor:
000850D0
(= offset:744D0
)
change 0C 01 00 AA
in 0C 01 00 EA
Would it be that simple?
NO!
After replacing the old exe with the newly patched exe in the emulater I fire up the program.
It loads, without nagscreen... and crashes..
So I try a different approach, the debugger.
(don't forget to set the debugger process options to the right path: \Program Files\PocketDos\pocketdos.exe
)
Start up the emulator, install pocketdos and replace the exe with the patched one.
(save state, because you will have to restart the emulator a few times after the crash
)
The last thing I saw was "configuring Hardware"
So I placed a breakpoint on the function from which it's called.
After counting the [CTRL-F7]'s, and [F7], replacing breakpoints and some restarting
(savestate starts up fast and saves you from re-installing
), I finaly reached:
Code:
.text:000A6648 ; sub_A64A4+170j ...
.text:000A6648 BL sub_87934
.text:000A664C MOVS R3, R0 ; LAST BP
.text:000A6650 BEQ loc_A6660 ; Do Bad Branch
.text:000A6654 BL sub_88234 ;
By Moving R3 to R0 I make the program believe the checksum is ok.
So it will look like this:
Code:
.text:000A664C 0003a0e1 mov R3, R0 ; copy R3, R0
.text:000A6650 MOVS R3, R0 ;
.text:000A6654 BL sub_88234 ;
In hex editor:
000A664C
(= offset:95A4C
):
Change: 00 30 B0 E1 02 00 00 0A F6 86 FF EB
in: 00 30 A0 E1 00 30 B0 E1 F6 86 FF EB
Again I refresh the exe in the emulator and fire it up..
It loads
I see the DOS screen loading, and then it crashes... Again
(but on a different place
).
I reload IDA Pro with the altered EXE.
Again I start the debugger, and let it stop on load of a library.
After loading PDOS_CON.DLL it crashes, Nice, I now know it is in the dll provided by pocketdos.
Again close the project in IDA and now load the dll.
(in debugger process options make sure to load the exe
)
After putting breakpoints in the dll on suspicious routines, I reached the routine responsible for the program crash @
Code:
.text:013F1968 ADD R3, SP, #0x4C8+ClassName ; Warning you are using an illegal or cracked.....
.text:013F196C ADD R3, R3, R0,LSL#1
.text:013F1970 MOV R1, #0 ; lpWindowName
.text:013F1974 STRH R4, [R3]
.text:013F1978 ADD R0, SP, #0x4C8+ClassName ; lpClassName
.text:013F197C BL FindWindowW
.text:013F1980 CMP R0, #0
.text:013F1984 MOVNE R2, #0 ; dwNewLong
.text:013F1988 MOVLNE R1, 0xFFFFFFFC ; nIndex
.text:013F198C BLNE SetWindowLongW
.text:013F1990 BL GetForegroundWindow
.text:013F1994 MOVL R3, 0x50010
.text:013F199C ADD R2, SP, #0x4C8+Caption ; lpCaption
.text:013F19A0 ADD R1, SP, #0x4C8+Text ; lpText
.text:013F19A4 BL MessageBoxW
.text:013F19A8 ADD SP, SP, #0x4C0
.text:013F19AC LDMFD SP!, {R4,PC}
.text:013F19AC ; End of function sub_13F1860
Switch to graph view, and analyse the whole subroutine.
Again I think it's wise to ignore the whole sub, so I do a return here:
Code:
.text:013F132C
.text:013F132C
.text:013F132C Killer_1 ;<- name I gave to the sub.. ; CODE XREF: sub_13F1000+Cp
.text:013F132C ; DATA XREF: .pdata:013F7010o
.text:013F132C
.text:013F132C lpData = -0x1188
.text:013F132C cbData = -0x1184
.text:013F132C hTemplateFile = -0x1180
.text:013F132C Buffer = -0x117C
.text:013F132C hKey = -0x1178
.text:013F132C var_1174 = -0x1174
.text:013F132C Filename = -0x116C
.text:013F132C
.text:013F132C STMFD SP!, {R4-R11,LR} ; make this return: 0e f0 a0 e1
.text:013F1330 LDR R12, =0x1164
.text:013F1334 SUB SP, SP, R12 ; lpData
.text:013F1338 MOV R2, #0xD30
.text:013F133C LDR R1, =unk_13F50F0 ; void *
.text:013F1340 ORR R2, R2, #5 ; size_t
.text:013F1344 MOVL R0, 0x42C
.text:013F134C ADD R0, SP, R0 ; void *
.text:013F1350 BL memcpy
.text:013F1354 MOV R11, #0
.text:013F1358 LDR LR, =unk_13F5E28
.text:013F135C MOV R6, R11
.text:013F1360 MOV R0, R11
.text:013F1364 LDRB R1, [LR]
.text:013F1368 ANDS R1, R1, #0xFF
.text:013F136C BEQ loc_13F13A8
.text:013F1370 MOV R3, R1
.text:013F1374 ADD R1, SP, #0x1188+Filename
In hex editor:
013F132C
(= offset:72C
):
change F0 4F 2D E9
in 0E F0 A0 E1
Replaced the old dll
(in /windows
) with the patched one
Firing it up again,
And now it runs withouut a glitch
Summary:
patch pocketdos.exe:
Code:
offset:744D0
change 0C 01 00 AA
in 0C 01 00 EA
And:
offset:95A4C
Change: 00 30 B0 E1 02 00 00 0A F6 86 FF EB
in: 00 30 A0 E1 00 30 B0 E1 F6 86 FF EB
Patch PDOS_CON.DLL
Code:
offset:72C
change F0 4F 2D E9
in 0E F0 A0 E1
This was a fairly simple patch, however it's a nice one to do, because it's a good practice in debugging exe and dll.
I completely ignored the keycheck for registering, because it's not used, I removed it from the help menu with Restorator 2007.
I also replaced the bitmap in the splash-screen.
BTW my name has changed to protect the guilty
Unquote
QF 07-01-13
