• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!
  • Fill out your device list and let everyone know which phones you have!    Edit Your Device Inventory

powkiddy x16 SoC droid clone?

Search This thread

godkingofcanada

Senior Member
Nov 13, 2013
1,000
454
Anyone seen these handheld retro units from China? Gba, gb, gbc, nes, snes, Sega, psx, cps1+2.

I'm trying to locate firmware. Factory or otherwise, trying to figure out what this is running.
 

Attachments

  • IMG_20181218_130547.jpg
    IMG_20181218_130547.jpg
    252.7 KB · Views: 274
Feb 11, 2021
16
2
The emulators are all in common. There's an emulator app called ... emulator.app which uses some emulator lib that doesn't actually do much and then also these different libs that I mentioned above.
In the emulator.app of the Powkiddy X6 at least there's this function:
judge_gametype_byname(char *name)
which looks at the file extension I assume and based on this decides what type of game it is. For the .bin extension though it seems to look at something else also.
Once it determines this it assigns the gametype global variable a value ( 1 is NES , 6 is PS1 and there's like 7 numbers all till 10 ). There's some other variables I think to detect if it supports this emulator and what type of library it needs.
Then still in the emulator.app there's the function that loads the right emulator based on gametype and it loads one of the libs I mentioned above.
All of these libs have a common interface from what I can tell , probably something like save game, pause game, exit game and the emulator app transfers control to the appropriate lib ( based on gametype ) which then does its thing as it needs to.

I'm not sure what improvements are made to these emulation libraries, most seem to rely on quite old code even on the X16 which is quite a new device. In theory they could synchronize with the upstream emulator code but sometimes upstream is abandoned or semi-abandoned. Also depending on how much the needed to modify the emulator to fit into their framework it might not be trivial to pick up the newer changes especially if it diverged quite a bit.

There's also the question of the license , most of these emulators are licensed under GPL or LGPL so there's the obligation to publish the source code but I'm not sure there's any way to enforce this, especially in China. We could try though. Getting the source code to the emulators could allow either to synchronize them with upstream or to completely replace the emulation core while keeping only the interfaces.

Hope that answers your question :)
Thanks for the breakdown, that completely makes sense based on how the system works. I agree, using commercially available open source emulators should give us the right to make changes and keep them updated. Can you see any advantage as to why they chose a software/UI like this considering how much different it is compared to any other emulation handheld?..
 
Last edited:

mforce2

Senior Member
Feb 14, 2009
103
53
Thanks for the breakdown, that completely makes sense based on how the system works. I agree, using commercially available open source emulators should give us the right to make changes and keep them updated. Can you see any advantage as to why they chose a software/UI like this considering how much different it is compared to any other emulation handheld?..
If you mean why not use Dingux or some Linux I've wondered myself but digging through all this I got the answer. Actions was into making mp3 and what the Chinese called mp4 and mp5 players. Those were video players actually. The ATK2279 was initially developed for this and it seems like their newer ATS3603 is a rebrand or this.

Since these video players ( some of which even had a touch screen ) are no longer popular these days with people just using their mobile phone I guess Actions tried to get into different markets. They tried the toys market with the ATS3603 ( https://www.programmersought.com/article/18267220/ ).

I think Powkiddy saw the opportunity and actions still had plenty of chips ( maybe even boards ) that they were willing to sell cheap. The video players that Actions had were all running UCOS ( from Micrium which is now open source ) due to legacy reasons I assume and also cost. UCOS seems to have lower requirements than Linux as far as RAM and Flash go.

I did see some mentions of Linux for ATJ3603 and even for ATJ2279 but I never really found any code or products actually running Linux on these SOCs.

To sum it up, Powkiddy got cheap leftover Actions SOCs and Actions had the SDK for UCOS that they just gave to Powkiddy with everything , it seems even including the emulator libs. It's likely Powkiddy did some small adaptations for their hardware but it would have been really hard for them to use anything other than the Actions SDK based on UCOS. They also probably don't have the rights ( from Actions ) to publish any code but also they most likely are unwilling to do so anyway.
 

o-marshmallow

Senior Member
Feb 26, 2011
85
6
Hello @mforce2 and @ThegreatHAMbino !

You just gave a lot of info, I had never found the PDF explaining the whole dev process before, I wish you were here few years ago when we started the first thread :LOL:
There are still some issues because we don't have the toolchain they are using (SDE). SDE has been replaced and I was not able to find it back.

Regarding the modified firmware, I did the step step as you did: I used the atjboottool you found, it gave me an SQL database. I guess it's the role of the flasher to go through the tables and flash the files one by one to the NAND flash. Anyway, I checked all the table with a classic SQL database explorer, then I checked the configuration files (txt), and there was a single flag called "mount system partition = 0" or something like that. My goal was to find the bit in the encrypted firmware in order to modify it. The fact is the encryption used by ATJ is quiet simple, each byte is encoded by using a XOR with a specific value, the good thing is each byte is encoded independently. This means that changing encrypted byte X will not affected byte X+1 encryption/decryption.

Anyway, after understanding this, and after finding the byte to modify, it was quiet simple, so I used a hex editor (dhex on linux) to modify directly the encrypted firmware.

I hope it was not too confusing :ROFLMAO:

I haven't tried modifying/adding a whole file to the SQL database and re-encrypting it. In that case, we'd need to write an ATJEncryptTool as I couldn't find one
 
  • Like
Reactions: ThegreatHAMbino

mforce2

Senior Member
Feb 14, 2009
103
53
Hello @mforce2 and @ThegreatHAMbino !

You just gave a lot of info, I had never found the PDF explaining the whole dev process before, I wish you were here few years ago when we started the first thread :LOL:
There are still some issues because we don't have the toolchain they are using (SDE). SDE has been replaced and I was not able to find it back.

Regarding the modified firmware, I did the step step as you did: I used the atjboottool you found, it gave me an SQL database. I guess it's the role of the flasher to go through the tables and flash the files one by one to the NAND flash. Anyway, I checked all the table with a classic SQL database explorer, then I checked the configuration files (txt), and there was a single flag called "mount system partition = 0" or something like that. My goal was to find the bit in the encrypted firmware in order to modify it. The fact is the encryption used by ATJ is quiet simple, each byte is encoded by using a XOR with a specific value, the good thing is each byte is encoded independently. This means that changing encrypted byte X will not affected byte X+1 encryption/decryption.

Anyway, after understanding this, and after finding the byte to modify, it was quiet simple, so I used a hex editor (dhex on linux) to modify directly the encrypted firmware.

I hope it was not too confusing :ROFLMAO:

I haven't tried modifying/adding a whole file to the SQL database and re-encrypting it. In that case, we'd need to write an ATJEncryptTool as I couldn't find one
Yeah, got that , thanks a lot. Well in the meantime I kinda figured it out, all except the modify the bit in the encrypted firmware, that didn't occur to me. I guess based on the decrypt software we could write one that does the encryption back.

I also sent you an email ( because I didn't know if you'll be back around here ) telling that I've found the SDE and looking at the debug symbols in the files it's the same version of SDE gcc that was used to build the binaries on my Powkiddy J6.
Both the Powkiddy J6 and the X16 were built under cygwin by this misterious Mr Huang , we really need to find him.
Anyway the SDE is here: https://drive.google.com/file/d/1HWbOy6a19PbnGPQ_crRHC-a6Y-O7P1Em/view?usp=sharing
 
Feb 11, 2021
16
2
Hello @mforce2 and @ThegreatHAMbino !

You just gave a lot of info, I had never found the PDF explaining the whole dev process before, I wish you were here few years ago when we started the first thread :LOL:
There are still some issues because we don't have the toolchain they are using (SDE). SDE has been replaced and I was not able to find it back.

Regarding the modified firmware, I did the step step as you did: I used the atjboottool you found, it gave me an SQL database. I guess it's the role of the flasher to go through the tables and flash the files one by one to the NAND flash. Anyway, I checked all the table with a classic SQL database explorer, then I checked the configuration files (txt), and there was a single flag called "mount system partition = 0" or something like that. My goal was to find the bit in the encrypted firmware in order to modify it. The fact is the encryption used by ATJ is quiet simple, each byte is encoded by using a XOR with a specific value, the good thing is each byte is encoded independently. This means that changing encrypted byte X will not affected byte X+1 encryption/decryption.

Anyway, after understanding this, and after finding the byte to modify, it was quiet simple, so I used a hex editor (dhex on linux) to modify directly the encrypted firmware.

I hope it was not too confusing :ROFLMAO:

I haven't tried modifying/adding a whole file to the SQL database and re-encrypting it. In that case, we'd need to write an ATJEncryptTool as I couldn't find one
I'll help out anyway I can. That's really why that first thread was so crucial because that's where the debugger and development pdf came from. I really appreciate the feedback and help you've given so far. Wasn't there for the first thread, but I'll damn sure be there for the second one 😆
 
Feb 11, 2021
16
2
Yeah, got that , thanks a lot. Well in the meantime I kinda figured it out, all except the modify the bit in the encrypted firmware, that didn't occur to me. I guess based on the decrypt software we could write one that does the encryption back.

I also sent you an email ( because I didn't know if you'll be back around here ) telling that I've found the SDE and looking at the debug symbols in the files it's the same version of SDE gcc that was used to build the binaries on my Powkiddy J6.
Both the Powkiddy J6 and the X16 were built under cygwin by this misterious Mr Huang , we really need to find him.
Anyway the SDE is here: https://drive.google.com/file/d/1HWbOy6a19PbnGPQ_crRHC-a6Y-O7P1Em/view?usp=sharing
Awesome job, that confirmed a lot of my suspicions right there. The firmware version listed might be different or in this case even the model(j6+x16) but in reality there almost the same thing with a few small interface/menu changes. Sounds like we're making some headway, I would love to see this project come to fruition. Keep up the good work guys! I'll post anymore updates on my end as they come..
 

mforce2

Senior Member
Feb 14, 2009
103
53
I'll help out anyway I can. That's really why that first thread was so crucial because that's where the debugger and development pdf came from. I really appreciate the feedback and help you've given so far. Wasn't there for the first thread, but I'll damn sure be there for the second one 😆
I'm not sure the debugger is doing much unfortunately. I couldn't get it to work myself but it mostly seems to show the contents or something ....
I did find in some Actions SDK the other part of the debugger, what it's supposed to talk to.
Hang around , we might get somewhere with this thread too.
All these Actions devices seem to share the same SDK, the functions are the ones here: https://github.com/uli/actsemi/blob/master/libactsemi/actsemi.c

They're all exactly the same addresses.
 
  • Like
Reactions: ThegreatHAMbino
Feb 11, 2021
16
2
I'm not sure the debugger is doing much unfortunately. I couldn't get it to work myself but it mostly seems to show the contents or something ....
I did find in some Actions SDK the other part of the debugger, what it's supposed to talk to.
Hang around , we might get somewhere with this thread too.
All these Actions devices seem to share the same SDK, the functions are the ones here: https://github.com/uli/actsemi/blob/master/libactsemi/actsemi.c

They're all exactly the same addresses.
I hadn't played around with it to know if it was going to work out or not. At that time I was just trying to gather any/all info that I could before I started to get deeper into the project. I'm not going anywhere, I'm gonna see this thru till the end. Truthfully, it's good to have you aboard. This time around seems just as promising as the last, but now we have a little more information to go off of. I'm excited to see what we all come up with.
 

mforce2

Senior Member
Feb 14, 2009
103
53
Hello @mforce2 and @ThegreatHAMbino !

You just gave a lot of info, I had never found the PDF explaining the whole dev process before, I wish you were here few years ago when we started the first thread :LOL:
There are still some issues because we don't have the toolchain they are using (SDE). SDE has been replaced and I was not able to find it back.

Regarding the modified firmware, I did the step step as you did: I used the atjboottool you found, it gave me an SQL database. I guess it's the role of the flasher to go through the tables and flash the files one by one to the NAND flash. Anyway, I checked all the table with a classic SQL database explorer, then I checked the configuration files (txt), and there was a single flag called "mount system partition = 0" or something like that. My goal was to find the bit in the encrypted firmware in order to modify it. The fact is the encryption used by ATJ is quiet simple, each byte is encoded by using a XOR with a specific value, the good thing is each byte is encoded independently. This means that changing encrypted byte X will not affected byte X+1 encryption/decryption.

Anyway, after understanding this, and after finding the byte to modify, it was quiet simple, so I used a hex editor (dhex on linux) to modify directly the encrypted firmware.

I hope it was not too confusing :ROFLMAO:

I haven't tried modifying/adding a whole file to the SQL database and re-encrypting it. In that case, we'd need to write an ATJEncryptTool as I couldn't find one
One more question , where did you get that SDK , usdk213f ? Seems almost the same as the one we need but not really. I was wondering if maybe we could get this one that was actually used :

/cygdrive/h/Mr_huang_work/ATJ2279B/ch7968_v1/usdk227c/case_tp/apps/desktop/emulator
Powkiddy

I'm also putting a ransom out for finding Mr Huang, $10 , I know it's not a lot but we can contribute and maybe make it worth it :))
 
Last edited:

mforce2

Senior Member
Feb 14, 2009
103
53
@mforce2 If I recall correctly, I found it here: https://forums.rockbox.org/index.php?topic=51071.30

I looked for this SDK but I was unable to find it. The only way we have is to ask Powkiddy for it. I sent them multiple emails but never got any reply...
Yeah , I asked the guy who posted the SDK there. He said he got it from a badly configured FTP that Actions had at the time. I don't even know if they still have it.
Actions will have this SDK, I'm pretty sure, I emailed them about it but nothing so far.
Gamesir also realeased a device similar to the Powkiddy J6 , the GC 1 I think it's called and I asked them but they wouldn't send neither the SDK or either the .fw file.
I'm not sure why even the .fw file is such a secret. Maybe they just don't have it . Could it be that because SPI NOR flash is used it's just pre-programmed and there's no .fw file like for the NAND flash devices ?
 

mforce2

Senior Member
Feb 14, 2009
103
53
One more thing, it seems Powkiddy is more of a shell or something. The realy manufacturer of th X16 seems to actually be Subor and it's called the Subor Q700 ( which is why the firmware has this name too ).
@o-marshmallow Maybe try to contact Subor directly , you might have more luck.
 

o-marshmallow

Senior Member
Feb 26, 2011
85
6
@mforce2 I just did. I directly contacted Subor's after sale service, the guy was named Huang, what a coincidence. I asked for the SDK, he said he doesn't have it/cannot provide it. He advised me to contact the resellers directly. This is what I did, unfortunately, the sellers don't seem to know what I mean by "SDK " :(
 

mforce2

Senior Member
Feb 14, 2009
103
53
@mforce2 I just did. I directly contacted Subor's after sale service, the guy was named Huang, what a coincidence. I asked for the SDK, he said he doesn't have it/cannot provide it. He advised me to contact the resellers directly. This is what I did, unfortunately, the sellers don't seem to know what I mean by "SDK " :(
Neah resellers won't know anything about the SDK.

I've also found out who makes the "Powkiddy J6" , it's these guys : http://www.szrenshun.com/about.asp?ids=8

It would make sense since the board has "CB" on it. If you speak Chinese could you try contacting them please and ask about the .fw file to flash for the Powkiddy X3 I think they call it but internally it's called the "D3560_V4" on the PCB and the "CD3670" in the software.

It could be that the only guys who have the SDK are Actions Semiconductors but they'll never release it. Previous one which you have was leaked from their FTP site ... I wonder if they still have a FTP , haha.
 

o-marshmallow

Senior Member
Feb 26, 2011
85
6
Neah resellers won't know anything about the SDK.

I've also found out who makes the "Powkiddy J6" , it's these guys : http://www.szrenshun.com/about.asp?ids=8

It would make sense since the board has "CB" on it. If you speak Chinese could you try contacting them please and ask about the .fw file to flash for the Powkiddy X3 I think they call it but internally it's called the "D3560_V4" on the PCB and the "CD3670" in the software.

It could be that the only guys who have the SDK are Actions Semiconductors but they'll never release it. Previous one which you have was leaked from their FTP site ... I wonder if they still have a FTP , haha.
No luck unfortunately, I contacted the person directly, he told me he doesn't know this device (X16), it's not his company's, then I asked about the D3560_v4 and Powkiddy more generally, he said he doesn't know that company...
 

mforce2

Senior Member
Feb 14, 2009
103
53
No luck unfortunately, I contacted the person directly, he told me he doesn't know this device (X16), it's not his company's, then I asked about the D3560_v4 and Powkiddy more generally, he said he doesn't know that company...
Thanks for trying, it's really strange how these products are made. No one really knows who makes them , they can't even decide on the name , haha.
I'm pretty sure Powkiddy is just rebranding them though.
 

mforce2

Senior Member
Feb 14, 2009
103
53
No luck unfortunately, I contacted the person directly, he told me he doesn't know this device (X16), it's not his company's, then I asked about the D3560_v4 and Powkiddy more generally, he said he doesn't know that company...
Attempted to get some more info but couldn't find much from Actions. As I don't have any relations or anything in China maybe you could get some info about the Actions FTP , it seems to be not public anymore .
They also seem to have some CS thingy but that's not working sadly .... At least not for me, maybe it's working in China: https://cs.actions-semi.com/Login.aspx
 

o-marshmallow

Senior Member
Feb 26, 2011
85
6
Good news, I managed to get a demo application working on the board.
The source is here: https://github.com/mcirsta/ActSDK/tree/master/case/apps/desktop/demo
I've just replaced the calculat.app with this one and I got the writing to file working perfectly.
I've used the SDE that I mentioned.
That's some great news !
Then I guess the SDK I used to use was definitely not suitable for the device 😄

In the previous SDK I linked, you have some examples that should work on our devices. (edit: my bad, I didn't see yours also have these examples)
uCOS system is based on message passing to perform communication between the system and the applications (so in order to launch a new applicaiton, the launcher application receives a message and itnerpret it). Have a try compiling one of them with the toolchain you got.
 
Last edited:

mforce2

Senior Member
Feb 14, 2009
103
53
That's some great news !
Then I guess the SDK I used to use was definitely not suitable for the device 😄

In the previous SDK I linked, you have some examples that should work on our devices. (edit: my bad, I didn't see yours also have these examples)
uCOS system is based on message passing to perform communication between the system and the applications (so in order to launch a new applicaiton, the launcher application receives a message and itnerpret it). Have a try compiling one of them with the toolchain you got.
The SDK was not the issue, it's the one you shared. Maybe the compiler was the problem.
First thing I want to do is to dump the contents of the partitions on my Powkiddy J6 as I don't have the firmware for it.
Also of interest to me is how to add another library in the system. They seem to have some fixed addresses.
For the launcher I'm not that concerned, right now I'm happy to just use the calculator app to launch my stuff, it's not like I'm going to use the calculator anyway.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 2
    In the meantime I've made some discoveries of my own.

    1. There's no python script as I thought initially . The Actions Pad Tools does indeed support flashing using Python scripts but at least for the Q700 firmware ( where Q700 = X16 ) this is not how the update is done.
    2. Instead there's some sort of state machine as far as I can tell and it's mostly all in this Production.dll
    3. SQLite3 is statically linked inside Production.dll and queries are fun from the functions inside this dll


    Now for the interesting part. I've generated a text file , here: https://drive.google.com/file/d/1LSeQ4VLt3gwJQPyMkF6t3tgaUNdQ6lvM/view?usp=sharing

    with all or almost all of the SQL queries that are run during the update in the sequence that they're called in. I think this speaks a lot about what's actually being done.

    It also seem there's some functions defined the SQL Database under tables like : ExSymbol and FuncSpec. These functions are then using binaries like hwsc09.bin ( found in FileTable ) to perform operations.

    It also seems there is indeed some encryption :
    'select count(*) from sqlite_master where type=',27h,'table',27h,' ' 'and name=',27h,'ENCRYPT_EN',27h,0

    'select NumberA from ENCRYPT_EN ;',

    In the Q700 update this 'ENCRYPT_EN' is set to 1.

    The sequence itself of the update is.

    1. Check if ADFU and if not switch to ADFU mode
    2. Open Connection ( using winusb.dll )
    3. Use ADFU write from Hardware60u.dll to upload the ADFU binary to the device, adec09_1.bin
    4. Run various command using CHardware::ExtCommand

    The problem with using the Q700 firmware upgrade file to update the Powkiddy J6 is that it gets stuck and give and error in the flashing software. It's not bad since I don't want it to mess up my J6 which is not compatible for sure because of the NOR SPI vs NAND.

    Last query after which the failure happens is:

    debug1456:10C657F9 aSelectFilename_10 db 'select FileName from NAND_ID where NumberB = 909717587 ;',0

    I assume that 909717587 is the ID of the NOR flash on the J6 while the Q700 firmware only knows about 2 IDs :

    858796102 and 858801747.

    It all fails here and that's the end of the SQLite3 queries.


    If you have the time I really suggest browsing the text file with the queries, it tells quite a good story and better than I can in words.
    2
    This script that is used is really weird,

    FUNCS_AHEAD( )
    {
    BYTE UPG_TOOL = 1 , MAKER_TOOL = 2 ;
    BYTE SCODE = 1 , SCODE_BAK = 2 ;
    __RunFunc("LFI" , "TOOL_TYPE" , UPG_TOOL , "SCODE_TYPE" , SCODE_BAK);
    __ReleaseFunc("LFI");
    __RunFunc("LFI" , "TOOL_TYPE" , UPG_TOOL , "SCODE_TYPE" , SCODE);
    __ReleaseFunc("LFI");
    __RunFunc("HideDisk");
    __ReleaseFunc("HideDisk");
    };

    And these __keywords are then defined in the production dll ... the functions are then expanded from what I can tell and it becomes recursise.
    The above extract seems like the main upgrade instructions.
    1
    Great that you guys have picked-up this project, I was on the now mysteriously vannished thread and managed to install the modified FW successfully couple of days before the thread disappeared. I have the older x16 and it was with the older menu so it was nice to get it a bit updated. Except being able to launch games from the icons the rest works well. The psx games are quiet slow but the rest play well, will be checking-in to see how yall doing, thanks
    1
    Great that you guys have picked-up this project, I was on the now mysteriously vannished thread and managed to install the modified FW successfully couple of days before the thread disappeared. I have the older x16 and it was with the older menu so it was nice to get it a bit updated. Except being able to launch games from the icons the rest works well. The psx games are quiet slow but the rest play well, will be checking-in to see how yall doing, thanks
    Hi,
    Glad that you're still around. It's a pity about the original forum thread. I don't really know what happened, I tried to contact someone from xda support but never got any answer back.
    What was cool is that someone shared the original firmware for the X16. I still wonder where he got it from.
    1
    @mforce2 More and more info are coming in, that's great!

    I recall seeing some scripts in the Q700 firmware, they should be called by Action software when flashing, here is the HideDisk function that the code you showed calls:
    Code:
    HideDisk( ){
        DWORD dDiskLen ;
        BYTE pbFsType[6] = __ParamKey(1 , "MAKE_HIDE_DISK" , 0) ;
        DWORD dDiskCap = __ParamKey(1 , "MAKE_HIDE_DISK" , 1) ;
        BYTE bFsType = 1 ;
        if(__MemCmp(pbFsType , "FAT16" , 5) ==0);
        JmpFalse 9;
        bFsType=1;
        Jmp 18;
        if(__MemCmp(pbFsType , "FAT32" , 5) ==0);
        JmpFalse 13;
        bFsType=2;
        Jmp 18;
        if(__MemCmp(pbFsType , "FAT12" , 5) ==0);
        JmpFalse 17;
        bFsType=18;
        Jmp 18;
        bFsType=1;
        if(dDiskCap  !=0);
        JmpFalse 23;
        BYTE pbFileName[12] = __ParamKey(1 , "HIDE_DISK_IMG" , 0) ;
        MFILE fFileHandle = __FileOpen(1 , "HIDE_DISK_IMG" , pbFileName , 1) ;
        dDiskLen=__FileSizeOf(1 , fFileHandle);
    };

    All these scripts can be foun din the table FuncSpec. Another interesting table is ExSymbol (External Symbol ?), I think it contains a declaration of the symbol used by the scripts but not present in the firmware file, they should be defined in the DLLs of the flashing software. Here is an example of the table entry:
    TypeNameParentFuncScript
    2ENCRYPT_FWIMAGEMakeFwImage( )
    FILE_ITEM ENCRYPT_FWIMAGE {encrypt_fw_part_1 ; fwutail ; }
    It means that MakeFwImage() script in the FM image makes the use of ENCRYPT_FWIMAGE symbol (located in the DLLs I guess), the last column.. I am not sure about it
  • 2
    Hello @mforce2 and @ThegreatHAMbino !

    You just gave a lot of info, I had never found the PDF explaining the whole dev process before, I wish you were here few years ago when we started the first thread :LOL:
    There are still some issues because we don't have the toolchain they are using (SDE). SDE has been replaced and I was not able to find it back.

    Regarding the modified firmware, I did the step step as you did: I used the atjboottool you found, it gave me an SQL database. I guess it's the role of the flasher to go through the tables and flash the files one by one to the NAND flash. Anyway, I checked all the table with a classic SQL database explorer, then I checked the configuration files (txt), and there was a single flag called "mount system partition = 0" or something like that. My goal was to find the bit in the encrypted firmware in order to modify it. The fact is the encryption used by ATJ is quiet simple, each byte is encoded by using a XOR with a specific value, the good thing is each byte is encoded independently. This means that changing encrypted byte X will not affected byte X+1 encryption/decryption.

    Anyway, after understanding this, and after finding the byte to modify, it was quiet simple, so I used a hex editor (dhex on linux) to modify directly the encrypted firmware.

    I hope it was not too confusing :ROFLMAO:

    I haven't tried modifying/adding a whole file to the SQL database and re-encrypting it. In that case, we'd need to write an ATJEncryptTool as I couldn't find one
    Yeah, got that , thanks a lot. Well in the meantime I kinda figured it out, all except the modify the bit in the encrypted firmware, that didn't occur to me. I guess based on the decrypt software we could write one that does the encryption back.

    I also sent you an email ( because I didn't know if you'll be back around here ) telling that I've found the SDE and looking at the debug symbols in the files it's the same version of SDE gcc that was used to build the binaries on my Powkiddy J6.
    Both the Powkiddy J6 and the X16 were built under cygwin by this misterious Mr Huang , we really need to find him.
    Anyway the SDE is here: https://drive.google.com/file/d/1HWbOy6a19PbnGPQ_crRHC-a6Y-O7P1Em/view?usp=sharing
    2
    In the meantime I've made some discoveries of my own.

    1. There's no python script as I thought initially . The Actions Pad Tools does indeed support flashing using Python scripts but at least for the Q700 firmware ( where Q700 = X16 ) this is not how the update is done.
    2. Instead there's some sort of state machine as far as I can tell and it's mostly all in this Production.dll
    3. SQLite3 is statically linked inside Production.dll and queries are fun from the functions inside this dll


    Now for the interesting part. I've generated a text file , here: https://drive.google.com/file/d/1LSeQ4VLt3gwJQPyMkF6t3tgaUNdQ6lvM/view?usp=sharing

    with all or almost all of the SQL queries that are run during the update in the sequence that they're called in. I think this speaks a lot about what's actually being done.

    It also seem there's some functions defined the SQL Database under tables like : ExSymbol and FuncSpec. These functions are then using binaries like hwsc09.bin ( found in FileTable ) to perform operations.

    It also seems there is indeed some encryption :
    'select count(*) from sqlite_master where type=',27h,'table',27h,' ' 'and name=',27h,'ENCRYPT_EN',27h,0

    'select NumberA from ENCRYPT_EN ;',

    In the Q700 update this 'ENCRYPT_EN' is set to 1.

    The sequence itself of the update is.

    1. Check if ADFU and if not switch to ADFU mode
    2. Open Connection ( using winusb.dll )
    3. Use ADFU write from Hardware60u.dll to upload the ADFU binary to the device, adec09_1.bin
    4. Run various command using CHardware::ExtCommand

    The problem with using the Q700 firmware upgrade file to update the Powkiddy J6 is that it gets stuck and give and error in the flashing software. It's not bad since I don't want it to mess up my J6 which is not compatible for sure because of the NOR SPI vs NAND.

    Last query after which the failure happens is:

    debug1456:10C657F9 aSelectFilename_10 db 'select FileName from NAND_ID where NumberB = 909717587 ;',0

    I assume that 909717587 is the ID of the NOR flash on the J6 while the Q700 firmware only knows about 2 IDs :

    858796102 and 858801747.

    It all fails here and that's the end of the SQLite3 queries.


    If you have the time I really suggest browsing the text file with the queries, it tells quite a good story and better than I can in words.
    2
    @ThegreatHAMbino Waw, you still remember my name :LOL:
    @erexx Hello guys, I haven't connected to XDA for a while, I didn't even know that the old thread was down. Well, I reached the point where I was able to modify a firmware a user posted. This firmware was the one with bubbles on the screen (NOT the PSP-like one). Looking at my archives, I've found back the modified FW I made:

    The only modification done is when you plug the tablet to the PC, it will also mount the system partition, not only user partition, letting you see all the binaries used inside. both partitions will be writable! Interestingly, the binaries are not stripped, so all the debug symbols are still there.

    You'll need the powkiddy flasher program and ADFU drivers to install it. The name of the program is "Actions PAD Product Tools", you'll be able to find this on Google.



    Another interesting finding I've made is that if you open the console, on the motherboard itself, there is a test point to UART TX pin:
    45976bb6-2c2c-4935-941f-1f8bb321d27c.jpeg

    by soldering a cable there and connecting it to a USB TTL module or an Arduino, you'll be able to get message from the system (GND can be taken from the SD Card slot case).

    I could modify one of the binary by hand, i.e. by modifying the binary code, to print out a message on the UART when executing it. However, I was not able to rebuild a binary from scratch with an SDK I found online (which was for a similar device as stated in the archive you've found)


    Note: Multiple members of the former thread and I have tested the modified firmware and reported it working. Still, I am not responsible for any potential damage it could cause to your device.

    EDIT:
    The Powkiddy RES editor will let you modify the RES file you'll find in the system partition. thanks to this, you'll be able to modify the icons image. The icons title can be modified by editing the ".desktop" files

    EDIT2: Just found the following link online which SEEMS to be the original firmware:
    It also includes the Action Pad software for flashing the boards.
    2
    This script that is used is really weird,

    FUNCS_AHEAD( )
    {
    BYTE UPG_TOOL = 1 , MAKER_TOOL = 2 ;
    BYTE SCODE = 1 , SCODE_BAK = 2 ;
    __RunFunc("LFI" , "TOOL_TYPE" , UPG_TOOL , "SCODE_TYPE" , SCODE_BAK);
    __ReleaseFunc("LFI");
    __RunFunc("LFI" , "TOOL_TYPE" , UPG_TOOL , "SCODE_TYPE" , SCODE);
    __ReleaseFunc("LFI");
    __RunFunc("HideDisk");
    __ReleaseFunc("HideDisk");
    };

    And these __keywords are then defined in the production dll ... the functions are then expanded from what I can tell and it becomes recursise.
    The above extract seems like the main upgrade instructions.
    2
    Hallo
    Ich bin neu hier. Es tut mir leid, aber ich spreche kein Englisch, also benutze ich Google-Übersetzer. Zum Thema
    Ich habe auch die powkiddy X16 Konsole und fand eine Firmware. Habe es noch nicht ausprobiert.
    Hier ist ein Link:
    https://techtoytinker.com/powkiddy-x16-handheld