Sonicview 360P not commicating with PC through RS232C port.

[Jdread]

I have a Sonicview 360P receiver that sometime ago I had a Ihub connected to it and was working quite OK until lightning toasted the ihub while connected to the receiver. Everything else is working fine on this receiver except I cannot load a file or communicate with the receiver through serial port (rs232c) with the computer. I can load files through the USB port using a thumb drive so getting bins loaded to the receiver is not a problem. I would like to try using the emulator with this receiver but if the serial port is not working this would not be possible. I have tested the voltage coming from the Power Supply Board connected to the main board (under load) and all the readings seems OK. However when the voltage is tested with the main board disconnected the readings seems off i.e 3.3V is reading 2.54V and the others seems to be lower also but not too far off. The problem really is it is difficult to read the numbers as they keep switching through a range of numbers so I take the highest reading so that is how I got the 2.54V. Can anyone guide me how to actually fix this problem, is it the Power Supply Board, or is it the Main Board. I am leaning towards the Main Board as the damage to the receiver was caused by lightning coming in through the cable connected to the ihub and burning it and rendering the Ihub unusable. Anyone has seen this before with one of these box and can it be repaired. The box is basically New and everything else works fine.

[Jdread]

OK, guys I believe that this problem is not very common so no one was able to assist. Anyway I loaded the file through the USB port that is recommended for the receiver to work with emulator and fire up the receiver and connect to the PC and the channels came in for a few seconds and then go black until I shut down and start the emulator again and then the same thing happens again. Is this up at this time or is it down, I have read where it went down but not sure if it is back up. I have not seen any posts to say whether it is up at this time, can anyone enlighten me on this.

[It's Jafo]

You need to understand the game just a bit better :)
Your question about "Up or down" is one you would ask in you iks provider.Most are up at this time.
Next, if you get something on the box by way of a pic, your rs232 port is most likely working.
Next, I would look at the config file in the emulator to confirm you don't have an issue there.

[abouttosnap]

There still has not been an update to the emulator from what I've seen. Been checking from time to time but nothing so far.

[rcm4453]

I have a Sonicview 360P receiver that sometime ago I had a Ihub connected to it and was working quite OK until lightning toasted the ihub while connected to the receiver. Everything else is working fine on this receiver except I cannot load a file or communicate with the receiver through serial port (rs232c) with the computer. I can load files through the USB port using a thumb drive so getting bins loaded to the receiver is not a problem. I would like to try using the emulator with this receiver but if the serial port is not working this would not be possible. I have tested the voltage coming from the Power Supply Board connected to the main board (under load) and all the readings seems OK. However when the voltage is tested with the main board disconnected the readings seems off i.e 3.3V is reading 2.54V and the others seems to be lower also but not too far off. The problem really is it is difficult to read the numbers as they keep switching through a range of numbers so I take the highest reading so that is how I got the 2.54V. Can anyone guide me how to actually fix this problem, is it the Power Supply Board, or is it the Main Board. I am leaning towards the Main Board as the damage to the receiver was caused by lightning coming in through the cable connected to the ihub and burning it and rendering the Ihub unusable. Anyone has seen this before with one of these box and can it be repaired. The box is basically New and everything else works fine.


Same thing happened to me when I tried using my PC to emulate an ihub. You can get replacment ihubs for around $25 or $26 now. The latest ihub emulation file that you load to your box allows them to work and they work great! Check out this thread:


http://www.satfix.net/showthread.php?135056-Ihub-replacments-for-only-26!

[Jdread]

There still has not been an update to the emulator from what I've seen. Been checking from time to time but nothing so far.

Thanks man, this is all I am asking. Just not want to waste my time trying to fix something that everyone knows is not working at this time.

[Jdread]

You need to understand the game just a bit better :)
Your question about "Up or down" is one you would ask in you iks provider.Most are up at this time.
Next, if you get something on the box by way of a pic, your rs232 port is most likely working.
Next, I would look at the config file in the emulator to confirm you don't have an issue there.

All the answers you gave I have actually came to the same conclusion already, and only wanted to know if the the emulator was working at this time, which is a simple question yes or no and you have not answered. I also know that you are one of the persons who have helped in making this programme a reality, so thank you on behalf of the members of this community. However, I find your post a little ms-leading if you are telling me to look at the config file for issues when the programme itself is not working at this time. By the way, I think I understand the game much more than you think.

[It's Jafo]

There was no insult intended.
As to the emulator... there is no up or down. It either works for you or it doesn't and if set up correctly, it will work just fine for everyone.Your connecting and then disconnecting... that's very likely a config file issue.
I'm sure you'll figure it out.
Good luck,
Jafo

[Russ]

I have a Sonicview 360P receiver that sometime ago I had a Ihub connected to it and was working quite OK until lightning toasted the ihub while connected to the receiver. Everything else is working fine on this receiver except I cannot load a file or communicate with the receiver through serial port (rs232c) with the computer. I can load files through the USB port using a thumb drive so getting bins loaded to the receiver is not a problem. I would like to try using the emulator with this receiver but if the serial port is not working this would not be possible. I have tested the voltage coming from the Power Supply Board connected to the main board (under load) and all the readings seems OK. However when the voltage is tested with the main board disconnected the readings seems off i.e 3.3V is reading 2.54V and the others seems to be lower also but not too far off. The problem really is it is difficult to read the numbers as they keep switching through a range of numbers so I take the highest reading so that is how I got the 2.54V. Can anyone guide me how to actually fix this problem, is it the Power Supply Board, or is it the Main Board. I am leaning towards the Main Board as the damage to the receiver was caused by lightning coming in through the cable connected to the ihub and burning it and rendering the Ihub unusable. Anyone has seen this before with one of these box and can it be repaired. The box is basically New and everything else works fine.

My SV 360p & ihub was toasted due to lightning last month & I check the ihub first connected to ethernet no lights at all, then I check the reciever no light display also. So I think if your reciever will not work, I think is bad too

[DualTest]

I have had the same issue. On both an Premium and Elite. It works for 2 minutes and then stops communicating. And have to restart the svlan exe file. As far as the configuration file goes there really isn't much in there, 5 lines. Two of which we are adviced not to alter, 2 for the PS info and 1 for the port. So I can't see how that is causing it. I have tried everything I can think of. Redoing files, shutting down the firewall, adjusting the network timeout in the receiver menu. Nothing has worked.

[It's Jafo]

Have a look at the log in your router and see if there is a message indicating what might be happening with the connection.
Look for dropped,timed out,denied or something indicating the issue.If you can, observe the connection in real time and see what happens when it stops working.
It works well for most.I suspect something is different in those connections versus the ones that don't work.
Since mine works, it's hard to troubleshoot the issue from here.

[jvvh5897]

You could just hook the serial output of the box to the PC and see what is coming out of the box--that would tell you if the serial port is running OK or not. The box to hub comms are in ascii so just about any terminal program will let you see just about anything that comes out. A "spy" rs232 cable would let you hook up the hub or PC running emulation of hub too, so you could get more of a feel for what is going on. HyperTerm on a windows box would work for this, or get something like RealTerm free from sourceforge site.

[Jdread]

Can anyone else apart from Jafo say if they are up using this emulator. It would be interesting to know what is happening as his posts are not helping anyone in dealing with this issue. There is nothing technical or complicated about the setup so what is there to figure out. I read on some other site that an expired date was written in the programme and until that issue was addressed the programme will not work. I have not heard of this issue been addressed by Jafo so if this is the case just let us know and let us all move on, there is no need to waste time.

[Jdread]

I have read a lot of posts where the emulator was working very well when it was just released, what would have changed in there settings or config file to prevent it from working for them now? It is a little strange or odd.

[abouttosnap]

Posted 6/2:


Listen guys I did screw up.
I try to place some mechanism to put pressure on the beta issue. And One of the stuff i work was to have a some sort of expiration. I submitted the previous svhub with that expiration ON on error!. Was not intentional. Well it seems that it work pretty well!!! I am sorry.

I did not resubmit a valid new one becouse I was not aware of it. I realize it that Friday night. Then when i try to resolved the issue I found then that my svhub source files where corrupted. Then after an hour of bad time I went to bed. Yesterday I was busy on my personal issues. Hopefully I will submit a new SVhub in the following hours. Hopefully before noon. I need to rework in an old version since my original sources got corrupted. Then I see what I can then do with the router version.

My apologies.

What I was getting: 18718

[Jdread]

Same thing I am getting snapo, by the way I have not heard from one other person who have this working. So my conclusion it is not working for anyone else except Jafo.

[Jdread]

I am happy though that based on my recent testing it seems that my Sonicview 360P is running OK and communicating through the RS232C port, although I cannot load a bin file through it. In my case the Ihub got burnt while connected to the box, it did not seem to have damaged anything else. Based on what Snapo posted and due to the fact that I am getting the same exact screen from the emulator I can safely say that my receiver is functioning properly and communicating with the PC. I was also able to get picture very briefly which is also proof that the box is working properly.

[abouttosnap]

Just curious but when you try to load a file via serial port with the loader do you get some kind of error with the loader?

I haven't tried mine in a few days. But the last time I tried it basically the same thing happened. When you first fire up the emulator everything would click right along. Then say with in five minutes the emulator would stop and or give that error message and freeze. Close out the emulator then restart and with in five minutes it would repeat. When it first came out it ran almost flawless for about a week. Oh well on word and up word.

I'm still noodling over getting a wiz for mine. Don't really need it but it will be something new to play with. Decisions decisions. :idea:

[Jdread]

On using the loader through serial port I did not get a error message all it would do is it just sit there and did not respond and you could see that nothing was loading. My experience with the emulator is similar to yours, I am only sorry that I did not tried it when the emulator was running good, however, I thought that because it was not loading through the serial port it would obviously not work but apparently I was wrong. Do you get the feeling that the emulator is now being used to sell this new hub. I would also buy one but it is kind of difficult based on my location in the Caribbean and the cost of shipping and the taxes and custom duties. I have this Sonicview for a long time but decided that I would not buy a Ihub for the price it was going for and was very happy to know that something was been done to get them up without it costing a lot of money. I have other receivers running OK, but as you know we in this hobby we are always experimenting and to be honest I am convinced that the Sonicview receivers are one of if not the best receiver ever built.

[jvvh5897]

Well, hate to suggest it, but IDA Pro does a good job of disassembling exe files for PC. You could go into the code of the program and find the stuff around that count-up in the screen shot you have--maybe look for a test of the date code that might be expiration test.

[abouttosnap]

On using the loader through serial port I did not get a error message all it would do is it just sit there and did not respond and you could see that nothing was loading. My experience with the emulator is similar to yours, I am only sorry that I did not tried it when the emulator was running good, however, I thought that because it was not loading through the serial port it would obviously not work but apparently I was wrong. Do you get the feeling that the emulator is now being used to sell this new hub. I would also buy one but it is kind of difficult based on my location in the Caribbean and the cost of shipping and the taxes and custom duties. I have this Sonicview for a long time but decided that I would not buy a Ihub for the price it was going for and was very happy to know that something was been done to get them up without it costing a lot of money. I have other receivers running OK, but as you know we in this hobby we are always experimenting and to be honest I am convinced that the Sonicview receivers are one of if not the best receiver ever built.

I don't think the emulator is being used to sell the wiznet because it is a legal devise so to speak and has no ties to anything to do with fta. All though it possible that the emulator is being used now to say sell the router version. I haven't seen anything myself but I'm just brain storming.

You may have already know this but I'll throw it out there just in case. Turn the stb off via the back switch. While holding down the ok button on the front panel of the stb flip the back switch back on. The display should show USBL. Then try and load the file and see if it loads. Make sure you have Main sw in the drop down window like below. Just kinda odd that that seeing the emulators works it won't load a file via serial port.


http://www.satfix.net/attachment.php?attachmentid=18723&d=1371754001




Well, hate to suggest it, but IDA Pro does a good job of disassembling exe files for PC. You could go into the code of the program and find the stuff around that count-up in the screen shot you have--maybe look for a test of the date code that might be expiration test.

Thanks. I'll check it out. May not get any where but who knows lol.

[Jdread]

Well to be honest i have not tried loading a file since I tested the emulator, so will be doing some more testing with this box including your suggestion. But is this not for force loading through the USB port, at the moment I have no issue with loading through USB port, this is how I am able to load bin files etc to the box.

I agree it is been use to sell something, was also following the posts on the router and was also wondering what was going on. I am hoping that something will be done on the emulator for PC use, so that Peeps who would like to do so can and not be forced to buy a special router or hub. My own view is that I will not be forced to buy anything for this box to work because it is easier to just move on to another box.

[jvvh5897]

Well, the readme with the emu suggests that you send in a little money to support development--not all that bad an idea I would think.

For the heck of it I loaded the exe into IDA and found code doing count up:

text:0040299B push offset aD ; "*%d"
.text:004029A0 call printf

Nothing jumps out at me as to a date being used to expire, but I do see some stuff that makes me wonder if number of times the program is used might trigger something. You could try to erase all the files and then pull them out of the distribution zip/rar again--don't know if that requires you set up cfg file again but that did not look all that hard--might want to trash the whole folder with the files and then create folder and unpack things. Other code made me wonder if the code checked in with another site to see if you were allowed to proceed, but honestly I'm just guesing at this--I only have that screen shot and what little the program does when I run it with no sv box and no internet.

[abouttosnap]

Again thanks for the IDA suggestion jvvh. I've been looking myself with what little I know about code trying to see something that looks a miss. I've tried to delete the files and start fresh but nothing. Even tried resetting the internet protocol on my laptop but didn't help. I did see something in the hex that made reference to "get date error". Not sure if it means anything but thought I would throw it out there. Again my understanding of this is very limited but I keep looking. If I get a chance next time I log on I'll post a screen shot. :noidea:

I also may try to see what is coming out of the stb with hyper terminal if I can. If I get that to work I'll try and post a screen shot as well. Well via my brain don't blow up. lol

[Jdread]

I actually looked at the file using the Ida programme and I also did not see anything which would resemble a expiration date, however, because it was admitted to be there I said maybe I did not know what I was looking for. I was not able to hook up the receiver and run the Ida programme to see if I am missing something, so I will attempt to do this next.

I do not object to making a donation to help with the Development of something like this, so don't get me wrong.

Thanks also to you for your assistance and I will try your recommendations and see what happens.

[Jdread]

Just on a side note though, if the programme was written in such a way to prevent peeps who were using a particular server from using it successfully I would not be surprised if it was logging on to some site and a decision is made who to allow to use the programme. Thanks JVVH you have really shed some light as to what might be some of the issues with this emulator at this time. There is much more to getting this emulator to work than just corrupt files or wrong settings in config files or Internet Issues.

[steveng]

Can anyone else apart from Jafo say if they are up using this emulator. It would be interesting to know what is happening as his posts are not helping anyone in dealing with this issue. There is nothing technical or complicated about the setup so what is there to figure out. I read on some other site that an expired date was written in the programme and until that issue was addressed the programme will not work. I have not heard of this issue been addressed by Jafo so if this is the case just let us know and let us all move on, there is no need to waste time.

I tried this emulator with a 360P and it runs for a couple of minutes and then disconnects, it also disconnects when you change the channel. You have to restart the svhub program to get it to connect again. The PS I used runs fine on other receivers, no rocket PS involved and my computer and internet work fine. The program definitely needs some more work to get the bugs out. I wouldn't mind making a donation if it worked better but at this stage I think I'll pass.

[Jdread]

Thanks for your post, as I predicted no one apart from Jafo has it up and running. I am still asking though if there is anyone reading this post that have this emulator running OK on a PC please let me know.

I share the same view on the donation issue. How could you donate to something that is not working or that is not helping anyone or just a few.

I don't think there are any bugs to be sorted out, it was deliberately done for it to work for a while and then to decide who should be allowed to use it after, this is just my view.

[jvvh5897]

Well, I'll post a few spots around the area that is sending out the messages on that screen shot that I've found. One spot get you that setsockopt error and the only way to get there is if a specific byte of data does not equal 0xe--that seems to be something that would stop you getting everything set correctly, so that might be a good place to look.

You know that what the program is doing is actually pretty straight forward and you could write it easily enough under lcc-win32. The list of commands for the wiznet dongle make up the majority of the commands and I think wiznet has some code you could use for parts of that, sv added a few commands and I made up a list of them for the project and posted it over at dssrookie, there are also the captures of the commands to the CE test of security chip and also on of part of the newcamd init. newcamd protocol is out there, so that is not too much of biggie. Tutorial for lcc-win32 has a whole chapter with examples of web comms and the disassembly of the hub emulation can be used to fill in some info too. Any takers?



another count up (the one just before the NEWCAMD message in screen shot)

text:004028A7 push offset aD ; "*%d"
.text:004028AC call printf

.text:004038C2 ; create socket and connect to NEWCAMD server
text:00401EFC ; SocserThreadStart...includes 1545 setsockopt error and "1516 fd_socket=%d\n"

We get to 'Closing Previous Server Session' message :
.text:0040283F cmp ds:dword_408320, 0Eh
.text:00402846 jnz short loc_402868 ; close session
only if 408320 not equal to 0Eh

[abouttosnap]

I stuck my nose in that thread over at rookie once or twice. I'm still digging but still not sure what I'm looking at. Stuff may as well be in pig latin. lol But at least I'm starting to seeing some of what you are seeing.....I think. I gave up drinking about 25 years ago but by the time I'm done with this I may have to start back up. :D Have to do this a bit at a time. Don't want to pop a spring. lol


.text:0040283F cmp ds:dword_408320, 0Eh
.text:00402846 jnz short loc_402868

[Jdread]

Aboutosnap you are one funny dude, I wish I was able to understand this sh*t I would certainly be the first to take up jvvh on his offer. But believe me my friend when I say I would pop more than a spring trying to understand this stuff. I want to thank jvvh though for his willingness to help and hope that someone with the expertise in this area will take up the challenge. This does not mean that I am not going to look at the things he is talking about and see what I can learn from it.

[abouttosnap]

Well, I'll post a few spots around the area that is sending out the messages on that screen shot that I've found. One spot get you that setsockopt error and the only way to get there is if a specific byte of data does not equal 0xe--that seems to be something that would stop you getting everything set correctly, so that might be a good place to look.

You know that what the program is doing is actually pretty straight forward and you could write it easily enough under lcc-win32. The list of commands for the wiznet dongle make up the majority of the commands and I think wiznet has some code you could use for parts of that, sv added a few commands and I made up a list of them for the project and posted it over at dssrookie, there are also the captures of the commands to the CE test of security chip and also on of part of the newcamd init. newcamd protocol is out there, so that is not too much of biggie. Tutorial for lcc-win32 has a whole chapter with examples of web comms and the disassembly of the hub emulation can be used to fill in some info too. Any takers?

jvvh I'm willing to give it a try but I have to warn you up front when it comes to this code stuff I'm a noob. I'm still trying to figure out where and how to mod a file. I've downloaded a copy of Icc-win32 from 2009. Like I said I've tried to follow that thread over there but still can't seem to grasp it. Can't seem to find the string you are referring to.

[abouttosnap]

Just an fyi but there is a least one other file that shows network adapter connect and will get picture with the emu. But the file has some issues if you power the box off and on. Also has the cce still and missing a couple of options in the ip menu that the svlan files has but connects never the less. Just thought I would throw it out there. It came out in 2010 and I archived on a cd back in 2011.

It also shows the same error after a short time as the screen shot I posted above. Or just stops responding.

[jvvh5897]

I just grabbed an emu file at random from the files area, so not sure if the one I'm looking at is the one you have.
Let's see the thumb drive that I'm working on has the SVhub1.02 with application inside date stamp 5/23/2012 4:05AM, 84kb size.

I'm pretty sure the code is calling to a site, I won't post the whole IP but:
00403E28 ; create socket and inet "66.***.**.**"
then when it returns from that routine it does a test on a value. That addr does not mean anything to me, but maybe someone else can recognize it.

The program has to do less than I thought. The newcamd seems to all be done in the box code, so the commands to the hub have to be parsed (they all start with "<" and end with ">" chars) in the program you see that at 00401ACD ; parse commands routine. Then back in 004024EE ; main it checks the first byte after the < for the command set used, it checks for R (read a setting), W (write a setting), D (write data to the hub's flash), and C (the sv command set). The command code for a return packet from the hub to box can be S for succes and F for fail (with codes 1 and 2 for what type of fail it was). When the box has to send data to the web, it sends a CXT command but all the payload is in ascii coded hex, so the program has lots of hex to binary convert routines and the other way too as web traffic to the hub gets changed to ascii hex to send to box.

So, the program has to get serial packets in, figure out how to respond to the box (most of the commands get a fixed response), if needed, convert packet format and send to web, or pull in traffic from web and convert. There is an example serial port setup in the lcc tutorial for windows and a set of routines that could be easier to use called "sapi" that compiles under lcc (
http://download2.polytechnic.edu.na/pub4/sourceforge/s/se/serialapi/OldFiles/sapi.c)--I coded up the serial routine and compiled sapi with it last night, but did not try to use the sapi routines (thought I would check the web for an example). The way dale coded the tree for all the commands looks to me to just be a bunch of if then statements, but there was a disassembler I looked at a while back who's methods might do the job better and it could be more modular so that a number of coders could try their hand at coding. And the web side of things could be just the last example in the lcc tutorial--it was really easy way to do things.

I wonder if a thread in the advanced section should be started?

Anyway here are a few more routines that I named and spots that I labeled in the disassemly:


004024EE ; main

004011FD ; convert from hex
00401302 ; convert byte to hex?
00404296 ; read ihub.cfg
00402402 ; fopen "rb"
00401468 ; get time and write to svhub_log.txt
408008 holds value to log or not log. log if value 1
00401ACD ; parse commands
00403C44 ; part of newcamd
00403E28 ; create socket and inet "66.***.**.**"

00402807 cmp al, 45h ; if <CE received do stock reply
jmp loc_402DBB ; we need to send a reply to box
00402CC9 cmp al, 46h ; <RF> received?
00402CC1 cmp al, 44h ; <RD> received?
00402CDD cmp al, 48h ; <RH> received?
00402CD9 cmp al, 47h ; <RG> received?
00402B9A cmp al, 53h ; Just a <CXS> recieved?
00402A1C cmp al, 31h ; we have gotten <CXR so lets test 1 or 2 invalid command or parameter

00402DCB test esi, esi ; error writing to serial port
00402CFD cmp al, 4Ch ; <RL> received?
--note should be <S1.0> returned but code has <1.0>!
00402D0D cmp al, 4Dh ; <RM> received?
00402D11 cmp al, 4Eh ; <RM> received?
00402D21 cmp al, 50h ; <RP> received?
00402D31 cmp al, 53h ; <RS> received?
00402CED cmp al, 49h ; <RI> received?
00402CB1 cmp al, 52h ; is this <R command?
00402C9B cmp byte ptr [esp+10h+arg_B24+2], 41h ; is this <RA>?
00402BDB push 3 ; send "command failed" <F>
00402BE7 push ds:dword_408B60 ; pause and then write <S>
00402A20 push ds:dword_408320 ; handle <CXR1> and <2> ==invalid command or parameter
00402C7F cmp al, 44h ; is this <D ?
00402D46 cmp al, 55h ; <RU> received?
00402D53 cmp al, 56h ; <RV> received?
00402D60 cmp al, 57h ; <RW> received?
00402D6D cmp al, 58h ; <RX> received?
00402D7A cmp al, 57h ; is this <W command?
00402D86 cmp al, 4Dh ; <WM> received?
00402D93 cmp al, 52h ; <WR> received?
00402DAB push 3 ; <WX> and <WW> handling


004047E8 ; int __cdecl write(int,const void *,unsigned int)
004047F0 ; int __cdecl read(int,void *,unsigned int)
00403A59 ; int __cdecl sub_403A59(void *,unsigned int)--calls "write"

00402817 cmp al, 4Dh ; is this <CM ?
0040281F cmp al, 4Eh ; is this <CN ?
00402827 cmp al, 58h ; is this <CX ?
00402837 cmp al, 43h ; is this <CXC ?
004029B9 cmp al, 45h ; is this <CXE ?
004029C9 cmp al, 46h ; is this <CXF ?
004029D1 cmp al, 4Bh ; is this <CXK ?
004029D9 cmp al, 51h ; is this <CXQ ?
00402A0C cmp al, 52h ; is this <CXR ?
00402BA2 cmp al, 54h ; <CXT> received
004027F7 cmp al, 43h ; have we gotten <C ?
004027F9 jnz loc_402C7F ; if not <C then start testing for other commands
00402C93 cmp al, 52h ; is this a <R command ?

[abouttosnap]

A thread in the advance section would probably be a good idea. For now I'm gona take a short break on this. Kinda got frustrated on a couple of fronts with this.

Seems I'm a lot better with trouble shooting the stb it's self and or setting up a dish than this code s...stuff.

[abouttosnap]

Ok jvvh back at it....maybe. lol Look at what I've done below. Does it look correct? I did this with IDA. Also if this looks correct do you save with just selecting file and save? I'm trying but tant easy. Time I figure this s.....stuff out the sd boxes will be obsolete. I guess I trying to know if it is in there when I test it.....maybe. lol I just picked a spot to try and edit. I always go base ackerds at s...stuff.

One other bit of info. The version of IDA is 5.0 and doesn't have all the bells and whistles. Should I use hexworkshop instead? I warned you I was a noob. ssshhhheeewwww

Bartender drink me whiskey.



.text:00402A1C cmp al, 31h
.text:00402A1E jnz short loc_402A8B
.text:00402A20 push ds:dword_408320 ; handle<CXR1>and<2>

[It's Jafo]

as I predicted no one apart from Jafo has it up and running.
Mine has since died as well.
The 110 board continues to work well with the Nochk file loaded to the box.I think that kills the idea that it's being used to sell something other than the emulator itself and we know how well that went the last time around.
I also had a look at the file and the only date in the file is associated with creation date of the Cygwin file.
I too think the program looks to another site that probably verifies the ip addy your trying to connect to is not the one they want to block.I don't know that for sure but that's my guess.
At first, I had a suspicion that it was date related but I find that's not the case.My bios date is set to the year 2000 and Windows is blocked from getting internet time.I thought that might be the reason I was still up when others were down but as stated, mine eventually died too.
I would guess that those that wrote the files have a pretty good idea of why it has stopped working.The files worked great for a few weeks so I don't expect that the issue is with mechanics of the file.
I do hope for those that need the emulator that they get the issues worked out soon.
Again, the 110 board still works well and for many, that might be a simple work around for the Ihub.

:)

[jvvh5897]

The way to mod the exe file is not in IDA, use hexeditor like a cracked HexWorkshop or XVI32 --last is free and I use it a lot but sort of like hub emu it tries to phone home so I keep the computer I use it on off-line (well, I don't have a line to be off of, but you get the idea. I also went in and changed the IP addrs but that was just playing around). There are lots of other hexeditors around.

If I were to mod the exe, I would go to where it calls 403E28 ; create socket and inet "66.***.**.**" and put in NOPs or jump past all the code around that call and the test that follows it. Making sure that the code ends up getting you to the right spot to continue.

Hard to say if that will fix things either but it would tell you something. I'll look around that area and see what I would try as a mod.

I went ahead and built a simple (very simple) program to get output from a box and parse it for a reply. Code for lcc-win32 and I use a bat file to do the compile. The ides is that it opens COM1 port and waits for a "<" character to start looking for more and stops when it sees the ">" and then calls to find out what to reply to that command then loops around for another string to respond to. I've put in as many of the command strings as I could easily do, but put a FORCE_EXIT to stop the program when you get to the CE step--if you get past that test, you can remove the type that forces the exit and move it to another spot to see how far you can get. My testing was on a different box and it sort of looked like it ran, but the code is very simple and it might work with your sv boxes and it might not. Only for the serial port too and I've not bothered with many of the possible commands (so that get_cxtbl routine is just a place holder really).

I would save the below as buildser2.bat

set path=c:\lcc\bin;c:\lcc\include;c:\lcc\lib
lcc.exe serial2.c
lcclnk.exe -o serial2.exe -subsystem console -s serial2.obj
ECHO Finished!

And save the below as serial2.c

#include <windows.h>
#include <stdio.h>

const char HexChar[]={'0','1','2','3','4','5','6','7','8','9','A','B', 'C','D','E','F'};


typedef enum {
NONE,SIMPLE,CX_MORE,FORCE_EXIT
} TYPE;


typedef struct {
const char *commandstr;
const char *returnstr;
TYPE type;
} CTBL;

// added a TYPE entry to the above and then use a case(switch) in code to route different commands to diff routines

const CTBL Ctbl[] =
{
{"<RD>","<S0>",SIMPLE},
{"<RF>","<S4.11>",SIMPLE},
{"<RH>","<S2.1>",SIMPLE},
{"<RL>","<S1.0>",SIMPLE},
{"<RM>","<S1>",SIMPLE},

{"<RG>","<S192.168.0.1>",SIMPLE},
{"<RI>","<S192.168.0.11>",SIMPLE},
{"<RV>","<S192.168.0.1>",SIMPLE},
{"<RX>","<S0.0.0.0>",SIMPLE},

{"<RP>","<S80>",SIMPLE},
{"<RS>","<S255.255.255.0>",SIMPLE},
{"<RU>","<S1>",SIMPLE},
{"<RW>","<S*****>",SIMPLE},


{"<RN>","<S10010>",SIMPLE},

{"<WM>","<S0>",SIMPLE},
{"<WR>","<S>",SIMPLE},
{"<WX>","<S>",SIMPLE},
{"<WW>","<S>",SIMPLE},

//below FORCE_EXIT is to stop emu at CE step, change to SIMPLE to get passed that step

{"<CE0DEDDFF8557A9275>","<CEFFFFFFFFFFFFFFFF>",FORCE_EXIT},
{"<CM>","<S>",SIMPLE},
{"<CN>","<S>",SIMPLE},
{"<CX","<S>",CX_MORE},

{".word","last",NONE} //must be the last always but return value should be "" empty string--"last" just a test
};

const CTBL CXtbl[] =
{
{"<CXF>","<F>",SIMPLE},
{"<CXK>","<S>",SIMPLE},
{"<CXS>","<S>",SIMPLE},


{".word","last",NONE} //must be the last always but return value should be "" empty string--"last" just a test
};

//---------------start of code--------------



//below routine to find a match in the Ctbl array and return matching string to return
const CTBL *get_ctbl(const char *str)
{
const CTBL *pt;
pt=Ctbl;
while (strncmp(pt->commandstr,str,3)) //hope the string compare for 3 char will let all the commands be tested here
{++pt;}

return (pt);
}

//similar to the above but for the CX* commands
const CTBL *get_cxtbl(const char *str)
{
const CTBL *pt;
pt=CXtbl;
while (strncmp(pt->commandstr,str,4)) //more chars to be tested
{++pt;}

return (pt);
}

int main(int argc, char *argv[])
{
//-----variable list-------
DCB dcb;
HANDLE hCom;
BOOL fSuccess;

COMMTIMEOUTS CommTimeouts;

BYTE Byte;
DWORD dwBytesTransferred;
unsigned char buffer[512];
int i=0;
const CTBL *pt,*px;

//--------set up serial port----------------
char *pcCommPort = "COM1";
hCom = CreateFile( pcCommPort,
GENERIC_READ | GENERIC_WRITE,
0, // must be opened with exclusive-access
NULL, // no security attributes
OPEN_EXISTING, // must use OPEN_EXISTING
0, // not overlapped I/O
NULL // hTemplate must be NULL for comm devices
);
if (hCom == INVALID_HANDLE_VALUE)
{
// Handle the error.
printf ("CreateFile failed with error %d.\n", GetLastError());
return (1);
}
// Build on the current configuration, and skip setting the size
// of the input and output buffers with SetupComm.
fSuccess = GetCommState(hCom, &dcb);
if (!fSuccess)
{
// Handle the error.
printf ("GetCommState failed with error %d.\n", GetLastError());
return (2);
}
// Fill in DCB: 57,600 bps, 8 data bits, no parity, and 1 stop bit.
dcb.BaudRate = CBR_115200; // set the baud rate
dcb.ByteSize = 8; // data size, xmit, and rcv
dcb.Parity = NOPARITY; // no parity bit
dcb.StopBits = ONESTOPBIT; // one stop bit
fSuccess = SetCommState(hCom, &dcb);
if (!fSuccess)
{
// Handle the error.
printf ("SetCommState failed with error %d.\n", GetLastError());
return (3);
}
printf ("Serial port %s successfully reconfigured.\n", pcCommPort);

GetCommTimeouts (hCom, &CommTimeouts);

// Change the COMMTIMEOUTS structure settings.
CommTimeouts.ReadIntervalTimeout = MAXDWORD;
CommTimeouts.ReadTotalTimeoutMultiplier = 0;
CommTimeouts.ReadTotalTimeoutConstant = 0;
CommTimeouts.WriteTotalTimeoutMultiplier = 10;
CommTimeouts.WriteTotalTimeoutConstant = 1000;

// Set the timeout parameters for all read and write operations
// on the port.
if (!SetCommTimeouts (hCom, &CommTimeouts))
{
// Could not set the timeout parameters.
printf("Unable to set the timeout parameters %d", GetLastError ());

return FALSE;
}

//above from Microsoft Windows CE 5.0 info


//--------------------user code below--------------


while(1)
{
i=0;
Byte=' ';
//read a string from serial port
//first find the <


while(Byte!='<')
{
ReadFile (hCom, // Port handle
&Byte, // Pointer to data to read
1, // Number of bytes to read
&dwBytesTransferred, // Pointer to number of bytes
// read
NULL // Must be NULL for Windows CE
);

if ((dwBytesTransferred == 1) && (Byte=='<')) //ignore all char but <
{buffer[i]=Byte;
i++;
}
if(i>510) i=0; //protect buffer from overflow just in case
//printf("byte received %c\n",Byte);
}

//then find the rest of string to the char > that ends it

while(Byte!='>')
{
ReadFile (hCom, // Port handle
&Byte, // Pointer to data to read
1, // Number of bytes to read
&dwBytesTransferred, // Pointer to number of bytes
// read
NULL // Must be NULL for Windows CE
);

if (dwBytesTransferred == 1)
{buffer[i]=Byte;
i++;
}
if(i>510) i=0; //protect buffer from overflow just in case
//printf("byte received %c\n",Byte);
}
buffer[i]=0; //string NULL char terminated makes things easier

//print the received string out one character at a time till NULL
for (i=0;i<512;i++)
{printf("%c",buffer[i]); if (buffer[i]==0) {break;}}
printf("\nbytes received %d\n",i);


//look up a string to return based on received string
pt = get_ctbl(buffer);
if(pt->type==SIMPLE)
{
printf("returnedstr = %s\n",pt->returnstr);

//do a hex convert on the data received

WriteFile (hCom, // Port handle
&Byte, // Pointer to the data to write
strlen(pt->returnstr), // Number of bytes to write
&dwBytesTransferred, // Pointer to the number of bytes
// written
NULL ); // Must be NULL for Windows CE

}



if(pt->type==CX_MORE)
{
px = get_cxtbl(buffer);
printf("returnedstr = %s\n",px->returnstr);

//do a hex convert on the data received
printf("\nRecieved string converted to hex:\n");
for(i=0;i<strlen(buffer);i++)printf("%c%c ",HexChar[buffer[i]>> 4],HexChar[buffer[i] & 0xf]);
printf("\n");
}

if(pt->type==FORCE_EXIT)
{
break;
}
//note that a cntl-C should force exit too but that handle should be closed
}

//--------------exit--------------
CloseHandle( hCom );
return (0);
}

[jvvh5897]

Spotted an error in my code adaption of Microsoft code:

WriteFile (hCom, // Port handle
&Byte, // Pointer to the data to write
strlen(pt->returnstr), // Number of bytes to write
&dwBytesTransferred, // Pointer to the number of bytes
// written
NULL ); // Must be NULL for Windows CE

Should have been using &returnstr not &Byte as Pointer to the data to write.

Think there is a bug of some sort too, when I send two string of the type I'm using back to back the program picks up on them OK, but if I pause and send some other stuff in between the two strings the second string does not get picked up. Might not be a problem for your boxes, but as I pointed out the code is very simple and you might want a better bit of code lifted from a known working example. Seems to happen only when the write routine is activated--that is one reason that I spotted that code error above. Fixing the code eror and playing with a number of other things has not gotten the problem solved for me, but I'll be looking around to see what the web can tell me--maybe a delay after the write step, or a check of the GetLastError is needed.

[jvvh5897]

Oh, and I think the hub emulation only tries to phone home if there is an error. And there is one error in the program that might need a fix.

I noted:
00402CFD cmp al, 4Ch ; <RL> received?
--note should be <S1.0> returned but code has <1.0>!
above.

This could be fixed by:
We have a pointer to it at 402D03 in the program--that is byte sequence 68 89 5F 40 00 @2103 in the file
And we have a long string we could mod at 405FE2: 'Error writing to Serial Port writeto_lenght=%d'
Change that to 'Error: Serial Port writeto_length=%d',0Ah,0
Then there is space starting at 5208 in the file to write:<S1.0>,0 leaving the 0x64 and 0x0a that was the end of the string there intact, but you can overwrite them too if you like.
Then the pointer at 2103 should be changed from 68 89 5F 40 00 to 406008 location w/ byte sequence: 68 08 60 40 00

Now, I don't know if that is a problem--would need to see a serial capture of the box to hub comms to see if something odd was happening, but....

[abouttosnap]

Oh, and I think the hub emulation only tries to phone home if there is an error. And there is one error in the program that might need a fix.

I noted:
00402CFD cmp al, 4Ch ; <RL> received?
--note should be <S1.0> returned but code has <1.0>!
above.

This could be fixed by:
We have a pointer to it at 402D03 in the program--that is byte sequence 68 89 5F 40 00 @2103 in the file
And we have a long string we could mod at 405FE2: 'Error writing to Serial Port writeto_lenght=%d'
Change that to 'Error: Serial Port writeto_length=%d',0Ah,0
Then there is space starting at 5208 in the file to write:<S1.0>,0 leaving the 0x64 and 0x0a that was the end of the string there intact, but you can overwrite them too if you like.
Then the pointer at 2103 should be changed from 68 89 5F 40 00 to 406008 location w/ byte sequence: 68 08 60 40 00

Now, I don't know if that is a problem--would need to see a serial capture of the box to hub comms to see if something odd was happening, but....

This is ironic. I was messing around with this last night and was poking around that same area. Of course not really knowing what I was poking at but poking never the less. I'll smoke it over jvvh. I'm still trying but my pea brain can't handle but so much at a time. lol

[jvvh5897]

All we can do is try things and see until someone does wireshark capture. Would not hurt if someone trys to log box to wizhub comms either.

Well, I figured out (well, stole the idea from an example I found) a better way to do the receive part of the posted source and fixed that send part up too. My test box no longer has trouble getting stuff.

Here is the fixed up code:

#include <windows.h>
#include <stdio.h>
#include <stdlib.h>

const char HexChar[]={'0','1','2','3','4','5','6','7','8','9','A','B', 'C','D','E','F'};


typedef enum {
NONE,SIMPLE,CX_MORE,FORCE_EXIT
} TYPE;


typedef struct {
const char *commandstr;
const char *returnstr;
TYPE type;
} CTBL;

// added a TYPE entry to the above and then use a case(switch) in code to route different commands to diff routines

const CTBL Ctbl[] =
{
{"<RD>","<S0>",SIMPLE},
{"<RF>","<S4.11>",SIMPLE},
{"<RH>","<S2.1>",SIMPLE},
{"<RL>","<S1.0>",SIMPLE},
{"<RM>","<S1>",SIMPLE},

{"<RG>","<S192.168.0.1>",SIMPLE},
{"<RI>","<S192.168.0.11>",SIMPLE},
{"<RV>","<S192.168.0.1>",SIMPLE},
{"<RX>","<S0.0.0.0>",SIMPLE},

{"<RP>","<S80>",SIMPLE},
{"<RS>","<S255.255.255.0>",SIMPLE},
{"<RU>","<S1>",SIMPLE},
{"<RW>","<S*****>",SIMPLE},


{"<RN>","<S10010>",SIMPLE},

{"<WM>","<S0>",SIMPLE},
{"<WR>","<S>",SIMPLE},
{"<WX>","<S>",SIMPLE},
{"<WW>","<S>",SIMPLE},

//below FORCE_EXIT is to stop emu at CE step, change to SIMPLE to get passed that step

{"<CE0DEDDFF8557A9275>","<CEFFFFFFFFFFFFFFFF>",FORCE_EXIT},
{"<CM>","<S>",SIMPLE},
{"<CN>","<S>",SIMPLE},
{"<CX","<S>",CX_MORE},


{".word","last",NONE} //must be the last always but return value should be "" empty string--"last" just a test
};

const CTBL CXtbl[] =
{
{"<CXF>","<F>",SIMPLE},
{"<CXK>","<S>",SIMPLE},
{"<CXS>","<S>",SIMPLE},


{".word","last",NONE} //must be the last always but return value should be "" empty string--"last" just a test
};

//---------------start of code--------------



//below routine to find a match in the Ctbl array and return matching string to return
const CTBL *get_ctbl(const char *str)
{
const CTBL *pt;
pt=Ctbl;
while (strncmp(pt->commandstr,str,3)) //hope the string compare for 3 char will let all the commands be tested here
{++pt;}

return (pt);
}

//similar to the above but for the CX* commands
const CTBL *get_cxtbl(const char *str)
{
const CTBL *pt;
pt=CXtbl;
while (strncmp(pt->commandstr,str,4)) //more chars to be tested
{++pt;}

return (pt);
}

int main(int argc, char *argv[])
{
//-----variable list-------
DCB dcb;
HANDLE hCom;
BOOL fSuccess;

COMMTIMEOUTS CommTimeouts;

BYTE Byte;
DWORD dwBytesTransferred,dwBytesSent;
unsigned char buffer[512];
int i=0;
const CTBL *pt,*px;
COMSTAT comstat;
DWORD temp;

//--------set up serial port----------------
char *pcCommPort = "COM1";
hCom = CreateFile( pcCommPort,
GENERIC_READ | GENERIC_WRITE,
0, // must be opened with exclusive-access
NULL, // no security attributes
OPEN_EXISTING, // must use OPEN_EXISTING
0, // not overlapped I/O
NULL // hTemplate must be NULL for comm devices
);
if (hCom == INVALID_HANDLE_VALUE)
{
// Handle the error.
printf ("CreateFile failed with error %d.\n", GetLastError());
return (1);
}
// Build on the current configuration, and skip setting the size
// of the input and output buffers with SetupComm.
fSuccess = GetCommState(hCom, &dcb);
if (!fSuccess)
{
// Handle the error.
printf ("GetCommState failed with error %d.\n", GetLastError());
return (2);
}
// Fill in DCB: 57,600 bps, 8 data bits, no parity, and 1 stop bit.
dcb.BaudRate = CBR_115200; // set the baud rate
dcb.ByteSize = 8; // data size, xmit, and rcv
dcb.Parity = NOPARITY; // no parity bit
dcb.StopBits = ONESTOPBIT; // one stop bit
fSuccess = SetCommState(hCom, &dcb);
if (!fSuccess)
{
// Handle the error.
printf ("SetCommState failed with error %d.\n", GetLastError());
return (3);
}
printf ("Serial port %s successfully reconfigured.\n", pcCommPort);

GetCommTimeouts (hCom, &CommTimeouts);
//printf("%d\n%d\n%d\n%d\n%d\n",CommTimeouts.ReadIntervalTimeout,CommTimeouts.Rea dTotalTimeoutMultiplier,CommTimeouts.ReadTotalTime outConstant,CommTimeouts.WriteTotalTimeoutMultipli er,CommTimeouts.WriteTotalTimeoutConstant);
// Change the COMMTIMEOUTS structure settings.
CommTimeouts.ReadIntervalTimeout = MAXDWORD;
CommTimeouts.ReadTotalTimeoutMultiplier = 0;
CommTimeouts.ReadTotalTimeoutConstant = 0;
CommTimeouts.WriteTotalTimeoutMultiplier = 10;
CommTimeouts.WriteTotalTimeoutConstant = 1000;

// Set the timeout parameters for all read and write operations
// on the port.
if (!SetCommTimeouts (hCom, &CommTimeouts))
{
// Could not set the timeout parameters.
printf("Unable to set the timeout parameters %d", GetLastError ());

return FALSE;
}

//above from Microsoft Windows CE 5.0 info


//--------------------user code below--------------


while(1)
{
buffer[0]=' ';


while( !(buffer[0]=='<'))
{
clear:
ClearCommError(hCom, &temp, &comstat);
// if (comstat.cbInQue != 0) goto break;
Sleep(100);

ReadFile (hCom, // Port handle
&buffer, // Pointer to data to read
200, // Number of bytes to read
&dwBytesTransferred, // Pointer to number of bytes
// read
NULL); // Must be NULL for Windows CE

if (dwBytesTransferred<4) goto clear;


}

for(i=0; i <dwBytesTransferred ; i++)
{
if(buffer[i] < 32) /* replace unreadable control-codes by dots */
{
buffer[i] = '.';
}
}
buffer[dwBytesTransferred]=0; //string NULL char terminated makes things easier
printf("string received %s\n",buffer);

printf("bytes received %d\n",dwBytesTransferred);


//look up a string to return based on received string
pt = get_ctbl(buffer);
if(pt->type==SIMPLE)
{
printf("returnedstr = %s\n",pt->returnstr);


WriteFile (hCom, // Port handle
&pt->returnstr, // Pointer to the data to write
strlen(pt->returnstr), // Number of bytes to write
&dwBytesSent, // Pointer to the number of bytes
// written
NULL ); // Must be NULL for Windows CE
//if(strlen(pt->returnstr)!=dwBytesSent) {printf("error writing\n");} else {printf("writing OK %d\n",strlen(pt->returnstr));}

}



if(pt->type==CX_MORE)
{
px = get_cxtbl(buffer);
printf("returnedstr = %s\n",px->returnstr);

//do a hex convert on the data received
printf("\nRecieved string converted to hex:\n");
for(i=0;i<strlen(buffer);i++)printf("%c%c ",HexChar[buffer[i]>> 4],HexChar[buffer[i] & 0xf]);
printf("\n");
}

if(pt->type==FORCE_EXIT)
{
break;
}
//note that a cntl-C should force exit too but that handle should be closed
}

//--------------exit--------------
exit:
CloseHandle( hCom );
return (0);
}

[abouttosnap]

Here is a screen shot of what I did jvvh18741. But I'm getting an error that it has encountered a problem and has to close. Maybe I'm doing something wrong. Had to go out and grab a translator. Got tried of running up and down the screen. sshhhheeewwww


Update:
I did get it work finally but it still hung up. But again it could be me or what I did or didn't do. I'm not sure on the part in bold in your post below. I found the bytes in 2103 68 89 5F 40 00 but I get confused after that. I did change 89 5F to 08 60 but it still hung up after a few minutes as before.

I'm going to go back threw some of my posts from a few other boards and see if I can get a time line on how long the emulator ran before it went down. I'm thinking it was between 3 and 5 days.

Update:
Ok I grabbed the files when they first came out and they were still off site which was 5/23. I made my first post with the screen shot error on 5/30 on another board. So it ran almost flawless for about 7 days.




Oh, and I think the hub emulation only tries to phone home if there is an error. And there is one error in the program that might need a fix.

I noted:
00402CFD cmp al, 4Ch ; <RL> received?
--note should be <S1.0> returned but code has <1.0>!
above.

This could be fixed by:
We have a pointer to it at 402D03 in the program--that is byte sequence 68 89 5F 40 00 @2103 in the file
And we have a long string we could mod at 405FE2: 'Error writing to Serial Port writeto_lenght=%d'
Change that to 'Error: Serial Port writeto_length=%d',0Ah,0
Then there is space starting at 5208 in the file to write:<S1.0>,0 leaving the 0x64 and 0x0a that was the end of the string there intact, but you can overwrite them too if you like.
Then the pointer at 2103 should be changed from 68 89 5F 40 00 to 406008 location w/ byte sequence: 68 08 60 40 00

Now, I don't know if that is a problem--would need to see a serial capture of the box to hub comms to see if something odd was happening, but....

[nunoit]

joining in here i try to open in ida some how i screwed up ida will give me hex view good. but some how i cant get line view only block view played with all the buttons i think but cant see where i f**ed up i am sure its something simple.

on another note when i was playing yesterday with the emu i noticed that when i start i get start socket of 300 works like every one else till it starts new socket 324 then hangs there forever.

2 questions

1 can a loop be put to return back to 300, that might work to keep channel going, not sure if that would work for changing channels.

2 could there be a log which only allows for 300 up to 324. if that is the case can the log be turned off like the rq which has option for no log.

maybe i am just blowing smoke. i will try to get snooper of what goes on while running emu and post.

[jvvh5897]

Yes, abouttosnap, I'm not surprised. The ,0 at the end of the string was not telling you to put in ,0, it tells you to put in the hex value 0x00--all strings should be NULL character terminated. The 0x0a is a return character and is needed at the end of most strings that print out on the screen. I was using the same format of showing strings that IDA uses, so all you had to do was look at the disassembly and see how the string was in the code and duplicate that format with a couple of changes. The <S1.0> string HAD TO START EXACTLY at the address that you put in the pointer to the string.

-------------------------------------------------------------------------

nunoit: The value 300 or 324 is not something that you set, it is the handle returned by the socket instruction.
Here is what the machine code shows and example C code that does the same:

In the exe you see that here:
.text:004038C2 ; create socket and connect to NEWCAMD server
.text:004038C2
.text:004038C2 sub_4038C2 proc near ; CODE XREF: StartAddress+3D2p
.text:004038C2 push 0 ; protocol
.text:004038C4 push 1 ; type
.text:004038C6 push 2 ; af
.text:004038C8 call socket
.text:004038CD mov ds:s, eax
.text:004038D2 inc eax
.text:004038D3 jnz short loc_4038E8
.text:004038D5 call WSAGetLastError
.text:004038DA push eax
.text:004038DB push offset aCouldNotCreate ; "Could not create socket : %d"
.text:004038E0 call printf
.text:004038E5 pop eax
.text:004038E6 pop edx
.text:004038E7 retn
.text:004038E8 ; ---------------------------------------------------------------------------
.text:004038E8
.text:004038E8 loc_4038E8: ; CODE XREF: sub_4038C2+11j
.text:004038E8 movzx eax, word ptr ds:dword_408AF0

------------------------------------
C code:
SOCKET Socket = socket( AF_INET, SOCK_STREAM, IPPROTO_TCP );
if ( Socket == INVALID_SOCKET ) {
printf( "Error: %ld\n", WSAGetLastError() );
}

So what you see at the return from the machine code to socket is the value SOCKET Socket in ds:s, it is moved to eax to test to see if the value returned was 0 and if zero returned that is an error code indicating INVALID_SOCKET, but if not zero then that is the handle used in other TCP client routines like listen and recv or send.

A few years ago I found udp client and server example code and compiled it under lcc-win32 using winsock (the h file that has all those socket, listen, bind, send....)--the two C source files were called sizeserver and sizeclient. Last night I changed sizeclient so that one of the printf's in it gave me the udp handle returned from socket--it was always 938 as I recall. When I run hub emu on my PC with no internet and no sv box, it starts a socket handle number 3. I suspect that the handle number is a result of a number of OR'ed values about the type of socket started, but haven't looked into how the number is assigned.

----------------------------------------------------------------------

While I was trying to sleep last night I kept thinking about the issue and I was thinking in circles. The program worked, there may be coding errors of one type or another, but the program worked and still does for a few minutes. But to run even a few minutes requires a number of web exchanges (one every 15 seconds or so in each direction). And some folks were having trouble at differnt times that others. SO, what is common to the trouble?--not the program as it worked earlier, but what about the IKS servers? What if the servers were seeing something that they did not like coming from the program?--maybe a program bug that they did not like the results of, or maybe the program uses a constant MAC address and they did not like having that confusing things on their end and when they see comms like this program uses then block the IP and MAC. That might be a better explaination than a shutoff of the coder's computer, or a program feature or bug directly---it is not on your PC end.

Maybe try to change the hardcoded MAC--I haven't looked closely to see if it was used in the code in more than the one spot I saw it, but that might be something to try.

[nunoit]

just for giggles i logged between pc and fta and this is what i get. i don't know if this helps but maybe worth a look. these samples were taken with serial port monitor. from start up to freeze up. table view might be the best to use. will have to re-post later after i edit

BTW what did i do to make ida screw up.

[jvvh5897]

Well, those should help fill in the table of commands and responses. You should know however that lots of your personal info are in the files--your IP for instance. That would be enough for DN to track you down. Edit or remove IMO.

[nunoit]

i removed the add on's i looked at the text what i seen is the called address and the faked address for the emu. unless its coded i don't see my addie hope you got what you needed. i could pm that to you i think if you need.

o and i found my problem with ida dummy me its the space bar thingy.

tomorrow is another day later dudes

[abouttosnap]

Just a note on a few things I have seen with this. Mine will hang most of the the time at 320 but not always. It will hang on others plus I don't always get the error but it will hang never the less. The server issue is a possibility. I do remember reading when this emu first come out that one service in particular was banned from jump.

I'm still trying with this but I got a lot to learn. lol I would like to learn to mod a file but no bigger than this program is to mod a file on the cce and the test or security chip check would be pushing it for me. lol

[jvvh5897]

Well the MAC addr should be easy to mod, at least the one that I can make out and just ascii characters.
MAC addr:
@405F55 in disassembly or 0x515A in file:
<S00.90.BC.0F.00.01>
Now, I would think a PC program would use the MAC of the PC rather than one that the program gets from the emu's hard coded ascii, but the box code might just rely on the info downloaded form the hub and clearly the box does ask for the MAC address for some reason. And it would kind of explain the observed behavour--you take over the servers attentions with your use of MAC till another user logs on trying to use the same MAC--might be nothing to do with an action on the IKS prov side, just too many folks using the same info.

[abouttosnap]

One more bit of info. Here is the original quote on the expiration error in bold print. Now it doesn't make any since to me but some of you it might. I've seen some areas in the text with errno and also seen test followed by rewind.


Listen guys I did screw up.
I try to place some mechanism to put pressure on the beta issue. And One of the stuff i work was to have a some sort of expiration. I submitted the previous svhub with that expiration ON on error!. Was not intentional. Well it seems that it work pretty well!!! I am sorry.

I did not resubmit a valid new one becouse I was not aware of it. I realize it that Friday night. Then when i try to resolved the issue I found then that my svhub source files where corrupted. Then after an hour of bad time I went to bed. Yesterday I was busy on my personal issues. Hopefully I will submit a new SVhub in the following hours. Hopefully before noon. I need to rework in an old version since my original sources got corrupted. Then I see what I can then do with the router version.

My apologies.

[Jdread]

I personally don't believe a word that was said in that post. I think it would have been better not to have released a post like that or was it intended to ms-lead.

[nunoit]

the problem is in the start of the second socket well that's where it hangs for me anyway. need to look for difference between first socket and second socket. find out whats happening there. slow learner when it comes to coding.


i need to find out why this 360p wont load any files at all ether serial or usb ??? may be bad connection on board i think this fta was in sand lol going to give it a good cleaning today.

[jvvh5897]

Hum....don't think a second socket should be started. Now if there is an error long after the first is started, you close it. Then I think the program tries to phone home to tell the coder of the problem. Then it might try to start a new socket, but odds are that the same number would be used--at least every time I start up a simple client program and printf out the number it is the same. Maybe the bug is that it does not close socket correctly, but that would be hard thing to fix in the code at machine code level IMO. Be easier to start from scratch with source code that you guys write (as we don't have the source code for what you are using).

You could try to eliminate the phone home---if the bug is in that then you might bypass the issue. I could post the code section for that.
----------------------------------------------------
text:00402C5D call sub_403E28 ; create socket and inet "66.***"
.text:00402C62 mov ecx, 51A6EB68h
.text:00402C67 sub ecx, eax
.text:00402C69 mov eax, ecx
.text:00402C6B cdq
.text:00402C6C idiv ebx
.text:00402C6E lea ebp, [eax+4]
.text:00402C71
.text:00402C71 loc_402C71: ; CODE XREF: StartAddress+4C6j
.text:00402C71 pop ecx
.text:00402C72 jmp loc_402DCB ; error writing to serial port
.text:00402C77 ; ---------------------------------------------------------------------------
.text:00402C77
.text:00402C77 loc_402C77: ; CODE XREF: StartAddress:loc_402C29j
.text:00402C77 or ebp, 0FFFFFFFFh
.text:00402C7A jmp loc_402DCB
-------------------------------------------

Not sure what all is going on there. Call to inet to a site, then test a return value that is a bit odd looking and does not seem to jump somewhere as a result but does save a value, but I can't really see that that value is used elsewhere--might be that I don't do intel disassembly a lot. Might be able to just NOP the call and see what happens. Could fake a NOP with push ecx, pop ecx as long as that call is even number of bytes, or maybe do a jump to 402c77 in place of the call--something like that.

[abouttosnap]

I've tried various things but to no avail. Like mac address and port number etc. Of coarse I did manage to make some info vanish and appear in the client window. lol It still ran like before but it also hung like before. Got a hunch it ties back to that ip address 66.***.**.*. Still digging.

[jvvh5897]

Hum..again...I just tried to ping the site that call tries to get hold of and the reply time was pretty long 24 ms while a ping of google was 0 ms.

[nunoit]

jvvh i read your post and makes sense to me what if that call is to make sure that you are still connected to the server, part of the security check that was bypassed in the sv- file. i think a bypass (to satisfy request) or a jump to start over could solve the problem.

connect to server then every 2 min check connection. maybe the problem is not in the emu but in the bin still.
my test is done on sv-4000
now i did log the receive request and the emu response which could show if that is what is going on. i can pm it to you if you think that could help.

[nunoit]

i found this post that talks about maybe a second check in the sv modded bins.
hXXp://www.dssrookie.com/threads/289544-sssp-for-sv4000/page25 post # 250
talks about maybe a second security check if my second thought is right the sv bins need to be modded to work with the emu.

[nunoit]

small progress today i got the wiz110sr uploaded and running. will post else where for all. now to figure out she sv360p why it wont upload files, and play more with the sv-emu.

[jvvh5897]

Last night I took the log of box serial comms and fixed the list of commands and replies so that all that are left are three from the log, the two web comms commands CXR and CXT, and the CXE which seems to be a command to stop the socket and connect with the supplied IP addr. The CXR and CXT are no biggies as you just need to take standard winsock based source code to initialize winsock and start a socket, then in the body of the posted serial code add a couple of statements to deal with sending and receiving with the socket. But that CXE has me a bit confused at the moment, have to think about that one. I can supply the code as it is now and supply an example of how to setup server comms, but not willing to post source of them combined--pretty much think that that is job for someone that can test them on a box.

[jvvh5897]

i found this post that talks about maybe a second check in the sv modded bins.
hXXp://www.dssrookie.com/threads/289544-sssp-for-sv4000/page25 post # 250
talks about maybe a second security check if my second thought is right the sv bins need to be modded to work with the emu.

Well, the tlink file that is the topic for second check are a lot newer than the modded file with security check disabled. If you look at the older tlink files like the tlink15 that was looked at at an earlier point in the thread you only find a single spot with calls to the testing code. The fact that the modded file being used with emu or wiznet device passed the security test shows that it is modded as was needed.

[jvvh5897]

Here is some testing that might tell folks something. I set up com0com to send info from RealTerm to the svhub emu program. Even putting the strings to send to the emu program manually, I found that I could get the type of responces noted in the nunoit captures. Course I did not have internet and a server to connect to so I did get some errors, but by and large is functions OK. Responce to the CXC messages were the most interesting as it closes a socket and opens a new one and those sockets toggle between two numbers:
1297 Server Connected new fd_socket =288
on the first connect and:
1297 Server Connected new fd_socket =332
on the next. Then 288 for the next and then back to 332.

Not sure if that is the type of thing you guys are seeing.

---------------------------------------------------------------------------------

While I had com0com set up I tested that the exe from the source code that I've been playing with to do the serial part of emulation. Found a few bugs and fixed them. Added a atoh to go with the htoa (converting between ascii hex and hex info). Everything looks pretty good now if anyone wants to try it with a box. Even made the command line set the com port used, but figured that folks could just compile it with that they wanted for much of the rest.

[jvvh5897]

Hope I don't get in trouble posting a file here. Figured I might as well post the updated source code for the serial part of emu as well as the compiled exe and it's bat file to get lcc-win32 to do the compile. As pointed out earlier, the code does not do web comms at all, but the code is really close to the point where one could just add 3 parts to get that up: a part to close/open socket, a part to write to web and a part to read from web.

As is, I put a FORCE_EXIT type at the CXC command, so you should be able to see all of the initialization of the dongle to the point that web comms would have to be active.

[It's Jafo]

In the area of the questionable ip (66), has anyone seen the message "Return to large.Socket closing" or to that effect ? Any idea what that might reference ?

[jvvh5897]

My guess would be that the return packet from the server was bigger than the requested return in the CXR command, so rather than retry dale decided to close the socket and try a reconnect. Haven't spotted that string in the exe file though, I'll look around for it.

[nunoit]

Jv back on post 42 you wrote "All we can do is try things and see until someone does wire-shark capture. Would not hurt if someone trys to log box to wizhub comms either." well i just got the thing tested out i will need a snooper wire to get a sample.

i am going to assume this cable would work. i hope that free serial port mon will do the trick

[jvvh5897]

Yep, that is an rs232 "spy" cable--should work just fine. I suspect you will see pretty much the same as your earlier logged files.

I do have a new guess about what is happening. If you look at the logged files you see the box sending CXS before the CXC and if you look at the sequence of how to write a client routine you see a call to socket before a call to connect--I'm wondering if dale put a couple of steps into his CXC that should have been separate--not sure if that really makes a diff though. The real clue is the CXT that sends a:<CXT 2 00A8 that would be an ECM packet of size 0xa8 bytes (with the checksum and final > char) and a receive step expects a 0x40 byte return:<CXR 2 40 but gets a return of 0x2a bytes (looking at the ascii hex and eliminate the <S andfinal > chars then divide by two) and then the box sends a CXF command--now if the CXF means that there was a failure seen by the box, and that CXR was incorrect in size than expected--What happened? My guess is that the box is sending the incorrect cmd07 packets.

In the pansat testing to add coolsat4000's rq-sssp format, two sizes of cmd07 packets were seen, one with the first few bytes looking like: 81 30 A2 07 A0 and another with the first few bytes looking like: 80 30 8F 07 8--so total packet size of a4 or 91 if I'm counting right. The a4 sized packets were filtered out in the added pansat code and only the 0x91 byte packets sent to rq-sssp-client program on the PC. I wonder if the servers don't like taking in the larger cmd07 packets or if they can deal with them but the returned packet does not have the box's expected contents.

Anyway, it might be a box code fix to deal with that if filtering is needed. But if you have to get into box code to do something like this, you might as well mod the box code in other ways--like changing code to do coolsat4000's rq-sssp format.

Still would be good to have wireshark capture to see the way hub to server comms work. I've been looking at the NewCamd protocol and some earlier posted info from dale and what I see going out to server is like newcamd but simpler and I'm not if it is right. I disassembled the rq-sssp-client program and I can see that it uses newcamd protocol. Basically the sv hub is getting the newcamd protocol from the box without the leading command byte and following two bytes--so I'm guessing that it has to add those bytes and I don't see that the emu program is doing so.

[nunoit]

so that would mean that the wiz110sr is ignoring the a4 packets and only the 91 packets are being sent out. from what was seeing during the sample when the it froze the request and received were still going on. near the end point where you see

data read
30 34 33 30 3E 3C 43 58 4B 20 32 37 45 3E 3C 43 0430><CXK 27E><C
58 46 20 32 37 33 3E 3C 43 58 53 20 32 20 31 20 XF 273><CXS 2 1
31 39 37 33 34 36 46 3E 3C 43 58 43 20 32 20 37 197346F><CXC
data write
<F><S><S0028><S
30 38 32 32 44 37 46 32 35 46 42 45 41 41 43 42 0822D7F25FBEAACB
36 33 41 39 42 36 33 41 44 46 35 38 45 46 46 41 63A9B63ADF58EFFA
35 36 38 37 33 36 44 44 45 30 30 37 34 31 37 32 568736DDE0074172
42 35 31 39 41 31 32 32 46 44 35 38 32 38 44 37 B519A122FD5828D7
37 30 39 37 36 34 35 44 35 44 30 37 37 36 38 36 7097645D5D077686

if i am not mistaken that is the point it froze in the data lines i don't know what that tells you. the rest is what showed while frozen.

while looking at the request txt the returned data is twice the size of the other lines look for "Answer: 6/26/2013 10:35:32 AM.98764 (+0.1102 seconds)"

looks to me the returned packet was to large and is what causing emu freeze.
in fact what is happened is it read the same data twice causing the freeze. so some where in the emu it writes twice

some where between the 12th and 13th request.

sorry about all the editing as i am viewing as i write.

[jvvh5897]

I did screw up a little in the last post myself. The size info in the CXR packet is in decimal and I was thinking it was hex unlike the CXT packet size which is in hex. So, that packet size is not that far off--0x2a is 42 decimal and if you look at some other returned packets they often are too big, but the extra bytes are 0x00 bytes. You don't see 0x00 in the extra bytes on that 42 byte sized return.

Reading the newcamd protocol they have added some extra bytes since the early days. Oh, I looked at the box fw for prem and elite and found the e0, e2,e3... login sequence in the code of both boxes, so the code is doing the newcamd protocol, but that does not seem to be visible in the captured data--not sure why.

I also looked in prem fw for where the CXT commands are called for and found 5 calls--looks like most of those are for the fw upgrade via network. Looked around for the ecm handling and did find a little bit of code to do that but not much of it looked familiar. Might help to do a RAM dump of the box, but not sure how to do that at this point--might be able to do it with a mod in the dongle code. Hum....well just typing and not thinking too hard. Might be a good idea to get that serial source code modded to do network and use that as a test bed for further work--might be able to filter the ecm packets there easy. The example netutils based client seems easy enough to insert into that serial code, don't see why someone isn't working on that.

[nunoit]

if you have a script for dumping the 4000 i will try it if you like. you may have to guide me on how to compile it though.

i would say the 360p but that receiver still wont take files ??? strange.

[jvvh5897]

Is this a problem with the sv 4k too? I thought it was just 360p.

I found a spot in the sv360p 28 or 29 svlan file that could be a good place to mod to do a RAM dump. It is the system information menu code. There is a spot that get the remote control code and tests for 21-26 codes to do some other stuff. Now I don't know what those 21-26 key code represent--I would guess up, down, OK and exit or something like that and as you go up or down it shows details for the active line selection. That area of code could be modded to send out the remote control code to figure some of that out I bet. And you could slip a little code in that area of code with a little overwriting, or you could use some location in the data area for code (there are a couple of likely spots in a card dump that I bet is safe to put code in).

sysinfo buttoncode tests:
ROM:005DF05C loc_5DF05C ; CODE XREF: ROM:005DF04Aj
ROM:005DF05C LDR R0, [SP,#0xA8]
ROM:005DF05E CMP R0, #0x21
ROM:005DF060 BEQ loc_5DF06E
ROM:005DF062 CMP R0, #0x22
ROM:005DF064 BEQ loc_5DF0D4
ROM:005DF066 CMP R0, #0x24
ROM:005DF068 BEQ loc_5DF0D4
ROM:005DF06A CMP R0, #0x25
ROM:005DF06C BNE loc_5DF0D6
ROM:005DF06E


example use of UART_Write
ROM:00541D16 ADD R1, R0, R4--buffer addr
ROM:00541D18 ADD R3, R7, #0--timeout
ROM:00541D1A MOV R2, #1--number
ROM:00541D1C MOV R0, #2--port
ROM:00541D1E BL sub_510144 ; UART_Write

spot to put code? part of card dump: ROM:006827E8
just a little past the "DNASP110 RevAC" all 0x00 about 0x90 bytes
or a little further into dump @006871C0

There is even a call to a null sub in the sysinfo code that you can rework easily to call code in the card dump area. And as the sv360p is ARM processor, there is a gcc varient that can compile good code for it.

-------------------------------------------------------------------------------
I bet there is similar code for the sv4k to do the system info page--don't have a thumb drive with me with notes of sv4k though. Bu the sv4k is MIPS based processor, so slightly diferent.

[jvvh5897]

Let's see, the area in code that might be the easiest to mod in the sv4k svlan13 file or 14 file seems to be a menu that lets you control beep frequency/volume option. I found a routine that puts the menu strings on screen and highlights lines as you move on the page--if the right part of the routine is modded, I think you could get a RAM dump as you move to a specific line. Here is an area for the 0xa'th line:
ROM:8016F870 li $t8, 0xA--beep volume line
ROM:8016F874 lw $1, -0x7AD8($gp)
ROM:8016F878 bne $1, $t8, loc_8016F948
ROM:8016F87C nop

------------------------------------------
The usual spot to exit to after doing a specific line is: exit point loc_8016F948
-------------------------------------------

Here is the code that seems to be organizing strings to be displayed:

ROM:8016E7B0 la $t6, off_802D6C5C # remote control 7
ROM:8016E7B8 addu $t7, $t6, $t8
ROM:8016E7BC lw $t9, 0($t7)
ROM:8016E7C0 sw $t9, 0x14($t5)
ROM:8016E7C4 addiu $t7, $sp, 0x1E8
ROM:8016E7C8 addiu $t8, $t7, 0xD8
ROM:8016E7CC la $t6, aSignalBeep # 8
ROM:8016E7D4 sw $t6, 0x14($t8)
ROM:8016E7D8 addiu $t9, $sp, 0x1E8
ROM:8016E7DC addiu $t5, $t9, 0x120
ROM:8016E7E0 move $t8, $s0
ROM:8016E7E4 sll $t8, 2
ROM:8016E7E8 la $t6, off_802D6C90 # 9 beep freq
ROM:8016E7F0 addu $t7, $t6, $t8
ROM:8016E7F4 lw $t9, 0($t7)
ROM:8016E7F8 sw $t9, 0x14($t5)
ROM:8016E7FC addiu $t7, $sp, 0x1E8
ROM:8016E800 addiu $t8, $t7, 0x144
ROM:8016E804 move $t6, $s0
ROM:8016E808 sll $t6, 2
ROM:8016E80C la $t9, off_802D6CC4 # a beep volume
ROM:8016E814 addu $t5, $t9, $t6
ROM:8016E818 lw $t7, 0($t5)
ROM:8016E81C sw $t7, 0x14($t8)
ROM:8016E820 addiu $t5, $sp, 0x1E8
ROM:8016E824 addiu $t6, $t5, 0x168
ROM:8016E828 move $t9, $s0
ROM:8016E82C sll $t9, 2
ROM:8016E830 la $t7, off_802D8B3C # b prev channel
ROM:8016E838 addu $t8, $t7, $t9
ROM:8016E83C lw $t5, 0($t8)
ROM:8016E840 sw $t5, 0x14($t6)
ROM:8016E844 addiu $t8, $sp, 0x1E8
ROM:8016E848 addiu $t9, $t8, 0x18C
ROM:8016E84C la $t7, aRadioScreenSav # c
ROM:8016E854 sw $t7, 0x14($t9)


-----------------------------------------
Now the routine that seems to use the serial port:
801C5518 # write to dongle w/timeout
might be the one to call to do a dump but
801C6194 # comm to network adapter
also seems to have serial port write, so maybe one maybe another.

Maybe with a little testing you could figure it out.

[nunoit]

my test 360p fta wont take bins through serial or usb i opened up and feel there may be cold solder joints on the cpu. so i am going to try a re-flow with my iron. to see if that fixes things.

the only fta i have for testing with is the 4000.the info i got is from that so far.i will make that cheater cable and post results.

[jvvh5897]

here is a possible way to dump RAM from sv4k using the beep volume line:

Find 8016F760 with searchterm : 34 0D 00 09 8F 81 85 28 --looks more like beep volume to me

ROM:8016F770 8F B9 00 20 34 18 00 13 17 38 00 14 00 00 00 00
ROM:8016F780 27 AE 00 6C 25 CF 00 24 8D ED 00 00 29 B9 00 6E
ROM:8016F790 13 20 00 08

Try a change to (starting at 8016f770):
27 85 00 00 34 04 00 01 3C 06 00 01 34 07 00 64
0C 07 15 46 00 00 00 00 17 38 00 11

that 3C 06 00 01 is lui $a2, 0x1 which loads the upper 16 bits of $a2 with the value 1 which is the same as loading it with 0x10000
27 85 00 00 loads the buffer addr with the value of $gp, which is just above the file area and the start of RAM that is likely of interest.

You are calling something that looks very like the UART_Write noted for sv360p:
example:
ROM:801ADCB8 addiu $a1, $sp, 0x38+var_29--buffer
ROM:801ADCBC li $a0, 1--port number I think
ROM:801ADCC0 li $a2, 1--number of bytes I think
ROM:801ADCC4 li $a3, 0x64--timeout
ROM:801ADCC8 jal sub_801C5518 # write to dongle w/timeout

[nunoit]

i see in the emu file .data:0040561F aOjoEncontreCom db '******************OJO encontre commando pero sigue abiendo mas da'

says
oJo= eye found command but need more data. don't know if that makes sens to you. also found something odd to me, i see data:004052E0 aSvhub_log_txt db 'svhub_log.txt',0 ; DATA XREF: sub_401468+3Bo but in the menu there is no log file. should we have some location and size for a log if we are making one.

[jvvh5897]

I think the emu program was written in steps, like the posted serial source here it was built first by dale, then as things progressed, more was written and debugging went on. Some of what is left in the emu program was bypassed but the code stayed in. And then there is the problem that the code was written on a linux machine and then ported to windows with cygwin--lots of calls are in there to do the support needed for that. The core of the program though is the serial tests for "<" and ">" chars and commands, and the web socket/connect/recv and send with conversion from ascii hex to hex and hex to ascii hex.

I seem to recall in the thread on the emu that there was a post about if he should leave logging on or turn it off--might have been in the NF thread in advanced section here rather than sv one at the other site. He might have used the NF emu as base for sv too.

BTW, do all the sv boxes use the same loader program? I see zmodem strings in the sv4k but not in the sv360p program. And the serial port has been taken over to some extent to support the hub, so I think the boot is the more reliable way to update the fw--you know turn the box on just as you start the download to box.

[nunoit]

as for trying to load the 360 i have read that they use the same loader. which works on the 4000 does not seem to work for the 360
but the 360 is supposed to load via thumb drive also and wont. i will probably need a manual for it. all i know is so far no luck loading.

if the emu is supposed to mimic the wiz110sr whats the wiz do that the emu is not doing. i know the wiz does not need a set server receiver does that.

[nunoit]

i decided to try a slightly different route i went and reloaded my other laptop and going to try dale's method with code blocks and cygyn. once i get that to fire up right i will keep experimenting.

[nunoit]

having problem setting up code blocks the way suggested. here http://www.satfix.net/showthread.php?131844-Basic-Intro-to-Compiling-in-C post's 1, 6, 7, and 8,

now the versions i have are higher then the ones he says i have cygwin 4.7.3-1 and code blocks is ver 12.11

did search for gcc-3.exe not found. changed search to gcc found a crap load which is the compiler.??

when i start code blocks i get gcc-3.exe compiler not found

i have icon on desk top which properties comes up as C:\cygwin\bin\mintty.exe -i /Cygwin-Terminal.ico -

question is, is mintty.exe the compiler or the what. when i click on icon terminal window pops up.

how do i find the compiler exe. i know dumb question i am new to this.

[jvvh5897]

Well, mintty is likely a mini tty program. tty == rs232 serial comunication terminal emulator--which is just a fancy way of saying it lets you use the serial port.

Anything that uses cygwin is likely compiled with gcc or cpp as cygwin is a windows emulation method that that the linux folks developed to let them run applications built on linux platforms with windows PCs. For the hub emu program cygwin lets the serial communications methods that linux uses interface with the way that windows (above winNT) allows. If you look in the source code I posted for serial comms you see the OpenFile command?--that is what windows requires, but linux will let you just write to the serial port chip.

[nunoit]

may be i should try to find an older version of cygwin ver 3.?.?. might make my instillation easier.

[nunoit]

well i got it configured and compiling. the script you posted over there the cksum test works only if i run in code blocks. if i try with win i get dll error i git the dll and then it runs for split second with different results then shuts down.

i guess i am asking was this supposed to compile a win exe. or linux exe. BTW: even the simple hellow world compiled the same way. it wont execute in win xp sp3. what do you think i did wrong.

[jvvh5897]

If you are trying to compile anything that I have posted C source code for, then you should be using lcc-win32 to compile as pointed out in most of my posts. Most likely all you want to compile the source to is a console type program--not windows per se but you have to run it under windows (my PC is running win2k). I have no idea what code blocks is or what you are really trying here so I'm not able to give you any advice on what you are doing.

[nunoit]

loaded lcc-win32 need to start to practice. some c code.

[jvvh5897]

There is a tutorial pdf for lcc-win32. One site has source code that has been compiled under lcc-win32 so you know it will do so for you. Another site has opengl examples and lcc-win32 is one of the compilers that they have source for. I like to take interesting source code for things I have interest in and make them work under lcc-win32--that is how I got hexv, a flocking example, and a plasma routine or two running so I could play with the code.

Here is the client source modded to compile under lcc

#include<windows.h>
#include <stdio.h>
#include <sys/types.h>
#include<winsock.h>
//#include "netutils.h"
//#include <sys/socket.h>
//#include <netinet/in.h>



#define bcopy memcpy
#define bzero(arg1,arg2) memset(arg1,arg2,0)

int main(int argc, char *argv[])
{
int portno, n;
SOCKET sockfd;
WSADATA wsaData;
struct sockaddr_in serv_addr;
struct hostent *server;

char buffer[256];

if (argc < 3) {
fprintf(stderr,"usage %s hostname port\n", argv[0]);
exit(0);
}


if (WSAStartup(MAKEWORD(2,1),&wsaData) != 0){
return GetLastError();
}

portno = atoi(argv[2]);
/* Create a socket point */
sockfd = socket(AF_INET, SOCK_STREAM, 0);
if (sockfd == 0)
{
perror("ERROR opening socket");
exit(1);
}
printf("sockfd = %d\n",sockfd);
server = gethostbyname(argv[1]);
if (server == NULL) {
fprintf(stderr,"ERROR, no such host\n");
exit(0);
}

bzero((char *) &serv_addr, sizeof(serv_addr));
serv_addr.sin_family = AF_INET;
bcopy((char *)server->h_addr,
(char *)&serv_addr.sin_addr.s_addr,
server->h_length);
serv_addr.sin_port = htons(portno);

/* Now connect to the server */
if (connect(sockfd,&serv_addr,sizeof(serv_addr)) < 0)
{
perror("ERROR connecting");
exit(1);
}
/* Now ask for a message from the user, this message
* will be read by server
*/
printf("Please enter the message: ");
bzero(buffer,256);
fgets(buffer,255,stdin);
/* Send message to the server */
n = send(sockfd,buffer,strlen(buffer),0);
if (n < 0)
{
perror("ERROR writing to socket");
exit(1);
}
/* Now read server response */
bzero(buffer,256);
n = recv(sockfd,buffer,255,0);
if (n < 0)
{
perror("ERROR reading from socket");
exit(1);
}
printf("%s\n",buffer);
closesocket(sockfd);

WSACleanup();
return 0;
}


You can use the lcc IDE to do the compile. I tend to use a bat file from the command line like:

set path=c:\lcc\bin;c:\lcc\include;c:\lcc\lib
lcc.exe netutil_client.c

lcclnk.exe -o netutil_client.exe -subsystem console -s netutil_client.obj netutils.lib
ECHO Finished!

I used the above to compile the netutilities client source code lifted from the lcc-win32 tutorial:


#include <stdio.h>
#include <stdlib.h>
#include "netutils.h"

int main(int argc,char *argv[])
{
Session session;
char buf[256];
memset(&session,0,sizeof(session));
session.port = 25876;
session.Host = "127.0.0.1";
if (ClientConnect(&session)) {
printf("Unable to connect\n");
goto end;
}
if (Send(&session,5,"data")) {
printf("Unable to send\n");
goto end;
}
if (Receive(&session,5,buf)) {
printf("Unable to receive\n");
goto end;
}
buf[session.BytesReceived] = 0;
printf("Received %d bytes: %.5s\n",
session.BytesReceived, buf);
end:
CloseSession(&session);
}

And a very similar bat file to compile the server netutil example:


#include <stdio.h>
#include "netutils.h"
int main(int argc,char *argv[])
{
Session session;
char buf[8192];
memset(&session,0,sizeof(session));
session.port = 25876;
session.Host = "127.0.0.1";
if (ServerConnect(&session))
return 0;
printf("Connected...\n");
memset(buf,0,sizeof(buf));
if (Receive(&session,sizeof(buf)-1,buf))
return 0;
printf("received request\n");
printf("data is: %s\n",buf);
if (Send(&session,5,"data"))
return 0;
CloseSession(&session);
}

For the first example you would not need to have the lib file part in the bat file, but for the two netutil examples you do.
Just a quick replace step under Notepad can change the name of the c program from netutils_client to the server c file BTW.

[It's Jafo]

Not knowing any where near what you guys know.... I was thinking about that ip addy in the file.
Being that the file was made using an existing Svlan file, could that Ip be the ip for the old Akai Japan Server that's in slot one under "Network settings" ? The ip you never had to enter to connect to that server.
Just kicking ideas around....

:)

[nunoit]

i have bin trying to follow the tutor i don't know if i setup lcc-win32 the right way. some of the examples the use seem to work meaning they compile and seem to execute. but i don't know if i am doing it right. i have tried to copy and past scripts, program wont let me. so i guess i am still trying configure the settings for lcc.

i am just hoping that by the end of this tutor i will have learned some real c code. not just playing follow the leader. this tutor i got is 325 pages. i still getting used to the way its being taught. like this example of yours

int main(int argc, char *argv[])
{
int portno, n;
SOCKET sockfd;
WSADATA wsaData;
struct sockaddr_in serv_addr;
struct hostent *server;

i know it something to do with setting up serial port. my problem is knowing what commands to use, in what order to use them.

where are all these lists. do i need them. should i just use other peoples examples and play with that.

#include<windows.h>
#include <stdio.h>
#include <sys/types.h>
#include<winsock.h>
//#include "netutils.h"
//#include <sys/socket.h>
//#include <netinet/in.h>

maybe i am just trying to hard to learn. i have lots of questions just not many answers.

[jvvh5897]

The double // turns a line into a comment line, anything after // is ignored. /* at the start of a section and */ at the end makes the whole section a comment and so it is ignored.

I have no real idea of what order commands have to be in either, I just copy/use existing source code examples and mod the parts that I need to and see if they compile and run as I wanted.

The #include items are there to let you use commands that they tell the compiler/linker how to use. stdio supports the input/output routines. windows is needed for the OpenFile stuff. winsock supports the socket and network comms stuff. Leave an include out and the compiler or linker will give you an error about and un-referenced instruction.


but i don't know if i am doing it right. i have tried to copy and past scripts, program wont let me.
The program won't let you?--not sure what you mean, you paste like one would in NotePad. If you mean that once pasted in, the code will not compile, then there is something that you are not doing that you should--without seeing error messages hard to say what that would be. Remember the programs generated are console programs, so you need to run them from a command window--go to "start" button and enter in "cmd" or "command" in the window that pops up, navigate to the folder with your program in it and type the name of the program in at the command prompt.

If I wanted to test a server/client pair of programs, I would either use two computers or get someone to test with. One PC runs as server and the other as client--they have to be linked with internet or directly linked with a cat5 cable.

[nunoit]

i am going to take some advice and maybe start a new thread on basic programming in c for beginners. that way i might a better grasp on being able to do mods more proficiently. i will keep following this thread and as soon as i build the snooper i will post info for viewing.

[nunoit]

Well the MAC addr should be easy to mod, at least the one that I can make out and just ascii characters.
MAC addr:
@405F55 in disassembly or 0x515A in file:
<S00.90.BC.0F.00.01>
Now, I would think a PC program would use the MAC of the PC rather than one that the program gets from the emu's hard coded ascii, but the box code might just rely on the info downloaded form the hub and clearly the box does ask for the MAC address for some reason. And it would kind of explain the observed behavour--you take over the servers attentions with your use of MAC till another user logs on trying to use the same MAC--might be nothing to do with an action on the IKS prov side, just too many folks using the same info.

in reading this make me think a little. what if the receiver is asking for the dongals mac address not the servers and the emu does not know what to return to receiver. which lead me to think what if the receiver bin needs to be modded. to not ask for the mac address. and see if that cures the problem with the emu. or mod the emu to give the computers mac address as the return when the receiver ask's for it.

just hashing things out

[jvvh5897]

The listed MAC is the one returned from the emu program. I suspect it is the one that the box will think is the dongle's. I don't know if it is used in any way by the program or box --pretty much would have to do a capture of the web comms to know that. And you would likely have to force the emu/box to use a specific des key so that you could view all the packet contents, though MAC would be in the packet header and not encrypted.

[nunoit]

could we remove the mac request from the receiver bin and see what that does. what do you think would happen??? its testing right. trial and error, slowly one removes all other possibilities.

[jvvh5897]

It would be easier to change the mac in the pc program, it is easy to find. Maybe try all zeros or put in the mac from your computer.

[nunoit]

took a look for the mac in ida found where i think it is and think what it should be changed to

from
00405F55 3C 53 30 30 2E 39 30 2E 42 43 2E 30 46 2E 30 30
00405F65 2E 30 31 3E 00

to
00405F55 3C 53 30 30 2E 30 30 2E 30 30 2E 30 30 2E 30 30
00405F65 2E 30 30 3E 00

now i may be wrong but that's how we learn. i have not tested yet this lappy does not xvi32 nor hexworkshop loaded.

update loaded programs made 2 versions one 00 mac one mine. may test both tomorrow. tested 00 mac with out serial adapter and receiver connected went well so far.

[nunoit]

i had a few minutes an tested the mac changes made no difference. still stopped at socked 324. i start at socked 300, emu it runs till it closes socked then restarts at 324 where it hangs.

[nunoit]

while looking through the emu i found where i changed

00405F55
then i found text:00403E9D push offset a**_232_**_8 ; "66.***.97.*" which google tells me its Tampa FL
i think that address is hard coded. that spot looks interesting to look for lock up problem may be a nop somewhere in those lines.

or changing the push to call ihub.cfg server ip. i will look to see if i can find that line in the code. or even change to jmp to the line once i find it.

these address have ip in them
405F55
403E9D
04018F1
and this is the call to ihub.cfg
4021E5

[jvvh5897]

My best guess on what is going wrong in the hub program right now is the way it handles the CXC command (at least that is what I think the command was--time has passed and it is not as clear any more). From what I see, the program when it gets that command from box, shuts down the current socket and starts another. I don't think that should be what it does--maybe the first time it sees the command but not every time after that. The IKS server is listening on the socket you start with and when you shut down that socket and start a new one, you have to handshake the DES key all over again and all the other startup handshaking needed for an IKS session. I don't see that the box is doing that handshaking, so that is not what the hub emulation should be doing in response to CXC.

[nunoit]

can we by pass the cxc command or change the emu to ignore the command. we can see how it reacts with a test.

[jvvh5897]

I'm sure you can in some fashion or another. The code does a series of tests on the command from the box and the reply for the cxc is just "s", find the spot where the test is for cxc and force it to jump to send out the s response--that is kind of a default response to a number of commands.

[nunoit]

thanks i will look to see what i can find

quick look i found.

.text:00401442 push offset aCxc216s5d6a ; "<CXC 2 %16s %5d6A>"

.data:004051A3 aCxc216s5d6a db '<CXC 2 %16s %5d6A>',0 ; DATA XREF: .text:00401442o

now what to do if i got it right.

[jvvh5897]

What I've posted before is where the code tests for CXC, I've copied off disassembly from the area:


text:00402837 cmp al, 43h ; is this <CXC ?
.text:00402839 jnz loc_4029B9 ; is this <CXE ?
.text:0040283F cmp ds:dword_408320, 0Eh
.text:00402846 jnz short loc_402868 ; close session
.text:00402848 cmp ds:dword_408008, 1
.text:0040284F jnz loc_402DAB
.text:00402855 push 0Eh
.text:00402857 push offset aKey_logging_le ; "\n key_logging_lenght =%d\n"
.text:0040285C call printf
.text:00402861 pop ebx

.text:00402DAB push 3 ; <WX> and <WW> handling
.text:00402DAD push offset aS_1 ; "<S>"
.text:00402DB2 jmp short loc_402DBB ; we need to send a reply to box

What you might try is to force the code from the
.text:0040283F cmp ds:dword_408320, 0Eh
.text:00402846 jnz short loc_402868 ; close session
to jump to 402DAB

Search term for the above two commands: 40283F: 83 3D 20 83 40 00 0E 75 20 with the last two bytes the jnz
Change 75 20 to EB 1B will force the code to jmp short to a line that jmp to required addr. You could NOP the cmp if you want (NOP is just 0x90).

[nunoit]

will give that a try later i have my daughter and grand kids here i haven't seen in 3 years

[nunoit]

here you go the first is jump. second emu.

first
Read from ihub.cfg
modemdevice=/dev/ttyS3
server_socket_ip=***.**.***.***
server_socket_port=*****
network_timeout=1000
tr_delay=40000
************************************************** **********************
modemdevice=/dev/ttyS3
fd_serial=3
0350 Starting Serial Pthread
0363 Server thread launched
0376 Continue after Starting Serial Pthread

Initialising Winsock...
Initialised.

it starts and only gets to above. same result with nop

i close the above and start the emu and i get

Read from ihub.cfg
modemdevice=/dev/ttyS3
server_socket_ip=***.**.***.***
server_socket_port=*****
network_timeout=1000
tr_delay=40000
************************************************** **********************
modemdevice=/dev/ttyS3
fd_serial=3
0350 Starting Serial Pthread
0363 Server thread launched
0376 Continue after Starting Serial Pthread

Initialising Winsock...
Initialised.
Closing Previous Server Session
Small Wait before next Server Session
*0*1*2*3*4*5*6*7*8*9
[Newcamd] Successfully connected to server.
1297 Server Connected new fd_socket =300
1334 Socket thread Staring
1354 Socket thread launched


************************************************** ******************************
*****************
******************************* Socser Thread Starting ***********************
*****************
************************************************** ******************************
*****************
1516 fd_socket=300
*0*1*2*3*4*5*6*7*8*9
*0*1*2*3*4*5*6*7*8*9
*0*1*2*3*4*5*6*7*8*9
*0*1*2*3*4*5*6*7*8*9
*0*1*2*3*4*5*6*7*8*9
*0*1*2*3*4*5*6*7*8*9
*0*1*2*3*4*5*6*7*8*9
*0*1*2*3*4*5*6*7*8*9
*0*1*2*3*4*5*6*7*8*9




Closing Previous Server Session
************************************************** ******************************
*****************
******************************* Socser Thread Closed**************************
*****************
************************************************** ******************************
*****************
Small Wait before next Server Session
*0*1*2*3*4*5*6*7*8*9
[Newcamd] Successfully connected to server.
1297 Server Connected new fd_socket =316
1334 Socket thread Staring
1354 Socket thread launched


************************************************** ******************************
*****************
******************************* Socser Thread Starting ***********************
*****************
************************************************** ******************************
*****************
1516 fd_socket=316
*0*1*2*3*4*5*6*7*8*9
*0*1*2*3*4*5*6*7*8*9
*0*1*2*3*4*5*6*7*8*9
*0*1*2*3*4*5*6*7*8*9
*0*1*2*3*4*5*6*7*8*9
************************************************** ******************************
*****************
******************************* Socser Thread Closed**************************
*****************
************************************************** ******************************
*****************
*0*1*2*3*4*5*6*7*8*9
Socket created.
A litle Wait.. i=48*0*1*2*3*4*5*6*7*8*9 52012977 (at this point i be leave it stops communicating)




Closing Previous Server Session
Small Wait before next Server Session
*0*1*2*3*4*5*6*7*8*9
[Newcamd] Successfully connected to server.
1297 Server Connected new fd_socket =332
1334 Socket thread Staring
1354 Socket thread launched


************************************************** ******************************
*****************
******************************* Socser Thread Starting ***********************
*****************
************************************************** ******************************
*****************
1516 fd_socket=332
*0*1*2*3*4*5*6*7*8*9 (frozen)

there must be another spot that needs the jump. will look

[nunoit]

where can i get a list of commands like ebp, esp. it would make it easier to follow

[jvvh5897]

I would suspect you modified a spot in code that was not the suggested addr.

As for where to get intel 80x86 instruction set--google.

[nunoit]

you suggested to mod 83 3D 20 83 40 00 0E (75 20) to (eb 1b) and or change (83) to (90) and neither worked. as for the op-codes i did not know they were intel instruction set thanks. i will look that up.

also i tried to change the server ip at 4018F1 to the one i am testing with. and would not take because i did not format it right and the one posted is 10 digits and the one i have is 11.

there are 2 different address one at 403E9D the other at 4018F1 i think one of those calls could be an issue. trying to contact a different server then the one your connected to. if that is the case then a address change a jump or a nop might work.

also i was thinking of doing something that sounds dumb kinda. change clock to 2012 and then see if dales expiry date comment is an issue. i see it calls the time for the log which may be working even though its not seen. it seems time may be a factor as it works for so much time then restarts and locks up.

tried it still froze time did not make a difference.
thinking out loud.

[nunoit]

looking through there is allot of press enter to continue. yet all those seem to be bypassed. can that be turned back on maybe we can spot exactly where the hangup is big deal if you have to press keys just to run the exe.

[jvvh5897]

Why not just complete the source code?

As for the mod spot--I recomended an addr to mod and gave you a search term to help you find it, the search string might just get more than one spot in code--I did not check.

[nunoit]

completing the source code as you know will take me at least a year as you know i am very slow. that's why i haven't gone that way. i don't have even a 10th of the knowledge you have with code. also the source code you pointed out would not work with my usb to serial adapter on com 4 as i pointed out earlier some kind of error popped up. but if you think that would be the better way i will try.

otherwise i will look for the addr and search term you mentioned. of course i will need to re-read the posts and do to comprehension problem of mine can and will take time.

as always thank you for helping this old fart learn something new. the mind is a terrible thing to wast.
nunoit

[nunoit]

well i have gone through the post's and marked some pages of interest. i am going to create a new post to discuss how complete the source code. if i am right in thinking all the pieces of the code have already bin posted. its just a matter of combining them and compiling to test finished product. new post found here. http://www.satfix.net/showthread.php?138355-scripting&p=980740#post980740

looking any posts at rookies don't seem to find any.