Announcement

Collapse
No announcement yet.

Converting hex to Chinese.

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Converting hex to Chinese.

    Hello,

    I have a program, Mcgs Configuration Installation Utility. They used the old Wise Installation Studio or whatever it's called to create the setup.exe file.

    Unfortunately, it seems they set the language locale code page to 1033 (English https://www.science.co.il/language/Locale-codes.php ) but didn't translate the text, so it shows as all garbage on my system. For example, when I start the program, the title bar says:
    Code:
    MCGSǶÈë°æxé̬Èí¼þ
    Here's the hex for that title screen:
    Code:
    00 4D 43 47 53 C7 B6 C8 EB B0 E6 D7 E9 CC AC C8 ED BC FE 20
    I'm trying to use a debugger to modify the program and eventually create a patch file that has English.

    I'm having a hard time trying to figure out how the hex encoding works though. 4D 43 47 53 is MCGS. I thought the rest was unicode, but I haven't been able to successfully convert it Chinese.

    Any one have any experience with this?

    So far, I've tried using on-line converters and tried hex values like:
    Code:
    C7B6 C8EB B0E6 D7E9 CCAC C8ED BCFE
    
    B6C7 EBC8 E6B0 E9D7 ACCC EDC8 FEBC
    The second one appeared almost chinese like on one converter site. It had some chinese looking characters, but when put into various Chinese to English translators, it was gibberish, not real words.

    Anyone know how a program stores Chinese characters in a binary format? The compiler that was used was the Microsoft Visual C / C++ compiler, according to a plugin I have that detects the compiler. I think it said version 7. I can double check if it's important.

    It's a 32-bit program but has calls to 16-bit APIs (well, they're 32-bit APIs, but Microsoft ported them and there's much better APIs to use now-a-days).

    It seems the compiler was using the _CDELC calling convention, or atleast the WISE installer is. Parameters to API calls are pushed onto the stack, in reverse order, ESI stores the API we're calling, etc.

    I can provide a link to the program if anyone's interested in looking at it or trying to help. I can provide offsets and the notes I've taken. I'm using x64dbg (well, the 32-bit version, x32dbg).

    Any help would be greatly appreciated.

    **EDIT: One thing to keep in mind, I think they were using a very old version of the Wise installer and Wise has not been used in years, so I don't think this is unicode or anything like that. I'm trying to google how the _CDELC calling convention stores chinese characters in 32-bit programs. But I might be on the wrong track here. Learning a lot in the process though.
    Last edited by Spork Schivago; 01-21-2018, 10:37 PM.
    -- Law of Expanding Memory: Applications Will Also Expand Until RAM Is Full

    #2
    Re: Converting hex to Chinese.

    Originally posted by Spork Schivago View Post
    For example, when I start the program, the title bar says:
    Code:
    MCGSǶÈë°æxé̬Èí¼þ
    Here's the hex for that title screen:
    Code:
    00 4D 43 47 53 C7 B6 C8 EB B0 E6 D7 E9 CC AC C8 ED BC FE 20
    So far, I've tried using on-line converters and tried hex values like:
    Code:
    C7B6 C8EB B0E6 D7E9 CCAC C8ED BCFE
    
    B6C7 EBC8 E6B0 E9D7 ACCC EDC8 FEBC
    6 of the 7 UTF-16 characters represented in the first of these appear to be valid Hangul codepoints -- with the exception of the U+D7E9 (but, that could be because I'm using v4 of the standard and its ~17 years old; new codepoints have undoubtedly been added!)

    [I've no idea how to paste the glyphs, here, to show them; google "U+" (without the quotes) followed by the 4 hex digits to find images of the glyphs]

    Also, be sure these are ASCIZ strings and not "counted" strings.

    Comment


      #3
      Re: Converting hex to Chinese.

      Yes, I did the same you did, but although they show glyphs, try putting them in a translator. It's gibberish.

      I do not think they're UTF-16 characters. I believe the code page is supposed to be 1028, but they have it set to 1033, which isn't easy to change yet.

      The fact that 16-bit API function calls are used (Microsoft ported them to 32-bit), I'm not certain this is UTF-16.

      I've compared the glyphs to an older version where the code page was set to 1028, and they look nothing similar....

      I think, when properly "decoded", it should look a bit like this:
      Code:
      MCGS嵌入版组态软件 安装
      -- Law of Expanding Memory: Applications Will Also Expand Until RAM Is Full

      Comment


        #4
        Re: Converting hex to Chinese.

        Also, wouldn't the MCGS be UTF-16? The old Wise Installation program is calling ANSI API calls, which didn't support unicode back in the days of XP, although some limited support was added somewhere along the lines if I remember correctly.
        -- Law of Expanding Memory: Applications Will Also Expand Until RAM Is Full

        Comment


          #5
          Re: Converting hex to Chinese.

          Originally posted by Curious.George View Post
          ...
          Also, be sure these are ASCIZ strings and not "counted" strings.
          What do you mean ASCII strings and not "counted" strings?

          **EDIT: Around 5:10, you'll see what it's supposed to look like: https://www.youtube.com/watch?v=-X8OZgCoQjI

          I need to find away to convert those hex values into what that title of that window looks like. Once I can do that, I can work on converting the rest of the program.

          Thanks for helping.
          Last edited by Spork Schivago; 01-21-2018, 11:26 PM.
          -- Law of Expanding Memory: Applications Will Also Expand Until RAM Is Full

          Comment


            #6
            Re: Converting hex to Chinese.

            Originally posted by Spork Schivago View Post
            Yes, I did the same you did, but although they show glyphs, try putting them in a translator. It's gibberish.
            Can't help you, there.

            I do not think they're UTF-16 characters. I believe the code page is supposed to be 1028, but they have it set to 1033, which isn't easy to change yet.

            The fact that 16-bit API function calls are used (Microsoft ported them to 32-bit), I'm not certain this is UTF-16.
            If the series of bytes that you presented is what you saw in memory, it is more likely that it is a UTF-8 "string" because the "MCGS" characters map to the single-byte codepoints at 4D 43 47 53. If it was a UTF-16 representation (as is common in modern Windows API), each character would have required two bytes (e.g., 00 4D 00 43 00 47 ...)

            I've compared the glyphs to an older version where the code page was set to 1028, and they look nothing similar....
            Can't help with codepages. I deal with ASCII and UTF-16 directly.

            I think, when properly "decoded", it should look a bit like this:
            Code:
            MCGS嵌入版组态软件 安装
            Have you tried pasting it into an encoder and seeing what the result looks like?

            Comment


              #7
              Re: Converting hex to Chinese.

              Originally posted by Curious.George View Post
              ...
              If the series of bytes that you presented is what you saw in memory, it is more likely that it is a UTF-8 "string" because the "MCGS" characters map to the single-byte codepoints at 4D 43 47 53. If it was a UTF-16 representation (as is common in modern Windows API), each character would have required two bytes (e.g., 00 4D 00 43 00 47 ...)
              This is actually in the binary itself, I can give offsets. So when a Windows API is called, it reads those specific bytes and displays them as is, without any type of conversion. I would think if the WISE Installer program they used to create this setup.exe supported UTF-8, they wouldn't appear in the title screen as they do now. The APIs they call just simply print them to the screen as is. It does not do anything to decode them, it does not treat them as UTF-8. It does not seem to treat them as unicode at all.

              Originally posted by Curious.George View Post
              Can't help with codepages. I deal with ASCII and UTF-16 directly.



              Have you tried pasting it into an encoder and seeing what the result looks like?
              Yes, I have tried many things. Encoders, decoders. The only thing that kinda looked like the Chinese glyphs where the UTF-8, like you discovered, but I think that's just a bit of luck there. The fact that the hex editor shows the string exactly as the title bar, and the disassembler just loads the string and passes it to an ANSI API call, I'm going with this isn't unicode (or UTF-anything).

              I think I have to research these code pages a bit more. I tried finding a hex to character-code whatever decoder / displayer, but I couldn't. But I, like you, don't know very much about code-pages and have to learn a bit more first I guess.

              In Linux, we used to be able to pick what code-pages we wanted to support, and depending on what code-page we picked, characters would look differently. I think if I can change the code page to the chinese one I listed earlier (1028d), it'd display properly.

              It's my understanding that with unicode (UTF-8, UTF-16, etc), we don't use code-pages anymore. Been a while since I majored in Computer Science and worked as a system programmer, so please feel free to correct any misunderstandings I have.

              Thanks guys.

              **EDIT: I think this site puts me on the right track. I think those are Double-Bytes Character Sets (DBCS), which Microsoft developed for languages like Chinese, Japanese, etc, and aren't used much anymore.

              https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx
              Last edited by Spork Schivago; 01-22-2018, 03:13 PM. Reason: Added information about double-bytes character sets.
              -- Law of Expanding Memory: Applications Will Also Expand Until RAM Is Full

              Comment


                #8
                Re: Converting hex to Chinese.

                GBK or GB18030 look right.

                https://r12a.github.io/apps/encodings/

                Go there, paste the hex bytes:
                Code:
                4D 43 47 53 C7 B6 C8 EB B0 E6 D7 E9 CC AC C8 ED BC FE
                Into the box on the right, hit convert, and it appears to convert it to something translatable. Those two encodings (GBK and GB18030) both translate to:
                Code:
                MCGS Embedded Edition configuration software
                Which seems a bit more reasonable. Now that I know what encoding was used, I just need to figure out how to convert it manually. After my last post and a lot of reading, I thought it might be big-5. Kinda got lucky finding that converter there. I was looking for a big-5 to ASCII converter. That led me to some page that wanted it in actual ASCII. But other pages came up and decided to search for:
                Code:
                gbk big5 sjis ksc hex converter
                Third link down had what I wanted. First link didn't do the job, I downloaded the program and went to installed, but while I was waiting, I tried the other programs.

                Just gotta figure out how to manually read the encodings and see how they're decoded, etc. But at least I can continue now.


                For people who have used debuggers to modify programs, if the hex bytes I'm trying to overwrite are longer than what's originally there, can I just extend the code and modify the API call to read a bit extra, or do I need to create a code-cave and call my code-cave to pull the english data from the end of the file or something? You know, append the data at the end, then read it from there?

                Thanks!
                -- Law of Expanding Memory: Applications Will Also Expand Until RAM Is Full

                Comment


                  #9
                  Re: Converting hex to Chinese.

                  I'm now thinking it might be easier to finder a newer installer program, something like Wise, but perhaps free, and that supports Unicode. Extract the various files, step through the code to see what gets installed where or what registry entries get created / modified, try to use some language.ini file or something to store the various languages, and have it read from that.

                  I can at least figure out what the program is supposed to say now, by following it in the disassembler, seeing the broken language in the program, seeing it in the hex editor, using the gbk decoder site, google translate, etc, and install it / use it. I guess that's a start.
                  -- Law of Expanding Memory: Applications Will Also Expand Until RAM Is Full

                  Comment


                    #10
                    Re: Converting hex to Chinese.

                    I think I'm going to try to recreate the setup.exe file using Inno. I guess that came a long way and supports Unicode. Maybe I can use it to display Chinese for the Chinese, English for the English speaking people, send a copy to the company.

                    Thanks for all the help. Would have never figured this out without your help Curious.George. You changed the way I was thinking and looking at it, and I was able to figure out the encoding because of that.

                    Thanks!!!!!!
                    -- Law of Expanding Memory: Applications Will Also Expand Until RAM Is Full

                    Comment


                      #11
                      Re: Converting hex to Chinese.

                      Originally posted by Spork Schivago View Post
                      I think I'm going to try to recreate the setup.exe file using Inno. I guess that came a long way and supports Unicode. Maybe I can use it to display Chinese for the Chinese, English for the English speaking people, send a copy to the company.
                      You might, instead, want to prepare all the translations of the program's "resources" and send them to the company BEFORE bundling them into an executable/installer.

                      I suspect most companies would be leary of accepting a "binary of unknown origin" -- especially if you were expecting them to redistribute it. However good intentioned you may be, they would have to suspect the integrity of the "product" you are now asking them to distribute as "their own".

                      I.e., do the "hard part" (sorting out what needs to be translated, and how) and let them do the easy part (verify the other files are untainted and rebundle your resources into a new "product"). They may, for example, have other corporate standards -- or tools -- that their policies "force" them to use.

                      And, don't be surprised (or insulted!) if they say "Thank You -- but we're not interested" (in some form or another). Instead, consider your effort as a possible indication to the company of the value of an English localized version of their products in the future.

                      Comment


                        #12
                        Re: Converting hex to Chinese.

                        I wasn't actually going to send them the binary. Just the script and "resources" as you say. I wrote them an e-mail in English and Chinese (using google translate) telling them about Inno and asking if they would like me to send the script so they can download Inno, build a proper setup.exe file, and have multi-language support. The only e-mail address I could get was from whois lookup, but I never received a response.

                        I told them about the problem with their current program as well. I'm afraid they might not speak English at all and Google Translate might not do the best job of translating my text, so maybe they receive an e-mail they cannot understand.

                        I tried writing to the company about a year ago asking if they wanted help translating their manuals to English, for free. I wrote a hand letter because I couldn't find an e-mail address at the time.

                        I know rules are different in China and encryption is one of those things. Right now, I believe certain types of encryption are illegal, or you need a license and can only use it in company or something. Hard finding English documents on this, but things might be changing. I think over in China, the government likes to monitor the sites that users can go to, and for all I know, the country might be blocking my gmail e-mail address.

                        I know when I was going to go over, my old company got me a 90 day VISA (before the flood we had, I never ended up going, unfortunately) and they gave me a prep talk. No tye dye tee-shirts, no peace signs, someone will be following me the whole time, don't notice the person, don't do anything that I do in the states (they knew I used to "party"), stuff like that. And no matter what, don't try performing any "security audits" on any PCs! Over there, they execute hackers!!!! Chop their heads right off sometimes I guess.

                        I was tempted to create the Inno files and if they didn't want them, put them up on github, but I think I'd be breaking some copyright laws. I wouldn't be claiming the program was mine or anything, I'd just offer a multi-language setup program, and maybe eventually, a multi-language program.
                        -- Law of Expanding Memory: Applications Will Also Expand Until RAM Is Full

                        Comment


                          #13
                          Re: Converting hex to Chinese.

                          Did you ever try just changing the system locale to Chinese?
                          See the following photo:


                          I program PLC's using a software by Fatek called WinProLadder.
                          The program is not Unicode aware, so when I load a project file written by the Taiwanese machine builder all the projects comments show up as gibberish.
                          But if I change the system locale and reboot (which is very annoying) as the picture above shows then the Chinese characters show up fine.
                          Of course I have to then change it back when I'm done with WinProLadder else everything else on my PC which is not Unicode aware will display the wrong characters...

                          I found an old abandoned Microsoft program called "AppLocale" that gets around that.
                          I'm using the modified version called pAppLocale from that Wikipedia page.
                          Attached Files
                          Last edited by Per Hansson; 01-28-2018, 05:58 AM.
                          "The one who says it cannot be done should never interrupt the one who is doing it."

                          Comment


                            #14
                            Re: Converting hex to Chinese.

                            Originally posted by Per Hansson View Post
                            Did you ever try just changing the system locale to Chinese?
                            See the following photo:


                            I program PLC's using a software by Fatek called WinProLadder.
                            The program is not Unicode aware, so when I load a project file written by the Taiwanese machine builder all the projects comments show up as gibberish.
                            But if I change the system locale and reboot (which is very annoying) as the picture above shows then the Chinese characters show up fine.
                            Of course I have to then change it back when I'm done with WinProLadder else everything else on my PC which is not Unicode aware will display the wrong characters...

                            I found an old abandoned Microsoft program called "AppLocale" that gets around that.
                            I'm using the modified version called pAppLocale from that Wikipedia page.
                            Actually, I did. For 7 though, I had to convert to Ultimate. And because I'm running in a virtual machine, I only had a key for Home Premium. I know this isn't right, but I built a KVM BIOS for the HPE DL380 Gen 9 that had SLIC 2.1 data specifically for the DL380 Gen 9. I then used the Windows Anytime Upgrade and some key I found online to upgrade 7 to Ultimate. The key didn't work though, it wouldn't activate, so I had to do the SLIC BIOS stuff and use an HP Ultimate pre-activation key with the cert, which worked fine.

                            I installed all the languages, I switched the Locale, but it didn't help. The reason is because although the language is in Chinese, in the actual program, they have the codeset set to 1033, English. The goal was to change that to Chinese, which isn't hard, using something like PE Explorer (or even a free alternative), but the Wise Installation program they used to create the Setup.exe has checksums, many. And I was following it in the debugger, but it was taking too much time. It extracts some wise programs, names them with a .tmp extension, executes another wise program (the main one). The actually programs are encrypted, and breaking that encryption is a pain. It'd take months to follow it all, for someone like me. I could never actually find the Chinese characters in the program, using the disassembler, because of the encryption or compression it uses. What a pain in the butt. Anyway, I just installed with all the giberish and I think it works, even though everything's gibberish (file names, device names, menus, etc). But I can find my way around. They attempt some English stuff, there's some English DLL file and a Chinese one.

                            If you understand PLC Ladder Logic, maybe you could help. On the HMI touch screen device, the columns for the BGA don't make sense. We know what they do, but we want to rename them. Would that be in the PLC Ladder Logic or would that be something in the actually HMI firmware code or something?

                            Thanks.
                            -- Law of Expanding Memory: Applications Will Also Expand Until RAM Is Full

                            Comment


                              #15
                              Re: Converting hex to Chinese.

                              That does not make sense, if the program only supports Chinese surely with a Chinese Windows install you'd get Chinese?
                              Did you actually change the setting I show above, which is "Language for non-Unicode programs"
                              (That setting does not change the system language, and does not require Ultimate AFAIK).

                              Originally posted by Spork Schivago View Post
                              If you understand PLC Ladder Logic, maybe you could help. On the HMI touch screen device, the columns for the BGA don't make sense. We know what they do, but we want to rename them. Would that be in the PLC Ladder Logic or would that be something in the actually HMI firmware code or something?

                              Thanks.
                              Usually that would be in the HMI.
                              The HMI should generally have a setup interface that allows to select languages.
                              Of course it it has not been translated there will only be Chinese to select...
                              "The one who says it cannot be done should never interrupt the one who is doing it."

                              Comment


                                #16
                                Re: Converting hex to Chinese.

                                Originally posted by Spork Schivago View Post
                                If you understand PLC Ladder Logic, maybe you could help. On the HMI touch screen device, the columns for the BGA don't make sense. We know what they do, but we want to rename them. Would that be in the PLC Ladder Logic or would that be something in the actually HMI firmware code or something?
                                Have you examined the program in detail to know, for sure that your efforts will actually result in a usable product? If they didn't address L12N then they probably didn't prep for it with I18N, either! So, you may find you only succeed in making it a little less of a bastard implementation but still stuck with characteristics that make it tedious to use.

                                What market do you think they were addressing?

                                Are you of the belief that they just "used Chinese" for words that they couldn't translate into English? Or, did they design AS IF a Chinese market and just paste in a few English words/phrases??

                                For example, columns may be narrower because their (textual) content, in Chinese, requires less horizontal space than English (or other romance languages).

                                Dates are presented as 2018-01-28 instead of 1/28/2018.

                                Colors have different connotations to the Chinese than westerners. E.g., red doesn't have the negative connotation that it carries in the West.

                                Etc.

                                Consider how (if!) you can change these aspects of the program. Otherwise, you may just end up spending a lot of effort on superficial things. (i.e., you may find yourself back where you started, but with a different binary!)

                                Comment


                                  #17
                                  Re: Converting hex to Chinese.

                                  Originally posted by Per Hansson View Post
                                  That does not make sense, if the program only supports Chinese surely with a Chinese Windows install you'd get Chinese?
                                  Did you actually change the setting I show above, which is "Language for non-Unicode programs"
                                  (That setting does not change the system language, and does not require Ultimate AFAIK).
                                  I must be in the wrong place, because when I go to Control Panel -> Region and Language, I set it, it changes the Recycle Bin to Chinese, etc.

                                  Let me try to explain better. The text is in Chinese, but with a resource editor, we see the code page in the file is set to English. When I run it, it picks 1033 for me, but the text is still in Chinese. I think the programmers thought they could just pick the English code-set and it'd convert the language itself to English. I don't think they realized they had to actually write the text in English as well, hence the reason it shows up as junk.

                                  But if I can set it your way, the resource will still be set to 1033, which is stored in the actual setup.exe file. And because the 1033 codeset page doesn't display Chinese characters, I don't think it'll work, unless I'm missing something. I can send a screen shot of the options I have under Region and Language. It's a bit different than what your screen shot looks like. It's been a while since I ran 7, so maybe I'm just clicking the wrong icon.

                                  Originally posted by Per Hansson View Post
                                  Usually that would be in the HMI.
                                  The HMI should generally have a setup interface that allows to select languages.
                                  Of course it it has not been translated there will only be Chinese to select...
                                  The language on the HMI is in English, so let me try to explain better.

                                  There's a table, something like this (I'm pulling it from memory so it's not right, just an example)
                                  Code:
                                           PREHEAT1   PREHEAT2  TEMP1  TEMP2  PREHEAT3  COOLDOWN
                                  ================================================================================
                                  Temp
                                  Ramp Speed
                                  Ramp Temp
                                  Time
                                  etc...
                                  However, some of those values are wrong, at least in my mind. Ramp Speed should be how fast it heats up. Ramp Temp should be that temperature. For example, I should be able to set Ramp Tempt to 2 degrees C and Ramp Speed to 2 seconds, and I would expect the preheater / heating element will heat up 2 degrees celsius every 2 seconds, until the target temp is reached, and then hold it there. However, those two are backwards on my unit. Ramp Speed is actually the time, Ramp Temp is actually how quickly to raise it, or something like that. That's what I want to change.

                                  I'd also like to rename some of the columns / row headers to something a bit more meaningful. In my example, they're pretty straight forward. I mean, I don't understand the purpose of a second pre-heater, but my BGA rework station has two. But in real life, the rework station labels don't make much sense. Trial and error is how you figure out what they are. My goal was to just modify either the software on the HMI or the ladder logic (I would think the HMI, because the ladder logic just controls the relays, right?) and have them make more sense as to what their actual functions are....

                                  That's all.
                                  -- Law of Expanding Memory: Applications Will Also Expand Until RAM Is Full

                                  Comment


                                    #18
                                    Re: Converting hex to Chinese.

                                    Originally posted by Curious.George View Post
                                    Have you examined the program in detail to know, for sure that your efforts will actually result in a usable product?...
                                    Yes, I've examined the program in detail.

                                    Originally posted by Curious.George View Post
                                    What market do you think they were addressing?
                                    The American and Chinese market, because there's an English .dll and a Chinese .dll.

                                    Originally posted by Curious.George View Post
                                    Are you of the belief that they just "used Chinese" for words that they couldn't translate into English? Or, did they design AS IF a Chinese market and just paste in a few English words/phrases??
                                    I believe they thought they could just change the codepage to English, and their Wize Setup Installation creator program would automatically convert the Chinese words to English for them. I don't think they realized they actually had to convert the text themselves. All of the text in the setup program are set to GB18030. But using a resource editor, the language is set to 1033, which is English. This is why when you run the program, instead of seeing English or Chinese text, you see gibberish. The English codepage just doesn't have those symbols. Normally, I could simply switch the codepage to Chinese and they'd display as proper chinese glyphs or whatever it is (which I've done with some of it), but there's a lot of CRC-32 checksums and I've given up on trying to convert it all. The program seems to install correctly, even though the filenames are all jacked up. The OS seems to understand what files the programs are trying to run....so I can use the actual program that gets installed.

                                    Originally posted by Curious.George View Post
                                    For example, columns may be narrower because their (textual) content, in Chinese, requires less horizontal space than English (or other romance languages).

                                    Dates are presented as 2018-01-28 instead of 1/28/2018.

                                    Colors have different connotations to the Chinese than westerners. E.g., red doesn't have the negative connotation that it carries in the West.

                                    Etc.
                                    I'm not following you here Curious.George. What columns are you referring to? Are you talking about where I convert the Chinese "text" to English in the actual setup program? I don't know how much you know about PCs or how code is actually executed, but I can replace words in a program with the same number of characters or less, but not more.

                                    Let's take the old MS-DOS boot sector on a bootable floppy for example. . We configure the BIOS to try to boot off floppy first. You'll get some message saying something along the lines of:
                                    Code:
                                    Starting MS-DOS...
                                    We could use a hex editor to change that text to something like:
                                    Code:
                                    Spork's OS...
                                    But we couldn't easily use a hex editor to insert code (instead of overwritting the current text) to say something like:
                                    Code:
                                    Starting Spork Schivago's Operating System...
                                    Because "Starting Spork Schivago's Operating System..." is longer than Starting MS-DOS.

                                    Instead, we could find where the code is that loads that string, and instead, replace it with a jmp statement to jump to some place new. We could over-write some code that we know won't be used, and replace that code with new code, code that says "Starting Spork Schivago's Operating System..." and then we can jump back to where ever the "program" left off at.

                                    This is what people call a code-cave. This is what I was going to do with the Chinese program. Instead of over writing the Chinese hex characters with English ones, I was going to write some code-caves.

                                    I was curious as to if I could just append my code-cave at the end of the program, or if I would have to actually over-write code that was non-essentially (for example, the sub-routines for the demo mode of the Wise installer program). Those sub-routines will never get called because the creators of the programmed used a fully registered version. There's a check early on (offset A300 in the program I believe), where if the physical byte is a 0, it's considered to have been created with a fully registered version of Wise. If it's not a 0, it's considered to be created with a trial version, and checks to make sure the setup.exe program was being ran on the computer it was actually created on.


                                    Originally posted by Curious.George View Post
                                    Consider how (if!) you can change these aspects of the program. Otherwise, you may just end up spending a lot of effort on superficial things. (i.e., you may find yourself back where you started, but with a different binary!)
                                    All I wanted was to be able to read what the text said, either using an on-line Chinese to English translator, or converting it to English. But I have since given up.

                                    Been diagnosed with some shitty stuff, and just don't got the energy to try or care about it anymore. Just gonna run it the way it is, and try to figure out what each thing does.

                                    Keep in mind, the actual HMI interface is in English. This program just allows me, once installed, to hook up to the HMI interface and the PLC controller, to modify the program on the BGA rework station, the PLC ladder logic, etc.

                                    The ultimate goal was to change the BGA interface a bit, so things made sense. Right now, they have a couple fields that aren't very clear, and a few that are switched. If you need or really want to see what fields, I could go down, hook everything back up, power up the BGA rework station, take a screen shot, upload it here, and show you.

                                    The program I'm trying to install is how you create software for the HMI interface that the creators (Scottle) used in my BGA rework station.
                                    -- Law of Expanding Memory: Applications Will Also Expand Until RAM Is Full

                                    Comment


                                      #19
                                      Re: Converting hex to Chinese.

                                      Originally posted by Spork Schivago View Post
                                      For example, columns may be narrower because their (textual) content, in Chinese, requires less horizontal space than English (or other romance languages).
                                      I'm not following you here Curious.George. What columns are you referring to? Are you talking about where I convert the Chinese "text" to English in the actual setup program? I don't know how much you know about PCs or how code is actually executed, but I can replace words in a program with the same number of characters or less, but not more.
                                      I'm just making general statements about how one internationalizes a program. The point being that a whole phrase in "English" may reduce to a couple of ideograms in some other language (e.g., "Chinese"). So, setting aside space for the English phrase in the code segment AND ON THE DISPLAY DEVICE can be counterproductive when the program is localized to Chinese -- that "column" (of text) may end up wastefully wide while another is woefully narrow.

                                      But we couldn't easily use a hex editor to insert code (instead of overwritting the current text) to say something like:
                                      Code:
                                      Starting Spork Schivago's Operating System...
                                      Because "Starting Spork Schivago's Operating System..." is longer than Starting MS-DOS.[/CODE]

                                      Instead, we could find where the code is that loads that string, and instead, replace it with a jmp statement to jump to some place new. We could over-write some code that we know won't be used, and replace that code with new code, code that says "Starting Spork Schivago's Operating System..." and then we can jump back to where ever the "program" left off at.
                                      Your example isn't pedantic, enough.

                                      Consider displaying the string "wwwwwww" in place of the string "iiiiiii". Both occupy the same amount of space in the code segment. But (for a proportional font), the former consumes more display real estate than the latter! My point is that, takes up more display real estate than the concatenated string ':' "violin" ':'.

                                      When you internationalize a program, you have to consider the requirements of each representation. Typically, the code segment representation can be automatically accommodated by delayed binding (e.g., dynamic linking). So, you replace a resource package with a set of resources for a different locale -- and everything is hunky dory within each of those "packages" (DLL's in your case). You don't have to fudge one part of the package while preserving the balance -- you treat it as a completed set.

                                      I was curious as to if I could just append my code-cave at the end of the program, or if I would have to actually over-write code that was non-essentially (for example, the sub-routines for the demo mode of the Wise installer program).
                                      That's hard to know from external observation. Even if a piece of code LOOKS like it isn't referenced, you have no idea if there aren't some set of circumstances that cause it to be referenced. Having replaced it with stuff of your own leaves the program helpless in that event as it was expecting something other than what you'd placed there.

                                      For example, many programs have easter eggs buried within. The code can run for years and never touch that easter egg reveal code. This could make it a likely candidate to be overlaid. OTOH, if someone deliberately tried to reveal one of those easter eggs, they might be stunned by the program crashing or running off in some unusual direction (because your patch had it doing something "unexpected" for which it was "unprepared")

                                      All I wanted was to be able to read what the text said, either using an on-line Chinese to English translator, or converting it to English. But I have since given up.
                                      Try replacing strings with numeric strings: "S01", "S02", "S03", ... Then, watching where they appear (on screen) to sort out their meanings. A string may be reused in multiple places so you really want to be able to identify which instance of a string is being displayed in which place.

                                      Keep in mind, when replacing multibyte characters, that you are replacing CHARACTERS, not BYTES. So, if you replace a 2 byte character, make sure you replace it with 2 ASCII characters. If, instead, you replace it with just one, then the second byte of the 2-byte character will be interpreted as the first byte of a new character. Depending on its actual value, this might be some bizarre/unexpected ASCII character or the first of a bogus 2-byte character (the second byte of which is actually the first byte of some other character)

                                      Been diagnosed with some shitty stuff, and just don't got the energy to try or care about it anymore.
                                      Sorry to hear that.

                                      Keep in mind, the actual HMI interface is in English. This program just allows me, once installed, to hook up to the HMI interface and the PLC controller, to modify the program on the BGA rework station, the PLC ladder logic, etc.
                                      The "S01" approaches might be sufficient, then. Just make a cheat sheet on a piece of scrap paper so you know what each "S" parameter means... Pretend you're programming a Hayes modem!

                                      Comment


                                        #20
                                        Re: Converting hex to Chinese.

                                        Originally posted by Spork Schivago View Post
                                        I must be in the wrong place, because when I go to Control Panel -> Region and Language, I set it, it changes the Recycle Bin to Chinese, etc.

                                        Let me try to explain better. The text is in Chinese, but with a resource editor, we see the code page in the file is set to English. When I run it, it picks 1033 for me, but the text is still in Chinese. I think the programmers thought they could just pick the English code-set and it'd convert the language itself to English. I don't think they realized they had to actually write the text in English as well, hence the reason it shows up as junk.
                                        If it picks English obviously your operating system is telling the program that your system language is English.
                                        Otherwise you'd get Chinese!

                                        The screenshot I showed above of how to change the Language for non-Unicode programs in Windows 7 is pretty much the same in Windows 10 too.
                                        They have just split Region & Language into separate entities.
                                        The path for 7 and 10 is: Control Panel > Region (& Language) > Administrative > Change System Locale
                                        "The one who says it cannot be done should never interrupt the one who is doing it."

                                        Comment

                                        Working...
                                        X