hardwarefetish.com

Fixing Kyocera fs-6021dn errors 7401 7402 7403 and 7404

At the office, we had a cheap Kyocera fs-6021dn. After a few years of use, the printer finally gave up with error 7403. Looking at the service manual, the error description is:

Developing unit M noninstalling error
No density detection signal is output from toner sensor M in developing unit M.
Possible causes:
 – Defective connector cable or poor contact in the connector.
 – Defective toner sensor M.
 – Defective engine PWB.

So I found a video showing the disassembly of the printer in order to find the drum developer transfer units. This video showed the removal of the toners and the transfer belt in order to find the drums. When I removed toner and transfer belt (which also wasn’t completely sane, but it seems that the defect found here didn’t really cause real problems for the printer), I found out that the contact of one of the drum units was loose. I just pushed it down so that the connector had contact again and tadaa – no more error 7403

Plötzlicher SCHANNEL Fehler von Outlook auf Win7 nach Let’s Encrypt Zertifikatswechsel

Hatte heute ein lästiges Problem. Habe SoGO mit EAS auf einem Server laufen, dessen Zertifikat von Let’s Encrypt ausgegeben und automatisch erneuert wird.
Seit der Zertifikatserneuerung heute war plötzlich eine Mailsynchronisation mehr möglich, Outlook zeigte immer nur “getrennt” an.

Im Ereignisprotokoll habe ich dann einen Haufen SCHANNEL Fehler gefunden, immer gleichlautend:

“Es wurde eine schwerwiegende Warnung empfangen: 40”

und auch:

“Es wurde eine schwerwiegende Warnung empfangen: 70”

Sehen wir uns also einmal die Fehlercodliste an:
SSL3_ALERT_HANDSHAKE_FAILURE  40
TLS1_ALERT_PROTOCOL_VERSION  70

Outlook dürfte also – vermutlich aufgrund des Zertifikatswechsels – aus irgendeinem Grund nicht mehr mit der bevorzugten SSL-Version mit dem Server kommunizieren können. Nach Prüfung der Liste der vom Server unterstützten TLS-Versionen kommt heraus, dass dieser nur TLS 1.2 angeboten hat. Dies wird jedoch wiederum standardmßig von Win7 WinHttp nicht unterstützt. Zum Glück hat mich dieser Artikel dann auf die richtige Spur gebracht: KB3140245. Das war zwar schon installiert, jedoch muss man noch 2 Registry-Schlüssel anlegen, um die Standards zu ändern:

Unter

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp

und

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp

(sofern 64bit Win7) einen DWORD-Wert namens DefaultSecureProtocols mit dem Hex-Wert 0xA80 anlegen, und schon funktioniert es wieder.

Der Grund für die plötzliche Umstellung dürfte übrigens sein, dass die Zertifikatserneuerung über certbot funktioniert, und dieser aktualisiert sich offensichtlich bei einer Erneuerung auch selbstständig und hat mit dann in der Datei /etc/letsencrypt/options-ssl-apache.conf folgende Zeile eingefügt/geändert:

SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1

Damit wurden also dann fieserweise die alten TLS-Versionen einfach abgedreht.

Crack für Monkey Island 2 / Deutsch

Nachdem ich in einem Kommentar gefragt worden bin, wie man Monkey Island 2 crackt, geht’s weiter in der Serie von LucasArt Adventure cracks.
Wie auch bei Monkey Island 1 sind die files mit 0x69 verXORt.

Fehlerfall:

Script 130, offset 0x24f: [14] o5_print()
Script 130, offset 0x254: [14] o5_print()
Script 130, offset 0x259: [9A] o5_move()
Script 130, offset 0x25e: [88] o5_isNotEqual()
Script 130, offset 0x265: [14] o5_print()
Script 130, offset 0x276: [AE] o5_wait()

Erfolgsfall:

Script 130, offset 0x24f: [14] o5_print()
Script 130, offset 0x254: [14] o5_print()
Script 130, offset 0x259: [9A] o5_move()
Script 130, offset 0x25e: [88] o5_isNotEqual()
Script 130, offset 0x287: [2E] o5_delay()
Script 1, offset 0x96e: [68] o5_isScriptRunning()

Als die Kommandos in MONKEY2.001 ansehen (nachdem wir 0x69 XOR gemacht haben):

879289: 9A EA 01 03 40 88 06 02 ea 01 22 00

Warum steht hier 9A und nicht 1A für o5_move und 88 und nicht 08 für o5_isNotEqual?
Weil der Parameter (PARAM_1) als Variable genommen werden soll und nicht als Wert.
In Variable 1EA wird also der Wert von Variable 4003 eingefügt, anschließend wird verglichen, ob in Var 1EA der Wert von Var 206 steht, wenn ja, dann um 22 Bytes gesprungen.

Nachdem der Wert vielleicht später auch nochmal geprüft wird, moven wir einfach den korrekten Inhalt von Var 206 in var 1EA, indem wir also 4003 mit 206 ersetzen:

879289: 9A EA 01 06 02 88 06 02 ea 01 22 00

Das Ganze wieder mit 0x69 verXORen, fertig ist der Crack 🙂
 (Keine Garantie, dass er funktioniert, aber zumindest nimtm der Kopierschutz dann jede Eingabe an).
Jetzt könnt ihrs aber dann schon langsam alleine auch, oder? *gähn*

Mehrere JPG-Bilder in ein PDF konvertieren

Es kommt immer einmal wieder gerne vor, dass man – um sich die teuren Kopiergebühren zumindest temporär zu ersparen – Akten abfotografiert.
Hierbei kommen dann ein Haufen JPG Bilder zusammen in meistens unterschiedlichen Ausrichtungen: Mal kopfüber, mal richtig, mal quer, je nachdem, wie es das Tablet/Handy gerade für gut befindet.
Um die Bilder in die richtige Ausrichtung zu bringen und in ein PDF zu wandeln, habe ich mir eine kleine Batchdatei geschrieben, die dies erledigt.
Hierfür werden das kostenlose OCR-Programm Tesseract und das ebenfalls freie Tool jpegtran (für Seitenerkennung und Ausrichtung) genutzt.
jpegtran muss sich im Suchpfad befinden, dann kann man einfach ein Verzeichnis mit .jpg Dateien auf die .bat Datei ziehen und diese wird konvertiert:

@echo off
setlocal enableextensions
set PATH=%PATH%;C:\Program Files (x86)\Tesseract-OCR\
echo Drehe Seiten...
for %%I in ("%~1\*.jpg") do (
  for /F "tokens=2"  %%F in ('tesseract.exe --psm 0 "%%I" stdout ^| find "Rotate:"') do (
    echo %%I um %%F Grad
    if not "%%F"=="0" jpegtran -rotate %%F "%%I" "%%I"
  )
)
echo Erstelle OCR-PDF...
dir /s /b "%~1\*.jpg" | tesseract - "%~1\combined" -l deu pdf
endlocal

MS SQL Server 2017 upstart script

I recently had to install a MS SQL Server 2017 on Linux. Unfortunately, the supplied scripts only support the stupid systemd, not upstart, so for Devuan or Debian Jessie without systemd, the script may be benificial:

!/bin/sh
### BEGIN INIT INFO
# Provides: mssql-server
# Required-Start:       $syslog $local_fs $network.
# Required-Stop:        $syslog $local_fs $network.
# Default-Start:        2 3 4 5
# Default-Stop:         0 1 6
# Short-Description: Microsoft SQL Server Database Engine
### END INIT INFO
 
DESC="Microsoft SQL Server Database Engine"
NAME=mssql-server
PIDFILE=/var/run/$NAME.pid
DAEMON="/opt/mssql/bin/sqlservr"
SCRIPTNAME=/etc/init.d/mssql-server
USER=mssql
 
. /lib/lsb/init-functions
 
# Exit if the package is not installed
[ -x "$DAEMON" ] || exit 0
 
case "$1" in
        start)
                log_daemon_msg "Starting $DESC" "$NAME"
                start-stop-daemon --start --quiet --oknodo --chdir /var/opt/mssql --background --make-pidfile --pidfile $PIDFILE --chuid $USER \
                        --exec $DAEMON -- $DAEMON_ARGS
                log_end_msg $?
                ;;
        stop)
                log_daemon_msg "Stopping $DESC" "$NAME"
                start-stop-daemon --stop --retry=TERM/15/KILL/5 --remove-pidfile --pidfile $PIDFILE
                status=$?
                rm -f $PIDFILE
                log_end_msg $?
                ;;
        status)
                pidofproc -p $PIDFILE $DAEMON >/dev/null
                status=$?
 
                if [ $status -eq 0 ]; then
                        log_success_msg "$DESC is running"
                else
                        log_failure_msg "$DESC is not running"
                fi
                exit $status
                ;;
        reload|force-reload)
                log_daemon_msg "Reloading $DESC configuration..."
                start-stop-daemon --stop --signal 1 --quiet --pidfile $PIDFILE --name $NAME
                log_end_msg $?
                ;;
        restart)
                $0 stop
                sleep 1
                $0 start
                ;;
        *)
                echo "Usage: $SCRIPTNAME {start|stop|restart|reload|force-reload|status}"
                exit 1
                ;;
esac

Unformtunately, MS SQL Server 2017 on Debian Jessie is a real pain to install. Newer versions tend to crash (coredump) very often and without a recent openssl-version from jessie-backports (which can only be installed with a little trick nowadays), it just drops every TCP connection to the server on client side with:

Sqlcmd: Error: Microsoft ODBC Driver 17 for SQL Server : TCP Provider: Error code 0x2746.
Sqlcmd: Error: Microsoft ODBC Driver 17 for SQL Server : Client unable to establish connection.

and on server side respectively with error 0x80090304

So we need a suitable version of MS SQL Server and the correct version of openssl to get it working.
Here is what seems to work here (currently stress testing with HammerDB before productive use):

apt-get install curl apt-transport-https
echo "deb http://archive.debian.org/debian/ jessie-backports main contrib non-free" >>/etc/apt/sources.list
echo 'Acquire::Check-Valid-Until no;' > /etc/apt/apt.conf.d/99no-check-valid-until
apt-get update
apt-get install -t jessie-backports openssl
curl https://packages.microsoft.com/keys/microsoft.asc | sudo apt-key add -
curl https://packages.microsoft.com/config/ubuntu/16.04/mssql-server-2017.list | sudo tee /etc/apt/sources.list.d/mssql-server.list
apt-get install mssql-server=14.0.1000.169-2
/opt/mssql/bin/sqlservr-setup

Paragon GPT loader #3

Recently, I bought a 3rd harddisk which is over 2TB in space and added it to my Desktop machine. As mentioned previously,I had to fix the gpt_loader.sys driver in order to not crash.

My patch worked quite well for a few years, but after adding the new drive, it always crashed with 0xc000001d. So I first thought about another bug in the driver, but then I saw, that the ExceptionCode means c000001d Illegal instruction. Then checking with the debugger, I found out that it crashed at a location that I patched. As the instruction in the closeDriver call was bogus,I immediately thought about a reloaction table entry that must have been written ot the wrong location and indeed – when moving up the code by 2 bytes to get space for my patch, I overlooked a reloaction entry in place.

As long as the driver wasn’t moved in memory and got loaded at the preferred load address, the bug didn’t surface,but due to the new drive, it seems that the driver was reloacted and so the bug struck me. Of course, it was easy to patch, I just had to adjust the reloaction table entry by 2 bytes as well. I updated the patch so that it patched this too. If you need to install this fix on your machine, the patch created a gpt_loader.bak file in the %SystemRoot%\drivers directory. Just restore the gpt_loader.bak to gpt_loader.sys, then apply the updated patch from here and also don’t forget to apply the second patch.

If you have further questions, feel free to ask.

Windows 7 Professional as RemoteApp Server

I found out, that Windows 7 Professional doesn’t support providing RemoteApps to clients per default, only Windows 7 Enterprise, Ultimate or higher provides this functionality.
But fortunately, I found this thread on github.
You need to follow all the instructions in the thread:
The following files can be found in various subdirectories of the %SystemRoot%\WinSXS directory and copied to the appropriate place:

%SystemRoot%\system32\rdpinit.exe
%SystemRoot%\system32\rdpshell.exe
%SystemRoot%\system32\TSErrRedir.dll
%SystemRoot%\system32\tspubwmi.dll
%SystemRoot%\system32\wbem\tsallow.mof
%SystemRoot%\system32\spp\tokens\ppdlic\terminalservices-remoteapplications-clientsku-ppdlic.xrm-ms

Then register the components:

RegSvr32 %SystemRoot\system32\tspubwmi.dll
mofcomp %SystemRoot%\system32\wbem\tsallow.mof

Now patch %SystemRoot%\system32\rdpinit.exe (0x8000404 to 0x00000001)

rdpinit.exe (1.7601.17514) 32bit:

0000568E: 04 01
0000568F: 40 00
00005690: 00 00
00005691: 80 00

rdpinit.exe (1.7601.17514) 64bit:

0000611D: 04 01
0000611E: 40 00
0000611F: 00 00
00006120: 80 00

Finally add registry keys:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\TerminalTypes\eddcc3ce-6e7e-4f4b-8439-3d9ad4c9440f]
"Name"="Remote Applications Terminal"
"SessionSource"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\ConnectionHandler\eddcc3ce-6e7e-4f4b-8439-3d9ad4c9440f]
"CLSID"="2be8bdbb-be09-499d-9a4b-4637e09ae00b"
"Description"="Default Connection Handler"
"Name"="Default Connection Handler"
"fAcceptConnection"=dword:00000001

Now restart Terminal services and use RemoteAppTool to create Remote Applications and .rdp files for the clients.

KB4500331 (fixes CVE-2019-0708) for Windows XP SP2

KB4500331 fixes a critical bug in Microsoft Windows RDP protocol in Windows XP and Windows 7.
The patch is available via the Microsoft update site. However it is only available for Windows XP SP3. When looking at the code, I found out that it also works properly with XP SP2, so if you are a user who cannot or doesn’t want to upgrade to XP SP3, here is my patched installer that also allows you to install the update on SP2.

“Word kann den Speichervorgang aufgrund eines Berechtigungsfehlers nicht zu Ende führen” Problem seit 22.2.2019

Diese Woche hatte ich gleich mehrere Benutzer, die plötzlich das Problem hatten, dass Microsoft Word keine Dateien mehr speichern konnte und oben genannte Fehlermeldung ausgaben.
Nach längerer Suche stellte sich heraus, dass wohl der Avira Antivirus an dem Problem schuld ist, ich musste das Programm daher entfernen und warte darauf, dass das Problem hoffentlich bald behoben ist. Ob Avira davon Kenntnis hat, weiß ich nicht. Die betroffenen Rechner liefen alle auf Windows 7, das kann aber auch Zufall sein.
Betroffen waren sowohl ältere (Word 2000), als auch neuere Word-Versionen (Word 2007)

Fixing an endless loop bug in the Xerox Unix printing Package 4.50.29 xsf tool

I got annoyed today by a Xerox printer that was driven via CUPS, where the queue hung forever from time to time.
So I investigated where it hung. Turns out, it got stuck in this loop:

int __cdecl SendLprCmd(int a1, int a2, int a3, int a4, int fd)
{
  int v5; // ST1C_4@21
  signed int v7; // [sp+10h] [bp-98h]@10
  int v8; // [sp+14h] [bp-94h]@17
  char s; // [sp+20h] [bp-88h]@2
 
  switch ( a1 )
  {
    case 1:
      sprintf(&s, "\x01%s\n", a2);
      break;
    case 2:
      sprintf(&s, "\x02%s\n", a2);
      break;
    case 7:
      sprintf(&s, "\x02%i %s\n", a3, a2);
      break;
    case 8:
      sprintf(&s, "\x03%i %s\n", a3, a2);
      break;
    case 3:
      sprintf(&s, "\x03%s\n", a2);
      break;
    case 4:
      sprintf(&s, "\x04%s\n", a2);
      break;
    case 0:
      s = 0;
      break;
    case 5:
    case 6:
      break;
  }
  RdBufI = 0;
  RdBuf = 0;
  if ( a1 )
    v7 = strlen(&s);
  else
    v7 = 1;
  if ( a1 == 1 )
  {
    write(fd, &s, v7);
  }
  else
  {
    while ( !pPN->byte38 )
    {
      if ( (pPN->byte38 || write(fd, &s, v7) == v7) && (v8 = GetLprResponse(a4, fd), v8 >= 0) && v8 != 1 )
      {
        if ( !v8 )
          return 0;
      }
      else
      {
        ReturnPrinterError(14, fd);
      }
      v5 = rand();
      sleep(v5 % 16 + 5);
    }
  }
  return 0;
}

Let’s have a look at ReturnPrinterError function:

int __cdecl ReturnPrinterError(int errcode, int fd)
{
  int *v2; // eax@2
  char v3; // ST14_1@2
 
  if ( errcode == 16 )
  {
    v2 = __errno_location();
    v3 = (unsigned int)strerror(*v2);
    WrStatus(pPN->fdError, "ERROR: %s\n", v3);
  }
  else
  {
    WrStatus(pPN->fdError, "ERROR: %s\n", (unsigned int)SocketErrorMsg[errcode]);
  }
  if ( fd > 0 )
    close(fd);
  return errcode;
}

So file descriptor gets closed in there and becomes invalid. Therefore write() call can never suceed again ever after, so we got stuck in an endless loop on error.
Upon calls of SendLprCmd, return value gets checked (0=success).
Turns out this function never returns anything different than 0. So conclusion: Routine shall return something != 0 in EAX if error occurs.
ReturnPRinterError always returns error code>0, so EAX gets set fine by this routine.
Let’s have a look at the ASM code of the call then:

.text:08049E9B loc_8049E9B:                            ; CODE XREF: SendLprCmd+17Dj
.text:08049E9B                                         ; SendLprCmd+19Dj ...
.text:08049E9B                 sub     esp, 8
.text:08049E9E                 push    [ebp+fd]        ; fd
.text:08049EA1                 push    0Eh             ; int
.text:08049EA3                 call    ReturnPrinterError
.text:08049EA8                 add     esp, 10h
.text:08049EAB                 jmp     short loc_8049EB8
.text:08049EAD ; ---------------------------------------------------------------------------
.text:08049EAD
.text:08049EAD loc_8049EAD:                            ; CODE XREF: SendLprCmd+1A8j
.text:08049EAD                 cmp     [ebp+var_94], 0
.text:08049EB4                 jnz     short loc_8049EB8
.text:08049EB6                 jmp     short loc_8049F0F
.text:08049EB8 ; ---------------------------------------------------------------------------
.text:08049EB8
.text:08049EB8 loc_8049EB8:                            ; CODE XREF: SendLprCmd+1BAj
.text:08049EB8                                         ; SendLprCmd+1C3j
.text:08049EB8                 sub     esp, 0Ch
.text:08049EBB                 sub     esp, 4
.text:08049EBE                 call    _rand
.text:08049EC3                 add     esp, 4

So instead of jumping back to rand sleep() routine, just let it bail out to 08049F14:

.text:08049F0F loc_8049F0F:                            ; CODE XREF: SendLprCmd+13Bj
.text:08049F0F                                         ; SendLprCmd+14Cj ...
.text:08049F0F                 mov     eax, 0
.text:08049F14                 leave
.text:08049F15                 retn
.text:08049F15 SendLprCmd      endp

JMP to rand() is EB 0B, so change it to new offset EB 67 @08049EAB:

08049E9C  EC 08 FF 75 18 6A 0E E8  D5 FC FF FF 83 C4 10 EB
08049EAC  0B 83 BD 6C FF FF FF 00  75 02 EB 57 83 EC 0C 83
-->
08049E9C  EC 08 FF 75 18 6A 0E E8  D5 FC FF FF 83 C4 10 EB
08049EAC  67 83 BD 6C FF FF FF 00  75 02 EB 57 83 EC 0C 83

So patch 0B @ file offset 1EAB to 67, problem fixed.

At least, bug seems to be fixed now, will have to look if there is an update to this buggy version of the printing system that runs on the target machine, but as it’s a productive machine, I first need a timeslot to test.