re: Heat Stakes at 3:30. I've never heard this term before but it looks very convenient. Specifically what material did you 3D print with that allows this? I've watched your previous videos but can't seem to find much about materials. Thanks for the channel. Really great.
At the top, where you can recognize a bit of a pattern, that's probably register configuration tables, so they may possibly have other configurations, but parts of the addresses must not be changed or something like that. There may also be other tables like interrupt vectors.
A byte inversion is not a common fault so checksums are not as good at detecting them. A single bit flip would be more likely and would tell you much better which bytes are covered. Most likely all are though. No sense in storing a firmware copy and not just protecting the entire blob.
Your 3D printed test frame technique is an excellent idea. I've only recently acquired my first 3D printer (same as yours) and now I need to learn OpenSCAD so that I can steal your idea. :)
Good! I put the source code in show notes: opentechlab.org.uk/videos:017:notes , and I did a quick tutorial about OpenSCAD a while back: ruclips.net/video/38Z7E8OcVd8/видео.html . Hope you find it helpful!
Inspirational! One day, one day I'll be playing around like this. I've got to get these software skills first. I've never seen someone use 2 blue pills like this before. Smart. Thanks for the upload. -Jake
The shell is zsh, installed with oh-my-zsh for the theming. And I'm using tmux as a windows manager in the terminal. More recently I've started using vim instead for windowing. If you want to see my config files, I keep them on stashed on GitHub: github.com/jhol/shellrc
The checksums are often CRC16 CRC32 or unsigned addition. I would start with unsigned addition, the snag is you need to know the offset at the start (if any) and the length. The area containing the checksum is likely to be a C structure, the structure itself may not be the part of the checksummed data. Try no offset at the start and do an addtion, if it fails move another byte backwards from the checksum and re-compute it ?
I would also calculate the checksum on the uncompressed data, that way any defect during decompression could be caught. So trying different de compression algorithms until you find one that matches the decompressed length, then trying different crc32s to match the suspected checksum ?
With regards to byte flips and then rendering them in a table, it seems there is a pattern in the SMEDIA area where some columns are more critical so it might be few bytes of data and then few control bytes. Columns 8 and 16 definitely look like least significant bytes of control data, therefore when they are changed a break is imminent. Those two columns often monotonically increase by 2 every 8 bytes. On the other hand some columns seem to be in the "data" category and don't seem to affect loading if they are changed. The "control" bytes seem to be 32bit numbers distributed around 0. A bit later in the flow they start to come up as negative values. So these numbers could be indexes in to some kind of a table. Would be interesting to try to increment the bytes by 1 instead of flipping them. A value of FF instead of 0 in column 7, assuming it is a not least significant control byte, seems to have no effect on booting which doesn't seem to make sense. Maybe 1 instead of 0 will cause it to break as it will look closer to a value the system may consider valid.
I put most of the code in a git repository here: github.com/jhol/otl-lkv373a-tools . Have a look at test-startup.py and tabulate-test-startup.py which formats the results in HTML. It's nothing fancy - just a quick-and dirty script. Which is the best way for a project like this.
Nice ,you are spoiling us ,2 videos in one week . Thank you. 👍 I hope you find the time to do more video's in the future . 2 weeks ago a went true my subsciberlist to see if you are still in there . I discovered Sigrok thanks to you ,just a shame my latest Kingst LA2016 doesn't support it . The software of the manufacturer is shit compared with sigrok . Shame that there is no development for it , it is planned from 2016 but still red dot.
Looking at the page in the sigrok wiki, I wouldn't be surprised if it isn't very similar to one of the other devices - either a direct clone, or something very similar. The folks on the #sigrok irc channel are very helpful answering questions. If you're looking for a project, writing logic analyzer drivers can be quite good fun. There's a tutorial about how to reverse-engineer USB protocols in video 005 at 0:32:23.
@@OpenTechLab Thanks for the tips ,i will look in to it , it would be great to use sigrok for this analyser. PS : don't wait another year to upload a video ,they don't need to be polished ,they are always fascinating and interesting .
You've piqued my interest. How confident are you in the opcode names/constants in the git repo? I've been monkeying with firmware blobs today and I think I'm getting a different idea of what the opcodes are. Though it looks like you've possibly been able to run some code, in which case you're definitely going to know the instruction set better than I've figured out thus far =)
I'm not top-notch when it comes to putting thought processes to words....but I'll give it a go :) There are (if memory serves) a set of standard compression logarithms which get used by different manufacturers - was thinking that for the manufacturer of these soc's to write their own logarithm would be a bit long-winded (time being money, etc...if any of you've seen Ben Eater's videos on creating checksums, you'll see what I mean). You could take the compressed part of the code out of the hex file and then apply the 'popular' logarithms to it to see if that renders it readable. Also, are there any other soc's produced by this manufacture where there is information available on the compression process? 'Tis a shot in the dark, but maybe the same (or simular) compression is used there too. Or, examine how other manufacturers do this. I hope that no-one feels like I'm teaching anyone to suck eggs....just throwing some thoughs to words. This has definitely got me triggered though - which is what I like about ths opentechlab channel. Thanks for posting! Time for a cup of tea and a nice relaxing thinking session :) Edit: Just watched part 3 in this series which has rendered my above comment obsolete :)
Yeah... on the second hand market the GH4's seem really well priced relative to the compact GX series and mid-range G series. Perhaps there is less demand for "pro" cameras. Lenses are less expensive on Micro 4/3 and APS-C cameras, but quality glass is rarely cheap - even second hand. There are lots of lens reviews on RUclips. Beware though, lens shopping is an addictive pastime.
Thanks for the support! It helps a lot. Previously I used Patreon and I had it set for donations per-video, which is better for me because often other things in my life get in the way of video making, so I can't guarantee a release schedule. Unfortunately, I've become a little unhappy with some of Patreon's business practices, so I decided to switch to SubscribeStar - the only problem being that they only allow monthly donations at the current time. So at the moment the two options I can think of are 1. join subscribestar and pledge $1/month. That's the smallest tier it will allow. I don't think that will break anyone's bank month by month - even if they forget about it. Or 2. I'm considering publishing a PayPal link for one-time donations. Would either of these work for you? Or do you have any other suggestions?
To be honest the PayPal link would be preferred but upon reflection the amount I would give would go for a couple of month on the monthly subscribe. Just don't want the unsubscribe to seem like a disinterest. I would just really like a firmware without the multicast spewing lol
![[018] IT9919 Hacking - part 3 - Hacking Upgrade Files](http://i.ytimg.com/vi/SR7yhFioWwg/mqdefault.jpg)
![[018] IT9919 Hacking - part 3 - Hacking Upgrade Files](/img/tr.png)
![[016] IT9919 Hacking - part 1 - Reading firmware with flashrom](http://i.ytimg.com/vi/j7JRosD_ua8/mqdefault.jpg)
![Felix "Unfair" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/Oswujxm2Ag0/mqdefault.jpg)
I'm really glad that have started producing content again - thank you! Your long form videos are a precious resource.
Interresting approach. And you even read my name correctly :)
I bought a bevy of the dev boards you shared in the previous video. Looking forward to getting them. Thanks for the tips!
I'm glad to see they you're posting again. Hope the move and everything else your side is going well
Ooooh! So YOU are where I got my recent thing for SMD on pad board from!
Really nice work. Thank you.
re: Heat Stakes at 3:30. I've never heard this term before but it looks very convenient. Specifically what material did you 3D print with that allows this? I've watched your previous videos but can't seem to find much about materials.
Thanks for the channel. Really great.
I only ever print with PLA - but I think it would work with just about anything. It has to melt to get through the printer nozzle, right?
Amazing challenge Joel!
It's Mr Bert Vermeulen everyone! One of the founding fathers of sigrok!
Like your rigs. I use a MakerBeam kit to make all sorts of testing rigs. Very versatile.
At the top, where you can recognize a bit of a pattern, that's probably register configuration tables, so they may possibly have other configurations, but parts of the addresses must not be changed or something like that. There may also be other tables like interrupt vectors.
A byte inversion is not a common fault so checksums are not as good at detecting them.
A single bit flip would be more likely and would tell you much better which bytes are covered. Most likely all are though. No sense in storing a firmware copy and not just protecting the entire blob.
Your 3D printed test frame technique is an excellent idea. I've only recently acquired my first 3D printer (same as yours) and now I need to learn OpenSCAD so that I can steal your idea. :)
Good! I put the source code in show notes: opentechlab.org.uk/videos:017:notes , and I did a quick tutorial about OpenSCAD a while back: ruclips.net/video/38Z7E8OcVd8/видео.html . Hope you find it helpful!
Glad to see that you're back. May be, you might do few videos on SDR stuff too. Thanks for considering.
Inspirational! One day, one day I'll be playing around like this. I've got to get these software skills first. I've never seen someone use 2 blue pills like this before. Smart.
Thanks for the upload.
-Jake
What's the diffing app with the highlighted colors that you're using at 12:08?
It's vbindiff- nice little tool!
What the binary file compare utility? Showing differences in red. Really enjoying the series.
It's vbindiff!
Finally! another great post!
Love it, keep up the amazing work
Unrelated question:
How do I make my terminal look like yours at 7:33? (I am talking about bottom row, and directory/branch colors and styling)
The shell is zsh, installed with oh-my-zsh for the theming.
And I'm using tmux as a windows manager in the terminal. More recently I've started using vim instead for windowing. If you want to see my config files, I keep them on stashed on GitHub: github.com/jhol/shellrc
Looks like a solder bridge there on U2, just above C130 at about 5pm 1:27
I think those pins are meant to be linked. On the data-sheet, pins 44 and 45 are labelled RAMVSS.
Nice video, enjoyed watching
The checksums are often CRC16 CRC32 or unsigned addition. I would start with unsigned addition, the snag is you need to know the offset at the start (if any) and the length. The area containing the checksum is likely to be a C structure, the structure itself may not be the part of the checksummed data. Try no offset at the start and do an addtion, if it fails move another byte backwards from the checksum and re-compute it ?
Nice work! Keep it going.
VERY fascinating !!! thanks for sharing!!
Maybe the checksum is one of the standard CRC32's, but protecting the uncompressed data not the original one.
I would also calculate the checksum on the uncompressed data, that way any defect during decompression could be caught.
So trying different de compression algorithms until you find one that matches the decompressed length, then trying different crc32s to match the suspected checksum ?
This is pretty interesting. Thanks!
I think you need to try a hot swap on the eeprom, swap it out after the check, between read cycles
With regards to byte flips and then rendering them in a table, it seems there is a pattern in the SMEDIA area where some columns are more critical so it might be few bytes of data and then few control bytes. Columns 8 and 16 definitely look like least significant bytes of control data, therefore when they are changed a break is imminent. Those two columns often monotonically increase by 2 every 8 bytes. On the other hand some columns seem to be in the "data" category and don't seem to affect loading if they are changed.
The "control" bytes seem to be 32bit numbers distributed around 0. A bit later in the flow they start to come up as negative values. So these numbers could be indexes in to some kind of a table.
Would be interesting to try to increment the bytes by 1 instead of flipping them. A value of FF instead of 0 in column 7, assuming it is a not least significant control byte, seems to have no effect on booting which doesn't seem to make sense. Maybe 1 instead of 0 will cause it to break as it will look closer to a value the system may consider valid.
I'm interested to know about your python script and the tabulation looks great.
I put most of the code in a git repository here: github.com/jhol/otl-lkv373a-tools . Have a look at test-startup.py and tabulate-test-startup.py which formats the results in HTML. It's nothing fancy - just a quick-and dirty script. Which is the best way for a project like this.
IGMP snooping would be a ... better solution, don't you think?
Nice ,you are spoiling us ,2 videos in one week .
Thank you. 👍
I hope you find the time to do more video's in the future .
2 weeks ago a went true my subsciberlist to see if you are still in there .
I discovered Sigrok thanks to you ,just a shame my latest Kingst LA2016 doesn't support it .
The software of the manufacturer is shit compared with sigrok .
Shame that there is no development for it , it is planned from 2016 but still red dot.
Looking at the page in the sigrok wiki, I wouldn't be surprised if it isn't very similar to one of the other devices - either a direct clone, or something very similar. The folks on the #sigrok irc channel are very helpful answering questions. If you're looking for a project, writing logic analyzer drivers can be quite good fun. There's a tutorial about how to reverse-engineer USB protocols in video 005 at 0:32:23.
@@OpenTechLab Thanks for the tips ,i will look in to it , it would be great to use sigrok for this analyser.
PS : don't wait another year to upload a video ,they don't need to be polished ,they are always fascinating and interesting .
You've piqued my interest. How confident are you in the opcode names/constants in the git repo? I've been monkeying with firmware blobs today and I think I'm getting a different idea of what the opcodes are. Though it looks like you've possibly been able to run some code, in which case you're definitely going to know the instruction set better than I've figured out thus far =)
I went into it in a bit more detail in the next part: ruclips.net/video/SR7yhFioWwg/видео.html
Now THIS is podracing.
Very interesting !!
I'm not top-notch when it comes to putting thought processes to words....but I'll give it a go :)
There are (if memory serves) a set of standard compression logarithms which get used by different manufacturers - was thinking that for the manufacturer of these soc's to write their own logarithm would be a bit long-winded (time being money, etc...if any of you've seen Ben Eater's videos on creating checksums, you'll see what I mean). You could take the compressed part of the code out of the hex file and then apply the 'popular' logarithms to it to see if that renders it readable. Also, are there any other soc's produced by this manufacture where there is information available on the compression process? 'Tis a shot in the dark, but maybe the same (or simular) compression is used there too. Or, examine how other manufacturers do this.
I hope that no-one feels like I'm teaching anyone to suck eggs....just throwing some thoughs to words. This has definitely got me triggered though - which is what I like about ths opentechlab channel.
Thanks for posting! Time for a cup of tea and a nice relaxing thinking session :)
Edit:
Just watched part 3 in this series which has rendered my above comment obsolete :)
*MOAR VIDEOS MOAR OFTEN!!!!!*
Which camera are you using?
This was filmed on a Lumix G7. In addition I recently acquired a GH4
@@OpenTechLab Thank you. I'm looking for good video quality when i will be filming my work table.
Yeah... on the second hand market the GH4's seem really well priced relative to the compact GX series and mid-range G series. Perhaps there is less demand for "pro" cameras.
Lenses are less expensive on Micro 4/3 and APS-C cameras, but quality glass is rarely cheap - even second hand. There are lots of lens reviews on RUclips. Beware though, lens shopping is an addictive pastime.
This is bleeping awesone.
i like your content and would like to donate but not continously, is ther another option apart from bitcoin?
Thanks for the support! It helps a lot.
Previously I used Patreon and I had it set for donations per-video, which is better for me because often other things in my life get in the way of video making, so I can't guarantee a release schedule.
Unfortunately, I've become a little unhappy with some of Patreon's business practices, so I decided to switch to SubscribeStar - the only problem being that they only allow monthly donations at the current time.
So at the moment the two options I can think of are 1. join subscribestar and pledge $1/month. That's the smallest tier it will allow. I don't think that will break anyone's bank month by month - even if they forget about it. Or 2. I'm considering publishing a PayPal link for one-time donations.
Would either of these work for you? Or do you have any other suggestions?
To be honest the PayPal link would be preferred but upon reflection the amount I would give would go for a couple of month on the monthly subscribe. Just don't want the unsubscribe to seem like a disinterest. I would just really like a firmware without the multicast spewing lol
I created a PayPal link here: www.paypal.me/opentechlab . Thanks for supporting the channel!
I think someone seen the fact that there was no dislikes so they decided to be the first and just annoy everybody