A590IS porting...

whim

@brake

congrats, great work !

the 'qemu-encoded' and the 'brake-encoded' versions show small differences at the end of the file though:

26540: D7 00 00 51 7D 00 F9 FF-1C (eof) <-- 'brake-encoded'

26540: D7 00 00 FF FF 00 FF FF-00 00 00 00 00 00 00 00 <-- 'qemu-encoded'
..... more trailing zeroes

does this mean that the non-identical bytes are spurious (like the trailing zeroes in 'qemu-encoded')
and can be chopped off ?
could you - or anybody else who owns a NewDryOs cam (ma_jk ?) - please check this ?

wim

brake

I cut them off and it still works. That example you gave is interesting actually because it looks like my code is actually acting on data (15x encoding of 00 00 00 00 00 00 00 00 should give some permutation of the following:

0x3000: 0xffffff00      0xffffa0a0      0x00ffffff      0xa000ffff
0x3010: 0xff00a0ff      0xffffffff      0xffffff00      0xffffa0a0
0x3020: 0x00ffffff      0xa000ffff      0xff00a0ff      0xffffffff

unless there's other data there).

What does the unencoded image look like at that line?

whim

@brake

last line in hexedit of unencoded diskboot.bin (that you supplied):

26540: FF FF FF FF

i hope that's what you meant, I only used the bins that you supplied

besides in your cam, did you also check DEcoding in the qemu emulation ?

wim

brake

Yeah I have. Decoding is just removing the 00 from the front and applying the encryption once, so yeah, I restored one the firmware I created with my app and decoded using qemu and it worked.

I just fixed up the code so that it shouldn't leave any trailing stuff in the encode or decode now.

[files removed - get update in last reply]

whim

@brake

excellent ! i'll now test your stuff by compiling/encoding/padding a modified udumper for NewDryOS
which dumps not just 4 Meg, but the entire firmware.
I'll attach it here when done.

wim

edit: attached nudumper.zip contains diskboot.bin & empty.dum - put both on empty, CHDK-bootable disk
changes vs. chr's udump08:
- removed led blinking
- dumps entire firmware (begin of firmware to FFFF FFFF)
- sources (+ .bat to compile under Win32) included in archive

nudumper.zip

17.45KB

ma_jk

A quick compile, just in case someone would like to give a try encoding their builds.

decode.exe

7KB

encode.exe

7KB

whim

thanks ma_jk !

could you test the new udumper in the post before yours? TIA

BTW did you use gcc for that ? my compile with Borland C++ 5.5 is 27K, even after upx --ultra-brute !

wim

edit: never mind, i see: VisualStudio 2005

ma_jk

this is what i got. 😀

ive VS2005 installed on this comp...

whim

@ma_jk

your dump looks pretty peculiar, it seems to miss the first part, but does contain
(part of) a readable dump ???
Are you sure you copied empty.dum and diskboot.bin to an EMPTY bootable card ?
Udumper is really 'primitive', you see, it doesn't know anything about filesystems
(which is not surprising considering it's effectively only 175 bytes 'big' )
it just starts dumping from sector 2048 on the card; that's about 1 mb from the
beginning of the card. So if there's more than 1mb on the card when your copying
empty.dum on it it will overwrite (part of) already existing data ...

on the other hand, if your card WAS empty, then this udumper is no good ...

wim

ma_jk

try now. 😀

whim

@ma_jk

still no good: no leading zeroes in dump.

I'm integrating nudump in a new CardTricks version, maybe you can try with that.

I'll attach it here as soon as it's done.

wim

PS You might as well remove your attached empty.rar's now, that'll reduce the load on the forum server ...

edit: here it is ... use NewDryOs option to create your dump. If after dumping, the 'Strings' button does
not show 'gaonisoy' as the first string, I guess it's back to the drawing board ...
edit2: removed attachment

ma_jk

There you go whim..

0009FE04 0009FE04 0 gaonisoyP

we have a new udumper here...

whim

@ma_jk

good news ! if you don't mind, i'll remove the CT test version, i need to make a few other mods, then I'll
release it. Thanks for your help !

wim

brake

Updated.

I looked again at the end of the encoded file with qemu and it looks like the firmware encoder pads with 0xff instead of 0x00. This means that if the diskboot.bin file isn't a multiple of 8 in length it will be after the encryption process, and when it's decrypted will end up with 0xffs padding the last 8 bytes.

I've attached the update including fixing a really stupid arithmetic error I had in the padding.

whim

@brake
@ma_jk

Oof ! Guess I got lucky - new udumper's size before encoding is 176 bytes, so it was not affected by this ...
(checked by comparing bins)

thanks again brake - IMHO your code makes NewDryOs cams as easy (or difficult?) to port as 'regular' DryOS ones.

ma_jk, could you do your VS2005 magic on these too (if & when you have the time of course, no hurry) TIA

wim

ma_jk

whim
@brake
@ma_jk
thanks again brake - IMHO your code makes NewDryOs cams as easy (or difficult?) to port as 'regular' DryOS ones.

ma_jk, could you do your VS2005 magic on these too (if & when you have the time of course, no hurry) TIA

sorry whim, i didnt see your edit. on my way

bootbin utils.rar

6.62KB

whim

@ma_jk

Thanks, looking forward to trimming 20k off my installation file !

sorry for late reaction, i somehow missed your post ???

wim

chr

LOOOOOOOOOOOOOOOOOOL

I was not aware of this thread. Must be the negative topic!

Just for a comparison:

[REQ]Adding new cameras, applying patches into trunk (with source code prepared)

I don't see a 192bit key. *g*

brake

Oh well, I suck. Always doing things the hard way.

chr

brake
Oh well, I suck. Always doing things the hard way.

What u think how I do feel?

I made a great hack 😎and then I had to release someone else already made it 😛 🤣

« Previous Page Next Page »